Lviv PMDay 2016 S Андрій Мандріка: "Шлях Product Owner`a. Від факапів до успішного продукту"

Editor's Notes

• #2: Всем добрый день. Меня зовут Андрей Мандрика и сегодня мы поговорим с вами о такой роли в аджайл проектах как Продакт овнер. Данная роль мне особо близка ибо последние 2 года я занимаю именно эту позицию. За данный период очень много чего поменялось как в моей работе, в окружении, в используемых подходах так и вообще в моем мировозрении относительно этой роли и ее месте в жизни организации, проекта и наконец, самого продукта. На моем пути были разные моменты, как успешные так и не совсем. Поэтому сегодня я хочу с вами поделиться моими наблюдениями и взглядами, ведь всегда лучше учиться на чужих ошибках, нежели на своих собстенных.
• #3: Итак начнем наверное с самого главного – определим, кто же такой этот Продакт овнер. На самом деле, готовясь к данному докладу я нашел порядка 10 разных трактовок данного термина, которые были порой абсолютно противоположными, но все они были правильными и отображали разные стороны этой загадочной но манящей персоны. Например, если рассматривать классическую формалировку из СкрамГайда, то продакт овнер – это проектная роль в методологии Scrum, ответственная за сбор требований к продукту, документирование требований в форме пользовательских историй, задание приоритета историям и приемку функциональности, реализованной командой…». Скажите, что не правда? – да нет же, все как есть. И требования ты собираешь (если это можно так назвать). Вообще, мне очень нравится фраза «Сбор требований». Ну честно, такое чувство, что требования как грибы на лесной поляне, на которую ты зашел дивным весенним деньком и под приятные, теплые лучики солнца наполнил свою корзинку красивыми требованиями. Чепуха. В реальной жизни, в большинстве случаев, так не бывает и порой приходится эти требовования прямо выбивать и выдирать у заказчиков и пользователей. А если не выбивать то просеивать огромную простыню несуразной речи. Ну это так, о наболевшем=) Все остальные пункты тоже отчасти верны, но отчасти. Поэтому пока не будем про них. Но в данной формулировке нету самого главного…
• #4: Что продакт овнер, это в первую очередь роль в организации, которая владеет неким продуктом от этой же организации и несет всю ответственность за его развитие и дальнейшую реализацию. По сравнению с предыдущей трактовкой эта выглядит как какая-то крайность. В некоторых ситуациях так и есть. И как показывает практика, многие продакт овнеры действительно не владеют своим продуктом. Хм… Кто же они тогда такие? Для того, чтобы разобраться в этом, предлагаю рассмотреть следующее очень смежное и важнейшее понятие. Это продукт!
• #5: Понятие продукта можно тоже рассмотреть с двух сторон. Со стороны потребителей или пользователей и со стороны организации в условиях которой и используя активы которой и разрабатывается этот продукт. Со стороны пользователей Продукт – это некое решение проблемы или удовлетворение потребности потребителя в чем-либо. Для организации же Продукт – это то, что приносит ей прибыль, которую предприятие может потратить для разработки новых продуктов или удовлетворение каких-то дургих бизнес целей. То есть и там и там продукт удовлетворяет чьи-то потребности. Не стоит это забывать. Я бы ваще рекомендовал вам, независимо от вашей роли, перед началом любого действия задать себе вопрос. А решит ли это действие проблему пользоваталя? а будет ли он удовлетворен? Поверьте, порой такой простой вопрос очень сильно отрезвляет и позволяет посмотреть на вещи совсем с другой точки зрения. Таким образом владелец продукта должен постоянно балансировать между ценностью для потребителей и ценностью для его бизнеса. Но неужели это все? На самом деле нет, давайте тогда попробуем определить за что еще владелец продукта должен нести ответственность?
• #6: Для начала скажу пару слов о той комапнии, где и происходили все эти замечательные изменения давно знакомой роли продакт овнера. Как я уже скзаал, последние 2 года работаю в одной украинской продуктовой компании под название Бетлаб. Наша компания занимается разработкой комплексных решений для автоматизации иГейминг бизнеса, в частности спорт беттинга или букмекерства. На данном этапе мы уже имеем реализованную платформу, которая включает в себя как множество больших фич, так и еще большее количество составных элементов. Основные фичи и сотавные блоки показаны на схеме. Но 2 года назад все начиналось с самого нуля. Исходными данными у нас было то, что на тот момент подобной платформы еще не было в мире, и был действующий клиент который согласился первый испробовать на себе данное программное обеспечение, конечно если оно будет готово. В общем мы собрали команду людей, каждый из которых в прошлом так или иначе сталкивался с букмекерскиим бизнесом. Работать мы решили по скраму, при этом не имея раньше подобного опыта. Хотя уже тогда определенные участники команды разделяли принципы аджайл. Но отдельные – это еще не все. Поэтому дальше нас ждала долгая и безумная дорога на пути к полноценной аджайл трансформации. До текущего момента за полтора года работы нам пришлось пройти несколько этапов нашего развития. Дальше мы кратко пройдемся по каждому из них и определим как менялась роль и работа продакт овнера.
• #8: Согласно тому же СкрамГайду и здравому смыслу можно выделить 12 основных обязанностей классического продакт овнера в скраме. Тут хотелось бы сделать акцент именно на слове «Основных». Вроде все предельно просто но, как говорится, дьявол кроется в деталях. Поэтому давайте пройдемся по каждому пункту и определим, какие аспекты ведут к факапу, а какие к действительно успешному продукту.
• #9: Первое и как по мне, самое основное – это видение продукта. Не имея четко визуализированной цели, для чего мы это делаем – невозможно сделать толковую вещь. Цель это как маяк в бушующем море, если постоянно не держать его в поле зрения, то тебя точно заведет не туда. И это очень распространенная проблема среди разного рода руководителей, которые причастны к разработке продуктов. А как следствие этого и получается, что 60% всех продуктов не удовлетворяют потребности их пользователей. Одной из основных причин, почему так происходит есть именно не понимание потребностей ваших пользователей. Ну логично, если вы не знаете, что надо этим надоедливым пользователям - то как вы можете-то что-то полезное сотворить для них. Еще одной распространенной ошибкой есть подход – «Работа ради работы, процесс ради процесса». Да, может быть это и успешно работает в аутсорсинговых компаниях, но в продуктовых – это неприемлемо. Что же надо сделать, чтобы исправить данную ситуацию? 1) постарайтесь понять ваших пользователей, прочувствуйте всю их боль. Затем выработайте решение для унытия этой боли и обязательно запишите это. Еще лучше – составьте документ с вашим видением этого решения, этого продукта. А после составление такого документа попробуйте разбить вашу цель на некоторые осязаемые части. Для каждой из этих частей также можно создать по документу с видением. Таким образом вы сможете обосновать любой кусочек в вашем продукте и никогда не потеряете фокус.
• #10: Очень простой и эффективный шаблон был придуман Романом Пичлером. Данные документ состоит из 5 пунктов – краткое описание продукта. Желательно чтобы здесь уже были какие-то рамки. Например, если нашим продуктом является басейн на крыше торгового центра, то давайте так и скажем, что басейн – а не бар возле байсена. Это поможет сфокусироваться на главном. Затем, для кого мы делаем этот продукт, кто будет им пользоваться. Да, конечно есть множество продуктов, целевая аудитория которых насчитывает миллионы пользователей, но поверьте у этих пользователей будет что-то общее, как минимум то, что они пользуются вашим продуктом=). Зафиксируйте нужды этих пользователей. Зачем им ваш продукт? Что они будут с ним делать.Топ 5 фич в продукте. Тут не надо описывать все. Достаточно будет, только идей для ключевого функционала. А также, опишите тут – чем уникальны эти фичи. От этого можно будет отталкиваться при дальнейшей маркетинговой комапнии, если такая имеет место быть. И конечно же велью. Как мы уже разобрались, что продукт всегда должен удовлетворять пользователей и компанию, в которой он создается. Поэтому последним пунктом опишите, чем данный продукт ценен для вашей компании. Это очень хорошая отправная точка для управления приоритетами внутри вашей организации. Конечно, данный документ можно дополнять и какими-то своими пунктами. Например, у нас в подобном документе мы еще описываем как данный продукт повлияет на текущий бизнес процесс клиента и какие есть первоначальные ограничения и риски. В общем если у вас до сих пор нету подобного документа, но тем не менее вы хотите разработать успешный продукт – быстрее это сделайте.
• #11: В документе с видением мы уже определили целевую аудиторию для нашего продукта. Теперь же надо конкретно определить, кто может каким-либо образом повлиять как на весь продукт, так и на процесс создания вашего продукта. Представьте себе ситуацию, что высоздаете программный продукт для уже существующего и работающего бизнеса с достаточно большим количеством департаментов и линейных руководителей. Ваш продукт затрагивает деятельность нескольких отделов. Где-то больше, где-то меньше. И вот в ходе разработки вы учли пожелания всех руководителей, кроме одного – на ваш взгляд который меньше всего будет подвержен влиянию внедрения вашего продукта. Но он оказался хорошим другом собственника бизнеса, а поскольку люди бывают разные, некторые очень злопамятные, то даже имея идеальный продукт, данный человек может пойти на принцип. И тогда вероятно, что у вас появятся некому не нужные проблемы. Поэтому в ваших же интересах, как можно раньше идентифицировать всех людей, которые тем или иным образом могут повлиять на вашу деятельность. Также, не стоит забывать, что заинтересованные стороны могут быть не только внешними, но и внутренними. Например, ваш саппорт. С продуктом по прежнему все отлично, но для представителя саппорта вы забыли предусмотреть средства поддержки – и опять ваше релиз затягивается. Плюс, человек так устроен, что он любит чувствовать себя важным и влиятельным – так дайте же эту возможность вашим заинтересованным сторонам, я не говорю делать абсолютно все что они вам говорят, но показать, что его мнение важно и очень ценно для вас – это еще никому не помешало. Да аджайл нам мало что говорит об управлении стейкхолдерами, но поверьте – эта практика уже неоднократно доказала свою полезность, в том числе в классическом управлении проектами. Так почему бы этим не воспользоваться. Для этого я предлагаю попробовать следующие инструменты.
• #12: Вот могу вам предложить неплохой шаблон, которым лично я пользуюсь и который помогает держать информацию о всех заинтересованных сторонах в одном месте. Что еще надо понимать, так что данный документ лучше не выкладывать в публичный доступ, ибо если его увидит один из заинтерсованных сторон, то возможно ему не понравится что-либо и опять же будут проблемы. А наша цель с наименьей затратой ресурсов реализовать наш продукт. И это нам совсем ни к чему=) Относительно данного документа то обратите внимание на вот эти 3 колонки. Значения в них будут определять каким образом вам надо действовать с тем или иным человеком. Например, человек с большим влиянием на продукт и с одновременно большим интересом к этому продукту должен быть удовлетворен продуктом и его требования должны быть учтены в первую очередь.