Планирование roadmap при высокой неопределённости

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

• Horizon 1 (0–2 недели) — committed: задачи полностью проработаны, готовы к исполнению, команда уверена в оценке.
• Horizon 2 (2–6 недель) — at-risk: есть зависимости или открытые вопросы, задачи требуют refinement.
• Horizon 3 (6+ недель) — exploratory: направления, не задачи; уточняются по мере поступления информации.

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

1. Зафиксировал outcome, а не output: «Пользователь может совершить покупку в 3 клика» вместо «Интегрировать YooKassa API».
2. Разбил работу на независимые вертикали: UI-форма оплаты, backend-оркестратор, вебхук-обработчик — каждая могла поставляться и тестироваться отдельно.
3. Ввёл assumption log в Notion: каждое решение содержало явное предположение и триггер пересмотра.
4. Синхронизировался с PM и стейкхолдерами еженедельно с явной повесткой: «Что изменилось? Какие допущения стали невалидными?»

Инструменты, которые я применяю:

• Shape Up (Basecamp) — аппетит фиксируется до начала работы, команда сама решает как достичь цели.
• Impact mapping — связываю deliverable с бизнес-метрикой, чтобы при изменении контекста было понятно, что отрезать.
• Dependency matrix — таблица в Confluence, где строки = эпики, столбцы = команды/сервисы; блокеры видны сразу.

# Assumption Log (пример строки)
| ID  | Допущение                        | Решение, которое зависит | Триггер пересмотра              | Статус  |
|-----|----------------------------------|--------------------------|----------------------------------|--------|
| A-1 | Регулятор утвердит SCA до 1 июня | Использовать 3DS v2      | Письмо от регулятора с датой     | Open   |
| A-2 | YooKassa поддержит webhook v3    | Отказ от polling         | Ответ YooKassa на тест-запрос   | Closed |

Результат: когда регулятор перенёс дату на 3 месяца, мы не потеряли спринт — просто переключили H2 на альтернативный сценарий (Stripe fallback), потому что решение было явно помечено как зависимое от A-1.

Подводные камни

• Горизонт 3 превращается в «мусорное ведро» — задачи попадают туда и никогда не пересматриваются. Нужен явный ритм pruning раз в 4 недели.
• Committed зона раздувается — команда или PM давят на увеличение committed, теряя буфер на непредвиденное. Держите 20% спринта незапланированными.
• Outcome формулируется как output — «выкатить фичу» вместо «снизить churn на 5%». При изменении требований непонятно, что сохранять.
• Assumption log не ведётся — решения принимаются повторно, потому что команда не помнит, почему был выбран тот или иной подход.
• Стейкхолдеры видят только H1 — они начинают импровизировать и добавлять срочные задачи, минуя процесс. Делитесь всем roadmap, объясняя уровни уверенности.
• Нет явного владельца каждого допущения — когда допущение становится невалидным, никто не инициирует пересмотр.
• Переоценка скорости команды при параллельных неопределённостях — velocity падает из-за частых переключений контекста, что не учитывается в планировании.

• Выдавать rough estimate за обязательство.
• Прятать неопределённость от stakeholders.
• Не иметь критериев, когда план нужно пересмотреть.

• Управляет uncertainty явно.
• Строит план через milestones и learning points.
• Коммуницирует изменения до того, как они становятся кризисом.