Product Owner - Лучшие практики: чеклист для самооценки

Лучшие практики Владельцев Продукта: чеклист для самооценки

popractices-preview-new

От команды BrainRain:

Даже беглый поиск по ключевым словам Product Owner best practices показывает: мнений о лучших практиках много, но редко кто отваживается говорить о работе Владельца Продукта системно, в формате чек-листа или схемы. Одна из любопытных попыток создать систему — фреймворк для оценки работы PO от Роберта Гэлена, Аджайл-коуча и сертифицированного Скрам-тренера из Нью-Йорка с 17-летним опытом. Публикуем ее в русском переводе и призываем отнестись к статье с любопытством, но не без критики.

По словам Гэлена, его фреймворк построен по аналогии с Индексом освоения Аджайла Agile Maturity Index Билла Кребса (Bill Krebs). Этот индекс, в свою очередь, появился из многолетней практики XP и Скрама в командах Кребса и связан с такими системами, как инструмент самопроверки команд IBM (IBM Rational Self-check for Software Teams TM).

Зачем это оценивать

Здесь приведены главные практики, техники и подходы, которые важны для качественной и сбалансированной работы Владельца Продукта. Они не предназначены для сравнения разных Владельцев Продукта между собой. Скорее это инструмент, который поможет разобраться, что такое “хорошо” в контексте вашей организации. Он также поможет поощрять беспрерывное развитие и обучение.

Главные практики Владельцев Продукта обобщены в четырех разделах:

  1. Программа минимум
  2. Базовые практики
  3. Коммуникация
  4. Управление

Рассмотрим их по очереди.

Программа минимум

Первое и главное — инвестиции во владение Продуктом, или точнее, во Владельца Продукта в организации. Есть ли у вас по PO на каждую команду и действительно ли работа с этой командой — их главная  обязанность? Часто компаниям трудно перейти на Скрам именно из-за того, что нужно “инвестировать” во Владельцев Продукта и Скрам Мастеров. [А иногда Владельцу Продукта приходится выполнять непосильный объем работы, потому что организация не готова оплатить только одну роль].

Теперь обратим внимание на такой распространенный артефакт, как пользовательские истории (user stories). Они — не только один из самых популярных инструментов работы с требованиями в Аджайле, но и хорошая иллюстрация того, как работают эти самые требования. Они по сути своей привязанные к актуальности и нечеткие. Они должны эволюционировать, пока их не отдаст в работу Владелец Продукта —  “пастух историй”.

И наконец, важен Бэклог Продукта. Здесь много противоречий: это требования/истории или что-то совсем другое? Например, не набросок ли это плана релиза? Краткий ответ: это все, что нужно, чтобы эффективно направлять поставки команды. А главный направляющий — Владелец Продукта.

Владелец Продукта

  • Есть ли он у вас? Достаточно ли у этого человека подготовки, знаний и понимания для практики?
  • А как насчет опыта в вашей сфере? И в самой организации?
  • Есть ли у этого человека достаточно времени для выполнения своей роли? Как во внешнем, так и во внутреннем аспекте.
  • Есть ли у них достаточные полномочия, чтобы принимать бизнес-решения и вести команду?

Пользовательские истории

  • Используете ли вы их хотя бы в облегченном варианте или все еще придерживаетесь традиционных строгих требований?
  • Если вы применяете пользовательские истории, понимаете ли вы, из каких трех частей они состоят и как правильно их писать?
  • Есть ли у вас понимание критериев приема и готовности (entry or readiness criteria)?
  • Вы вкладываете в формулировку критериев приемки как способ донести “что” и “почему” вашего бизнеса?

Бэклог Продукта

  • Работает ли у вас многоаспектная приоритезация с учетом потребностей бизнеса, команды и технологий?
  • Кто “владеет” Бэклогом Продукта — Владелец Продукта или команда?
  • Происходит ли активное уточнение Бэклога и проверяются ли истории так, чтобы они были описаны максимально понятно и выполнимо?
  • Прогнозирует ли Владелец Продукта, как развивается ситуация, чтобы поделиться пониманием с командой?

Базовые практики

Владелец Продукта не занимается оценками (эстимацией) напрямую. Но он/а создает нужную среду через уточнение Бэклога, где элементы уточняет команда. Кроме командных оценок, участие в таких активностях дает Владельцу Продукта понимание уровня сложности и усилий, нужных команде для поставки фич. Эта информация полезна для продуктовой стратегии и расписания (workflow).

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

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

Оценка

  • Избегайте любой оценки, которую проводите не с командой или менеджментом. Поощряйте команду заниматься и оценкой кратковременных занятий (историй для спринта), и долговременными прогнозами.
  • Используйте одну из практик эстимации для всей команды (например, Покер Планирования) и следите, чтобы все при этом были услышаны.
  • Находите время и место для спайков, которые помогут определить объем задач. Это особенно важно для элементов, которые сложны технически или по бизнес-функциональности.

Приоритезация

  • Следите, чтобы у вас была сбалансированная стратегия оценки (приоритезации) Бэклога Продукта, которая учитывает бизнес, запросы заказчика и технические факторы. Хорошо напрямую включать стейкхолдеров в процесс (value poker).
  • Не бойтесь разбивать элементы Бэклога на составляющие, уменьшая их объем и поощряяя эксперименты, рассуждения и поиск фактов, чтобы все лучше понимали ценность.
  • Пусть в ваших критериях релиза будут метрики ROI с дорелизными целями и реалиями пост-релизов. Учитесь и приспосабливайтесь к реалиям по актуальным результатам команд и обратной связи на Ретроспективе.

Постановка целей

  • Для начала, есть ли у вас последовательные цели и на уровне спринта, и на уровне релиза? Четкие ли они, легко ли их понять? Вовлекаете ли вы команду в определение их реалистичности и рациональности?
  • Автор чеклиста считает определение готового (Definition-of-Done) своего рода целью, объединяющей работу команды с ожиданиями стейкхолдеров.
  • Прозрачно ли у вас достижение целей или вы частично прячете его? Встраиваете ли вы в цели какие-нибудь увертки, чтобы у команды было пространство для инноваций и творчества?

Коммуникация

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

У хорошего менеджера проекта обычно есть план коммуникаций. В этом плане указаны каналы, распределение ответственности и лица на проекте. Этот документ может быть слишком трудновыполнимым для большинства Аджайл-проектов, но общая цель этой практики довольно здоровая. В Скраме большинство такой коммуникации ложится на Владельца Продукта.

Это может показаться странным, но в списке автора одним из ключевых навыков коммуникации является умение слушать. Это, возможно, нечестно, так как основывается на личном стиле общения автора, а именно манере слишком много болтать.Но все равно Владельцам Продукта не помешает напоминание о том, что нужно уметь слушать. А важная его часть — наблюдение за языком тела и тем, что не говорится вслух.

Обзор спринта

  • Показываем и мы постоянное работающие программы, при этом полностью придерживаясь критериев готовности (Definition of Done)?
  • Была ли вся работа утверждена и принята, и достигла ли команда целей спринта?
  • Посещают ли обзор спринта ключевые стейкхолдеры? Помимо посещения, вовлечены ли они как-нибудь еще — задают ли вопросы, дают ли обратную связь?
  • Привязываете ли вы результаты к плану релиза? Так сказать, ведете ли линию от результатов предыдущего спринта к вещам, к которым планируете приступить?

Общение

  • Эффективно ли в организации распространяют информацию и “слушают” ли тех, кто ею делится? Один из способов отследить это — обращать внимание, задают ли вам вопросы об артефактах команды.
  • Дает ли команда согласованную, открытую и честную обратную связь на ретроспективах спринтов? Владельцу Продукта здесь важно не слишком “продавливать” потребности бизнеса, что стесняет людей в общении.
  • Выступает ли Владелец Продукта активным “представителем” команды во всех отделах организации? Обращаются ли вышестоящие менеджеры и ключевые стейкхолдеры к PO за отчетом о ходе дел?

Умение слушать

  • Следите за уровнем вовлеченности на Ретроспективе. Заботьтесь о том, чтобы в команде обсуждались точки зрения индивидов и бизнеса, а также ценности — это важно для улучшений.
  • Активно включайте обратную связь от команды в Бэклог Продукта через истории, их порядок, стратегию и усилия для устранения технического долга.
  • Посещайте планирование спринта и релиза. Внимательно слушайте, как команда обсуждает технические решения, уступки по качеству, архитектуру и уровень сложности. Но — с точки зрения разработки и тестирования.

Управление

Управление в этом блоке — это о том, чтобы направлять усилия команды к бизнес-целям, ориентированным на клиентов.

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

Другая важная зона — видение. Это о том, как представить себе проект в общих чертах, определить цели, ограничения и условия приемки. Практические активности в этом смысле — Story-Mapping, планирование релиза с учетом дорожной карты. Это не только полезно команде для понимания стратегии, но и необходимо Владельцу Продукта для презентации плана действий стейкхолдерам и клиентам.

Аджайл-команды часто погружаются в проекты и инициативы без достаточно продуманного плана движения вперед. Эта группа практик помогает избежать такого антипаттерна.

Продакт-менторинг и профессиональное сообщество

  • Позаботьтесь о том, чтобы в организации было профессиональное сообщество, которое бы обеспечивало последовательность артефактов роли Владельца Продукта (Бэклог, истории, дорожная карта и так далее).
  • Владельцы Продукта сотрудничают как одна команда. По терминологии модели Spotify, у них появляется “Chapter”, то есть они активно работают в парах и учат друг друга.
  • В Аджайл-среде есть тенденция уменьшать количество стандартов и шаблонов. Но важно, чтобы в организации были здоровые и сбалансированные стандарты, которые не сковывали бы командную работу.

Видение

  • Команде должны быть ясны миссия и визия организации или глобального проекта, в рамках которого она делает продукт.
  • Можно проводить project chartering, чтобы начать работу над проектом. Часто это необходимость для планирования релиза (например, в SAFe есть понятие о chartering внутри планирования PSI…)
  • Используйте понятия Minimal Marketable и Minimal Viable (минимально жизнеспособного) для объяснения фокуса и целей проекта. Сюда же входит стори мэппинг, который проясняет, как раскроется функциональность и как она решит проблемы клиента..

Планирование релиза. Дорожная карта

  • Здесь мы двигаемся от видения Бэклога Продукта как “серии требований и фич” к динамическому потоку работы, направленному на достижение целей бизнеса.
  • Хорошо удерживать баланс между активностями, связанными с фичами, техническими вложениями и техническим долгом. Бэклог не должен быть привязан исключительно к фичам.
  • Планирование релиза должно быть занятием всей команды и приводить к созданию дорожной карты и обязательств перед бизнесом по поводу результатов работы. То есть команда должна быть вовлечена в создание видения, планирование поставки и принятие обязательств (commitments). А у бизнеса таким образом появляется понимание вариативности этих обязательств.

Переведено и адаптировано командой BrainRain по статье Роберта Гэлена Measuring Product Ownership — What Does ‘Good’ Look Like?

Сам инструмент оценки для Владельцев Продукта можно посмотреть тут

Всего комментариев: 0

Оставить комментарий

Ваш email не будет опубликован.

Будь в курсе! Подпишись на scrum-новости