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

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

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

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

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

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

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

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

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

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