Планирование релизов продукта: как связать состав, ресурсы и реальные сроки

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

Обычно есть несколько источников работы одновременно:

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

Почти всё выглядит полезным.

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

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

Главная задача Product Owner — определить:

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

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

Что такое планирование релиза

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

У релиза обычно есть несколько ключевых параметров:

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

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

Например:

Релиз должен выйти 15 декабря.

Но при этом ещё не известно, какой объём действительно помещается до этой даты.

Или наоборот:

В релиз должны войти все эти 14 инициатив.

Но никто не проверил, когда команда сможет их завершить.

Хорошее планирование связывает обе стороны:

состав релиза ↔ доступная мощность команды ↔ дата выпуска.

Сначала определите цель релиза

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

Например:

Запуск нового пользовательского сценария

Цель — дать пользователям возможность пройти весь новый процесс.

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

Улучшение активации

Цель — повысить долю пользователей, которые доходят до первого полезного действия.

Тогда релиз может объединять несколько изменений onboarding.

Выполнение обязательства перед клиентом

Главным ограничением становится согласованный объём и дата.

Технический релиз

Основная цель — снижение риска, миграция или изменение инфраструктуры.

Если цель не определена, состав релиза быстро превращается в принцип:

раз уж мы всё равно выпускаемся, давайте добавим ещё это.

И объём начинает расти.

Релиз должен иметь границы

Одна из типичных проблем — постоянное расширение scope.

В начале в релиз входят пять изменений.

Через неделю добавляется ещё два.

Потом появляется «совсем небольшая» задача.

Затем бизнес просит включить ещё одну функцию, раз выпуск всё равно скоро.

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

Но суммарный эффект постепенно разрушает первоначальный прогноз.

Поэтому у релиза должны быть понятные границы:

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

Это не означает, что состав нельзя менять.

Это означает, что изменение должно быть осознанным.

Приоритизация состава релиза

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

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

Обязательные

Без них релиз не решает заявленную задачу или нарушается внешнее обязательство.

Важные

Сильно повышают ценность релиза, но при необходимости могут быть перенесены.

Дополнительные

Полезны, если остаётся доступная мощность.

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

Главное — чтобы при дефиците времени Product Owner уже понимал, что будет исключено первым.

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

Фиксированная дата или фиксированный состав

У релиза обычно есть одно из двух главных ограничений.

Фиксированная дата

Например:

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

Тогда объём должен подстраиваться под дату.

Фиксированный состав

Например:

релиз состоится только после готовности полного нового платёжного сценария.

Тогда дата является следствием плана.

Иногда фиксированы и дата, и состав.

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

Если фиксированы сразу:

• scope;
• дата;
• команда,

любая ошибка оценки или новая проблема превращается в срыв.

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

Не путайте релиз с завершением разработки

Функция может быть разработана, но релиз ещё не готов.

Могут потребоваться:

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

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

Если эти работы важны, они должны быть частью плана.

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

Разбейте релиз на этапы

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

Например:

1. Аналитика.
2. Дизайн.
3. Разработка.
4. Интеграция.
5. Тестирование.
6. Исправления.
7. Подготовка выпуска.
8. Релиз.

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

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

Зависимости определяют минимально возможный срок

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

Функция A зависит от нового API.

Функция B может разрабатываться независимо.

Функция C использует результат A.

Даже если у команды достаточно людей, C не может завершиться раньше A.

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

Важно понять:

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

Общие ресурсы создают очередь

Теперь добавим ещё одно ограничение.

Для A и B нужен один backend-разработчик.

Формально обе функции независимы.

Ресурсно — нет.

Если A имеет более высокий приоритет, backend сначала выполняет A, затем B.

В таком случае срок B зависит от работы A, даже если между самими функциями нет технической зависимости.

Это принципиально важное различие.

Есть:

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

и

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

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

Оценка задачи ещё не даёт дату релиза

Допустим:

• backend — 5 дней;
• frontend — 4 дня;
• QA — 3 дня.

Это не означает, что функция будет готова за 12 дней.

Возможно, часть работы идёт параллельно.

А возможно, нужный backend освободится только через неделю.

Поэтому для каждой значимой работы нужно знать не только оценку, но и:

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

Только после этого появляется календарный прогноз.

Как рассчитать дату релиза

Практический процесс можно построить так.

Шаг 1. Определите цель и обязательный scope

Зафиксируйте минимальный набор изменений, который делает релиз осмысленным.

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

Даже внутри одного релиза часть работ важнее других.

Шаг 3. Разбейте работу на этапы

Не обязательно планировать каждый тикет.

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

Шаг 4. Получите оценки

Используйте рабочую единицу — например, рабочие дни.

Шаг 5. Укажите зависимости

Что должно закончиться раньше?

Что может идти параллельно?

Шаг 6. Назначьте ресурсы

Кто выполняет каждый этап?

Есть ли конфликты с другими проектами и релизами?

Шаг 7. Учтите текущую занятость

Команда уже чем-то занимается.

Новый релиз не начинается в вакууме.

Шаг 8. Добавьте рабочий календарь

Учтите выходные, праздники и отсутствия сотрудников.

Шаг 9. Постройте календарную последовательность

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

Шаг 10. Добавьте этап выпуска

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

После этого появляется текущий прогноз даты релиза.

Дедлайн релиза и прогноз релиза — разные вещи

Пусть бизнес хочет выпустить новую функцию 1 декабря.

Это целевой срок.

После расчёта команда видит, что текущий прогноз — 12 декабря.

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

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

Уменьшить scope

Убрать менее важные элементы.

Повысить приоритет

Дать релизу ресурс раньше других работ.

Изменить последовательность

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

Добавить ресурс

Если именно ресурс является текущим ограничением.

Передвинуть дату

Если стоимость ускорения выше ценности исходного дедлайна.

Главное — не подменять прогноз желаемой датой.

Не используйте буфер для сокрытия проблем

Иногда к каждой оценке добавляют большой запас «на всякий случай».

Это может уменьшить количество формальных срывов, но ухудшает понимание плана.

Полезнее разделять:

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

Так Product Owner понимает, где именно находится запас.

И может принимать решение, если он начинает расходоваться.

Что делать с багами перед релизом

В конце разработки часто появляется новая очередь:

• блокирующие ошибки;
• важные дефекты;
• косметические проблемы;
• улучшения, замеченные во время тестирования.

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

Полезно разделять дефекты по влиянию.

Например:

Блокирует релиз

Без исправления выпуск невозможен.

Нужно исправить желательно до релиза

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

Можно перенести

Не мешает достижению основной цели релиза.

Это снова задача приоритизации.

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

Что делать, если оценка изменилась

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

Есть два плохих варианта:

скрыть изменение и надеяться догнать;

или

немедленно объявить новый срок без оценки остальных возможностей.

Полезнее пересчитать текущий план.

После этого видно:

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

Таким образом, изменение оценки становится входом для нового решения.

Что делать, если появилась более приоритетная инициатива

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

В середине цикла может появиться новый проект с более высоким бизнес-приоритетом.

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

Важно увидеть:

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

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

Несколько релизов одной команды

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

Тогда каждый из них конкурирует за общие ресурсы.

Например:

• релиз продукта A требует backend;
• релиз продукта B требует того же backend;
• внутренний проект C тоже использует этого специалиста.

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

Общий календарь покажет конфликт.

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

Как понять, что релиз под угрозой

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

Полезные сигналы:

Критический этап не стартовал вовремя

Значит, последующая цепочка уже под риском.

Узкий специалист занят дольше, чем ожидалось

Следующие работы получат ресурс позже.

Оценка обязательного элемента выросла

Нужно пересчитать дату или scope.

Появился новый блокер

Например, внешняя интеграция или согласование.

Слишком много работ остаётся на конец цикла

Особенно если тестирование и исправления сжаты в последние дни.

План изменился, но дата релиза осталась прежней

Это повод проверить, не превратилась ли дата из прогноза в пожелание.

План и факт релиза

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

Например:

Исходный план

Релиз — 15 ноября.

Обновление 1

После уточнения оценки backend прогноз — 20 ноября.

Обновление 2

После срочного проекта прогноз — 27 ноября.

Факт

Релиз — 26 ноября.

Такая история помогает понять:

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

Это полезнее, чем просто сравнение одной первоначальной даты с фактом.

Релизный план не должен заменять таск-трекер

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

Нет необходимости переносить их все на верхний уровень.

Таск-трекер продолжает отвечать на вопросы:

• что делает разработчик;
• какой статус тикета;
• где pull request;
• какой баг найден;
• что входит в текущий спринт.

Релизное планирование отвечает на другой уровень:

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

Эти инструменты дополняют друг друга.

Где здесь KORDO

KORDO полезен там, где релиз зависит от нескольких этапов и специалистов и должен конкурировать за ресурсы с другими инициативами.

Работы можно представить как этапы проекта, указать оценки, исполнителей и зависимости.

Дальше календарный срок формируется с учётом:

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

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

То есть Product Owner работает не только с формулировкой:

«релиз нужен 15 декабря»,

а с текущим ответом:

«при существующем составе, ресурсах и приоритетах план сейчас приводит нас к такой дате».

А дальше уже можно принимать решение.

Главное

Планирование релиза — это управление тремя связанными ограничениями:

состав → ресурсы → срок.

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

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

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

Поэтому хороший релизный процесс выглядит так:

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

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

Она становится текущим прогнозом, который можно объяснить, проверить и осознанно изменить.