Мы сейчас разберем некоторые особенности, которые связаны с ролью этих людей на проекте, решения каких вопросов можно ждать от владельцев бизнеса, а каких ждать не стоит.
О себе
Я партнер компании ScrumTrek, которая одна из первых в СНГ начала помогать компаниям применять Agile. Наша компания большая, и мы в основном помогаем бизнесу не внедрить Scrum, а стать более гибким, может быть, даже сильно гибким в современных условиях. Какие именно инструменты мы применяем, зависит от компании, от возможностей, от наличия определенных ресурсов и компетенций.
Очень много времени мы работали в основном с ИТ-индустрией, но в последнее время мы видим растущую популярность Agile, Scrum и подобных подходов – к их использованию переходят не только ИТ-компании, но и другие отрасли.
- лет 5-6 назад в этом направлении начали двигаться банки;
- последние 3-4 года туда двигаются телекомы и производственные компании;
- и совсем новые тренды – это ритейл-компании и строительство.
Владелец продукта (product owner) – это роль Scrum Framework
Начнем с роли владельца продукта. Это – роль, которая появилась во фреймворке Scrum. До этого были различные другие роли – продуктовик, продуктолог, продукт-менеджер. Но роль владельца продукта вошла в обиход, и сейчас от нее ждут очень разных вещей, иногда очень странных.
Об истоках появления этой роли я сейчас более детально расскажу и расскажу, какие ошибки допускает эта роль.
Я не буду рассказывать про отличия подходов Agile и Водопад, я только скажу, что мы теперь работаем не большими длительными циклами, а запускаем Agile для того, чтобы сократить Time-to-Market.
Основная цель этого – ускорить производство. Представьте, у вас есть производство. Это может быть ИТ-производство, может быть страховое производство, может быть строительное производство, и вы хотите быстрее делать продукт.
Чтобы делать продукт быстрее, мы все долгие этапы пытаемся сократить и в команду включаем все необходимые роли. Это получается дороже, но мы сокращаем время.
По результатам каждого отрезка времени, которые называются итерациями, мы делаем небольшое приращение продукта, которое называется инкремент.
И пользователь потихоньку из несчастного человека превращается в счастливого. А иногда он остается где-то посередине.
Дам краткую характеристику Agile-команды. Она должна быть небольшая, самостоятельная, иметь общую цель. Причем, эта цель должна быть бизнесовая.
Команда должна быть стабильной. Чтобы собрать команду, нужно время. В среднем становление команды занимает 3-6 месяцев. Поэтому если вы делаете короткие проекты, какие-то быстрые с уникальными наборами компетенций возможно формировать стабильную команду не рационально.
Ошибка № 1
Когда мы собираем Agile-команду, мы сокращаем время производства за счет того, что собираем все эти компетенции вместе и вводим в команду уникальную роль Владельца продукта.
Владелец продукта - человек от бизнеса. Но бизнес привык работать по-старому и говорит: «Я заказчик, и вы делаете то, что я сказал». Команда соглашается – это же заказчик так сказал. В данном случае это антипаттерн. Владелец продукта – это не заказчик, это представитель заказчика внутри Scrum команды.
И если вы видите, что заказчик, который стал владельцем продукта, отстранен от команды, что-то не работает. Мы специально берем владельца продукта от бизнеса для того, чтобы сократить коммуникацию между бизнесом и заказчиком.
На слайде показан пример структуры кроссфункциональной команды.
Кроссфункциональная команда – это не все компетенции, еще нужен бизнес заказчик внутри команды.
Как бывает в классическом варианте? Бизнес просит что-то сделать, но если вы не можете это сделать, он просит сделать хотя бы что-то другое. Когда ребята приносят готовый продукт или кусочек продукта, заказчик говорит, что хотел что-то другое. Команда переделывает, но заказчику снова не нравится. Такие циклы иногда повторяются очень часто.
Чтобы этого не было, мы помещаем внутрь команды представителя бизнеса.
Представьте: есть Product Owner, он посередине, но есть заинтересованные лица, есть пользователи и есть ваша кроссфункциональная команда.
- Заинтересованные лица – это, вероятнее всего, заказчики извне, их может быть много.
- Кроссфункциональная команда работает с приоритизированным списком задач, который называется бэклог.
- А владелец продукта – это этот фильтр, который, получая информацию от заинтересованных лиц и от пользователей, принимает определенное решение и, самое важное, запускает продукт в производство.
Но самое интересное, что эта роль может в некоторых случаях при поступлении задачи от заказчика сказать «нет». Но это не просто «нет», это обоснованный отказ, основанный на цифрах и данных.
Product Owner является балансировщиком между задачами пользователей и заинтересованных лиц. Ведь пользователи и заинтересованные лица – это всегда два лагеря.
Простой пример из жизни Facebook:
- акционеры (заказчики) хотят, чтобы в соцсети было много рекламы;
- а пользователи говорят: «Если будет много рекламы, мы этим пользоваться не будем».
И здесь нужно соблюсти баланс: и заказчиков удовлетворить, и пользователей.
Другой пример – про гостиницы.
- Заказчики хотят много клиентов, много денег, поэтому строят большие гостиницы и делают большие комплексы, экономя на стенах и чем-то еще.
- А потребитель хочет, чтобы в комнате у него было тихо, чтобы соседи не кричали, чтобы во время завтрака не надо было стоять в больших очередях.
В случае 1С пример, наверное, будет таким:
- бизнес всегда хочет многим внешним заказчикам продать одно и то же и подороже;
- а внешние заказчики хотят бесплатно и побольше и под себя.
В продвинутых западных странах фокус владельца продукта последнее время смещается в сторону Customer Value (потребительская ценность): когда мы удовлетворяем больше ожиданий пользователей, пользователи довольны, они приносят больше денег. В российских реалиях, к сожалению, пока мы двигаемся в другую сторону: мы пытаемся сделать бизнесовые задачи, не задумываясь о пользователях. Но этот тренд, я думаю, со временем все-таки уйдет, а пока мы немножко отстаем.
Ошибка № 2
Эта ошибка часто встречается на рынке. Приходит важный заказчик и говорит, что надо что-то срочно сделать. И тот заказчик, кто громче кричит, того задачу первой и делают.
Но в этом случае создается не очень здоровая среда. Все заказчики понимают, что крик позволяет приоритизировать задачу и поднять ее выше, и через какое-то время все начинают кричать громче, и момент нагнетания обстановки растет. Роль Product Owner в том, что он должен эту проблему решить, у него должен быть инструмент, который позволит рассчитать, как получить максимальную ценность.
Я дам простой инструмент приоритизации задач, который сейчас на рынке используется очень часто.
- Допустим, есть комбайны на разной степени готовности – в первом случае доделать комбайн стоит 1 день, во втором – 3 дня, а в последнем – 10 дней. Но стоимость доделки одинаковая. Какой комбайн мы первым возьмем в работу? Первый, конечно! Все логично: чем быстрее сделаем, тем быстрее деньги получим.
- Другой пример. Представьте, что любая работа занимает три дня, но бизнес-эффект разный. Какой комбайн возьмем в первую очередь? Тоже первый, потому что все сделаем за 3 дня, но денег мы получим за работу больше.
Независимо от того, используете вы Agile или не используете, есть такой способ приоритизации работ, как WSJF — Weighted Shortest Job First, когда стоимость задержки делится на длительность и получается та задача, которую нужно делать в первую очередь. Это самое ценное, самое простое, то, что дает быструю отдачу.
Допустим, есть две однозначные работы: два заказчика прибежали, один просит сделать полную автоматизацию 1С, а другой – автоматизацию склада. Вроде бы, эффект получится большой, но как понять, какую работу взять первой, какую второй? В этом случае, как раз используя этот коэффициент, можете выстроить диалог с заказчиком таким образом, что мы всегда идем в сторону самых важных и самых коротких задач.
Если задача большая, длинная, но в ней есть какая-то очень большая важность, нам нужно эту работу декомпозировать – выделить ценность, а то, что не нужно, оставить где-нибудь в бэклоге умирать.
Ошибка № 3
Следующая ошибка, которую часто допускают владельцы продукта, – «они просили, мы сделали».
Ребята, а что является результатом вашей работы? Продукт? Достижение цели? А что значит достижение цели? На самом деле – получившийся результат приносит деньги.
Интересный момент. Обычно когда я спрашиваю аудиторию: «Что считается результатом вашей деятельности?» – они говорят: «Фичи, которые работают на проде». Но важно, что фичи не просто стоят на проде, ими еще и пользуются. Это важная цель. Потому что бывает так, что фичи поставили, но никто ими не пользуется.
У меня есть пример одного большого ритейла. Они как раз делают Big Data, BI и все, что с этим связано. Раньше они делали аналитические отчеты, и за последние 5 лет у них накопилось их очень много. Чтобы поддерживать это, у них работает целый отдел на 80 человек. Представляете, сколько отчетов! В итоге они поняли, что так жить нельзя, потому что на создание нового отчета уходит минимум полгода, из-за того, что, делая один, они ломают все остальные. Начали разбираться. Оказалось, 70% отчетов, которые они сделали, пользователи открывали всего 1 или 2 раза. Или вообще, тот заказчик, который заказывал этот отчет, в компании уже давно не работает.
Поэтому еще одна очень важная задача, которую должен делать Product Owner, – не допустить того, что работа, которую делает команда, будет лежать на складе. Он должен выпускать только самое важное и самое ценное.
Команда разработчиков занимается, по большому счету, производством, и это – самое узкое звено, если вы загружаете самое узкое звено ненужной работой, то вы, как бизнес, теряете деньги.
Поэтому мы делаем фокус на самом ценном, не просто грузим кирпичи, а выделяем из этих кирпичиков те золотые кирпичики, которые потом выкладываем на нашу золотую машинку, которая стоит очень много денег и везет большую повозку.
Ошибка №4
Следующий важный момент – бывает так, что заказчик хочет все и сразу.
Владелец продукта приходит и говорит: «Ребята, заказчик хочет сразу готовый лимузин. Мы ему предлагали сначала велосипед, а он говорит – нет, сразу лимузин, я вам дал денег на лимузин, поэтому дайте мне лимузин».
Если вы общаетесь с теми людьми, кто принимает работу, помните, что эти люди не всегда являются теми, кто будет пользоваться продуктом. Для того, кто принимает работу, важно, чтобы вы сдали готовый продукт в срок. Обычно это департамент ИТ или какое-то подразделение закупок, которое требует результат работы от начала до конца.
Но надо пойти дальше и разобраться, кто будет потреблять этот продукт, а в некоторых случаях – не потреблять этот продукт. Потому что если вы автоматизируете что-то, вы снижаете стоимость обслуживания, а это ведет к увольнению некоторых людей. Здесь всегда есть баланс, и надо найти того потребителя, кто действительно будет пользоваться продуктом, кто в этом заинтересован. В некоторых случаях, наоборот, потребитель не очень заинтересован в создании какой-то автоматизированной системы.
Поэтому надо научиться найти того потребителя, кто действительно нам важен, кто может давать обратную связь, кто может получать продукт по частям, и уже говорить, в какую сторону мы двигаемся, а в какую – нет. После этого надо дальше двигаться определенными отрезками.
Причем, из большого продукта надо вытащить сначала самое-самое ценное. А в некотором случае нужно сначала проверить технические возможности, потому что не всегда можно сделать что-то сразу, иногда сначала нужно сделать ходячий скелет, прототип, а потом двигаться к Minimum Viable Product (минимальному ценностному продукту).
Очень важно понимать, что если заказчик просит сразу пончик с посыпкой, мы не будем строить фабрику, которая сначала производит посыпку, потом делает пончики. Иначе, когда мы начнем выпускать и продавать эти пончики, может оказаться, что на этом рынке уже 10 компаний, которые занимаются тем же самым, и уже нет ни одного потребителя, а мы построили завод. Все это как-то нелогично. Поэтому надо понять, есть ли спрос, и принесете ли вы ценность, выпустив такой продукт.
Работая короткими циклами и вытаскивая самое ценное, мы потихоньку делаем поэтапный возврат инвестиций. Мы не сразу от начала до конца работаем, а в конце возвращаем деньги, мы, потихоньку делая, двигаясь короткими кусочками, постепенно возвращаем инвестиции, которые в нас вложены.
В этом случае мы дополнительно немного стабилизируем компанию. Бывает, когда вы делаете какой-то большой серьезный проект, происходит кассовый разрыв от момента, когда мы начали делать, до момента, когда вы его сдаете. А еще бывает, что сдача длится долго-долго, и компания в этом случае даже умирает.
Ошибка № 5
Еще одна ошибка, которую Product Owner не должен допускать. Я слышу часто тезис: «мы не должны ошибаться». Да, мы приоритизировали, и то, что мы сделали – это очень важно, очень ценно. Но вдруг мы допустили ошибку?
Владелец продукта говорит, что договорился со всеми, точно все хорошо и точно все получится, но в современном мире, к сожалению, такого не бывает. Когда мы двигаемся в запутанных системах, когда заказчики меняются, рынок меняется, ожидания пользователей меняются, не допускать ошибки – это очень странно.
Поэтому Product Owner должен уметь ошибаться. Но должен ошибаться очень правильно: чем быстрее и дешевле он ошибется, тем лучше. Если мы ошибаемся быстро, мы ошибаемся бесплатно. Не всегда так получается, но в любом случае мы экономим время производства. Кроме того, мы не попадем в сложные моменты в процессе сдачи и внедрения системы.
Эту ямку на слайде можно было заметить пораньше и передвинуть наши пятнашки в другую сторону или чуть дальше.
Некоторые компании доходят до того, что выделяют небольшой бюджет на ошибку. Делается это для того, чтобы команда научилась ошибаться, чтобы команда поработала чуть-чуть, поняла, что бежит не туда и не потратила много-много денег.
Кстати, есть такой инструмент – бережливый стартап (цикл Lean Startup). Наверное, многие о нем слышали. Он позволяет Product Owner научиться работать по-новому, ошибаться, проводить эксперименты. Потому что его эффективная работа заключается в том, чтобы за минимальное время проверить много гипотез, сэкономить много-много денег и не загрузить команду бесполезной работой.
За счет экспериментов Product Owner сможет найти самое ценное, самое важное и вырастить это до уровня хорошего полноценного продукта.
Выводы для владельцев продукта
Давайте резюмируем:
- Product Owner – это специальная роль в Scrum-командах для того, чтобы объединить бизнес и айтишников (производство). Если вы настоящий Product Owner, вы часть команды, вы работаете с командой.
- Product Owner должен быть не просто владельцем продукта, он должен уметь выстроить систему приоритизации, которая позволит бизнесу эффективно развиваться. Он должен учитывать интересы и заказчиков, и потребителей, но в то же время должен получать самую высокую ценность.
- Надо фокусировать команду на самое-самое ценное и самое-самое важное.
- Product Owner необходимо научиться декомпозировать работу вместе с командой. Я часто встречаюсь с ситуацией, когда команда не может декомпозировать большую задачу, они хотят выполнить ее полностью и получить результат. Но, по моему опыту, в 95 случаях работа декомпозируется. Есть много техник, которые позволяют это сделать.
- И самое главное – научитесь ошибаться. Но научитесь ошибаться дешево. И чтобы научиться ошибаться дешево, иногда вам, как владельцу продукта, не получится это сделать. Поэтому в больших современных компаниях под Product Owner создается еще одна целая команда, так называемая Discovery Team, которая занимается тем, что помогает Product Owner ошибаться эффективно, выстраивать набор гипотез и валидировать их на рынке.
Вы считаете, что Product Owner нужен, чтобы запускать пилоты? Желательно, чтобы пилотов не было, лучше продать то, чего еще нет. Лучше сначала надо вытащить ценность для пользователя, понять, что ему нужно: может быть ему нужна не автоматизация, а сокращение каких-то процессов или что-то еще. Идеально, если вы можете выращивать пользователя под себя. Но это не всегда возможно.
У Product Owner есть 3 основных направления, где он может черпать идеи:
- Выращивать продукт, если у вас есть деньги и возможности, – это один из важных моментов.
- Второе направление – следовать трендам,
- а третье – обратить внимание на метрики продукта, посмотреть, как продукт сейчас работает у вас, как работает продукт у конкурентов, посмотреть, в чем вы сильны, в чем они сильны, и вырастить из этого некоторую ценность.
- Еще один подход – это исследовать пользователя, для этого есть свои инструменты.
Интересный момент. Предыдущий докладчик говорил, что фреймворки Scrum тяжело использовать в 1С. Но я хотел бы вам сказать другой факт. У меня есть команды, работающие в 1С, и они более эффективно внедряют Scrum, чем другие команды. Потому что в командах, внедряющих 1С, нет выделенных ролей (например, как в банках, где человек может быть только аналитиком). В командах 1С-ников аналитик чаще всего раньше был программистом, он в этом больше понимает.
Поэтому если 1С-команды хотят двигаться в Scrum, то чаще всего у них получается. У меня есть порядка 10 эффективных Scrum-команд, которые работают на 1С. Есть даже один большой вендор, у которого 5 команд 1С-ников, самый большой ритейл на 1С. Все они работают по Scrum, и все хорошо.
Единственная проблема – одна из пяти команд так и не научилась оценивать в условных единицах, а остальные четыре работают нормально. И Product Owner там сильные.
Кстати, вырастить сильного Product Owner в большой компании – это проблема. Ее решают следующим образом: есть люди, которые понимают в бизнесе, и они хотели бы найти тех людей, которые могли бы работать с командой и доносили бы ценности бизнеса до команды. Такие люди есть. Но обычно проблема в том, что рынок пока только развивается в этом направлении, и людей, которые бы работали с командами, практически нет. Сейчас на эту роль обычно берут аналитиков, и это все печально.
Вопросы:
- Какие конкретные приемы вы можете порекомендовать для формирования требований к MVP? Мои заказчики почему-то всегда хотят все и сразу. Возможно, только мне попадаются такие заказчики. Порекомендуйте, пожалуйста, конкретные приемы общения, выделения, категоризации и приоритизации.
- Первый инструмент. Обычно, когда мы работаем с заказчиком, мы чаще работаем с тем человеком, кто будет принимать продукт. Как я уже раньше говорил, когда мы работаем в Agile-подходе или, как его сейчас называют продуктовом подходе, на старте Product Owner должен сформировать карту стейкхолдеров, понять, кто у него будет принимать продукт, кто у него потребитель и будет использовать продукт, кто заинтересован в создании ценности. Обычно мы идем от того заказчика, кто будет принимать продукт, а надо найти тех людей, кто будет заинтересован в создании этой ценности. Вот с ними можно работать. Среди тех пользователей, которые работают ниже, можно выделить две категории. Если вы делаете работу, которая спровоцирует их сокращение, они не заинтересованы в создании ценности. Но если это позволяет им достичь какого-то результата, то с этими пользователями можно работать. Это первый шаг, с чего можно начать. А потом уже проводить интервью с человеком, который заинтересован в создании ценности, с ним можно говорить о деталях.
****************
Данная статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT 2019. Больше статей можно прочитать здесь.
В 2020 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2020 в Москве.
