Recommended
More Related Content
What's hot
What's hot (15)
Similar to Путь Product Owner`s. От факапов до успешного продукта
Similar to Путь Product Owner`s. От факапов до успешного продукта (20)
Путь Product Owner`s. От факапов до успешного продукта
- 1. Путь Product Owner`а. От факапов до успешного продукта Мандрика Андрей, CSPO Product owner,
- 2. «Product Owner». Кто это такой? «Владелец продукта (Product Owner) - проектная роль в методологии Scrum, ответственная за сбор требований к продукту, документирование требований в форме пользовательских историй, задание приоритета историям и приемку функциональности, реализованной командой…»
- 3. «Product Owner». Кто это такой? «Владелец продукта (Product Owner) – персона, которая владеет определенным продуктом от имени организации.»
- 4. А что такое продукт? Направлен на решение проблемы и/или получение выгоды для пользователя/ клиента Создает прибыль, позволяет разрабатывать новые продукты или бизнес цели организации. Создает ценность
- 5. Product, Feature, Component Создает ценность для группы пользователей и компании Строительный блок продукта Отдельная возможность или свойство продукта, которую могут использовать люди
- 6. Owner Types Product owner Feature owner Component owner
- 9. Потенциальные обязанности Product Owner`a 1. Должен иметь и распространять видение продукта. 2. Общение с заинтересованными сторонами и синхронизация их интересов. 3. Определение и формализация требований. 4. Организация, заполнение и приоритезация беклога. 5. Планирование итераций и ведение груммингов. 6. Определение целей на итерации и релизы. 7. Консультация и объяснение сути задач для команд(ы). 8. Приемка результатов выполненных командой. 9. Определение успешности итераций для команды, заинт. сторон и бизнеса. 10. Участие в командных мероприятиях. 11. Презентация выполненной работы. 12. Создание условия для усовершенствования работы команд(ы)
- 10. Видение продукта Ошибки: 1. Не знаем конечную цель. Решения: 1. Составляем устав проекта или Vision document.
- 12. Видение продукта Ошибки: 1. Не знаем конечную цель. 2. Не понимаем потребностей и проблем пользователей. 3. Большая рас фокусировка в разработке. Решения: 1. Составляем устав проекта или Vision document. 2. Изучаем текущие бизнес процессы + конкурентов 3. Выделяем MVP.
- 13. Заинтересованные стороны Ошибки: 1. Работаем только с одним заказчиком. Решения: 1. Составляем матрицу заинтересованных сторон.
- 15. Заинтересованные стороны Ошибки: 1. Работаем только с одним заказчиком. 2. Работаем с заказчиком только вначале проекта и в его конце. 3. Реализуем все пожелания всех заинтересованных сторон. Решения: 1. Составляем матрицу заинтересованных сторон. 2. Держим заказчика в курсе по ходу разработки. Доносим реальное положение дел. 3. Фильтруем требования относительно цели и чаще говорим «Нет».
- 16. Сбор требований Ошибки: 1. Сами придумываем требования. 2. Обсуждаем требования без визуального представления. 3. Согласовываем требования только устно. Решения: 1. Валидируем все требования с заказчиком. 2. Практикуем дудление и макапы. 3. Высылаем итоги обсуждения и просим подтвердить.
- 17. Описание требований Ошибки: 1. Требования не достаточно описаны. 2. Не использование «языка» пользователей. 3. Требования разбиты на большие куски. Решения: 1. Внедряем AC, DoR, DoD. 2. Составляем глоссарий языка предметной области. 3. Совместная декомпозиция требований с разработчиками.
- 18. Организация беклога Ошибки: 1. Оперирование только 1-2 уровнями задач. 2. Беклог содержит более 100 задач, которым больше месяца. 3. По мере увеличения беклога теряется фокусировка. Решения: 1. Добавляем уровни иерархии в ИСР. Jira+Structure: (Themes -> Initiatives -> Epics -> User stories) 2. Периодически удаляем старые задачи. 3. Добавляем Milestones, двигаемся от цели к цели и считаем прогресс.
- 19. Грумминг задач Ошибки: 1. «Ну описание я потом допишу…» 2. Не понимание сколько стоит задача. 3. Учет оценки только от разработчиков. Решения: 1. Фильтруем задачи через DoR. 2. Оцениваем используя “Story points calibration scale”. 3. Учитываем все стадии разработки в оценке задачи. (FE, BE, QA)
- 20. Приоритезация задач Ошибки: 1. Неважные и ненужные задачи попадают в разработку. 2. Как приоритезировать равные по размеру задачи? 3. «Моя задача самая важная и точка». Решения: 1. Используем методы приоритезации: MoSCoW, Метод Сауро, Модель Кано, Метод Парето, Диаграмма Исикавы. 2. Определяем ценность каждой задачи ($-$$- $$$). 3. Квотирование времени для пожеланий.
- 21. Планирование итераций Ошибки: 1. Забиваем спринты под завязку. 2. Дисбаланс между тех. и бизнес тасками. 3. Не фокусируем команду внутри итерации. Решения: 1. Сбавляем давление на команду. Учет рисков в capacity. 2. Квотируем задач на итерацию (70% бизнес задачи, 15% тех. Таски, 10% баги с прошлого спринта, 5% на баги с текущего спринта). 3. Выделяем и фиксируем 2-3 цели итерации.
- 22. Приемка результатов работы Ошибки: 1. Просмотр выполненной задачи только на демо. 2. Приемка наполовину готовой задачи. Решения: 1. Пересмотр сделанных задач в середине спринта. 2. Не принимаем или разбиваем задачу на 2 части.
- 23. Демо выполненной работы Ошибки: 1. Первый раз показываем функционал на общем демо. 2. Приглашаем посторонних людей на демо спринта. 3. Акцент не на тех вещах во время демо. Решения: 1. Показываем сначала в личном порядке, а потом на демо. 2. Проводим отдельно демо с командой и с заинтересованными сторонами. 3. Прописываем сценарий демо.
- 24. Участие в командных мероприятиях Ошибки: 1. Не посещаем командные мероприятия. 2. Недоступны для связи. 3. Не следим за временем мероприятия. Решения: 1. По возможности посещаем все мероприятия с командой. 2. Всегда быть доступным для связи с командой. 3. Выделяем под митинги строго фиксированное время + высылаем агенду. Строго соблюдаем регламент + используем техники фасилитации.
- 25. Постоянное усовершенствование команды Ошибки: 1. Не распространяем знания о предметной области. 2. Строго следуем процессу. Решения: 1. Проводим обучение и семинары (Бизнес, процессы, видение и т.д.) 2. Экспериментируем и пробуем новые техники работы.
- 26. Не бойтесь меняться и совершенствоваться! Спасибо за внимание!
Editor's Notes
- Всем добрый день. Меня зовут Андрей Мандрика и сегодня мы поговорим с вами о такой роли в аджайл проектах как Продакт овнер. Данная роль мне особо близка ибо последние 2 года я занимаю именно эту позицию. За данный период очень много чего поменялось как в моей работе, в окружении, в используемых подходах так и вообще в моем мировозрении относительно этой роли и ее месте в жизни организации, проекта и наконец, самого продукта. На моем пути были разные моменты, как успешные так и не совсем. Поэтому сегодня я хочу с вами поделиться моими наблюдениями и взглядами, относительно основных проблем, которые ведут к факапам на каждом из этапов развития продуктового бизнеса, и самое главное – теми решениями, с помощью которых я лично решал те или иные проблемы.
- Итак начнем наверное с самого главного – определим, кто же такой этот Продакт овнер. На самом деле, готовясь к данному докладу я нашел порядка 10 разных трактовок данного термина, которые были порой абсолютно противоположными, но все они были правильными и отображали разные стороны этой загадочной но манящей персоны. Например, если рассматривать классическую формулировку из СкрамГайда, то продакт овнер – это проектная роль в методологии Scrum, ответственная за сбор требований к продукту, документирование требований в форме пользовательских историй, задание приоритета историям и приемку функциональности, реализованной командой…». Скажите, что не правда? – да нет же, все как есть. И требования ты собираешь (если это можно так назвать). Вообще, мне очень нравится фраза «Сбор требований». Ну честно, такое чувство, что требования как грибы на лесной поляне, на которую ты зашел дивным весенним деньком и под приятные, теплые лучики солнца наполнил свою корзинку красивыми требованиями. Чепуха. В реальной жизни, в большинстве случаев, так не бывает и порой приходится эти требовования прямо выбивать и выдирать у заказчиков и пользователей. А если не выбивать то просеивать огромную простыню несуразной речи. Ну это так, о наболевшем=) Все остальные пункты тоже отчасти верны, но отчасти. Поэтому пока не будем про них. Но в данной формулировке нету самого главного…
- Что продакт овнер, это в первую очередь роль в организации, которая владеет неким продуктом от этой же организации и несет всю ответственность за его развитие и дальнейшую реализацию. По сравнению с предыдущей трактовкой эта выглядит как какая-то крайность. В некоторых ситуациях так и есть. И как показывает практика, многие продакт овнеры действительно не владеют своим продуктом. Хм… Кто же они тогда такие? Для того, чтобы разобраться в этом, предлагаю рассмотреть следующее очень смежное и важнейшее понятие. Это продукт!
- Понятие продукта можно тоже рассмотреть с двух сторон. Со стороны потребителей или пользователей и со стороны организации в условиях которой и используя активы которой и разрабатывается этот продукт. Со стороны пользователей Продукт – это некое решение проблемы или удовлетворение потребности потребителя в чем-либо. Для организации же Продукт – это то, что приносит ей прибыль, которую предприятие может потратить для разработки новых продуктов или удовлетворение каких-то других бизнес целей. То есть и там и там продукт удовлетворяет чьи-то потребности. Не стоит это забывать.
- Также, очевидно что многие продукты, будь то упаковка йогурта, связка бананов или ерп система не есть монолитными и порой состоят из огромного количества возможностей и составных частей. При чем некоторые продукты могут принести ценность пользователю только в полном виде, не имея хотя бы одной ключевой возможности такой продукт не нужен. Например, представьте себе пакет или бутылку молока, которую нельзя закрыть крышкой или крышка вообще отсутствует. Такой продукт будет поистинне тяжело использовать по назначению. Но есть и продукты, где каждая отдельная возможность может быть ценна пользователям как сама по себе так и составе продукта. Например, представьте себе програмное обеспечение для автоматизации банковского дела, в большей части такие программы содержат в себе возможности для деятельности отдела анти-фрод, что служит для обнаружения мошенников. И даже такая возможность может содержать в себе много составных частей. Например, профайл клиента и онлайн монитор с действиями всех клиентов, который используется для обнаружения подозрительных операций. Я не просто так тут филосовствую на тему продукта и так далее, ибо не понимая, что это такое и для чего он создается нельзя до конца понять, как можно им владеть.
- Соответственно, исходя из вышеперечисленного можно выделить 3 типа овнеров или владельцев. Это именно продакт овнер, фича и компонент овнеры. Конечно, для какого-то маленького продукта скорее всего данная схему будет не очень востребована, но если речь идет о продукте, о программном продукте в разработке которого учавствует 3 и более команд, то этот подход есть вполне приемлимым. Вот представьте себе некое платформенное решение в котором есть кор система, модуль операционной дейтельности и клиентский сайт. Достаточно тяжело силами одной роли держать в голове всю стратегическую и тактическую информацию, и при этом, превращать ее в решение для удовлетворение пользователей по таким трем разным направлениям. Поэтому, дабы организации быть эффективной необходимо делегировать и декомпозировать ответственность на разных уровнях некой иерархии. Данная схема, подсмотренная мной у Романа Пичлера есть достаточно универсальной и может подойти для большинства средне-крупных продуктов.Также, она отлично масштабируется в аджайл окружении правда с использованием разных названий для выделенных ролей.
- Например, вот представлена достаточно упрощенная Хенриком Книбергом схема использования аджайла на уровне средне-большой организации. Все достаточно просто. В третьей версии данного фреймворка есть 3 уровня иерархии: портфель, программа и команда. На уровне портфеля отвечают за развитие всего
- Согласно тому же СкрамГайду и здравому смыслу можно выделить 12 основных обязанностей классического продакт овнера в скраме. Тут хотелось бы сделать акцент именно на слове «Основных». Вроде все предельно просто но, как говорится, дьявол кроется в деталях. Поэтому давайте пройдемся по каждому пункту и определим, какие аспекты ведут к факапу, а какие к действительно успешному продукту.
- Первое и как по мне, самое основное – это видение продукта. Не имея четко визуализированной цели, для чего мы это делаем – невозможно сделать толковую вещь. Цель это как маяк в бушующем море, если постоянно не держать его в поле зрения, то тебя точно заведет не туда. И это очень распространенная проблема среди разного рода руководителей, которые причастны к разработке продуктов. А как следствие этого и получается, что 60% всех продуктов не удовлетворяют потребности их пользователей. Одной из основных причин, почему так происходит есть именно не понимание потребностей ваших пользователей. Ну логично, если вы не знаете, что надо этим надоедливым пользователям - то как вы можете-то что-то полезное сотворить для них. Еще одной распространенной ошибкой есть подход – «Работа ради работы, процесс ради процесса». Да, может быть это и успешно работает в аутсорсинговых компаниях, но в продуктовых – это неприемлемо. Что же надо сделать, чтобы исправить данную ситуацию? 1) постарайтесь понять ваших пользователей, прочувствуйте всю их боль. Затем выработайте решение для унытия этой боли и обязательно запишите это. Еще лучше – составьте документ с вашим видением этого решения, этого продукта. А после составление такого документа попробуйте разбить вашу цель на некоторые осязаемые части. Для каждой из этих частей также можно создать по документу с видением. Таким образом вы сможете обосновать любой кусочек в вашем продукте и никогда не потеряете фокус.
- Очень простой и эффективный шаблон был придуман Романом Пичлером. Данные документ состоит из 5 пунктов – краткое описание продукта. Желательно чтобы здесь уже были какие-то рамки. Например, если нашим продуктом является басейн на крыше торгового центра, то давайте так и скажем, что басейн – а не бар возле байсена. Это поможет сфокусироваться на главном. Затем, для кого мы делаем этот продукт, кто будет им пользоваться. Да, конечно есть множество продуктов, целевая аудитория которых насчитывает миллионы пользователей, но поверьте у этих пользователей будет что-то общее, как минимум то, что они пользуются вашим продуктом=). Зафиксируйте нужды этих пользователей. Зачем им ваш продукт? Что они будут с ним делать. Топ 5 фич в продукте. Тут не надо описывать все. Достаточно будет, только идей для ключевого функционала. А также, опишите тут – чем уникальны эти фичи. От этого можно будет отталкиваться при дальнейшей маркетинговой комапнии, если такая имеет место быть. И конечно же велью. Как мы уже разобрались, что продукт всегда должен удовлетворять пользователей и компанию, в которой он создается. Поэтому последним пунктом опишите, чем данный продукт ценен для вашей компании. Это очень хорошая отправная точка для управления приоритетами внутри вашей организации. Конечно, данный документ можно дополнять и какими-то своими пунктами. Например, у нас в подобном документе мы еще описываем как данный продукт повлияет на текущий бизнес процесс клиента и какие есть первоначальные ограничения и риски. В общем если у вас до сих пор нету подобного документа, но тем не менее вы хотите разработать успешный продукт – быстрее это сделайте.
- Первое и как по мне, самое основное – это видение продукта. Не имея четко визуализированной цели, для чего мы это делаем – невозможно сделать толковую вещь. Цель это как маяк в бушующем море, если постоянно не держать его в поле зрения, то тебя точно заведет не туда. И это очень распространенная проблема среди разного рода руководителей, которые причастны к разработке продуктов. А как следствие этого и получается, что 60% всех продуктов не удовлетворяют потребности их пользователей. Одной из основных причин, почему так происходит есть именно не понимание потребностей ваших пользователей. Ну логично, если вы не знаете, что надо этим надоедливым пользователям - то как вы можете-то что-то полезное сотворить для них. Еще одной распространенной ошибкой есть подход – «Работа ради работы, процесс ради процесса». Да, может быть это и успешно работает в аутсорсинговых компаниях, но в продуктовых – это неприемлемо. Что же надо сделать, чтобы исправить данную ситуацию? 1) постарайтесь понять ваших пользователей, прочувствуйте всю их боль. Затем выработайте решение для унытия этой боли и обязательно запишите это. Еще лучше – составьте документ с вашим видением этого решения, этого продукта. А после составление такого документа попробуйте разбить вашу цель на некоторые осязаемые части. Для каждой из этих частей также можно создать по документу с видением. Таким образом вы сможете обосновать любой кусочек в вашем продукте и никогда не потеряете фокус.
- В документе с видением мы уже определили целевую аудиторию для нашего продукта. Теперь же надо конкретно определить, кто может каким-либо образом повлиять как на весь продукт, так и на процесс создания вашего продукта. Представьте себе ситуацию, что высоздаете программный продукт для уже существующего и работающего бизнеса с достаточно большим количеством департаментов и линейных руководителей. Ваш продукт затрагивает деятельность нескольких отделов. Где-то больше, где-то меньше. И вот в ходе разработки вы учли пожелания всех руководителей, кроме одного – на ваш взгляд который меньше всего будет подвержен влиянию внедрения вашего продукта. Но он оказался хорошим другом собственника бизнеса, а поскольку люди бывают разные, некторые очень злопамятные, то даже имея идеальный продукт, данный человек может пойти на принцип. И тогда вероятно, что у вас появятся некому не нужные проблемы. Поэтому в ваших же интересах, как можно раньше идентифицировать всех людей, которые тем или иным образом могут повлиять на вашу деятельность. Также, не стоит забывать, что заинтересованные стороны могут быть не только внешними, но и внутренними. Например, ваш саппорт. С продуктом по прежнему все отлично, но для представителя саппорта вы забыли предусмотреть средства поддержки – и опять ваше релиз затягивается. Плюс, человек так устроен, что он любит чувствовать себя важным и влиятельным – так дайте же эту возможность вашим заинтересованным сторонам, я не говорю делать абсолютно все что они вам говорят, но показать, что его мнение важно и очень ценно для вас – это еще никому не помешало. Да аджайл нам мало что говорит об управлении стейкхолдерами, но поверьте – эта практика уже неоднократно доказала свою полезность, в том числе в классическом управлении проектами. Так почему бы этим не воспользоваться. Для этого я предлагаю попробовать следующие инструменты.
- Вот могу вам предложить неплохой шаблон, которым лично я пользуюсь и который помогает держать информацию о всех заинтересованных сторонах в одном месте. Что еще надо понимать, так что данный документ лучше не выкладывать в публичный доступ, ибо если его увидит один из заинтерсованных сторон, то возможно ему не понравится что-либо и опять же будут проблемы. А наша цель с наименьей затратой ресурсов реализовать наш продукт. И это нам совсем ни к чему=) Относительно данного документа то обратите внимание на вот эти 3 колонки. Значения в них будут определять каким образом вам надо действовать с тем или иным человеком. Например, человек с большим влиянием на продукт и с одновременно большим интересом к этому продукту должен быть удовлетворен продуктом и его требования должны быть учтены в первую очередь.
- В документе с видением мы уже определили целевую аудиторию для нашего продукта. Теперь же надо конкретно определить, кто может каким-либо образом повлиять как на весь продукт, так и на процесс создания вашего продукта. Представьте себе ситуацию, что высоздаете программный продукт для уже существующего и работающего бизнеса с достаточно большим количеством департаментов и линейных руководителей. Ваш продукт затрагивает деятельность нескольких отделов. Где-то больше, где-то меньше. И вот в ходе разработки вы учли пожелания всех руководителей, кроме одного – на ваш взгляд который меньше всего будет подвержен влиянию внедрения вашего продукта. Но он оказался хорошим другом собственника бизнеса, а поскольку люди бывают разные, некторые очень злопамятные, то даже имея идеальный продукт, данный человек может пойти на принцип. И тогда вероятно, что у вас появятся некому не нужные проблемы. Поэтому в ваших же интересах, как можно раньше идентифицировать всех людей, которые тем или иным образом могут повлиять на вашу деятельность. Также, не стоит забывать, что заинтересованные стороны могут быть не только внешними, но и внутренними. Например, ваш саппорт. С продуктом по прежнему все отлично, но для представителя саппорта вы забыли предусмотреть средства поддержки – и опять ваше релиз затягивается. Плюс, человек так устроен, что он любит чувствовать себя важным и влиятельным – так дайте же эту возможность вашим заинтересованным сторонам, я не говорю делать абсолютно все что они вам говорят, но показать, что его мнение важно и очень ценно для вас – это еще никому не помешало. Да аджайл нам мало что говорит об управлении стейкхолдерами, но поверьте – эта практика уже неоднократно доказала свою полезность, в том числе в классическом управлении проектами. Так почему бы этим не воспользоваться. Для этого я предлагаю попробовать следующие инструменты.