К основному контенту

Эффективный Product Owner. Поиски ответов

Автор: Алексей Кривицкий.

В течение последних дней в нашей группе дискуссий велось активное обсуждение роли Product Owner-а (для краткости "PO"). Мы пытались найти ответы на такие непростые вопросы:
  • кто же такой эффективный Product Owner;
  • каковыми навыками он должен обладать;
  • чем его роль отличается от традиционных ролей Product Mananger-а, Project Manager-а, аналитика.
Возьму на себя смелость процитировать избранные высказывания, которые как мне показалось, отвечают на поставленные вопросы.

Здесь вы можете ознакомиться с полной историей этой дискуссии и, кстати (!), принять в ней участие.


Критерии хорошего PO:
  • знать, что конечные пользователи хотят от системы
  • уметь донести понимание системы до команды
  • понимать приоритеты этих вещей
  • не путать требования и реализацию
  • быть доступным для команды и достаточно мотивированным, что бы давать квалифицированные ответы
  • не делегировать полномочия людям, которые не удовлетворяют перечисленным выше пяти качествам или не расходятся во мнении с ним
  • уметь всё это проверить
(Boris Lebeda)

Для меня и некоторых моих знакомых PO в проекте - один из главных критериев при выборе работы.

(Evgeny Kompaniyets)

Если же в общих чертах, по для меня хороший Product Owner - это прежде всего человек понимающий в бизнес причинах и приоритетах проекта и умеющий говорить об этом с командой.

Идеальный Product Owner - это, разумеется, сам клиент имеющий понятие о программировании в данной предметной области, вежливый, болеющий за дело, не боящийся признавать ответственность и ошибки и имеющий время на всё то, что перечислил Борис.

(Artem Marchenko)

У нас был человек на голландской стороне, который был совершенно невыносим в качестве Продакт менеджера. Он предлагал технические решения, постоянно менял планы, задавал идиотские вопросы, не отвечал
на письма, лез не в своё дело и т.п. Сейчас он - лучший Продакт оунер из всех, кто работает с украинскими командами. Смотря на него, я вижу вот такие критерии "хорошести":
  • РО должен отвечать хоть чем-то за результат проекта. Коммитмент приложится.
  • РО обязательно кто-то должен обучить и поддерживать. В нашем случае Маурисом занялись лично Chief Technological и Chief Informational компании. После двух месяцев муштры глупые вопросы сошли на нет.
  • РО должен хорошо относиться к команде разработке и обязательно быть лично с ними знакомым. После визита "ужасного Мауриса" в Украину, когда он лично познакомился с командой (и понял какие же мы классные )). Ну и народу здесь тоже стало понятно, что он - вполне вменяемый чувак. После этого общение поменялось кардинально в лучшую сторону.
  • РО должен быть толковым. Остальное наберётся автоматом.
(Artjom Serdyuk)

Важнейшая ценность PO: уметь отказываться от ненужных фич.

(Evgeny Kompaniyets)

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

(Artem Marchenko)

Удачных дискуссий!

ПОПУЛЯРНОЕ

Шаблоны декомпозиции Пользовательских Историй (User Stories)

Автор: Richard Lawrence Переведено с английского проектом Agile Translations   Хорошие Пользовательские Истории следуют INVEST модели , предложенной Биллом Вейком (Bill Wake). Они независимые ( I ndependent), обсуждаемые ( N egotiable), ценные ( V aluable), поддающиеся оценке ( E stimable), небольшие ( S mall) и тестируемые ( T estable). Именно требование к размеру приводит нас к необходимости делить большие Пользовательские Истории, однако, даже после разбиения, они все еще должны следовать этой модели. Многие начинающие agile-команды пытаются разделять Пользовательские Истории по архитектурным слоям: одна история для пользовательского интерфейса, другая — для базы данных, и так далее. Такой подход может удовлетворять критерию “небольшая” , однако, не сможет похвастаться тем же в случае с “независимая” и “ценная” . За девять лет работы с гибкими методологиями, я определил девять шаблонов разбиения Пользовательских Историй на хорошие, небольшие истории.

Скрамбан - собираем лучшее

Автор: Илья Павличенко . Иногда я слышу фразу - «теперь у нас будет СкрамБан». И, к сожалению, наблюдаю, что чаще всего это означает, что у команды теперь не будет ни полноценного Скрама, ни внедренного должным образом Канбана. Хотя это понятие (СкрамБан) подразумевает и первое, и второе. Таким образом, команды лишают себя преимуществ обоих методов, переходя в серую зону неопределенности. Привожу цитату Алана Шалловея, одного из родоначальников Канбана (полностью его блог-пост по этому вопросу можно прочесть здесь ): « Теперь стало модно у многих Скрам команд уходить от итераций и кросс-функциональных команд и говорить, что теперь у них внедрен Канбан. Я принимаю то, что в Канбане отсутствует и первое, и второе. Но Канбан не определяется отсутствием итераций или кросс-функциональных команд. Он определяется визуализацией, управлением потока, наличием явных полиси и т.д. Если у вас был Скрам и вы решили уйти от итераций - у вас не Канбан. Вы даже и близко не подошли к тому, чтобы

Основополагающие принципы Agile-манифеста

Мы следуем таким принципам: Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения. Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды. Работающий продукт — основной показатель прогресса. Инвесторы, разработчики и пользователи должны иметь возможность поддержив

Ретроспектива спринта - эффективный формат

Автор: Майк Кон (Mike Cohn) Перевод с английского Неважно, насколько опытной является Скрам-команда, при этом всегда существует возможность для ее улучшения. Не смотря на то, что хорошая Скрам-команда будет постоянно искать возможности для своего улучшения, она должна выделять короткий период времени в конце каждого спринта для сознательного размышления над тем, как идут их дела, и для поиска способов их улучшения. Все это происходит во время Ретроспективы спринта.

Планирование релиза: уходим от термина, но не от практики

Автор: Майк Кон (Mike Cohn) Перевод с английского. Я хочу обратить внимание на термин, используемый в Скраме (точнее, даже Аджайл термин), который во многом пережил себя: планирование релиза. Общепринятое использование "релизного планирование" заключалось в том(я так тоже делал), что мы смотрели в будущее на несколько спринтов вперед и пытались предсказать, что бы мы могли выпустить. Было бы хорошо в идеале эти предположения выражать в виде диапазона значений, возможно даже с использованием интервалов вероятности. В течение многих лет я учил команды делать именно так. Скажем, мы могли сказать, что “Мы уверены на 90%, что через шесть месяцев сможем выпустить продукт с функционалом в диапазоне между 150 и 200 стори поинтов.” Я до сих пор считаю эту практику полезной и каждый Скрам-мастер должен знать как это делается. Что на самом деле потеряло смысл, так это сам термин “планирование релизов”.