Онлайн книга по продакт‑менеджменту
Глава 6

Дорожная карта развития продукта

Заполните форму и получите ссылку с презентациями, и подробными видео‑лекциями на свою почту!

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

Наличие дорожной карты очень важно для управления развитием продукта. Однако для грамотного составления дорожной карты необходимо подойти к этому вопросу системно. Очень важно не путать дорожную карту с видением (Vision), хотя наличие видения необходимо для того, чтобы правильно выстроить дорожную карту.
Девиз Организации Объединенных Наций: «Think Globally, Act Locally». Что интересно, он работает и при создании дорожной карты хорошего программного продукта. Для этого нужно иметь глобальное видение, чтобы ваши стремления не заканчивались «здесь и сейчас». В рамках видения задаются цели — они тоже достаточно глобальны, и именно к этим целям должна вести дорожная карта. Когда вы движетесь в соответствии с подготовленной картой, вехами и этапами этого движения становятся релизы — воплощение конкретных шагов по развитию продукта.
На какой горизонт стоит размахиваться с планированием? Он может быть разным, но для начала лучше ограничиться 6 месяцами. Если вы точно знаете, куда будет двигаться ваш продукт, он может составлять 3 года или 5 лет. Предела не существует. Например, в своем недавнем выступлении основатель Amazon Джеф Безос анонсировал космическую программу Blue Origin с горизонтом планирования в 50-100 лет. То есть человек создает компанию, которая будет работать большую часть времени после его жизни. Как это вообще возможно?
Просто в данном случае речь идет о глобальном видении — Blue Origin должен обеспечить возможность интенсивных космических полетов. По словам Безоса, Amazon опиралась на уже существующую инфраструктуру курьерской доставки и почты. Если бы их не было — Amazon не смог бы работать или стать таким успешным. Сегодня Blue Origin планирует создать инфраструктуру для будущих космических путешествий — ракеты, космодромы, спутники, орбитальные станции и так далее. Из глобальных целей Blue Origin — построить космический корабль к 2025 году.
Понимание своих глобальных целей помогает составлять дорожную карту, где мы показываем конкретные шаги, выстраивая реальный план для достижения поставленных целей в ближайшем будущем. А Blue Origin, как компания с амбициозными планами, пытается воплотить свою миссию — организовать всемирный сервис для доступного и удобного перемещения людей и грузов.

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

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

Как составлять 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 релиза. Но если мы уже определились с очередным релизом, возникает необхо­димость наладить взаимо­действие между менеджерами и разработчиками.

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

Хотите просмотреть подробную видео-лекцию по этой теме? Доступ к платной записи (1,5 часа) предоставляется после оплаты.

Дорожная карта переполнена планируемыми фичами? Хотите понять как сфокусироваться на самом главном и не разрабаты­вать фичи, которые не приносят прибыль? Обращайтесь, обсу­дим.
СОГЛАСИЕ НА ОБРАБОТКУ ПЕРСОНАЛЬНЫХ ДАННЫХ
Настоящим в соответствии с Федеральным законом № 152-ФЗ «О персональных данных» от 27.07.2006 года свободно, своей волей и в своем интересе выражаю свое безусловное согласие на обработку моих персональных данных, переданных через сайт «https://productdevelopment.tech/», (далее по тексту – Оператор).

Настоящее Согласие выдано мною на обработку следующих персональных данных: фамилии; имени; отчества; телефона; e-mail; а также любой информации, предоставленной мной по собственному желанию.

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

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

Настоящее согласие действует до момента его отзыва путем направления соответствующего уведомления на электронный адрес info@rudomanov.ru.

В случае отзыва мною согласия на обработку персональных данных Оператор вправе продолжить обработку персональных данных без моего согласия при наличии оснований, указанных в пунктах 2 – 11 части 1 статьи 6, части 2 статьи 10 и части 2 статьи 11 Федерального закона №152-ФЗ «О персональных данных» от 26.06.2006 г.