Планирование продуктовой разработки: от бэклога до реальных сроков

У большинства продуктовых команд нет проблемы с количеством идей.

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

Проблема начинается позже.

После того как Product Owner определил, что действительно важно, возникает следующий вопрос:

когда команда сможет это сделать?

Именно на этом этапе приоритизированный бэклог должен превратиться в план продуктовой разработки.

Это не одно и то же.

Бэклог отвечает на вопрос «что нам потенциально нужно сделать?». Приоритизация — «что важнее?». А планирование — «в какой последовательности команда реально сможет выполнить работу и когда мы получим результат?»

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

Бэклог — ещё не план

В бэклоге может быть сто задач.

Допустим, Product Owner аккуратно расположил их по приоритету:

1. Новый сценарий регистрации.
2. Интеграция с платёжным сервисом.
3. Отчёт для корпоративных клиентов.
4. Переработка административной панели.
5. Улучшение поиска.
6. Технический долг.
7. Новая система уведомлений.

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

Но уже на втором шаге появляются ограничения.

Для первой инициативы нужны аналитик, backend, frontend и QA.

Для второй — тот же backend и DevOps.

Для третьей — аналитик, который ещё не закончил первую.

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

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

Чтобы получить ответ, нужно добавить в модель как минимум:

• оценки;
• исполнителей или специализации;
• зависимости;
• текущую загрузку;
• отсутствия;
• приоритеты между инициативами;
• календарь.

Только после этого список превращается в исполнимый план.

Планирование начинается с уровня инициатив, а не отдельных тикетов

Одна из частых ошибок продуктовой разработки — пытаться строить верхнеуровневый план непосредственно из всех задач таск-трекера.

В итоге Product Owner получает сотни строк и постоянно меняющуюся картину.

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

На верхнем уровне полезнее работать с инициативами или достаточно крупными этапами.

Например:

Инициатива: новая модель подписки

• аналитика;
• backend;
• frontend;
• тестирование;
• запуск.

Внутри каждого этапа может находиться множество конкретных задач в Jira, YouTrack, Kaiten или другой системе.

Но для продуктового плана важнее понимать:

• сколько примерно занимает этап;
• кто нужен для его выполнения;
• от чего он зависит;
• когда нужный специалист сможет начать;
• какое место инициатива занимает относительно остальных.

Это позволяет не смешивать стратегию развития продукта с ежедневным управлением задачами команды.

Сначала определите, что действительно должно попасть в план

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

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

Поэтому полезно разделять как минимум три состояния:

В работе — команда уже выполняет инициативу.

Запланировано — решение о реализации принято, есть достаточная информация для планирования.

Бэклог — инициатива рассматривается, но пока не обязана занимать место в календарном плане.

Так Product Owner избегает ложной точности.

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

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

Приоритет должен влиять на последовательность работ

Приоритизация имеет смысл только тогда, когда она меняет поведение плана.

Допустим, есть три инициативы:

1. Новый платёжный сценарий — высокий приоритет.
2. Улучшение onboarding — средний.
3. Новый внутренний отчёт — низкий.

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

Иначе приоритет существует только как цветная метка в карточке.

Это важный переход:

приоритет продукта должен превращаться в приоритет получения ограниченного ресурса.

Но здесь есть нюанс. Приоритет не означает, что вся команда должна немедленно бросить текущую работу.

Если frontend может продолжать уже начатую задачу, пока backend переключается на более важную инициативу, план должен учитывать это.

Поэтому продуктовая приоритизация и календарное планирование связаны, но не идентичны.

Оценка задачи и дата её завершения — разные вещи

Команда может оценить разработку функции в семь рабочих дней.

Это полезная информация.

Но фраза «разработка займёт семь дней» ещё не означает «функция будет готова через семь дней».

Если разработчик освободится только через две недели, календарный срок будет другим.

Если после backend должен начать frontend, а затем QA, итоговая дата станет ещё позже.

Если между этапами есть зависимости или отсутствия сотрудников, результат сдвинется снова.

Поэтому Product Owner должен различать:

оценку длительности — сколько работы требуется;

и

календарный срок — когда работа реально начнётся и закончится с учётом всей остальной загрузки.

Именно смешение этих двух понятий часто создаёт ложные ожидания у бизнеса.

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

Хотя специалист мог иметь в виду только чистую трудоёмкость после фактического начала работы.

Планируйте ресурсы, а не только задачи

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

Например, в команде может быть:

• два frontend-разработчика;
• два backend-разработчика;
• один аналитик;
• один QA;
• один дизайнер.

При этом почти каждая крупная инициатива начинается с аналитики.

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

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

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

Это особенно важно, когда одна команда обслуживает несколько продуктов, направлений или проектов.

Учитывайте зависимости между этапами

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

Если frontend зависит от API, а API — от аналитики, последовательность выглядит так:

аналитика → backend → frontend → QA

При этом часть этапов может идти параллельно.

Например, дизайн интерфейса может начаться одновременно с аналитикой. QA может готовить сценарии проверки ещё до полного завершения разработки.

Чем точнее команда понимает реальные зависимости, тем реалистичнее становится прогноз.

Но здесь важно не впасть в другую крайность и не пытаться построить идеальную инженерную модель из тысячи связей.

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

Roadmap и календарный план решают разные задачи

Product roadmap помогает ответить на вопросы:

• куда развивается продукт;
• какие инициативы важны;
• какие результаты команда хочет получить;
• какие направления находятся в фокусе квартала или полугодия.

Это стратегический инструмент.

Календарный план отвечает на другие вопросы:

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

Попытка заставить roadmap одновременно выполнять обе функции часто приводит к проблеме.

Если сделать его слишком подробным, он становится тяжёлым операционным документом.

Если оставить высокоуровневым, он не даёт ответа на вопрос о реальных сроках.

Поэтому логичнее разделять уровни:

roadmap показывает направление, а операционный продуктовый план проверяет его выполнимость.

Как построить процесс планирования продуктовой разработки

Практически этот процесс можно разложить на восемь шагов.

Шаг 1. Соберите инициативы

Сведите в одно место всё, что уже находится в работе и что принято к реализации.

Не нужно переносить весь долгосрочный backlog. Только те инициативы, которые действительно претендуют на ресурсы команды.

Шаг 2. Расставьте относительные приоритеты

Проекты и инициативы должны иметь понятный порядок.

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

Шаг 3. Разбейте инициативы на этапы

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

Шаг 4. Оцените длительность

Используйте единую систему оценок.

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

Важно не стремиться к мнимой точности. План всё равно будет уточняться.

Шаг 5. Назначьте исполнителей или специализации

Определите, кто нужен для каждого этапа.

Именно здесь становится понятно, какие инициативы конфликтуют за один и тот же ресурс.

Шаг 6. Зафиксируйте зависимости

Укажите, какие этапы нельзя начать раньше других.

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

Шаг 7. Рассчитайте календарный план

Теперь можно определить реальные интервалы работы.

При этом должны учитываться:

• текущие работы;
• приоритеты;
• оценки;
• зависимости;
• рабочий календарь;
• отсутствия сотрудников.

После этого появляются расчётные даты старта и завершения.

Шаг 8. Регулярно обновляйте прогноз

План продуктовой разработки не должен восприниматься как контракт с будущим.

Он является текущей моделью наиболее вероятной последовательности работ.

Если меняются исходные данные, прогноз должен меняться вместе с ними.

Что делать с изменениями

Изменения — нормальное состояние продукта.

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

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

Допустим, в середине квартала появляется новая инициатива с максимальным приоритетом.

Недостаточно просто поставить её первой в backlog.

Нужно увидеть:

• когда она реально сможет начаться;
• кого она заберёт из текущего плана;
• какие работы будут отложены;
• насколько изменятся сроки других инициатив;
• остаётся ли квартальный план приемлемым.

Именно такой анализ превращает переприоритизацию из эмоционального решения в управляемый компромисс.

План должен хранить историю изменений

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

Поэтому полезно сохранять историю плана.

Например:

1 сентября Ожидаем завершение проекта — 18 октября.

15 сентября Добавили срочную интеграцию. Новый прогноз — 28 октября.

3 октября Уточнили оценку backend. Новый прогноз — 1 ноября.

Такая история позволяет отделять плохое планирование от нормального изменения условий.

Она также помогает обсуждать сроки с бизнесом предметно:

Мы не просто «опять перенесли дату». 15 сентября приоритет изменился, новая работа заняла восемь рабочих дней backend-разработчика, поэтому текущий прогноз стал другим.

Какие метрики действительно полезны Product Owner

Для верхнеуровневого управления разработкой необязательно собирать десятки показателей.

Полезнее несколько конкретных сигналов.

Проекты и инициативы в работе

Сколько направлений команда выполняет одновременно?

Слишком большое количество параллельной работы может означать постоянное переключение контекста.

Загрузка дефицитных специалистов

Кто является узким местом текущего плана?

Именно этот ресурс чаще всего определяет фактическую скорость движения портфеля.

Запланированные инициативы

Что будет выполняться после текущих работ и почему именно в таком порядке?

Отклонение от предыдущего плана

Какие сроки изменились и что стало причиной?

Риски ближайших стартов

Есть ли инициатива, которая должна была начаться, но не может получить нужный ресурс?

Такие сигналы полезнее общего ощущения, что «всё немного задерживается».

Типовые ошибки продуктового планирования

Пытаться поместить в план весь backlog

Чем дальше горизонт, тем выше неопределённость.

Долгосрочные идеи не обязаны получать точные календарные даты.

Подменять приоритет дедлайном

Фраза «это нужно к 1 ноября» не объясняет, что делать, если одновременно есть другая задача «к 1 ноября».

Нужен относительный приоритет.

Планировать без ресурсов

Если даты поставлены без проверки доступности команды, они выражают желание, а не прогноз.

Игнорировать уже начатую работу

Новая инициатива не появляется в пустой системе. Команда уже чем-то занята.

План должен учитывать незавершённые работы.

Считать первоначальный план неизменяемым

Продукт развивается в условиях неопределённости.

Цель не в том, чтобы никогда не менять план, а в том, чтобы понимать последствия каждого изменения.

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

Product Owner не должен вручную переставлять каждую техническую задачу, чтобы поддерживать актуальный продуктовый план.

Полезно разделить уровни управления.

Стратегический уровень

Цели, направления, roadmap, бизнес-приоритеты.

Плановый уровень

Инициативы, этапы, ресурсы, зависимости, расчётные сроки.

Исполнительный уровень

Конкретные задачи, pull request, баги, чек-листы, работа команды внутри спринта или потока.

Jira, YouTrack, Kaiten и другие таск-трекеры хорошо подходят для исполнительного уровня.

Проблема возникает, когда Product Owner пытается получить из огромного списка тикетов понятный ответ на вопрос:

когда закончатся пять ключевых инициатив квартала?

Для этого нужен более высокий уровень агрегации.

Где здесь KORDO

KORDO работает именно на плановом уровне.

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

Это не замена backlog и не попытка перенести внутрь системы каждый тикет разработки.

Задача другая:

связать решение Product Owner о том, что важнее, с ответом на вопрос, когда команда сможет это реализовать.

Когда приоритет изменяется, важен не сам факт перемещения инициативы вверх, а последствия для всего последующего плана.

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

Главное

Хорошее планирование продуктовой разработки строится как последовательность:

бэклог → приоритеты → этапы → оценки → ресурсы → зависимости → календарный план → перепланирование.

Если остановиться на первых двух шагах, получится хорошо организованный список задач.

Если поставить даты без следующих четырёх — получится roadmap с желаемыми сроками.

Исполнимый план появляется только тогда, когда приоритеты соединяются с реальной пропускной способностью команды.

Именно тогда Product Owner может отвечать не только на вопрос «что мы хотим сделать?», но и на более важный для бизнеса вопрос:

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