Gaperton (gaperton) wrote,
Gaperton
gaperton

Categories:

Ag;)e Checklist. Page 3. Product Owner.

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: Я несколько устал. Написание комментов к короткой методичке требует неиллюзорно больше времени, чем ее чтение. И охрененной концентрации мысли. Этот пост мне не очень нравится. Но посмотрим, как пойдет дальше.
Tags: agile checklist, scrum
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 49 comments