Когда говорят 'Сделай хорошо': Рекомендации для разработчиков по улучшению процесса

[VladA1982]

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

1. Почему вообще продуктовый менеджер должен быть подчинён руководителю разработки? Сама постановка вопроса мне кажется абсолютно некорректной.
   
   ИМХО, человек, определяющий, что должно быть разработано, стратегию создания и развития продукта, не может починяться человеку, определяющему, как это будет разработано, тактику разработки продукта. Это как начальника цеха ставить руководителем директора завода. Абсурдно.

2. Как у команды по разработке продукта могут быть разные цели с продуктовым менеджером? Если у руководителя разработки цель не в том, чтобы выпустить продукт, удовлетворяющий требованиям клиента с необходимым качеством и уложившись в заложенные ограничения (бюджет, сроки, т.д.), то он не соответствует занимаемой должности. Если у продуктового менеджера не эти цели, то это не продуктовый менеджер по определению самой роли.

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

Можно, конечно, замаскировать всё под лечение подорожником - набрать побольше листьев, залить гипсом, создать таким образом корсет и т.п. Иногда даже поможет, наверное. Но зачем идти таким сложным путём - без подорожников-то и маскировки будет лучше, нет?

Начать надо с того, чтобы у всех участников процесса главные цели совпадали, а побочные не мешали достижению главной, а дальше уже решать возникающие вопросы. Разве нет?

[netleon]

Абсолютно правы. Если кто-то не компетентен, то это отдельная тема. Поправил.

[VladA1982]

Кхм. Продуктовый менеджер - product manager. Можете открыть любой сайт и посмотреть его обязанности. В большинстве из них, там будет что-то на основе определения Хоровитца "CEO of the product" и в описании обязанностей будет "defines product vision, strategy, roadmap..." Defines - определяет. Не переводит. Не объясняет. Определяет. Помимо этого, он плотно работает с командами маркетинга, продаж, поддержки, клиентами - слишком много обязанностей для "переводчика".

Однако, я полностью согласен с тем, что проблему можно решить, убрав пафосные названия. Например, не обзывать продуктом то, что продуктом не является. Если у вас есть заказчик (неважно - внутренний или внешний), то у вас нет продукта, а есть услуга. Нет продукта - нет продуктового менеджера и задач, которые он решает. Просто, не правда-ли?

Впрочем, "секретаря продукта" тоже нет. Если вы работаете по скраму, то у вас есть product owner - крайне неудачное название роли, но agile в целом грешит названиями, не помогающими понять суть процессов и роли. И вот product owner и есть переводчик, т.к. в его обязанности входит "ensuring that the Product Backlog is transparent, visible and understood". "Составление первичного ТЗ" в виде "сreating and clearly communicating Product Backlog items", кстати, тоже его обязанность. Если вы работаете по более традиционным методикам, то "переводчиками" служат бизнес-аналитики.

Что касается вопроса расстановки вагонов и паровозов, то:

1. Утверждение, что команда разработки существует потому, что есть продукт, который надо реализовать - неверно по нескольким причинам.

   1. Продуктов, которые надо реализовать, вообще не существует. Есть потребности клиентов, которые можно закрыть в том числе и созданием продукта.

   2. Команды разработки куда чаще создаются не для создания продуктов, а для оказания того или иного рода услуг.

   3. Есть продукты, которые создаются без команд разработки.

2. Должность продуктового менеджера, ВНЕЗАПНО, существует исключительно в связи с созданием продукта и в этом плане от существования команды разработки если и отличается, то в "лучшую" сторону.

И как нам это всё поможет расставить паровозы и вагоны? Да никак. А что поможет? Да описание роли project manager. Который defines, что и в каком порядке создавать. Т.е., является главным. И никак не может подчиняться "начальнику цеха", который определяет только как создавать то, что приказал создать project manager.