Дорожная карта цифрового продукта: как спланировать развитие сайта или сервиса на полгода — пример и шаблон

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

Что такое дорожная карта проекта?

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

В английском варианте это roadmap. Для заказчика-предпринимателя у неё три практических пользы:

• Деньги по частям. Вместо одной большой сметы на «всё сразу» — понятные этапы, каждый из которых можно оплатить, принять и остановить.
• Общий язык с разработчиком. Когда в середине работы приходит новая идея, её не вставляют в текущий этап, а кладут в карту и решают, в какую версию она пойдёт.
• Точка для решения. После каждой версии есть данные: пользуются ли клиенты, платят ли, где застревают. Карта заранее говорит, что делать с этими данными.

Хорошая дорожная карта отвечает на вопрос «зачем». Плохая — перечисляет функции без причин, и её невозможно пересмотреть, потому что непонятно, что именно должно было случиться.

	Дорожная карта	Техническое задание	Диаграмма Ганта
Отвечает на вопрос	Зачем и в каком порядке развиваем продукт	Что именно делаем в этом этапе и как примем	Кто, что и в какие дни делает внутри этапа
Горизонт	Квартал — год	Один этап или одна версия	Дни и недели одного этапа
Единица планирования	Версия, цель, веха	Экран, функция, требование	Задача с длительностью и связями
Кто ведёт	Заказчик вместе с разработчиком	Согласуют обе стороны, входит в договор	Исполнитель, заказчик смотрит
Как часто меняется	После каждой вехи	Только допсоглашением	По ходу работ, внутри срока этапа
Юридическая сила	Нет, это рабочий документ	Да, приложение к договору	Обычно нет, если не вошла в договор

Чем она отличается от ТЗ и диаграммы Ганта?

Дорожная карта описывает направление на месяцы и меняется после каждой вехи. ТЗ подробно описывает один этап и входит в договор. Диаграмма Ганта раскладывает работы внутри этапа по дням. Это три уровня одного плана, и путать их дорого.

Типичная ошибка — пытаться превратить дорожную карту в ТЗ на полгода вперёд. Тогда каждое изменение требует переделки договора, а требования к версии 3 пишутся до того, как кто-то увидел версию 1. Обратная ошибка — начать работы по одной карте без ТЗ: у этапа нет критериев приёмки, и спор о том, «что входило», неизбежен. Как написать ТЗ на конкретный этап, разобрано в статье о ТЗ на сайт или веб-сервис.

Из чего состоит дорожная карта?

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

1. Цель бизнеса. Не «сделать оплату», а «клиенты оплачивают счета без звонка менеджеру». Цель формулируется как изменение в работе компании или поведении клиента.
2. Метрика. Как поймём, что цель достигнута: доля заявок через кабинет, число оплат онлайн, время ответа. Метрику нужно уметь посчитать — значит, аналитика должна войти в версию заранее.
3. Состав версии. Три-семь крупных функций, без подробностей экранов. Подробности появятся в ТЗ.
4. Зависимости. Всё, без чего версия не запустится и что не делает разработчик: договор эквайринга, доступ к API учётной системы, тексты, юридические документы, решение руководителя.
5. Ответственный. Конкретный человек у заказчика, а не «отдел продаж». Без имени зависимость не закрывается.
6. Бюджет. Ориентир по этапу: точная сумма — для ближайшего, вилка «от» — для дальних.
7. Решение на вехе. Заранее записанное условие «идём дальше» и условие «стоп, разбираемся». Это то, что отличает карту от списка желаний.

Порядок версий определяется приоритетом. Для расстановки приоритетов есть отдельные методики, например метод MoSCoW, но для первой карты достаточно правила: в первую версию идёт только то, без чего не работает основной сценарий клиента. Как выбрать этот сценарий, подробно разобрано в статье MVP или полная версия.

Срок и версия	Что появляется у клиента	Зависимости и кто отвечает	Решение на вехе
Месяц 1: подготовка	Ничего: сценарии, роли, прототип экранов, ТЗ версии 1	Ответственный со стороны заказчика, список статусов заявки, выгрузка базы клиентов	Утверждаем ТЗ версии 1 и подписываем договор
Месяц 2: версия 1	Вход, подача заявки, статусы, уведомления на почту и в Telegram	Тексты писем и политика обработки данных — заказчик; домен и сервер — оформлены на заказчика	Запуск на части клиентов; стоп, если заявки по-прежнему идут в основном через звонки
Месяцы 3–4: версия 2	Счета и оплата онлайн, документы в кабинете, обмен с CRM или 1С	Договор эквайринга и оферта от юрлица заказчика; доступ к API учётной системы	Идём дальше, если клиенты платят через кабинет; иначе разбираем, где бросают оплату
Месяцы 5–6: версия 3	Отчёты для руководителя, роли менеджеров, напоминания о продлении	Список показателей от руководителя; решение, кто видит чьи данные	Пересобираем карту на следующие полгода по данным

Пример дорожной карты на полгода: кабинет клиента

Условная компания: сервисный бизнес, заявки принимают по телефону и почте, счета отправляют вручную. Цель на полгода — чтобы клиенты сами подавали заявки, видели статус и платили онлайн. Карта ниже разбита на подготовку и три версии.

Обратите внимание на третий столбец. Почти все задержки в таких проектах возникают не в разработке, а в зависимостях на стороне заказчика: эквайринг нужно подключать от своего юрлица, а политику обработки персональных данных по ч. 2 ст. 18.1 закона 152-ФЗ оператор обязан опубликовать сам. В тарифе «Веб-приложение / SaaS» юрдокументы и подключение эквайринга от вашего юрлица указаны как работы за доплату, поэтому их стоит планировать как отдельную строку.

Что даёт такая разбивка на практике:

• Версия 1 запускается на части клиентов, и уже через несколько недель видно, пользуются ли кабинетом. Если нет, оплату пока не делаем, а выясняем причину.
• Оплата онлайн идёт второй версией, потому что для неё нужна внешняя зависимость, а её оформление само по себе занимает время. Её запускают параллельно с работой над первой версией.
• Отчёты для руководителя — последними: их состав становится понятным, только когда в системе накопились реальные данные.

Пример для сайта и Telegram-бота

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

• Месяц 1 — сайт. Корпоративный сайт: услуги, кейсы, контакты, формы заявок, Метрика с целями. Веха: заявки приходят и считаются.
• Месяц 2 — бот заявок. Telegram-бот принимает заявку, задаёт уточняющие вопросы и передаёт её в CRM или таблицу. Веха: доля заявок из бота и сколько из них доходят до сделки.
• Месяцы 3–4 — контент и доработки. Страницы под отдельные услуги, статьи в блог, правки по данным Метрики. Работа ведётся небольшими задачами: первый месяц поддержки входит в тариф корпоративного сайта, дальше — по абонентке, а регулярное наполнение блога оплачивается отдельно.
• Месяцы 5–6 — решение об ИИ-ассистенте. Если менеджеры тратят много времени на однотипные вопросы, имеет смысл ассистент, который отвечает по вашим документам. Если вопросов мало, этот пункт честно вычёркивается.

Ориентиры по прайсу студии: корпоративный сайт — от 56 000 ₽ и 3–4 дня, Telegram-бот — от 16 000 ₽ и 1–2 дня, поддержка и развитие — от 7 900 ₽ в месяц, ИИ-ассистент — от 72 000 ₽. Это нижняя граница тарифов, точную сумму каждого этапа называем после брифа.

Как связать этапы с бюджетом и договором?

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

Как это выглядит в договорах студии:

• Оплата. По каждому договору — 50 % предоплаты и 50 % после подписания акта. Значит, в карте у этапа две денежные точки, их удобно поставить в план платежей компании.
• Срок. В договор записывается срок в рабочих днях от предоплаты и получения материалов. По ст. 708 ГК РФ в договоре подряда указывают начальный и конечный сроки, а по согласию сторон — и промежуточные сроки отдельных этапов.
• Изменения. Стоимость в договоре зафиксирована; если объём меняется, это оформляется допсоглашением. Новая идея из середины этапа уходит в карту, а не в текущую работу без оценки.
• Приёмка и гарантия. На подписание акта или мотивированный отказ — 5 рабочих дней, гарантия на исправление ошибок — 30 календарных дней с даты акта. Закладывайте эти дни в карту между версиями.

Бюджет в карте честнее вести двумя цифрами: точной суммой по подписанному этапу и ориентиром «от» по следующим. Нижние границы берутся из прайса: например, веб-приложение с кабинетами — от 160 000 ₽ и от 10 дней. Ориентир по дальним версиям уточняется на вехе, когда понятен их реальный состав. Подробнее о выборе схемы оплаты — в статье о фиксированной и почасовой оплате.

Как часто пересматривать карту?

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

Порядок пересмотра на вехе:

1. Смотрим метрику версии: достигнута цель или нет, и почему.
2. Принимаем решение, записанное заранее: идём дальше, дорабатываем текущую версию или останавливаемся.
3. Переносим накопленные идеи в карту и решаем, в какую версию каждая попадает или не попадает вовсе.
4. Уточняем состав и оценку ближайшей версии, пишем по ней ТЗ.
5. Ставим новую дату пересмотра и отмечаем в документе дату изменения.

Удобно, когда ход работ и сама карта видны в одном месте, а не в переписке. О том, как это устроено у студии, — в статье о кабинете с доской задач.

Какие ошибки превращают карту в список желаний?

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

• Даты без владельцев. «Интеграция с 1С — апрель», но никто у заказчика не отвечает за доступ к базе. Апрель наступает, доступа нет, этап стоит.
• Всё в первую версию. Первая версия раздувается до полного продукта, срок и бюджет растут, а проверить гипотезу не на чем.
• Нет строки для юридических задач. Оферта, политика обработки данных, договор с платёжным сервисом не появляются сами — у них свой срок и свой исполнитель.
• Нет времени на приёмку и обучение. Между версиями проходят проверка, исправления по гарантии, обучение сотрудников. Если карта ставит версии встык, сроки съезжают с первой же вехи.
• Дальние версии расписаны подробно. Детальные требования к пятому месяцу пишутся до того, как появились первые пользователи, и потом всё равно переписываются.
• Карта живёт у подрядчика. Если документ ведёт только разработчик, приоритеты постепенно определяет он, а не бизнес.

Когда дорожная карта вам не нужна?

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

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

Шаблон: как собрать дорожную карту в таблице

Откройте Excel или Google Таблицы и сделайте одну строку на версию и восемь столбцов. Этого хватает для продукта небольшой компании; сложнее делать не нужно, пока карта не начала работать.

1. Срок — месяц или диапазон месяцев, без точных дат для дальних версий.
2. Версия — номер и короткое название: «1 — заявки онлайн».
3. Цель бизнеса — одно предложение о том, что изменится.
4. Метрика — цифра, по которой проверим цель.
5. Состав — три-семь крупных функций.
6. Зависимости и ответственный — что нужно от заказчика и третьих сторон, с именем.
7. Бюджет — сумма по договору или ориентир «от».
8. Решение на вехе — условие «идём дальше» и условие «стоп».

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

Короткие ответы на частые вопросы

Что такое дорожная карта проекта простыми словами?

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

Можно ли вести дорожную карту в Excel?

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

На какой срок составлять дорожную карту?

Подробно — на ближайшие три месяца, крупными блоками — на полгода, ориентирами — на год. Чем дальше этап, тем меньше в нём деталей: точное содержание версии 3 станет понятно только после запуска версии 1.

Фиксируется ли дорожная карта в договоре?

Целиком — нет. В договор попадает ближайший этап: его ТЗ, цена и срок. По ст. 708 ГК РФ стороны могут дополнительно согласовать промежуточные сроки отдельных этапов, а следующие версии оформляются новыми договорами или допсоглашениями.

Кто должен составлять дорожную карту — заказчик или студия?

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

Услуги и кейсы по теме: веб-приложения и SaaS · корпоративные сайты · цены и сроки