29.06.2018 13:43
SqPiglet 3 2200 Источник
Фаза 2

Все как в жизни.


Предыстория


В классических методологиях роли владельца продукта не было. Впервые роль владельца продукта появилась в Scrum фреймворке. До этого ближайшей по смыслу ролью была роль менеджера проекта в методологии PMI PMBoK. Роль менеджера проекта содержала в себе ряд противоречий и конфликтов интересов:


  1. Менеджер проекта отвечал и за команду, и за отношения с заказчиком. К сожалению, интересы заказчика противоречат интересам команды.
  2. Менеджер проекта отвечал только за стадию создания продукта. Менеджеру проекта все равно что будет потом, главное закончить в срок проект с нужными свойствами, качеством и уложиться в бюджет.
  3. Менеджер проекта не обязан знать как продавать и продвигать продукт. Отсюда — столько провалившихся на рынке, но формально успешных (выполненных в срок и уложившихся бюджет) проектов.

Решая эти проблему, создатели Scrum:


  1. Разделили роль менеджера проекта на две: Scrum мастер, которые заботится о команде, этакая строгая, но любящая нянька, и владелец продукта.
  2. Сделали так, что ответственность владельца продукта не заканчивается на завершении разработки, а продолжается в период коммерческой эксплуатации.
  3. Решили, что в компетенции владельца продукта входят: маркетинг, продажи, знания бизнеса и предметной области.

Кто такой владелец продукта?


Владелец продукта – это универсальный солдат, который понимает, что такое разработка ПО; знает жизненный цикл разработки; представляет, как продвигать и продавать продукт, понимает конъюнктуру и тенденции целевого рынка; знает UI и UX; умеет предсказывать и измерять ключевые метрики продукта.


История идеального владельца продукта могла бы звучать так:


  1. Работал в ИТ разработчиком, проектировщиком или дизайнером.
  2. Благодаря коммуникативным и лидерским качествам, что в ИТ редкость, дорос до руководителя проекта.
  3. Не остановился на этом и начал развиваться в сторону бизнеса, маркетинга, продаж.

Но, это в идеале, а на практике: любой, кому приходят в голову «замечательные идеи» считает себя владельцем продукта. Причем, когда эти идеи не выстреливают, можно спихнуть вину на разработку, дизайнеров, маркетинг или продажи.


7 грехов владельца продукта


  1. Не выдвигает измеримые бизнес гипотезы. Т. е. если реализуем эту фичу, то получим такую выгоду: увеличим конверсию на n%, уменьшим стоимость пользователя на m рублей, заработаем столько-то денег. Причем, нужно не только назвать произвольные значения метрик, но и обосновывать эти значения.
  2. Не объясняет команде цели изменений. Если исполнитель не понимает или не разделяет цели, то возникают две проблемы: исполнитель делает не то, что хотел владелец продукта; делает это плохо и медленно. Кроме того, команда – первичный цензор идеи. Не можешь доказать команде ценность идеи, задумайся, а есть ли в идее смысл.
  3. Не участвует в реализации. Если владелец продукта не проверяет артефакты: пользовательские истории, прототипы, блок-схемы, результат, то получает не то, что он хотел.
  4. Не участвует в приемке. Владелец продукта должен принимать готовые изменения еще до специалистов по тестированию, чтобы убедиться, что сделали то, что нужно и в нужном качестве.
  5. Не проверяет результаты. Выдвинув измеримые бизнес гипотезы, проверьте, получилось достигнуть прогнозных результатов или нет. Т. е. сверьте план с фактом.
  6. Не делает выводы. После внедрения изменений нужно не только сравнить план с фактом, но и понять причину, почему достигли или не достигли этих результатов. В будущем постараться усилить положительные результаты и нивелировать отрицательные.
  7. Не думает о том, что будет с продуктом в будущем. Кто и как будет поддерживать, развивать и продавать продукт.

Идеальный владелец продукта


Уберите частицу «не» из предыдущего списка и получите идеального владельца продукта.


Советы


  1. Чем больше вы знаете о смежных областях, бизнесе, предметной области, конкурентах, тем легче найти хорошую идею.
  2. Чем больше вы сделали успешных фич, тем большим авторитетом пользуетесь у команды и заказчика. В какой-то момент авторитет начнёт работать на вас.
  3. Приносите пользу всем – заказчику успешные фичи, команде ништяки.

Комментарии (3)


  1. uzverkms
    29.06.2018 18:17
    #18831099

    Автор, для чего вы написали этот текст? Какую проблему пытаетесь решить? Проджект менеджер — это очень плохо?
    У вас куча ошибок и противоречий в тексте. К тому же вы придумываете проблему, а потом героически её опровергаете.

    в методологии PM BOOK
    В первой же главе Свода знаний по управлению проектами сказано, что это не методология. Методология — это система практик, методов, процедур, и правил, используемых в определенной сфере деятельности. PMBoK является основой, на которой организация может разработать свои методологии, политики, правила, процедуры и т.д., необходимые в практике управления проектами. В самой свежей, шестой редакции книги, появились отдельные разделы с рекомендациями по адаптации предложенных практик к специфике организации. К тому же прямым текстом сказано, что предложены описательные, а не директивные практики.

    Роль менеджера проекта содержала в себе ряд противоречий и конфликтов интересов
    Существует Кодекс профессиональной этики и поведения PMI pmi.ru/about/code.php И там сказано:

    Конфликт интересов.
    Ситуация, возникающая в случае, когда специалист по управлению
    проектами должен принять решение или произвести какое-либо действие, которое принесет
    выгоду специалисту по управлению проектами или лицу или организации, по отношению к
    которым у него есть обязательство быть лояльным, и в то же время нанесет вред другому
    лицу или организации, по отношению к которым у специалиста по управлению проектами
    есть аналогичное обязательство быть лояльным. Единственный способ для специалиста по управлению проектами разрешить конфликт – предоставить разрешение конфликта на усмотрение затрагиваемых сторон и позволить им решить, каким образом в данной ситуации должен действовать специалист по управлению проектами.

    В случае конфликта интересов
    4.3.1
    Мы заблаговременно и полностью информируем соответствующие стороны о фактах
    возникновения конфликта интересов – реального или потенциального.
    4.3.2
    Если обнаруживается, что мы имеем дело с реальным или потенциальным
    конфликтом интересов, мы воздерживаемся от вмешательства в процесс принятия решений или влияния на исход каким-либо иным образом до тех пор, пока: мы полностью не проинформировали участников проекта, интересы которых были задеты; мы не утвердили план уменьшения вреда и не получили согласия участников проекта на принятие мер.

    1. Менеджер проекта отвечал и за команду, и за отношения с заказчиком. К сожалению, интересы заказчика противоречат интересам команды.
    Почему противоречат-то? Основная проблема — когда заказчик не может остановиться в формулировании своих желаний. И тут надо поступать в зависимости от задачи и контекста — либо принимать расширение задачи при увеличении бюджета и/или сроков, или изначально предлагать гибкие варианты разработки/контрактования. Тогда любой каприз — за счет заказчика. И команда довольна и заказчик.

    2. Менеджер проекта отвечал только за стадию создания продукта. Менеджеру проекта все равно, что будет потом, главное закончить в срок проект с нужными свойствами, качеством и уложиться в бюджет.
    Это важнейшее свойство project manager-а, не позволяющее проекту расползаться и в результате разваливаться. Проджект может не только создавать продукт, он может отвечать и за другие стадии жизненного цикла продукта.

    И такое ограничение ответственности как раз нужно для того, чтобы избежать конфликта интересов между ролями продакта и проджекта.

    3. Менеджер проекта не обязан знать, как продавать и продвигать продукт. От сюда столько провалившихся на рынке, но формально успешных (выполненных в срок и уложившихся бюджет) проектов.
    Я понимаю о чём вы. Но PMBoK учит нас, что кроме бюджета, сроков и содержания работ было бы неплохо выяснить критерий успешности проекта для заказчика. Если в качестве критерия успешности внешнего коммерческого проекта обозначить получение прибыли (не менее x % или по какой-то другой метрике), то менеджер проекта будет очень заинтересован в продаже проекта.


    1. SqPiglet Автор
      29.06.2018 21:12
      #18831695

      Спасибо за указание на ошибки.


  1. Yu_Sh
    30.06.2018 03:07
    #18832269

    На самом деле идея разделить управление продуктом и управление командой — достаточно древняя, не стоит говорить, что до Scrum ничего подобного не было. Ещё в MSF (1994) был «менеджер продукта».