Про продукт-менеджемент по русски

Обсуждаем разработку программного обеспечения

Сообщение vva » 07 май 2010, 08:32

http://gaperton.livejournal.com/44830.html

Ag;)e Checklist: Product Owner

«Product owner (он же Product Manager) - это человек, отвечающий за разработку продукта»

Что не может не радовать. Скажем так — это здорово и очень правильно выделять роль product manager. Многие методологии запросто игнорируют аспект управления требованиями, предполагая, что они, непротиворечивые и полные, как бэ даны нам свыше.


Что, естественно, нихрена не так. И даже - ровно наоборот. Термин «сбор требований», иногда встречающийся в литературе — отражает это недопонимание. Требования — не грибы, чтобы лениво разгуливая по лесу, увидев его, сказать: «О! Требование!», сорвать, и положить его в корзину. Они больше напоминают редкоземельный металл, добываемый нечеловеческим, рабским трудом в «этих проклятых рудниках» (кхе-кхе).

Роль продакт-менеджера, естественно, придумана не в рамках Скрама. Но за факт его наличия в системе — Скраму крепкий зачет.

Далее разберемся по нюансам — в чем собственно, состоит скрамовская специфика. Названия одного мало, сами понимаете. А описание местами мутновато.

«Как правило, это менеджер продукта для продуктовой разработки...»
«...менеджер проекта для внутренней разработки...»
«...и представитель заказчика для внешней разработки»

Я немного переформулирую — «Как правило: 1) в случае продуктовой разработки это выделенная должность, 2) для внутренней разработки — обязанности выполняются руководителем проекта, 3) для заказной — навешиваются на ответственного представителя заказчика»

1 и 2 — оба хорошо. 3 — комично и забавно для каждого, кто имел с заказной разработкой реальные дела. Собственно, почему так? А вот почему.

«Владелец продукта формирует эффекивный путь достижения целей, и доносит его до каждого, кто в том нуждается»

Сие есть традиционная обязанность менеджера проекта. В скраме его, менеджера проекта, вообще-то нет в традиционном понимании. Слышите, менеджеры?

Автор Скрама социалист, и поставил себе задачу передать заводы — рабочим, а власть — советам. Поэтому менеджера нет, но надо как-то крутиться. Вот у нас и завелась волшебная тройка - «скрам-мастер» (генеральный секретарь) + «самоорганизующаяся команда» (совет) + «продакт оунер» (представитель заказчика, черт, без него, мешающего работать элемента, к сожалению совсем никак, и заодно — все остальное пусть делает, что не ложится в систему).

Традиционные обязанности менеджера попилены на троих. Здесь мы наблюдаем их фрагмент. Это само по себе ни плохо, ни хорошо. Некий подход.

Да, насчет попытки навесить этот пункт на представителя настоящего заказчика — у кого-то правда есть какие-то ложные иллюзии? Вот я и говорю. (3) — это комично и забавно, ибо кому-то может казаться правильным что угодно, но на самом деле заказчик платит деньги исполнителю вовсе не за то, чтобы иметь счастье руководить его командой. И скрам у вас или не скрам — ему по барабану.
Имеем в результате что? Роль продакт-оунер — по своей природе внутренняя, а не внешняя. Хрен куда без менеджера денешься.

«Владелец продукта должен четко понимать, какие фичи должны быть сделаны, и каковы их приоритеты»

Гут. Кстати, я надеюсь, всем понятно, почему именно заказчик обычно на это не способен?

Потому что он четко понимает только свою проблему и потребность. То, что фича != проблеме или потребности, это, я надеюсь, также понятно? Предложить ему возможности для их решения и удовлетворения, которые выражаются в виде фичлиста — работа исполнителя, у самого заказчика не хватает на это ни квалификации, ни знаний ваших возможностей. И не должно хватать.

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

Этот выбор должны делать вы, и обсудить с ним разные варианты. Все, что должен делать заказчик — выбирать из них. Я говорю — так вам будет дешевле, а заказчик будет доволен. Дадите ему на откуп выдумывание фич — и вы получите бесконечный перебор вариантов, который будет выглядеть для вас как «постоянно меняющиеся требования», и «невменоз заказчика». А для него — как ваша неспособность решить его проблему, причем, за непонятно какие деньги. И он, что характерно, будет прав.

«Владелец продукта достаточно хорошо разбирается в продукте и предметной области для того, чтобы правильно расставить приоритеты»

Nuff said. Заказчик не может хорошо разбираться в продукте, которого еще нет, и по которому вы не провели тренинг.

Конечно, после первой итерации все будет не так. Скрамовские короткие итерации этот недостаток компенсируют. Глядя на то, что вы захерачите, что бы это ни было, говорить что надо получить, гораздо проще. И это наглядно продемонстрировал Хрущка на своем семинаре в игре с листками бумаги.

Но только есть нюанс — заказчик за этот перебор платит. Поэтому, а не почему нибудь еще, итерации в скраме надо делать короче. До итераций мы еще доберемся. Это следующая страница чеклиста.

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

Как может быть иначе? Иметь экспертизу в предметной области внутри компании, и решать проблемы клиентов, работая на опережение их «хотелок». Прогибать клиентов там, где выгодно, управляя их хотелками, и предлагая свои решения их проблем.

Короче, не пытаться валять дурака, и не навешивать «продакт оунера» на заказчика. В нормальной системе — он не просто должен быть внутри. Это должен быть член команды.
«Владелец продукта ставит задачи команде, но он не вправе ставить задачи конкретному члену проектной команды»

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

Это правило очень важно для обеспечения «самоорганизации». Спокойно — на порядок задач продакт оунер влиять может. Иначе была бы полная жопа. Он приоритеты расставляет, помните? Все почти хорошо.

Но что-то не очень хорошо, где-то здесь подвох, правда? :) Таки да, он есть :) Все дело в том, что трудоемкость и риски решения одной и той же проблемы сильно не одинаковы для разных людей. И есть, как я писал в первой части, естественная специализация, причина которой в разном опыте, таланте, знаниях, и уровне навыка людей.

Тот интеграл, который Ландау брал на завтрак для разминки мозга за 5 минут, создаст массу проблем первокурснику, с которыми он будет ковыряться часами и не факт что вообще справится — может и упереться. Про студента экономфака я вообще молчу. Зато — Ландау хрен сведет годовой балланс. А студент экономфака имеет хорошие шансы справится.

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

Что произойдет, когда менеджер выдающий задания выключен из процесса? Он лишен обратной связи и важнейшего фактора, позволяющего составлять реалистичные планы. Любой реалистичный план полагается в первую очередь на возможности, и только во вторую - на желания. И каким образом продакт-оунер это будет учитывать?

Ответ прост. Да никаким. Имеем очень сильно сниженную эффективность управления, за счет искусственного, не мотивированного бизнес-необходимостью ограничения - «вся власть советам».

Пример. Допустим, у меня в команде есть Сергей Зефиров (Опять он! Черт!). Он знает Хаскель. Он разбирается в проектировании микроэлектроники. Я выдаю группе задание — разработать эскизный проект суперскалярного процессора с системой команд MIPS.

Так как я знаю, что у меня в группе есть Зефиров, я поручаю ему сделать модель этого процессора на Хаскеле. Что радикально меняет весь цикл работы группы, в которую он включен. Через месяц у нас есть потактовая модель процессора. Через два — мы провели два десятка экспериментов на этой модели, и отсекли пяток «плохих» фич микроархитектуры, имеющих низкое соотношение затраты/эффект. Это, если кто не понял — чудо. Не было Зефирова — весь план работ был бы другим. Потактовая модель традиционно занимает пиздец, от полугода. И в ней не так просто ставить эксперименты. А у нашей команды нет опыта в разработке процессоров. И что делать?

Как классно, что у нас в команде есть Сергей Зефиров, правда? :) А теперь вопрос. Вы думаете, он случайно в команде такой хороший появился? Не совсем. Я, руководитель направления, его нашел, и заранее нанял. Вопрос — почему я искал человека похожего на него, с таким редким набором навыков, уже не стоит? Все понятно?

Я к чему клоню. Кто будет этим заниматься таким осмысленным наймом при таком разделении ролей, как в Скрам? Назовите роль. Не надо фантазировать - нет ее. У каждой недостаток информации, ответственности, и полномочий.

«Владелец продукта отвечает за приемку результатов в конце каждой итерации»

Чтобы дать вам понять, в каком контексте это плохо.

Допустим, я «владелец продукта», то есть продакт менеджер, этого MIPS. Вы правда считаете, что я приемку проводил в конце каждой итерации модели? :) Не, я не сумасшедший. Я бы закопался.

Но мне нужно при этом, чтобы группа получала обратную связь в процессе проектирования гораздо быстрее, чем раз в итерацию при демонстрациях мне. Казалось бы, противоречие. Что же делать?

А нефига склеивать роль «продакт менеджера» с непойми чем. Я просто определил для команды четкую цель и критерии успеха, и дал команде возможность спокойно работать, периодически проверяя результат в беседах. Открою тайну — я понятия не имею, как запускается модель Сергея, и как ей пользоваться. :)

Это — Auftragstaktik. В основе - принцип независимого действия, личная инициатива, и «внутреннее руководство». Применяется в немецкой армии со времен Бисмарка. И при этом почему-то никаких особых требований «самоорганизации» - четкая субординация.

Хорошо, к черту процессора. Берем автоматизацию торговой компании. Вопрос — нахера мне для приемки системы какой-то там оунер, и завязываться при этом на его глюки? Если я могу просто взять, и поручить людям собрать данные о том, как работает десяток ролей пользователей посредством интервью? Потом — составить общую картину потоков информации, и выполнить ее проверку на полноту и непротиворечивость? Потом — сделать по прототипу гуя на каждую роль, и показать тем, у кого собиралось интервью?

Чем это не скрам? Ну право слово:

«Владелец продукта — это единая точка принятия окончательных решений для команды в проекте, именно поэтому это один человек, а не группа или комитет».

Вот я спрашиваю — почему в предыдущем пункте этот «один человек» «отвечает за приемку», блин, когда ролей пользователей - десяток? Что значит вообще - «приемка» и что значит «отвечает»? Что — итерацию могут не принять? И что происходит в этом случае? Как в ЕСПД — клиент не платит бабок за этап? Очевидно, нет (объясните это вашему клиенту, попробуйте). Тогда что?

А что происходит после «приемки»? Сразу сломя голову в продакшн ставим?

Короче, пункт по поводу «приемки» построен на базе частного случая.

«Владелец продукта управляет ROI»

Я не вполне понимаю, что имели в виду авторы, когда это писали. Хочется спросить — что такое ROI в их понимании, как он считается, и от каких факторов зависит? Дело в том, что мне-то известно что это такое, и поэтому мне этот пункт чеклиста неиллюзорно доставляет. :) И я постараюсь передать свою радость вам.

http://ru.wikipedia.org/wiki/Окупаемость_инвестиций
ROI (англ. Return On Investment, русск. окупаемость инвестиций), так же известен как rate of return (ROR) - отношение увеличения инвестиций (чистой прибыли) к объёму инвестиций. Этот показатель может также иметь следующие названия: прибыль на инвестированный капитал, прибыль на инвестиции, возврат инвестиций, доходность инвестированного капитала.

Вы уже чувствуете, где подвох? :) По-моему пока нет. Я поясню. Читая прибыль — есть прибыль после налогообложения. Она делится на затраты.

То есть, что надо сделать, чтобы посчитать ROI по проекту. Чтобы им управлять, его надо как минимум уметь считать, правда? Берем, значит, прибыль по нашему проекту после налогов, и делим на, гхм, инвестиции. И выравниваем на период — чтобы ROI разных проектов мон было сравнивать между собой. Налоги считать умеете? А затраты, включая косвенные — умеете?

Попроще бы, правда? :) Вот, нехрен выпендриваться, и употреблять красиво звучащие слова вроде ROI. Во-первых, по русски это «рентабельность». Во-вторых, в модели DuPont есть коэффициент попроще, называемый «рентабельность продаж».

Это — «операционная прибыль», деленная на прямые расходы. Первое - тупо выручка по проекту (НДС по правильному надо отрезать, и это — все сложности) за вычетом прямых расходов (только те, которые реально относятся к проекту, и в нашем случае это будут в основном зарплаты исполнителей).

Считать уже умеем. Но - «владелец продукта» у нас управляет рентабельностью. Как ей можно управлять? Поглядим на формулу. Либо увеличить продажи, значить, либо — эта, сократить расходы, которые состоят в основном из зарплат. В случае отдельного проекта — «увеличение продаж» лишено смысла. Вопрос. Каким образом наш продакт оунер может сократить расходы, и как это вписывается в общую картину управления компанией? Он вообще имеет хоть какой-то контроль над «самоорганизующейся» командой?

А теперь - внимание. Про ROI написано в чеклисте. Это может быть вам ничего особенного не говорит, но мы, сертифицированные PSP/TSP инженеры, обучены чеклисты составлять. Знаете, что в этом деле главное?

Чеклист - это тупо список, в котором надо ставить галки. И каждый пункт чеклиста должен однозначно, и вполне элементарно проверяться. Без философских рассуждений, цесания затылка, и решения дифференциальны уравнений в уме.

И каким образом мы проверять будем - управляет у нас продакт оунер ROI, или нет?

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

PS: Я несколько устал. Написание комментов к короткой методичке требует неиллюзорно больше времени, чем ее чтение. И охрененной концентрации мысли. Этот пост мне не очень нравится. Но посмотрим, как пойдет дальше.
Аватар пользователя
vva
Администратор
 
Сообщений: 2914
Зарегистрирован: 06 фев 2007, 13:33

Сообщение Marysenka » 07 май 2010, 09:26

Сразу несколько вопросов возникает:

1. О чем статья?
Я так понимаю, что это какая-то локальная перебранка автора с его коллегами об адекватности некоторых положений методологии скрум.

2. Почему текст не для людей написан: много воды и много монотонных абзацев?
Ну, дял коллег наверное, писалось, а не для широкого круга читателей)

3. Почему её уместно разместить в этой ветке форума?
Тут у меня версий нет) VVA, почему эта статья здесь нужна?


Что понравилось:

1. Ирония автора по поводу модных менеджерских словечек (ROI, продакт-менеджер), которые никто почти не знает, как использовать).

2. Очень милый тезис о том, что работу надо поручать тому, кто её сделает, а не тому, кто её обязан делать.

3.
Это — Auftragstaktik. В основе - принцип независимого действия, личная инициатива, и «внутреннее руководство». Применяется в немецкой армии со времен Бисмарка. И при этом почему-то никаких особых требований «самоорганизации» - четкая субординация.


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

Недоверие между руководителем и специалистами - действительно серьезная проблема. Нет концентрации на общих целях. Нет адекватного взаимодействия.
Аватар пользователя
Marysenka
Команда РИТ
 
Сообщений: 1002
Зарегистрирован: 26 сен 2008, 08:48

Сообщение vva » 07 май 2010, 09:40

Marysenka писал(а):VVA, почему эта статья здесь нужна?


чтобы мои коллеги (и ты в том числе)
прочитали статью и откомментировали
не так много у нас информации по русски о данной теме чтобы такими ссылками разбрасываться

3. Это — Auftragstaktik. В основе - принцип независимого действия, личная инициатива, и «внутреннее руководство». Применяется в немецкой армии со времен Бисмарка. И при этом почему-то никаких особых требований «самоорганизации» - четкая субординация.

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


тут вообще проблема с очень длинными корнями.
замечено например что в ВОВ, победу в которой мы будем праздновать завтра например большая часть указаний младшим и средним офицерам в немецкой армии оформлялась как "боевая задача", в то время как у нас писался "боевой приказ".

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

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

Недоверие между руководителем и специалистами - действительно серьезная проблема. Нет концентрации на общих целях. Нет адекватного взаимодействия.


более того, она ещё сложнее чем ты думаешь

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

вот кому тут доверять? никому! мне можно.. хе хе хе (как говаривал один немецкий чин в одном популярном фильме)
Аватар пользователя
vva
Администратор
 
Сообщений: 2914
Зарегистрирован: 06 фев 2007, 13:33

Сообщение Marysenka » 07 май 2010, 09:45

Тот же Бисмарк говорил, что с русскими воевать бесполезно:
каждую (казалось бы беспройгрышную) хитрость они порушат своей непрепредсказуемой глупостью.
Аватар пользователя
Marysenka
Команда РИТ
 
Сообщений: 1002
Зарегистрирован: 26 сен 2008, 08:48

Кто сейчас на форуме

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1

cron