Все как в жизни.
Предыстория
В классических методологиях роли владельца продукта не было. Впервые роль владельца продукта появилась в Scrum фреймворке. До этого ближайшей по смыслу ролью была роль менеджера проекта в методологии PMI PMBoK. Роль менеджера проекта содержала в себе ряд противоречий и конфликтов интересов:
- Менеджер проекта отвечал и за команду, и за отношения с заказчиком. К сожалению, интересы заказчика противоречат интересам команды.
- Менеджер проекта отвечал только за стадию создания продукта. Менеджеру проекта все равно что будет потом, главное закончить в срок проект с нужными свойствами, качеством и уложиться в бюджет.
- Менеджер проекта не обязан знать как продавать и продвигать продукт. Отсюда — столько провалившихся на рынке, но формально успешных (выполненных в срок и уложившихся бюджет) проектов.
Решая эти проблему, создатели Scrum:
- Разделили роль менеджера проекта на две: Scrum мастер, которые заботится о команде, этакая строгая, но любящая нянька, и владелец продукта.
- Сделали так, что ответственность владельца продукта не заканчивается на завершении разработки, а продолжается в период коммерческой эксплуатации.
- Решили, что в компетенции владельца продукта входят: маркетинг, продажи, знания бизнеса и предметной области.
Кто такой владелец продукта?
Владелец продукта – это универсальный солдат, который понимает, что такое разработка ПО; знает жизненный цикл разработки; представляет, как продвигать и продавать продукт, понимает конъюнктуру и тенденции целевого рынка; знает UI и UX; умеет предсказывать и измерять ключевые метрики продукта.
История идеального владельца продукта могла бы звучать так:
- Работал в ИТ разработчиком, проектировщиком или дизайнером.
- Благодаря коммуникативным и лидерским качествам, что в ИТ редкость, дорос до руководителя проекта.
- Не остановился на этом и начал развиваться в сторону бизнеса, маркетинга, продаж.
Но, это в идеале, а на практике: любой, кому приходят в голову «замечательные идеи» считает себя владельцем продукта. Причем, когда эти идеи не выстреливают, можно спихнуть вину на разработку, дизайнеров, маркетинг или продажи.
7 грехов владельца продукта
- Не выдвигает измеримые бизнес гипотезы. Т. е. если реализуем эту фичу, то получим такую выгоду: увеличим конверсию на n%, уменьшим стоимость пользователя на m рублей, заработаем столько-то денег. Причем, нужно не только назвать произвольные значения метрик, но и обосновывать эти значения.
- Не объясняет команде цели изменений. Если исполнитель не понимает или не разделяет цели, то возникают две проблемы: исполнитель делает не то, что хотел владелец продукта; делает это плохо и медленно. Кроме того, команда – первичный цензор идеи. Не можешь доказать команде ценность идеи, задумайся, а есть ли в идее смысл.
- Не участвует в реализации. Если владелец продукта не проверяет артефакты: пользовательские истории, прототипы, блок-схемы, результат, то получает не то, что он хотел.
- Не участвует в приемке. Владелец продукта должен принимать готовые изменения еще до специалистов по тестированию, чтобы убедиться, что сделали то, что нужно и в нужном качестве.
- Не проверяет результаты. Выдвинув измеримые бизнес гипотезы, проверьте, получилось достигнуть прогнозных результатов или нет. Т. е. сверьте план с фактом.
- Не делает выводы. После внедрения изменений нужно не только сравнить план с фактом, но и понять причину, почему достигли или не достигли этих результатов. В будущем постараться усилить положительные результаты и нивелировать отрицательные.
- Не думает о том, что будет с продуктом в будущем. Кто и как будет поддерживать, развивать и продавать продукт.
Идеальный владелец продукта
Уберите частицу «не» из предыдущего списка и получите идеального владельца продукта.
Советы
- Чем больше вы знаете о смежных областях, бизнесе, предметной области, конкурентах, тем легче найти хорошую идею.
- Чем больше вы сделали успешных фич, тем большим авторитетом пользуетесь у команды и заказчика. В какой-то момент авторитет начнёт работать на вас.
- Приносите пользу всем – заказчику успешные фичи, команде ништяки.
