Планирование дорожной карты продукта: 5 этапов, 3 горизонта и шаблон

Последнее обновление: 15 сентября 2026 г.

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

Никто не солгал. Просто у презентации нет способа узнать, что что-то изменилось.

Хорошее планирование дорожной карты продукта — это не более красивая презентация. Это устранение разрыва между планом и работой, чтобы план узнавал новое одновременно со всеми остальными. Дальше: пять этапов, в которых прячется этот разрыв, как честно вести спор об очерёдности, и рабочий проект Quire, у которого можно позаимствовать структуру.

Что такое планирование дорожной карты продукта?

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

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

Почему дорожная карта продукта перестаёт соответствовать реальности?

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

Этот разрыв обходится в три конкретные вещи.

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

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

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

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

Мы какое-то время вели релизы в Quire через таблицу. Это работало — пока однажды кто-то не задал ей вопрос, на который она не могла ответить без совещания.

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

Какие пять этапов проходит функция от идеи до релиза?

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

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

• 1. Приём живёт в разделе «Приём идей». Пропустите его — и запрос останется в личном сообщении, а через полгода вернётся уже жалобой.
• 2. Разбор заканчивается в «Позже» или закрытием. Пропустите его — и список разрастётся настолько, что никто ему не будет доверять, и все тихо заведут собственный, приватный.
• 3. Оценка по объёму живёт в «Далее», со статусом Scoped. Пропустите её — и разработка откроет тикет и унаследует решение, которое вы отложили, уже на своей неделе.
• 4. Сборка живёт в «Сейчас», с подзадачами. Пропустите эту вложенность — и одна непрозрачная строка две недели будет показывать «восемьдесят процентов готово», а объяснить почему не сможет никто.
• 5. Релиз держится на подсписке Ship checklist. Пропустите его — и клиенты встретятся с функцией раньше, чем поддержка узнает о её существовании.

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

В чём разница между дорожной картой продукта и бэклогом?

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

Держите оба в одном проекте, но в разных разделах. Одни и те же задачи, одни и те же поля, разный смысл.

Полезное следствие в том, что продвижение становится событием. Перемещение задачи из «Позже» в «Далее» — это решение, которое кто-то принял в конкретную дату, а не строка, тихо всплывшая вверх, пока никто не смотрел.

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

Что находится внутри шаблона Quire Product Roadmap?

Это рабочий проект с уже встроенными пятью этапами, который можно бесплатно скопировать на любом тарифе. Образец данных — вымышленный релиз v2.0, так что вы можете увидеть, как структура работает, прежде чем заменить её своей.

Вместо того чтобы строить всё это с нуля, возьмите шаблон Quire Product Roadmap. Вместе с ним идут восемь вещей:

• Три раздела горизонтов плюс раздел приёма. «Сейчас» — текущий релиз с реальными датами, «Далее» — следующий в общих очертаниях, «Позже» — кандидаты без дат, а «Приём идей» — неразобранные запросы, где ничто не является обещанием.
• Пятиступенчатый конвейер статусов: Idea, Scoped, In Progress, In Review, Shipped. Статус Scoped существует не просто так: «не начато» и «никто ещё не решил, что это такое» — это разные проблемы.
• Шесть полей дорожной карты: Release, Impact, Effort, Customer requests, Source и чекбокс Needs release note.
• Функции, раскрывающиеся в реальную работу. «Центр уведомлений» — это не одна задача-заметка. Это спецификация, дизайн, сборка панели, настройки отключения звука и дайджест-рассылка, у каждой — свой владелец и срок.
• Релизные шлюзы как вехи: feature freeze, code freeze и GA, связанные зависимостями, чтобы был виден обязательный порядок их прохождения.
• Три подсписка, пронизывающие всё дерево: текущий релиз, всё, что обещано конкретному именованному клиенту, и чек-лист релиза.
• Документ «Как мы расставляем приоритеты» — методика, записанная один раз, чтобы вы перестали пересогласовывать сам метод каждый раз, когда спорите о конкретном пункте.
• Две вкладки отчётности: «Панель» для еженедельного чтения и Effort by owner, которая суммирует расчётные часы на человека, чтобы можно было спросить, укладывается ли релиз в возможности команды.

Вложенность — это то, что не даёт функции две недели подряд читаться как «восемьдесят процентов готово». Когда «Центр уведомлений» — это пять подзадач с владельцами, «восемьдесят процентов» превращается в «дайджест-рассылка ещё не начата, и ею занимается Ана».

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

1. Каждая функция в релизе имеет статус Shipped, либо явно вырезана и перенесена в следующий релиз.
2. Заметки о релизе написаны для всего, где отмечено Needs release note.
3. Документация и справочник по API обновлены для каждой изменённой поверхности.
4. Поддержка проинформирована: известные проблемы, обходные пути, что эскалировать.
5. Миграция протестирована на копии продакшн-данных, откат отрепетирован.
6. Функциональные флаги настроены на когорту запуска, значения по умолчанию подтверждены.
7. Заметка на странице статуса и внутриприложенческий список изменений запланированы на час релиза.

Пункт пять говорит «отрепетирован», а не «задокументирован». План отката, который никто не запускал, — это желание с именем файла.

Дублирование действует на весь проект целиком, так что дерево переносится целиком, а не по одной задаче. В выпадающем списке рядом с названием шаблона откройте «Ещё» и выберите «Дублировать».

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

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

Как решить, что войдёт в следующий релиз?

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

Держите входные данные раздельными и видимыми. В шаблоне это три поля у каждого кандидата:

• Impact — насколько это ценно: High, Medium или Low.
• Effort — примерная оценка от S до XL.
• Customer requests — счётчик тех, кто действительно просил.

Сортируйте по Impact, читайте Effort рядом, и пусть счётчик не даёт самому громкому голосу быть единственным входным сигналом.

Затем следите за несоответствием, которое ловит всех. В примере данных «Тёмная тема» вышла с 47 запросами от клиентов и Impact уровня Low.

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

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

Три проверки перед тем, как что-либо попадёт в «Сейчас». Есть ли у этого статус Scoped? Успевает ли это до code freeze, а не в неделю GA? Есть ли один именованный ответственный, а не команда? Переполненное «Сейчас» — то же самое, что отсутствие «Сейчас».

Сказать «нет» — вторая половина работы, а держать что-то в Idea вечно — это «нет», которое никто не произнёс вслух. Перенесите в «Позже» с однострочной причиной или закройте. Исключение — подсписок «Обещано клиенту»: всё, что человек пообещал конкретному именованному клиенту, живёт там, поэтому убрать это оттуда — уже разговор, а не тихая правка в 11 вечера.

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

Как отвечать на вопрос «что впереди и когда?» самой дорожной картой?

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

Горизонты отвечают, примерно когда. У «Сейчас» есть даты, потому что работа оценена по объёму и имеет владельца. У «Далее» есть релиз, но нет ежедневной точности. У «Позже» нет ни того, ни другого — намеренно. Дать «Позже» дату ради видимости порядка — это способ приобрести обязательство, на которое вы никогда не соглашались.

Вехи отвечают, что должно случиться первым. Feature freeze, code freeze и GA — это реальные объекты на Временной шкале с зависимостями между собой, а не предложения в документе. Когда функция сдвигается за freeze, временная шкала показывает, с чем это столкнётся.

Статусы отвечают, что происходит прямо сейчас. In Review выглядит иначе, чем In Progress, которое выглядит иначе, чем Idea. Инженер, меняющий статус, обновляет дорожную карту как побочный эффект своей обычной работы, а это единственный вид отчётности, который остаётся актуальным.

«Панель» отвечает на этот вопрос для людей, которые никогда не откроют дорожную карту. Здесь свою нишу заслуживают именно два виджета.

Tasks Created vs. Completed сопоставляет скорость поступления работы со скоростью её завершения. Это самый ранний честный сигнал того, что релиз разрастается, а не продвигается.

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

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

Стоит отдельно прочитать о двух механиках, лежащих в основе этого: как работают вехи в Quire и как зависимости задач связывают работу вместе, — именно это делает сдвинутый freeze видимым, а не гипотетическим.

Должно ли планирование дорожной карты продукта жить в вашем ПО для управления задачами?

Да, и проверка простая: обновляет ли дорожную карту инженер, закрывающий тикет, без чьей-либо просьбы. Если ответ «нет» — у вас два документа и привычка еженедельной сверки, от которой вы рано или поздно откажетесь.

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

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

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

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

Этот шаблон — один из набора. Остальные — в подборке шаблонов управления проектами, которые ваша команда реально будет использовать, включая шаблоны для запусков, отчётности по статусу и рисков.

Что вы меняете первым, когда копируете шаблон?

Начните с дат, потому что от них зависит всё остальное. Переименуйте релизы и перетащите три шлюза на свои сроки.

Затем замените примеры функций на реальные, у каждой — один человек, а не отряд.

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

Ключевые выводы

Дорожная карта устаревает, потому что живёт там, куда работа не может дотянуться. Сделайте каждую строку настоящей задачей — и дрейф в основном прекратится.

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

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

Зарегистрируйтесь в Quire, чтобы вести всё это там же, где уже живут задачи, — и тогда в следующий раз, когда кто-то спросит, что впереди, ответом будет ссылка, а не вечер работы.

Часто задаваемые вопросы

Что такое планирование дорожной карты продукта?

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

В чём разница между дорожной картой продукта и бэклогом?

Бэклог — это всё, что вы могли бы сделать. Дорожная карта — это часть, к которой вы уже привязались обязательствами, с примерным сроком. Шаблон хранит оба в одном проекте, в разных разделах.

На сколько вперёд должна смотреть дорожная карта продукта?

Реальные даты для текущего релиза, ориентировочные очертания для следующего, и ничего дальше. Именно для этого нужны «Сейчас», «Далее» и «Позже», потому что дата, придуманная для слайда, — это та, за которую с вас позже спросят.

Как расставлять приоритеты в дорожной карте продукта?

Ценность против затрат, с доказательствами рядом с обоими. Шаблон Quire включает Impact, Effort и Customer requests как сортируемые колонки Табличного вида, намеренно не смешанные в один балл, потому что единое число прячет разногласие, которое стоит проговорить.

Должна ли дорожная карта жить в том же инструменте, что и сама работа?

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

В каких случаях эта структура дорожной карты не работает?

Когда по-настоящему ещё ничего не согласовано. У команды, которая всё ещё ищет форму продукта, есть кандидаты, но нет релиза, поэтому горизонт «Сейчас» с датами придумывает обещание. Ведите только «Позже» и «Приём идей», пока что-то не будет оценено по объёму и не получит владельца.

Как такое планирование дорожной карты помогает команде быть продуктивнее на работе?

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