Привет, Хабр! Мы продолжаем серию материалов, посвященных продуктовому менеджменту. В этом посте мы обсудим, как продуктовый менеджер определяет что попадет в дорожную карту и как заниматься приоритизацией бэклога. Все подробности — под катом.

Оглавление курса

1. Роль менеджера по продукту и фреймворк
2. Сегментирование рынка и конкурентный анализ
3. Пользовательские персоны
4. Проверка гипотез
5. Позиционирование продукта
6. Дорожная карта продукта < — Вы здесь
7. Составление требований для разработки
— Продолжение следует

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



Девиз Организации Объединенных Наций: «Think Globally, Act Locally». Что интересно, он работает и при создании дорожной карты хорошего программного продукта. Для этого нужно иметь глобальное видение, чтобы ваши стремления не заканчивались «здесь и сейчас». В рамках видения задаются цели — они тоже достаточно глобальны, и именно к этим целям должна вести дорожная карта. Когда вы движетесь в соответствии с подготовленной картой, вехами и этапами этого движения становятся релизы — воплощение конкретных шагов по развитию продукта.

На какой горизонт стоит размахиваться с планированием? Он может быть разным, но для начала лучше ограничиться 6 месяцами. Если вы точно знаете, куда будет двигаться ваш продукт, он может составлять 3 года или 5 лет. Предела не существует. Например, в своем недавнем выступлении основатель Amazon Джеф Безос анонсировал космическую программу Blue Origin с горизонтом планирования в 50-100 лет. То есть человек создает компанию, которая будет работать большую часть времени после его жизни. Как это вообще возможно?

Просто в данном случае речь идет о глобальном видении — Blue Origin должен обеспечить возможность интенсивных космических полетов. По словам Безоса, Amazon опиралась на уже существующую инфраструктуру курьерской доставки и почты. Если бы их не было — Amazon не смог бы работать или стать таким успешным. Сегодня Blue Origin планирует создать инфраструктуру для будущих космических путешествий — ракеты, космодромы, спутники, орбитальные станции и так далее. Из глобальных целей Blue Origin — построить космический корабль к 2025 году.

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

С небес на землю…

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

? Vision — Построить лучший жилой квартал на севере Москвы (САО)
? Goals — 5000 квартир, современная архитектура, комфорт класс, удобные планировки, двор без машин
? Roadmap — Очереди застройки и благоустройства территории
? Release — Конкретные готовые здания, дороги, парки (Возможно деление на стадии готовности)
? Feature — составляющая релиза. Например, Детская площадка, посаженные деревья, крытая парковка, пандус

Как составлять Roadmap программного продукта?

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



Учитывайте, что roadmap нужно планировать сразу для всех отделов. Если компания большая, и у sales-менеджеров есть своя дорожная карта, необходимо связать ее с дорожной картой отдела разработки. Иначе, когда придет время, например, продвигать продукт на азиатском рынке, может оказаться, что у вас нет готовой локализации… да и вообще поддержки китайского языка.



Запросы на то, что должно быть в продукте поступают с самых разных сторон. Мы уже говорили об этом в одном из предыдущих постов. Их нужно тщательно систематизировать и планировать. Важно понимать, что подготовиться и выпустить все фичи в версии 1.0 не получится, потому что в реальности ресурсов никогда не хватает для того, чтобы реализовать все идеи (если это не так — значит у вас маловато идей, и нужно подумать еще).

При правильном подходе Roadmap — это возможность разделить процесс развития продукта на этапы и выкатывать в итерациях функционал с убывающим приоритетом и важностью.

Давайте рассмотрим еще один фреймворк разработки программного продукта (Software Product Management Framework), который управляет именно разработкой софта:



Матрица зрелости компании, которая живет по данному фреймворку определяет следующей таблицей. И при формальном следовании процесса подготовки дорожной карты, компания сразу попадает на второй уровень зрелости:



Вообще данный фреймворк является отдельной ветвью для любого курса по продуктовой разработки. Сейчас на нем останавливаться не будем. Если кому-то интересно прочитать дополнительный пост по данной теме — оставьте пожалуйста комментарий к данному посту.

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

Как собрать и обработать требования к продукту?

Когда мы получаем требования с разных сторон, их нужно заносить в какую-то систему. Например, в Acronis используется Jira — это довольно мощный инструмент, но для стартапов можно использовать и более простые, в том числе бесплатные, например Redmine или Asana.

Главное, чтобы все идеи регистрировались, потому что плохих мыслей не бывает. Если идея пока не заслуживает реализации, то ее приоритет будет оставаться низким. Поэтому очень важно вносить в систему каждое предложение — даже без подробного описания «как это должно работать». Только при таком подходе вы сможете запланировать реализацию востребованных фич — то есть создать настоящий Roadmap.



Все идеи приходят в так называемый “Incoming backlog”, они могут быть как оформленными, так и “сырыми”, без оценок и понимания, кому нужны эти фичи. После проработки запросов и добавления деталей, часть из них может пойти в ближайший релиз. Остальные отправляются в Backlog и могу находиться там достаточно долго.

Epic

Методология Agile или Scrum подразумевает такой термин, как «Epic». Если объяснять его суть максимально просто, то речь идет о какой-то большой фиче, внедрение которой требует вовлечения всех участников — разработчиков, тестировщиков, дизайнеров интерфейса, технических писателей и так далее.

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



Для уже оцененных эпиков можно присвоить приоритет в системе. Например, в той же Jira можно выставить «высокий», «средний» или «низкий». Но, например, у нас в Acronis в бэклоге находятся сотни и даже тысячи фичей. В этом случае простыми приоритетами не обойтись.

Считаем Feature Score

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

1. Срочность
2. Размер клиента, которому это нужно
3. Повышение рыночной доли за счет появления новых клиентов
4. Потенциальная прибыль или потери от ухода текущих клиентов
5. Стратегические достижения (цели, которая ведет нас к воплощению Vision)

Негативные метрики:
1. Объем трудозатрат
2. Возможные риски

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

Баллы определяются исходя из нормированных значений, рыночных целей компании и других параметров. Первый параметр, который учитывается в Feature Score — это фактор клиента. Так называемый Customer Factor определяется как произведение срочности на размер клиента. Пример расчета вы можете увидеть на изображении ниже.



Market Penetration определяется как вероятность привлечь новых клиентов и зависит от ваших планов по расширению клиентской базы. Например, для фичей, которые не привлекут новых клиентов, этот параметр может быть равен 0, а для тех, которые способны привести вам, скажем, 500 клиентов, оценка будет 20.

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



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



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



Risks — это второй аспект. Чем меньше ваша уверенность в проведенных оценках, тем выше риски, а значит — ниже значение критерия в формуле Feature Score.



После учета всех упомянутых факторов формула Feature Score может выглядеть таким образом:



Хорошо, если оценки получаются объективными, основываясь на конкретных факторах. Но если вы только еще выходите на рынок, все равно составляйте Feature Score. Пусть лучше они будут субъективными, чем их не будет вообще.

Roadmap на примере приложения “Такси”

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



Таблица с приоритетами может выглядеть следующим образом:



Рассмотрим фичу «Заказ к нужному времени». Просуммировав все параметры, мы получаем 56. Что значит это число? Ничего! Это относительный рейтинг, и нам нужно просчитать все 9 фичей, придерживаясь единых критериев и оценок. В результате получается лист приоритетов. В нашем приложении явно нужно сделать мобильное приложение на Android. Вторым ходом — тариф “Детский”.

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

Не только приоритеты

При планировании релизов принимаются во внимание емкость команды разработки. У некоторых продукта таких команд может быть несколько. Например, для создания сервиса заказа такси как минимум должны быть команды backend, QA, Android, iOS.

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

Емкость разных команд на один релизный цикл:



Если посмотреть на таблицу ниже, становится понятно, что на мобильное приложение под iOS нужно достаточно много ресурсов, причем не только команды разработки iOS, но также специалистов по бэкэнду и QA. Именно поэтому менеджменту логично принять решение не включать в первый релиз мобильное приложение под iOS, так как команда все равно не успеет сделать его, но зато доделать “Заказ такси к нужному времени».



Таким образом, если идти по порядку приоритетов всех отсортированных фичей, то дорожная карта развития приложения по заказу такси будет выглядит следующим образом:



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

Roadmap — как философия развития продукта

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

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

Для крупных продуктов, желательно также выделить разную емкость команд разработки на вещи, не связанные напрямую с разработкой пользовательских фичей, Например тим лид разработки может вам сказать, что “Нужно переходить на новую версию Python, иначе мы будем больше времени (денег) тратить на поддержку существующей экосистемы на старой версии”. Чтобы решать такие задачи можно выделить, например, 25% емкости команды на фичи, связанные на завоевание новых клиентов, 45% — удержание текущих, 20% на технический долг и рефакторинг, а 10% оставить как буфер, чтобы было место для фичей, которые пришли внезапно или overhead для учета активностей, не связанных напрямую с разработкой продуктов (развертывание новой билд-системы, внедрение CI\CD и так далее).

Заключение

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

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

> Видео-запись всех лекций курса доступна на YouTube

Лекция про дорожную карту и требования для разработки: