Управление продуктом. Российская практика

Большинство продуктовых команд работает по Scrum или в гибридном подходе Scrum + Kanban. Основным артефактом для работы становится бэклог продукта – список всех желаемых работ, обычно в виде пользовательских историй (user story), отсортированных в порядке приоритета. Он развивается по мере появления новых требований (или идей в нашем случае). В начале каждого спринта происходит планирование, в результате которого пользовательские истории переносятся из бэклога продукта в бэклог спринта с оценкой объема работ. Затем команда встречается на ежедневном стендапе, где делится ходом работы. В конце спринта проводится его ретроспектива.

Самый популярный фреймворк на данный момент – Scrum Кена Швабера и Джеффа Сазерленда. В его основе лежит идея работы короткими циклами – спринтами, в которых принимают участие и бизнес, и ИТ.

Спринты – регулярные ограниченные промежутки времени, в течение которых Scrum-команда выполняет заданный объем работы. Средняя продолжительность – 2–4 недели. По итогам команда обязуется создать новую версию продукта с приростом ценности для клиента (функционала) – инкрементом. Спринты выпускаются в определенные даты. Все это приводит к упорядочиванию работы ИТ. Поскольку вы действуете итеративно и попутно создаете продукты, вы можете предоставить больше гибкости своим конечным пользователям и клиентам и вовлечь их в процесс разработки и тестирования.

Пользовательская история – короткая формулировка намерения пользователя и того, что продукт должен сделать для него, поддержанная описанием функциональных требований и прототипом интерфейса. Если что-то не добавляет ценности клиенту, то это не может считаться пользовательской историей и будет оставаться задачей, подзадачей или просто требованием.

Формат пользовательской истории выглядит следующим образом: «Как [тип пользователя]; я хочу [некая цель]; так, чтобы [некая причина]». Рассмотрим все пункты подробнее.

• Как [тип пользователя]. В этом разделе указывается, кто пользователь. Это помогает лучше понять его точку зрения и потребности.

• Я хочу [некая цель]. Эта часть описывает, чего пользователь хочет достичь или какую функцию желает видеть в продукте. Она должна быть ясной и краткой, фокусироваться на желаемой функциональности, без подробностей реализации.

• Так, чтобы [некая причина]. Тут объясняется причина цели пользователя. Так мы обеспечиваем контекст и помогаем команде понять основную мотивацию, которая может иметь решающее значение для определения приоритетов и принятия решений.

Например, для сайта интернет-магазина пользовательская история может быть такой.

ПОЛЬЗОВАТЕЛЬСКАЯ ИСТОРИЯ: ОНЛАЙН-МАГАЗИН

Как клиент, я хочу иметь возможность просматривать подробную информацию о продукте, включая изображения, описание, цену и отзывы, чтобы принимать обоснованные решения о покупке.

Критерии приемки

• На странице продукта должны быть качественные изображения высокого разрешения, демонстрирующие продукт под разными углами, обеспечивающие четкое представление о его внешнем виде и функциях.

• Описание должно включать основные характеристики и быть структурировано так, чтобы включать краткую, но подробную информацию о ключевых функциях, спецификациях, размерах, материалах и любых других важных атрибутах, которые влияют на решение о покупке.

• Информация о ценах, включая базовую, любые применимые скидки, рекламные акции или пакетные предложения, должна отображаться на видном месте рядом с описанием продукта.

• Пользователи должны иметь возможность просматривать совокупные рейтинги и читать подробные отзывы тех, кто купил продукт. Система отзывов должна поддерживать материалы, отправленные проверенными пользователями, обеспечивая достоверность и подлинность.

• Клиенты должны иметь возможность фильтровать и сортировать отзывы по релевантности, дате, рейтингу или конкретным критериям.

Пользовательская история дополняется макетом интерфейса и нефункциональными требованиями к производительности, безопасности, отказоустойчивости (если применимо). Пользовательские истории могут быть сгруппированы в эпики, которые, в свою очередь, объединены в инициативы, а инициативы в темы.

Владелец продукта (Product Owner) – это ключевая роль в Scrum, отвечающая за максимизацию ценности продукта, создаваемого командой разработки. Он определяет приоритеты в бэклоге, собирает оценки трудозатрат, взаимодействует с заинтересованными сторонами для определения и удовлетворения их требований.

Все команды помешаны на планировании. Это неудивительно, ведь точные оценки позволяют прогнозировать сроки и бюджет проекта, на которые «коммитятся» владельцы продуктов. Сколько раз я участвовала во встречах, где все спрашивали: «Когда вы реализуете эту фичу?» Коммуникация статуса и сроков крайне важна, ведь по ней оценивается работа команды в фабрике функций.

Для каждой истории (либо в условных единицах – Story Points, либо в человеко-часах) выставляется оценка, которую дают разработчики. Поинты обозначают уровень сложности или трудоемкости реализации элементов бэклога продукта (пользовательской истории): один поинт – простую задачу, два – сложнее и т. д., однако для того, чтобы начать их использовать, необходим накопленный командой опыт разработки. Часто на этом этапе важно дробить истории, чтобы получить более точные оценки.

Для лучшего понимания нужно рассмотреть концепцию скорости работы (velocity). В конце каждого спринта команда суммирует оценки усилий, связанные с пользовательскими историями, которые были завершены за время спринта. Эта сумма называется скоростью: это количество поинтов, которое команда реализует за спринт. Таким образом, в начале вы как бы предполагаете или оцениваете, сколько поинтов вы можете набрать за спринт, но после пары спринтов вы сможете усреднить количество поинтов, а затем сделать вывод, что в среднем ваша команда может, например, набрать 15 поинтов за спринт. Это и есть скорость работы.

Для составления бэклога спринта команда берет пользовательские истории из бэклога продукта и обязуется доставить их за спринт. Это самый нижний уровень, на котором команды устанавливают приоритеты. В релиз (выпуск функциональности для пользователей) обычно попадают истории нескольких спринтов. Календарный план релизов представляет собой дорожную карту, которая часто выглядит как диаграмма Ганта с датами релизов.

Отдельно необходимо поднять вопрос качества планирования спринтов и релизов. Оно измеряется соблюдением сроков и соответствием требованиям пользовательской истории. При этом важно отслеживание качества не только в конце спринта, но и в процессе, а также проведение ретроспективного анализа. Этим тоже занимается владелец продукта.

Рис. 1.3. Пример Burndown Chart

Если скорость команды начинает падать, значит, она неправильно оценивает свои истории: берет на себя слишком много работы или кто-то заставляет ее это делать. Но если команда неожиданно обнаруживает, что у нее появляется много свободного времени, значит, ей следует сделать переоценку своих трудозатрат. Важный инструмент для налаживания темпа и прогнозирования скорости разработки – диаграмма сгорания задач, или Burndown Сhart.

Как следует из названия, диаграмма сгорания задач – это инструмент, показывающий, как быстро команда работает с пользовательскими историями. Они эффективны за счет того, что прогресс оценивается не в контексте потраченного времени, а в контексте оставшейся работы. Рекомендуется, чтобы оставшаяся работа уменьшалась более-менее равномерно по ходу спринта.

Один из популярных вопросов на собеседованиях: «Что делать, если команда отстает от графика?» Это головная боль владельца продукта и менеджера проекта. Тут можно вспомнить известный треугольник ограничений проекта, также называемый тройным ограничением, железным треугольником (рис. 1.4).

Рис. 1.4. Треугольник ограничений

Вот три основных ограничения (изменение одного из них обычно влияет на два других).

• Объем работ: определяет, что будет реализовано. Изменения объема могут повлиять как на время, так и на стоимость.

• Время: сроки и время, доступные для завершения проекта. Если временные ограничения ужесточены, может потребоваться больше ресурсов (увеличение затрат) или сокращение объема.

• Стоимость: включает бюджет, все ресурсы, необходимые для завершения задач, такие как рабочая сила, материалы, оборудование и накладные расходы. Увеличение бюджета может помочь уложиться в сжатые сроки или расширить объем работ, тогда как сокращение бюджета может потребовать уменьшения объема или продления сроков.

В центре треугольника находится качество, представляющее конечную цель: поддержание критериев приемки, несмотря на ограничения.

Итак, если команда отстает от графика, то допустимо сократить объем задач или перенести сроки запуска, однако это может плохо повлиять на бизнес-результат; добавить больше разработчиков (увеличить стоимость). Однако в последнем случае вы можете столкнуться с «мифическим человеко-месяцем» и законом Брукса – концепцией, которую описал Фред Брукс в своей книге «Мифический человеко-месяц: очерки по разработке программного обеспечения».

Идея добавления разработчиков в проект основана на предположении, что если один человек может выполнить задачу за определенное количество часов, то несколько человек могут выполнить ту же задачу за пропорционально меньшее количество часов. Однако при этом игнорируются сложности и накладные расходы, связанные с командной работой и координацией проекта.

Новым членам команды требуется время, чтобы они стали продуктивными. Это не только отнимает их собственное время, но и отвлекает время существующих членов команды, которым необходимо их обучать и интегрировать. По мере увеличения числа членов команды сложность и время, необходимое для общения и координации, растут в геометрической прогрессии. Каждый дополнительный участник увеличивает количество каналов связи и вероятность недоразумений или несогласованностей. И в целом не все задачи можно легко разделить между несколькими людьми.

Все это во многом исключает возможность реального варианта «сделать хорошо и быстро». В итоге приходится искать компромиссы, сокращать объем работ в угоду качеству, договариваться снова с заинтересованными сторонами.

Еще одним фактором, влияющим на сроки, становится задержка в работе другой команды, от результатов которой зависят ваши сроки. Часто она находится вне зоны контроля и влияния, и вопрос необходимо эскалировать.

Кто все вышеописанное будет делать и отвечать, если возникают сдвиги сроков, выпускается продукт, не отвечающий требованиям, и т. д.? Конечно, владелец продукта.

ВЛАДЕЛЕЦ ПРОДУКТА: ЗАДАЧИ И РОЛЬ В КОМАНДЕ

Я специально вынесла роль владельца продукта, а не менеджера продукта, в заголовок этого раздела. Между этими ролями есть существенная разница.

В команде выделяется роль владельца продукта, который должен отвечать за представление всех заинтересованных сторон и приоритизацию работ, уточнение требований и контроль сроков и бюджетов. Часто он берет на себя роль и Scrum-мастера, ответственного за соблюдение практик в команде и проведение мероприятий вокруг спринтов: планирование, обзор, ретроспективу, ежедневные статусы (стендапы). В подавляющем большинстве известных мне случаев владельцами продуктов становились системные аналитики, бизнес-аналитики и менеджеры проектов, которые и так выполняли функции планирования и администрирования задач, создания задач для разработчиков и тестировщиков.

Не стоит недооценивать ценность этой роли в контексте работы в разрозненных организационных структурах, на пересечениях зон влияния и ответственности. Организация представляет собой непростую систему, в которой степень сложности прямо пропорциональна количеству точек принятия решения.

Успешные владельцы продуктов часто помогают заказчикам конкретизировать видение и воплотить его в жизнь, работая со всеми заинтересованными сторонами.

Дело в том, что ресурс ИТ может быть общим (под ресурсом я понимаю сотрудников с необходимой специализацией и опытом: разработчиков, тестировщиков и т. д.) и делиться между множеством бизнес-заказчиков, а может быть выделенным под конкретного бизнес-заказчика.

Первая схема хорошо работает, когда потребность в ресурсе носит временный характер по проектному типу: например, у бизнес-подразделения возникает задача доработать систему под новые требования законодательства. Тогда претендентам на ИТ-ресурс нужно как минимум договориться о правилах его использования. В случае общего ресурса договориться всегда сложнее, поскольку претенденты имеют разные, а иногда и противоречащие друг другу цели.

Вторая схема эффективна, когда потребность в ресурсе постоянна, происходит постоянное улучшение продукта. Тогда создается кросс-функциональная команда. Внутри нее есть полностью выделенные роли: маркетологи, разработчики, тестировщики, дизайнеры, аналитики.

Можно считать, что размер компании – компромисс между производительностью и накладными расходами. Чем больше людей, тем больше задач можно выполнить, но тем больше общения и процессов необходимо для координации.

Например, для реализации одной пользовательской истории в интернет-банке может потребоваться интеграция минимум с тремя системами, за каждую из которых отвечает своя платформенная команда; сама интеграция в худшем случае может строиться напрямую между системами без какого-либо промежуточного слоя, на ресурсы может претендовать еще множество бизнес-заказчиков из бухгалтерии, операционного департамента и т. д. В итоге у нас получается не один, а множество бэклогов, тут возникает типичный вопрос: «Кто, когда, как, зачем сможет вставить эту историю в свой релиз?»

В этом процессе владелец продукта – держатель бэклога, относящегося к конкретной предметной области. Он понимает зависимости, фасилитирует встречи, получает требования и приоритизирует их вместе с заинтересованными сторонами, оценивает трудозатраты вместе с архитекторами и разработчиками и контролирует реализацию в срок в соответствии с бюджетом и критериями приемки, доводит до бизнеса все необходимые статусы по их задачам, контролирует интеграционное тестирование и обучение пользователей и т. д. Часто при этом одной роли владельца продукта недостаточно, нужна еще и роль менеджера проектов.

Вот другой пример. Предположим, что мы хотим создать продукт с нуля на новом рынке. Мы можем не знать многого о рынке и о том, что должен делать продукт, поэтому наличие большой команды приведет к большой путанице в отношении того, что делать и кто должен этим заняться. Типичная команда стартапа – пять человек, два из которых основатели. Понятно, что введение еще одной точки коммуникации в виде владельца продукта добавляет больше проблем и простоев: и так всем все понятно, разработка не требует сложного планирования, встреч и согласований. Все сидят в одной «съемной квартире». Проблемы начинаются, когда менеджер сильно перебарщивает с планированием, замыкает процессы на себе: ни одна работа не выполняется без его разрешения.

Таким образом, размер команды и компании имеет значение: чем крупнее организация, тем больше зависимостей и коммуникационных барьеров в ней образуется. Это неизбежно приводит к увеличению сложности. Организации (особенно в корпорациях) склонны начинать новые проекты с большими командами и долгим согласованием выделения ресурсов, годовыми бюджетными циклами, которые часто подменяют собой стратегию. Бремя координации ложится на владельцев продуктов и менеджеров проектов. В этой ситуации под прицел критики очень часто попадает именно владелец продукта. Ему «припоминают» большое количество непродуктивных встреч, отсутствие ясных и согласованных приоритетов, недостаточную проработку пользовательских историй, прототипов интерфейсов, функциональных требований, «поехавшие» релизные сроки и т. д. Вот только он не может устранить те ограничения, которые не находятся в зоне его влияния.

Применение принципов Agile, внедрение Scrum-ритуалов еще не означает, что команда приносит ценность клиенту и бизнесу, а не является фабрикой функций. Конечно, важно, чтобы к началу планирования спринта были проработаны все пользовательские истории, прототипы интерфейсов, функциональные требования и т. д. Но, даже несмотря на это, часто владелец продукта не понимает, как оценить влияние задачи на бизнес, а также уверенность в достижении оного. Ему приходится снова и снова встречаться с руководителями коммерческого блока для уточнения требований и оценок. Последние, в свою очередь, воспринимают это общение как обузу, отвлекающую их от главных задач. При этом все, конечно, понимают, что постановка внутри спринтов не может меняться, но тут и там возникают дополнительные задачи в формате «мы потеряем клиента, если не сделаем этого», «Иван Петрович позвонил и сказал…» и др.

Неорганизованный подход и «заваливание» ИТ разрозненными задачами долго воспринимались как приемлемая модель взаимодействия. Однако происходит то, что становится катализатором перемен, когда перед коммерческим блоком стоит задача сформулировать амбициозную стратегию и реализовать ее. Это, например, рыночные изменения, натиск конкурентов, стагнация доходов или их отсутствие, смена топ-менеджмента. В этот момент происходит поиск нового формата кросс-функционального взаимодействия для быстрого достижения бизнес-результатов, который учтет ключевые области бизнеса, такие как стратегия, бизнес-модель, рыночная конкуренция, а не только разработку. В этот момент появляется запрос на роль менеджера продукта.

LEAN STARTUP И ЕГО ВЛИЯНИЕ НА УПРАВЛЕНИЕ ПРОДУКТОМ В КОМПАНИЯХ

Многие стали задаваться вопросом: почему компания не может работать как стартап, который, как мы знаем по Стиву Бланку, «не уменьшенная версия большой компании»?

В XX веке инвесторы, по сути, говорили стартапам, что они уменьшенные версии крупных компаний. Но потом в США лопнул «пузырь доткомов»: новые бизнес-модели оказались неэффективными, а средства, потраченные в основном на рекламу, и большие кредиты привели к волне банкротств, сильному падению индекса NASDAQ. Выжили только те компании, у которых имелись устойчивые бизнес-модели. Внезапно инвесторы стали избегать риска и искать доказательства соответствия продукта рынку.

В это время появились методология Lean Startup и концепция Customer Development, книги Стива Бланка, Дэна Олсена, Марти Кагана, Эрика Риса. Ключевая идея их такова: необходимо сначала создать гипотезы относительно бизнес-модели, протестировать в экспериментах и только потом принимать решение о разработке.

В то время как крупные компании реализуют бизнес-модели, стартапы фактически ищут бизнес-модели, тестируя основные предположения (в этом суть Customer Development). В таблице 1.1 приведены ключевые отличия стартапа от зрелой компании.

Таблица 1.1. Различия стартапа и зрелой компании

Стартапы и те, кто занимается разработкой новых продуктов, уделяют большое внимание концепции Product-Market Fit. Если задача стартапа состоит в том, чтобы найти жизнеспособную бизнес-модель, то поиск соответствия продукта рынку считается результатом этих изысканий. В стартапах это часто означает, что до PMF вы направляете инвестиции в первую очередь на фазу поиска и развития клиентов.

После того как вы достигли PMF, вы переходите к этапу, который влечет за собой создание и построение компании. Этот сдвиг для стартапов часто может быть связан с новым инвестиционным раундом, когда новое вливание капитала будет использовано для масштабирования продаж и маркетинговых усилий бизнеса.

Для поиска PMF используется итеративный подход Learn, Build, Measure (научиться, создать, измерить). Это цикл, который делает упор на скорость как на важнейшую составляющую развития продукта (рис. 1.5).

Рис. 1.5. Цикл Learn, Build, Measure

Продуктовый менеджмент не рассматривается как линейный путь от точки А до точки Б. Он представляет собой непрерывный цикл тестирования гипотез.

Результативность в поиске PMF определяется способностью генерировать идеи, создавать эксперименты, измерять ее эффективность на рынке и извлекать уроки из этого эксперимента. Другими словами, это цикл обучения превращению идей в продукты, измерения реакции клиентов на созданные продукты и их поведения, а затем принятия решения о том, продолжать ли воплощать идею или изменить ее; этот процесс повторяется столько раз, сколько необходимо.

В цикле присутствует понятие гипотезы и MVP (Minimum Viable Product) – минимально жизнеспособного продукта. Разберемся, что это такое.

О чем-то мы точно знаем, что это правда; что-то можем только предполагать. Перед проведением эксперимента важно иметь четкую проблему, которую вы пытаетесь решить. Это может быть что угодно: от улучшения пользовательского опыта до повышения коэффициента конверсии или снижения оттока. Как только вы определили проблему, пришло время сформировать гипотезу. Гипотеза – предположение, сделанное на основе ограниченных доказательств в качестве отправной точки для дальнейшего исследования и принятия решения. Она должна быть конкретной, измеримой и поддающейся проверке.

Каждый раз, когда вы выпускаете новую функцию, запускаете маркетинговую кампанию или пробуете новый метод продаж, вы проводите эксперимент. Это ключевая деятельность для непрерывных инноваций.

Для проверки продуктовых гипотез доступен широкий спектр методов. Исследования пользователей делятся на два подмножества: качественные, которые помогут вам глубже понять, почему пользователи ведут себя определенным образом, и количественные, которые валидируют предположения, выработанные на основе качественных исследований, используя аналитические методы, такие как опросы или измерение определенных метрик (табл. 1.2).

Таблица 1.2. Особенности разных типов исследований

Люди, которые не до конца понимают разницу между качественными и количественными исследованиями, часто считают, что первые из-за маленького размера выборки могут исказить результаты и привести к неправильным выводам.

Качественные данные предоставляют богатое, детальное понимание сложных явлений и процессов. Они стремятся не к статистической значимости, а скорее к концептуальному пониманию. Количественные данные предоставляют статистические выводы, которые можно обобщить на более широкую популяцию. Качественные исследования играют ключевую роль в разработке новых гипотез, которые затем могут быть проверены количественными методами.

Мы также можем выделить два подхода к исследованию пользователей.

• Исследования отношения (Attitudinal) – путем задавания вопросов пользователям об их мыслях, чувствах и мнениях о продукте (например, интервью, фокус-группы).

• Исследования поведения (Behavioral) – непосредственное наблюдение за взаимодействием пользователей с продуктом и получение данных об их поведении. Наиболее часто используемые: юзабилити-исследования, Eye Tracking (где и как долго пользователь смотрит на различные области экрана), продуктовая аналитика (оценка активности пользователей внутри продукта), A/B-тестирование (сравнивает две версии веб-страницы или функции приложения, чтобы определить, какая работает лучше с точки зрения вовлеченности пользователей, коэффициентов конверсии или других поведенческих показателей).

В совокупности эти подходы предлагают целостное представление о пользовательском опыте, сочетая то, что пользователи говорят, с тем, что они делают.

Проведение исследований приводит к тому, что команда начинает аргументировать свои действия, основываясь на данных. Понятно, что это требует дополнительных ресурсов. Когда они ограниченны, вы не можете позволить себе роскошь детально изучить все, что можно, поэтому возникает задача приоритизации гипотез, оценки потенциального влияния на бизнес-результат и быстрой проверки на небольшой группе целевых клиентов. Это нужно, чтобы получить обратную связь как можно быстрее, доказать, что команда идет в верном направлении, увеличить свои шансы на успех.

Один из способов проверки гипотезы о жизнеспособности продукта – создание MVP. Кажется, что сам термин выбран неверно, поэтому появилось множество статей на тему того, что стоит использовать – MLP (Minimum Loveble Product) или Minimum Viable Process и т. п. Видимо, неоднозначность термина рождает широкий набор интерпретаций. А поскольку нет одной универсальной интерпретации, дискуссии о том, что это такое, не останавливаются.