Шаблон product roadmap: поля, которые стоит копировать

Шаблон product roadmap это короткая таблица, где каждая строка описывает один пункт, а каждый столбец это поле, которое вы обязуетесь поддерживать заполненным. Вариант, который подходит большинству небольших команд, состоит из шести полей: результат, источник запроса, статус, ответственный, уверенность и дата пересмотра. Всё остальное, что встречается в скачиваемых шаблонах, например дорожки, story points и столбцы по кварталам, необязательно и чаще всего становится причиной, по которой roadmap перестают обновлять.

Что должен включать шаблон product roadmap?

Включайте только те поля, по которым читатель принимает решение, и добавляйте новое поле лишь тогда, когда можете назвать, кто его будет читать. Результат это причина существования строки. Источник позволяет клиенту найти в ней свой запрос. Статус говорит, движется ли работа. Ответственный это человек, которого можно спросить. Уверенность не даёт прогнозу превратиться в обещание, а дата пересмотра не даёт строке устареть.

Ещё два поля стоит добавить, если команда о них просит. Список «не делаем» рядом с таблицей фиксирует, от чего вы отказались и почему, и избавляет от одного и того же спора каждый квартал. Столбец «изменено» показывает, когда строку правили в последний раз, так что читатель отличает живой roadmap от заброшенного.

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

Как выглядит заполненный шаблон product roadmap?

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

Две строки учат главному. У «Офлайн-режима» нет ответственного и низкая уверенность, и это честный способ сказать «мы об этом думаем». «Массовое изменение сроков» закрыто, а не удалено, поэтому клиенты, которые просили об этом, всё ещё могут найти, куда оно делось.

Если вам ближе простой текст, та же таблица работает как Markdown-файл в репозитории, и тогда она лежит под контролем версий рядом с самой работой:

| Outcome | Source | Status | Owner | Confidence |
|---|---|---|---|---|
| Keep the last filter | 14 requests | Building | Dana | Committed |
| Company SSO sign-in | 9 requests | Planned | Marcus | Forecast |

Какой формат выбрать для шаблона?

Берите таблицу, если в roadmap не больше десяти пунктов и читателям нужны детали. Берите три столбца, Now, Next и Later, если вы часто меняете направление и не хотите защищать даты. Раскладка Now/Next/Later описана в руководстве Atlassian по product roadmap рядом с раскладками по времени и по темам.

Таблица выше и доска из трёх столбцов хранят одни и те же данные. Таблица лучше для тех, кто работает внутри roadmap, а доска лучше для тех, кто только бросает на неё взгляд. Статья примеры product roadmap показывает шесть форматов с реалистичными пунктами и объясняет, как каждый из них ломается, так что раскладку можно выбрать после того, как поля определены.

Как заполнить шаблон, не гадая?

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

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

Уверенность указывайте честно. Строка Committed значит, что команда удивилась бы, не выпусти она это в заданном окне. Строка Forecast значит, что это план, если что-то не изменится. Строка Exploring значит, что никакого обещания нет, и если roadmap показывает такие строки клиентам, он должен объяснить, что означает это слово.

Как часто обновлять шаблон?

Обновляйте его при каждой смене статуса и пересматривайте каждую строку в её дату пересмотра. Roadmap устаревает, когда его обновление превращается в отдельную обязанность, поэтому держите его там, где уже идёт работа. Если источником правды служит трекер задач, статус в столбце могут задавать метки, и никому не придётся ничего перепечатывать. Статья как публичная roadmap остаётся честной показывает схему «метка на столбец», которую использует Changeloop.

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

Нужно ли делать шаблон публичным?

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

FAQ

Что такое шаблон product roadmap? Это многоразовая таблица или доска с фиксированным набором полей для каждого пункта roadmap, например результат, статус, ответственный и уверенность. Вы копируете её, заполняете по одной строке на пункт и поддерживаете актуальной.

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

Нужны ли в product roadmap даты? Для большинства команд только дата пересмотра. Календарные даты превращаются в обязательства, которые отдел продаж и клиенты цитируют обратно, поэтому используйте метку уверенности и временное окно вроде Now, Next и Later.

Можно ли вести roadmap в таблице или в Markdown-файле? Да. Таблица подходит команде, которая правит её вместе, а Markdown-таблица в репозитории подходит той, что хочет хранить её под версиями. Выберите место, где работа уже отслеживается, чтобы обновления не превращались в отдельную обязанность.

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

По теме на changeloop: Документация для разработчиков, Примеры changelog