Продуктовая команда, где дорожная карта связана с целями

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

Что продуктовая команда соберёт в Shtab вместо дорожной карты в презентации и бэклога в табличке:

• Дорожная карта — крупные инициативы и направления карточками на канбан-доске со статусами от «Идея» до «Выпущено», а сроки релизов — в представлении-календаре тех же задач.
• Бэклог и приоритизация — поток задач в одном проекте, где приоритет, метки и группировка показывают, что берём в работу сейчас, а что подождёт.
• Обратная связь и идеи — сигналы от пользователей, запросы клиентов и идеи команды попадают в один проект как задачи, а не теряются в чатах и почте.
• Планирование релизов — связанные этапы и сроки на диаграмме Ганта: исследование, дизайн, разработка, выпуск идут по порядку и пересчитываются при сдвиге.
• Цели и метрики продукта — над задачами надстраиваются цели и OKR продукта, чтобы видеть, как инициативы двигают результат.
• Связь идея → задача → цель — каждая инициатива привязана к цели, поэтому на любой вопрос «зачем мы это делаем» есть ответ из системы, а не из памяти.
• Главная страница — личная сводка с задачами, напоминаниями и комментариями, чтобы каждый видел свой кусок работы над продуктом сразу.

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

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

Релиз новой версии онбординга команда спланировала на диаграмме Ганта: исследование, прототип и тесты с пользователями, дизайн, разработка, выпуск — связанными этапами, где следующий шаг не стартует раньше предыдущего. Когда исследование затянулось на неделю, Ганта показала, что выпуск сдвигается, — и дату поправили заранее, а не объявили о переносе в день релиза. А над всем этим в графе целей висит цель продукта «Поднять активацию новых пользователей за квартал», к которой привязана инициатива по онбордингу. На продуктовом обзоре раз в две недели руководитель открывает граф целей и за минуту видит: какие инициативы двигают активацию, что уже выпущено, а что застряло на исследовании. Решения о том, что брать в следующий цикл, принимаются по связи задач с целями, а не по тому, кто громче просит.

Подойдёт продакт-менеджеру и продакт-оунеру, которым нужна общая картина: что в дорожной карте, что в бэклоге, что движет цели продукта. Продуктовым аналитикам, которые собирают обратную связь и метрики и хотят, чтобы выводы из них становились задачами, а не оставались в отчёте. Дизайнерам продукта, у которых идеи и результаты исследований живут отдельно от бэклога. Руководителю продукта, которому важно видеть связь между идеями, задачами и целями, а не просто список дел. Хорошо ложится на ситуацию, когда у команды есть продукт, цели по метрикам и поток идей и обратной связи, который нужно во что-то превращать. Пропустите этот раздел, если продукт ведёт один человек на ранней стадии и вся дорожная карта помещается в голове, — для такого хватит простого списка. И учтите: если вам нужен именно цикл разработки — бэклог разработки, спринты, баг-трекинг и переезд с Jira, — это смежный сценарий «Shtab для IT-команды», там логика про код, а здесь — про продукт.

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

• Держите дорожную карту крупными карточками-инициативами, а мелкие задачи — в бэклоге под ними. Если на доске дорожной карты лежат сотни мелких задач, она перестаёт быть картой и превращается в свалку.
• Привязывайте каждую заметную инициативу к цели продукта сразу при заведении. Задача без цели — это работа, про которую через месяц спросят «а зачем», и ответа не будет.
• Заведите отдельную точку приёма обратной связи и идей. Сигнал в чате теряется; сигнал как задача с автором и описанием доживает до разбора бэклога.
• Разбирайте входящие сигналы и идеи по расписанию, а не по настроению. Раз в неделю превращайте поток в решения: в бэклог, к существующей задаче или в архив с пометкой почему.
• Связывайте этапы релиза на Ганте там, где есть реальная зависимость (разработка после дизайна, дизайн после исследования). Тогда сдвиг одного срока честно пересчитывает остальные.
• Складывайте продуктовые артефакты — шаблон постановки задачи, чек-лист релиза, итоги исследований, описание метрик — в базу знаний, чтобы следующая инициатива собиралась быстрее.

• Дорожная карта в презентации. Её обновляют раз в квартал, и она расходится с реальной работой команды. Починка: дорожная карта карточками на доске, статус которых меняется по ходу дела.
• Бэклог в табличке без приоритетов. Сто строк, в которых непонятно, что брать следующим и почему. Починка: бэклог задачами с приоритетом и метками в одном проекте.
• Обратная связь по чатам и личке. Сигналы от пользователей оседают где попало и до бэклога доходит малая часть. Починка: единая точка приёма сигналов и идей, каждый — задача.
• Идеи в голове продакта. «Надо бы сделать онбординг» живёт устно, пока автор не забудет или не уйдёт. Починка: идея — карточка с описанием и связями.
• Задачи отдельно от целей. Цель по метрике живёт в презентации, бэклог — на доске, связи нет, и непонятно, приближает ли работа результат. Починка: привязать инициативы к целям продукта в графе целей.
• Релиз без зависимостей. Даты этапов есть, связей нет → задержка исследования не двигает выпуск, план врёт. Починка: связать этапы релиза на диаграмме Ганта.

Маленькой продуктовой команде из двух-трёх человек хватит одного проекта «Продукт», доски дорожной карты и бэклога с приоритетами — граф целей и планирование релизов на Ганте можно подключить позже, когда инициатив станет больше. Команде покрупнее, где над продуктом работают несколько ролей и метрик, уже нужны отдельная точка приёма сигналов, цели продукта над задачами и релизы на Ганте. По характеру работы: если основа — ровный поток правок и небольших улучшений, опирайтесь на канбан-доску бэклога; если в центре крупные релизы со сроками и этапами — добавьте планирование на диаграмме Ганта. Эти сценарии не исключают друг друга: доска дорожной карты и Ганта релиза живут в одном проекте и переключаются представлением. Важно не путать с разработкой: если вам нужен именно цикл написания кода — спринты, баг-трекинг, переезд с Jira, — это сценарий «Shtab для IT-команды», там речь про процесс разработки, а здесь — про продукт: что и зачем строим. А чтобы собрать базовый порядок в задачах и проектах, начните с тем управления проектами и контроля задач. Если рядом есть отдел маркетинга, которому продукт ставит задачи на запуски, ему подойдёт сценарий для отдела маркетинга.