Мой класс для Владельцев Продукта (Product Owner, PO) сильно отличается от большинства классов по этой тематике, которые я видел. Это не класс "Скрам для Владельцев Продуктов", где тренер использует свои "стандартные" слайды и лишь вставляет несколько терминов из контекста продакт-менеджмента.
Я стремлюсь, чтобы мой CSPO класс на 85-90% отличался от моего класса для Скрам-мастеров (CSM). Во-первых: участники нередко посещают оба (так что ни одна игра или симуляция не дублируются), во-вторых: этот класс нацелен на другую аудиторию, он даёт другие навыки, хотя нередко посещается Скрам-мастерами и членами Команд Разработки, которые хотят разобраться и начать помогать своим "продуктоводам".
Тренинг проходит под лозунгом "from idea to release roadmap", и я ставлю своей задачей наглядно, на примерах и повторяемых упражнениях показать участникам, как они могут взять практически любую идею продукта и разложить её на столько, что уже завтра можно начинать валидировать первые гипотезы и общаться с командой о рисках, технологиях, ключевых фичах. Хороший Владелец Продукта всегда имеет большой, видимый, известный всем и сделанный со всеми план релиза - долгосрочное видение развития продукта.
И это никак не беклог в джире, уж простите меня. Джиру можно использовать, на свой страх и риск, но не стоит путать "список айтемов" с ясным и согласованным со стейкхолдерами и командой видением развития продукта.
Мой класс - о том, как это виденье строить, валидировать, обновлять и коммуницировать всем вокруг. И также о том, как вписать эти активности в ежедневные Скрам рутины. Это важно. Ниже - детали.
Условно класс состоит из шести частей:
Но эти части мы прорабатываем в классе нелинейно, так как сложный нелинейный домен нельзя объяснять линейно. Его нужно объяснять спирально - понемногу углубляясь, итерируя с каждым новым проходом. К тому же, линейное объяснение скучно и не даёт никакой возможности проверить, на сколько "участники учебного процесса" интегрируют уже известную информацию с получаемой. Но философию обучения - в сторону.
Тренинг начинается с забавной игры-симуляции, где участники "разрабатывают" продукты с искусственными ограничениями (к примеру молча, или разделив команду на две функциональные и разнесённые в пространстве группы). Это открывает рамку для обсуждения сложности продуктовой разработки и вызовах продуктового мышления.
Модель Cynefin помогает вести разговор: разработка продуктов - это комплексный домен (как, к примеру вождение автомобиля), без эмпирического контроля далеко на уедешь!
Далее мы обсуждаем типичную win-lose игру власти, которая традиционно происходит в компаниях: бизнес, прижимая IT к стене, кричит: "больше и быстрей!", и IT ничего не остаётся, как соглашаться и делать как получится, при этом пытаясь спихнуть вину, прикрывшись заранее спецификациями с семью печатями:
Мы дискутируем на тему введения менеджеров проектов - типичное решение спора между "больше и быстрее" или "вовремя и качественно", и как появление такой роли по сути является заплаткой и не решает сути глубокого конфликта.
С другой стороны, роль Product Owner - человека со стороны бизнеса, вовлечённого в процесс и ход разработки продукта, наделённого властью, контролем над бюджетом, разделяющего ответственность и последствие инвестиций - это другая игра. Введение такой роли на корню ломает "win-lose" споры (также называемые "внутренней контрактной игрой") и создаёт условия для конструктивного взаимодействия.
Помните в Манифесте: "взаимодействие превыше контрактов"? Вот это как раз об этом. Имеются в виду не формальные договора (они нужны, и я их как консультант подписываю их со своими клиентами), а неформальные и часто неявные контрактные игры: "перетягивания одеяла" и поиск "козлов отпущения", которые происходят внутри компаний и между отделами. Это никак не помогает выпускать крутые продукты. Это CYA (cover-your-ass driven-development). И мы учим организации прекращать тратить на это время и внимание.
Ввод роли Владельца Продукта - хорошее решение. Основатели Скрам смотрели в корень проблемы. Пусть многие критикуют Скрам за эту роль, мол, "единоличное владение продуктов - это нонсенс", говорят он. Да. Никто не говорит о диктатуре. Речь о том, как сломать негативные тенденции. И вовлечение в ход процесс продукты кого-то из бизнеса - хорошее решение. Лучшего, по меньшей мере, я не знаю.
Когда вы делаете у себя дома ремонт, вы и только вы можете по-настоящему можете ответить на многие важные вопросы: совмещать ли кухню с гостиной, инвестировать ли сразу в застекление балкона или пожить какое-то время так? нужно ли вам отопление пола? только в ванной или же на кухне тоже? нужен ли вам бОльшего размера шкаф?.. и в конце концов - когда прекратить ремонт и начать вселяться?!
Прорабы, помощники, советчики - это очень полезно. Но ремонт проходит в вашей квартире, в которой вам потом жить. Так что решать в итоге вам. Любые попытки уйти от решения, свалив его на других, приведут к вашему же недовольству потом. И винить прорабов или работников уже будет поздно. Да и это мало эффективно задним числом в любом случае. Вы - владелец квартиры, а значит, вы должны быть вовлечены в процесс ремонта на столько, чтобы получить качественный продукт. Увы и эгегей.
Но что нужно Владельцу Продукта, чтобы полноценно выполнять свою роль? Он ближе к доктору или официанту?
Задаваясь этим вопросом, мы проводим симуляцию: к участникам (в роли продакт-менеджеров) приходит CEO компании и просит описать ключевые фичи нового мобильного продукта.
Фичи приходят незамедлительно - участники осознают, что за 10 минут писания стикеров могут "нагенерировать" от 3 до 9 месяцев работы для одной команды разработки!
Что же здесь не так? Практически всё.
И мы приходим к мантре продуктового менедмжента: "понижай выхлоп и повышай результат".
Вот, в чём состоит задача Владельца Продукта. А не становиться, прошу за мой французский, джира-секретаршей.
Но кто же пишет беклог?? Хороший вопрос! Спасибо, что спросили. Об этом - все оставшиеся полтора дня тренинга. И ещё о том "как и когда".
Беклог истекает из видения. А для этого, нужно начать думать о продуктовой рамке - рынке, его пользователях, их проблемах, гипотезах о них... Стабильность беклога (столь желанную как и редкую) можно гарантировать лишь тогда, когда выполнено домашнее задание - есть ясность о продукте, и в головах у всех, кто будет участвовать в его разработке.
Поэтому следующие полтора дня мы говорим и прорабатываем такие инструменты продуктового мышления, как, к примеру, продуктовые доски - такие себе продуктовые ЦУПы (центры управления полётами).
И вот неплохой шаблончик:
Только я учу делать из него физический артефакт с бОльшим количеством важных элементов:
Постепенно прорабатывая видения продукта, мы сталкиваемся ещё с одной дилеммой: когда и когда должен это делать? Ведь это же занимает уйму времени.
Да и к тому же, если подобный процесс проводить как отдельную фазу разработки - не приходим ли мы к вотерфоллу, столь хорошо задекорированному белилами ложного скрама,
что его и опознать-то без пристального изучения нельзя?
Хорошо, что вы спросили!
Да, и тут есть ответ. Скрам! Вернее, как его иногда называют - dual-track scrum. Но это всё тот же Скрам, только правильно понятый!
Владелец Продукт драйвит цикл "дискавери" - постоянное изучение того, в разработку какого именно продукта и конкретно каких фич стоит инвестировать. Но так или иначе - это игра в угадайку (только с научным соусом и дорогими сертификатами, lol) - и без циклов быстрой обратной связи здесь не обойтись.
Модель Cynefin (см. выше) помните? А эмпирический контроль процессов? А inspect-and-adapt - мантру Скрам? Учим матчасть.
Поэтому команда неустанно совершенствует свои технологии, навыки, инфраструктуру и себя (!), чтобы как можно быстрее и дешевле уметь валидировать идеи, выходящие с конвейера "дискавери".
Одна из целей внедрения Скрам - помочь перестроить разработку (это трансформация IT) так, чтобы она стала прозрачной - в сравнении с "black-box IT", где всё очень дорого, долго и некачественно.
Прозрачность разработки - основа перестроение отношений между IT/R&D и бизнесом (та самая упоминаемая нами выше игра в win-lose останавливается, когда IT/R&D становится предсказуемым, а эксперименты недорогими).
Но IT/R&D должны начать первыми - это вывод моих 15 лет коучинга компаний, с огромным количеством неудачных трансформаций.
Так что если IT/R&D полуживой, то никаким продуктовым мышлением и долгосрочным видением организацию не починить - станет только хуже, к вам придут и скажут: "пиши код, б@@дь!", ну, вы знаете, как это бывает.
Но какой код писать??
Вот опять, всё тот же парадокс - нам всё-таки нужно, чтобы разработка управлялась кем-то из-вне (бизнесом), который будет приоритезировать свои "хотелки" и "гадалки" и получать быструю обратную связь для их улучшений (так как далеко не все идеи будут оказываться стоящими).
Так что два маховика "дискавери" и "деливери" должны вращаться одновременно, подталкивая и поддерживая друг друга.
Новая мысль? Нет. Но очень полезная.
И продвинутые Скрам команды, с которыми мне посчастливилось работать делают эти оба цикла настолько параллельно, что они выглядят, как цельный процесс: continuous delivery (как освобождение от узд итераций) и затем continuous deployment (как нирвана продуктового производства) - вот цель внедрения Скрам:
Такой процесс снимает все эти ужасные вопросы:
- как нам оценить проект?
- как нам выполнять вкладываться в fixed-scope/fixed-time обязательства?
- как нам научиться более точно оценивать сложность задач?
- как нам заставить разработчиков отвечать за свои оценки?..
Это страшные вопросы. Столько страшные, сколь часто-задаваемые.
И ответ тут прост ("ответ прост, ответ прост" - подпевает греческий хор). Но, как бы, невпопад: нужно учиться выпускать быстро и часто. Это и есть выход за пределы диктатуры в разработке и также уход из так называемого Мрачного Скрама. Это просветление продуктовой разработки и организации.
Быстрый выпуск позволяет вовлекать ещё более весомых "десижн-мейкеров" и "власть имущих" в процесс проработки и разработки, позволяя им управлять организацией и продуктом на основании фактов, а не "аэропортных книг по лидерству". Когда IT/R&D умеет быстро и часто выпускать в продакшн, у всех появляются реальные данные, снятые с живых продуктов, которыми постоянно пользуются живые пользователи, которые постоянно получают в своё распоряжение новейший функционал. Вау!
"Та да", - как говорят в Харькове.
На тренинге какое-то время мы говорим о менеджменте стейкхолдеров - важнейшей задаче Владельца Продукта*
* На самом деле у Владельца Продукта все задачи важнейшие, поэтому хорошие Команды Разработки во всём помогают своим PO.
Где-то здесь заканчивается первый день тренинга. И всё ещё ни слова о беклоге (ну, почти ни слова, на самом деле мы говорим о продукте и видении - это предпосылка для создания беклога).
Если первый день о проработке проблем ("а ту ли проблему мы решаем?" - вопрос, с которым в холодном поту просыпается ответственный Продакт Оунер), то второй день - о решениях.
Как вы видите на слайде ниже, воронка видения понемногу начинает сужаться: мы переходит от проблем пользователей, рынка и текущих решение - это "зона проблем" - к "зоне решений", где мы начинаем описывать продукт и его фичи.
Мы опускаемся с уровня видения продукта на уровень планирования релизов и тут нам помогает Story Mapping - многомерная карта нужд пользователей и фич продукта, супер связка, где стратегия порождает тактику.
И это происходит никак не в джире. И никак не одномерным списком. Списком беклог начнём становиться много позже, после PBR (Product Backlog Refinement).
Но я не буду здесь вдаваться в детали. Скажу лишь, что вся эта кухня работы с беклогом занимает практически половину второго дня тренинга.
Так что, выходит в моём CSPO тренинге менеджмент беклога рассматривается только половину второго дня? (хорошо, что вы спросили).
Да.
"Product management is so much more than backlog administration" - пожалуй, стоит выдавать на тренинге такие футболки! Так как это чуть ли не главное послание тренинга.
Хотя, конечно же, я немного утрирую: умение управлять беклогом и направлять команду - важная часть (внутренней) жизни Владельца Продукта. И мы об этом говорим немало.
До встречи на тренинге?
Write a comment