Lviv PMDay 2016 S Андрій Мандріка: "Шлях Product Owner`a. Від факапів до успішного продукту"
•Download as PPTX, PDF•
0 likes•200 views
Андрій Мандріка: Шлях Product Owner`a. Від факапів до успішного продукту
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Lviv PMDay 2016 S Андрій Мандріка: "Шлях Product Owner`a. Від факапів до успішного продукту"
Similar to Lviv PMDay 2016 S Андрій Мандріка: "Шлях Product Owner`a. Від факапів до успішного продукту" (20)
More from Lviv Startup Club
More from Lviv Startup Club (20)
Lviv PMDay 2016 S Андрій Мандріка: "Шлях Product Owner`a. Від факапів до успішного продукту"
- 1. Путь Product Owner`а. От факапов до успешного продукта Мандрика Андрей, CSPO Product owner,
- 2. «Product Owner». Кто это такой? «Владелец продукта (Product Owner) - проектная роль в методологии Scrum, ответственная за сбор требований к продукту, документирование требований в форме пользовательских историй, задание приоритета историям и приемку функциональности, реализованной командой…»
- 3. «Product Owner». Кто это такой? «Владелец продукта (Product Owner) – персона, которая владеет определенным продуктом от имени организации.»
- 4. А что такое продукт? Направлен на решение проблемы и/или получение выгоды для пользователя/ клиента Создает прибыль, позволяет разрабатывать новые продукты или бизнес цели организации. Создает ценность
- 5. Channels SportsbookTrading ToolsMath Core CRM Payments Wallet Marketing Risks management
- 7. Потенциальные обязанности Product Owner`a 1. Должен иметь и распространять видение продукта. 2. Общение с заинтересованными сторонами и синхронизация их интересов. 3. Определение и формализация требований. 4. Организация, заполнение и приоритезация беклога. 5. Планирование итераций и ведение груммингов. 6. Определение целей на итерации и релизы. 7. Консультация и объяснение сути задач для команд(ы). 8. Приемка результатов выполненных командой. 9. Определение успешности итераций для команды, заинт. сторон и бизнеса. 10. Участие в командных мероприятиях. 11. Презентация выполненной работы. 12. Создание условия для усовершенствования работы команд(ы)
- 8. Видение продукта Проблемы: 1. Не знаем конечную цель. 2. Не понимаем потребностей и проблем пользователей. 3. Большая рас фокусировка. Решения: 1. Составляем Vision document. 2. Изучаем текущие бизнес процессы. 3. Выделяем MVP.
- 10. Заинтересованные стороны Проблемы: 1. Не знаем всех заинтересованных сторон. 2. Отсутствие интереса к незаконченному продукту. 3. Мнения разных сторон противоречат друг другу. Решения: 1. Составляем матрицу заинтересованных сторон. 2. Вовлекаем стороны в процесс разработки. 3. Показываем ценность каждого решения.
- 12. Сбор требований Проблемы: 1. Сами придумываем требования. 2. Непомерные желания заказчиков. 3. Слишком много входов для требований. Решения: 1. Валидируем все требования с заказчиком. 2. Не теряем цель из поля зрения. 3. Приоритезируем и движемся поэтапно.
- 13. Описание требований Проблемы: 1. Требования не достаточно описаны. 2. Требования разбиты на большие части. 3. Тяжело визуализировать требования. Решения: 1. Внедряем AC, DoR, DoD. 2. Совместная декомпозиции требований вместе с командой. 3. Практикуем дудление и макапы.
- 14. Организация беклога Проблемы: 1. Не видны взаимосвязи между задачами. 2. User story не позволяют оценить всю картину. 3. По мере увеличения беклога теряется фокусировка. Решения: 1. Используем линки и флаги. 2. Добавляем уровни иерархии. Jira+Structure: (Themes -> Initiatives -> Epics -> User stories) 3. Добавляем Milestones и считаем прогресс.
- 15. Приоритезация задач Проблемы: 1. Неважные и ненужные задачи попадают в разработку. 2. Как приоритезировать равные по размеру задачи? 3. Разные приоритеты у разных команд. Решения: 1. Используем MoSCoW метод. 2. Определяем ценность каждой задачи ($-$$- $$$). 3. Квотирование времени для другой команды.
- 16. Грумминг задач Проблемы: 1. «Ну описание я потом допишу…» 2. Не понимание сколько стоит задача. 3. Завышенные оценки задач. Решения: 1. Фильтруем задачи через DoR. 2. Оцениваем используя “Story points calibration scale”. 3. Декомпозируем задачи + техническая проработка перед груммингом.
- 17. Планирование итераций Проблемы:. 1. Постоянное уменьшение velocity команды. 2. Дисбаланс между тех. и бизнес тасками. 3. Рас фокусировка команды внутри итерации. Решения: 1. Сбавляем давление на команду. Учет рисков в capacity. 2. Квотируем задач на итерацию (70% бизнес задачи, 15% тех. Таски, 10% баги с прошлого спринта, 5% на баги с текущего спринта). 3. Выделяем и фиксируем цели итерации.
- 18. Приемка результатов работы Проблемы: 1. Работа выполнена не так как ожидалось. 2. Сделаны не все задачи. 3. Задача разработана, но не протестирована. Решения: 1. Пересмотр сделанных задач в середине спринта. 2. Не загружаем спринты под завязку. 3. Учитываем все стадии разработки в оценке задачи. (FE, BE, QA)
- 19. Участие в командных мероприятиях Проблемы: 1. Не понимание значения обязательных мероприятий в Скраме. 2. Митинги затягиваются по времени. 3. Митинги превращаются в балаган. Решения: 1. Безукоризненно соблюдаем все практики. 2. Выделяем под митинги строго фиксированное время + высылаем агенду. 3. Строго соблюдаем регламент + используем техники фасилитации.
- 20. Демо выполненной работы Проблемы: 1. «Эффект демо» или ничего не работает. 2. Деплой за 5 минут до демо. 3. Акцент не на тех вещах. Решения: 1. Выделяем ответственного за демо + заводим задачу на подготовку. 2. Код фриз за 1-2 дня до демо. 3. Прописываем сценарий демо.
- 21. Постоянное усовершенствование команды Проблемы: 1. Бесполезные ретроспективы. 2. Команда не развивается. Решения: 1. Составляем экшн план на следующую итерацию + начинаем ретро с валидации сделанного. 2. Проводим обучение и семинары (Бизнес, процессы, технологии и т.д.)
- 22. Не бойтесь меняться и совершенствоваться!
- 23. Спасибо за внимание! Andrii Mandrika Business Analyst / Product owner Contacts: • andrii.mandrika@gmail.com • andrey.mandrika@betlab.com • linkedin.com/in/andrii-mandrika • Skype: mandrikaandrew
Editor's Notes
- Всем добрый день. Меня зовут Андрей Мандрика и сегодня мы поговорим с вами о такой роли в аджайл проектах как Продакт овнер. Данная роль мне особо близка ибо последние 2 года я занимаю именно эту позицию. За данный период очень много чего поменялось как в моей работе, в окружении, в используемых подходах так и вообще в моем мировозрении относительно этой роли и ее месте в жизни организации, проекта и наконец, самого продукта. На моем пути были разные моменты, как успешные так и не совсем. Поэтому сегодня я хочу с вами поделиться моими наблюдениями и взглядами, ведь всегда лучше учиться на чужих ошибках, нежели на своих собстенных.
- Итак начнем наверное с самого главного – определим, кто же такой этот Продакт овнер. На самом деле, готовясь к данному докладу я нашел порядка 10 разных трактовок данного термина, которые были порой абсолютно противоположными, но все они были правильными и отображали разные стороны этой загадочной но манящей персоны. Например, если рассматривать классическую формалировку из СкрамГайда, то продакт овнер – это проектная роль в методологии Scrum, ответственная за сбор требований к продукту, документирование требований в форме пользовательских историй, задание приоритета историям и приемку функциональности, реализованной командой…». Скажите, что не правда? – да нет же, все как есть. И требования ты собираешь (если это можно так назвать). Вообще, мне очень нравится фраза «Сбор требований». Ну честно, такое чувство, что требования как грибы на лесной поляне, на которую ты зашел дивным весенним деньком и под приятные, теплые лучики солнца наполнил свою корзинку красивыми требованиями. Чепуха. В реальной жизни, в большинстве случаев, так не бывает и порой приходится эти требовования прямо выбивать и выдирать у заказчиков и пользователей. А если не выбивать то просеивать огромную простыню несуразной речи. Ну это так, о наболевшем=) Все остальные пункты тоже отчасти верны, но отчасти. Поэтому пока не будем про них. Но в данной формулировке нету самого главного…
- Что продакт овнер, это в первую очередь роль в организации, которая владеет неким продуктом от этой же организации и несет всю ответственность за его развитие и дальнейшую реализацию. По сравнению с предыдущей трактовкой эта выглядит как какая-то крайность. В некоторых ситуациях так и есть. И как показывает практика, многие продакт овнеры действительно не владеют своим продуктом. Хм… Кто же они тогда такие? Для того, чтобы разобраться в этом, предлагаю рассмотреть следующее очень смежное и важнейшее понятие. Это продукт!
- Понятие продукта можно тоже рассмотреть с двух сторон. Со стороны потребителей или пользователей и со стороны организации в условиях которой и используя активы которой и разрабатывается этот продукт. Со стороны пользователей Продукт – это некое решение проблемы или удовлетворение потребности потребителя в чем-либо. Для организации же Продукт – это то, что приносит ей прибыль, которую предприятие может потратить для разработки новых продуктов или удовлетворение каких-то дургих бизнес целей. То есть и там и там продукт удовлетворяет чьи-то потребности. Не стоит это забывать. Я бы ваще рекомендовал вам, независимо от вашей роли, перед началом любого действия задать себе вопрос. А решит ли это действие проблему пользоваталя? а будет ли он удовлетворен? Поверьте, порой такой простой вопрос очень сильно отрезвляет и позволяет посмотреть на вещи совсем с другой точки зрения. Таким образом владелец продукта должен постоянно балансировать между ценностью для потребителей и ценностью для его бизнеса. Но неужели это все? На самом деле нет, давайте тогда попробуем определить за что еще владелец продукта должен нести ответственность?
- Для начала скажу пару слов о той комапнии, где и происходили все эти замечательные изменения давно знакомой роли продакт овнера. Как я уже скзаал, последние 2 года работаю в одной украинской продуктовой компании под название Бетлаб. Наша компания занимается разработкой комплексных решений для автоматизации иГейминг бизнеса, в частности спорт беттинга или букмекерства. На данном этапе мы уже имеем реализованную платформу, которая включает в себя как множество больших фич, так и еще большее количество составных элементов. Основные фичи и сотавные блоки показаны на схеме. Но 2 года назад все начиналось с самого нуля. Исходными данными у нас было то, что на тот момент подобной платформы еще не было в мире, и был действующий клиент который согласился первый испробовать на себе данное программное обеспечение, конечно если оно будет готово. В общем мы собрали команду людей, каждый из которых в прошлом так или иначе сталкивался с букмекерскиим бизнесом. Работать мы решили по скраму, при этом не имея раньше подобного опыта. Хотя уже тогда определенные участники команды разделяли принципы аджайл. Но отдельные – это еще не все. Поэтому дальше нас ждала долгая и безумная дорога на пути к полноценной аджайл трансформации. До текущего момента за полтора года работы нам пришлось пройти несколько этапов нашего развития. Дальше мы кратко пройдемся по каждому из них и определим как менялась роль и работа продакт овнера.
- Согласно тому же СкрамГайду и здравому смыслу можно выделить 12 основных обязанностей классического продакт овнера в скраме. Тут хотелось бы сделать акцент именно на слове «Основных». Вроде все предельно просто но, как говорится, дьявол кроется в деталях. Поэтому давайте пройдемся по каждому пункту и определим, какие аспекты ведут к факапу, а какие к действительно успешному продукту.
- Первое и как по мне, самое основное – это видение продукта. Не имея четко визуализированной цели, для чего мы это делаем – невозможно сделать толковую вещь. Цель это как маяк в бушующем море, если постоянно не держать его в поле зрения, то тебя точно заведет не туда. И это очень распространенная проблема среди разного рода руководителей, которые причастны к разработке продуктов. А как следствие этого и получается, что 60% всех продуктов не удовлетворяют потребности их пользователей. Одной из основных причин, почему так происходит есть именно не понимание потребностей ваших пользователей. Ну логично, если вы не знаете, что надо этим надоедливым пользователям - то как вы можете-то что-то полезное сотворить для них. Еще одной распространенной ошибкой есть подход – «Работа ради работы, процесс ради процесса». Да, может быть это и успешно работает в аутсорсинговых компаниях, но в продуктовых – это неприемлемо. Что же надо сделать, чтобы исправить данную ситуацию? 1) постарайтесь понять ваших пользователей, прочувствуйте всю их боль. Затем выработайте решение для унытия этой боли и обязательно запишите это. Еще лучше – составьте документ с вашим видением этого решения, этого продукта. А после составление такого документа попробуйте разбить вашу цель на некоторые осязаемые части. Для каждой из этих частей также можно создать по документу с видением. Таким образом вы сможете обосновать любой кусочек в вашем продукте и никогда не потеряете фокус.
- Очень простой и эффективный шаблон был придуман Романом Пичлером. Данные документ состоит из 5 пунктов – краткое описание продукта. Желательно чтобы здесь уже были какие-то рамки. Например, если нашим продуктом является басейн на крыше торгового центра, то давайте так и скажем, что басейн – а не бар возле байсена. Это поможет сфокусироваться на главном. Затем, для кого мы делаем этот продукт, кто будет им пользоваться. Да, конечно есть множество продуктов, целевая аудитория которых насчитывает миллионы пользователей, но поверьте у этих пользователей будет что-то общее, как минимум то, что они пользуются вашим продуктом=). Зафиксируйте нужды этих пользователей. Зачем им ваш продукт? Что они будут с ним делать. Топ 5 фич в продукте. Тут не надо описывать все. Достаточно будет, только идей для ключевого функционала. А также, опишите тут – чем уникальны эти фичи. От этого можно будет отталкиваться при дальнейшей маркетинговой комапнии, если такая имеет место быть. И конечно же велью. Как мы уже разобрались, что продукт всегда должен удовлетворять пользователей и компанию, в которой он создается. Поэтому последним пунктом опишите, чем данный продукт ценен для вашей компании. Это очень хорошая отправная точка для управления приоритетами внутри вашей организации. Конечно, данный документ можно дополнять и какими-то своими пунктами. Например, у нас в подобном документе мы еще описываем как данный продукт повлияет на текущий бизнес процесс клиента и какие есть первоначальные ограничения и риски. В общем если у вас до сих пор нету подобного документа, но тем не менее вы хотите разработать успешный продукт – быстрее это сделайте.
- В документе с видением мы уже определили целевую аудиторию для нашего продукта. Теперь же надо конкретно определить, кто может каким-либо образом повлиять как на весь продукт, так и на процесс создания вашего продукта. Представьте себе ситуацию, что высоздаете программный продукт для уже существующего и работающего бизнеса с достаточно большим количеством департаментов и линейных руководителей. Ваш продукт затрагивает деятельность нескольких отделов. Где-то больше, где-то меньше. И вот в ходе разработки вы учли пожелания всех руководителей, кроме одного – на ваш взгляд который меньше всего будет подвержен влиянию внедрения вашего продукта. Но он оказался хорошим другом собственника бизнеса, а поскольку люди бывают разные, некторые очень злопамятные, то даже имея идеальный продукт, данный человек может пойти на принцип. И тогда вероятно, что у вас появятся некому не нужные проблемы. Поэтому в ваших же интересах, как можно раньше идентифицировать всех людей, которые тем или иным образом могут повлиять на вашу деятельность. Также, не стоит забывать, что заинтересованные стороны могут быть не только внешними, но и внутренними. Например, ваш саппорт. С продуктом по прежнему все отлично, но для представителя саппорта вы забыли предусмотреть средства поддержки – и опять ваше релиз затягивается. Плюс, человек так устроен, что он любит чувствовать себя важным и влиятельным – так дайте же эту возможность вашим заинтересованным сторонам, я не говорю делать абсолютно все что они вам говорят, но показать, что его мнение важно и очень ценно для вас – это еще никому не помешало. Да аджайл нам мало что говорит об управлении стейкхолдерами, но поверьте – эта практика уже неоднократно доказала свою полезность, в том числе в классическом управлении проектами. Так почему бы этим не воспользоваться. Для этого я предлагаю попробовать следующие инструменты.
- Вот могу вам предложить неплохой шаблон, которым лично я пользуюсь и который помогает держать информацию о всех заинтересованных сторонах в одном месте. Что еще надо понимать, так что данный документ лучше не выкладывать в публичный доступ, ибо если его увидит один из заинтерсованных сторон, то возможно ему не понравится что-либо и опять же будут проблемы. А наша цель с наименьей затратой ресурсов реализовать наш продукт. И это нам совсем ни к чему=) Относительно данного документа то обратите внимание на вот эти 3 колонки. Значения в них будут определять каким образом вам надо действовать с тем или иным человеком. Например, человек с большим влиянием на продукт и с одновременно большим интересом к этому продукту должен быть удовлетворен продуктом и его требования должны быть учтены в первую очередь.