Планирование, оценки и управление неопределённостью

О чём этот модуль

Оценка — это не гадание и не клятва кровью.

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

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

Плохое управление неопределённостью:
"Мы пока ничего не знаем, поэтому ничего сказать нельзя".

Другая крайность:
"Назовите точную дату, а дальше как-нибудь уложитесь".

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

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

Результаты обучения

После модуля участник должен уметь:

различать оценку, прогноз, целевую дату, deadline и commitment;
не смешивать размер работы, трудозатраты, календарную длительность и стоимость;
выбирать способ оценки под конкретный вопрос, а не использовать story points по привычке;
давать диапазон вместе с уровнем уверенности и условиями применимости;
выделять неизвестность в spike или discovery task;
строить delivery forecast на основании исторического потока команды;
использовать risk buffer открыто, не превращая его в спрятанную ложь;
обновлять прогноз по мере появления фактов;
разговаривать со стейкхолдерами о сроках без театра точности;
защищать команду от разрушительного давления, не пряча от бизнеса реальное состояние delivery;
отличать проблему оценки от проблемы slicing, архитектуры, требований, зависимостей или самого потока работы.

1. Зачем вообще нужна оценка

Бизнес обычно спрашивает не число ради числа. За вопросом «сколько займёт?» находится решение, которое кто-то должен принять.

Например:

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

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

Стейкхолдер:
— Когда будет готово?

Лид:
— С какой целью нужна дата? От неё зависит внешний запуск,
договор с клиентом, бюджет или порядок задач?

Это не уход от ответа. От ответа зависит необходимая точность и цена ошибки.

Если требуется решить, делать ли функцию в этом квартале, может быть достаточно t-shirt sizing: S / M / L / XL. Если на конкретную дату назначена миграция клиентов, нужен уже не размер, а календарный прогноз с зависимостями, диапазоном и вероятностью.

Главный принцип

Точность оценки должна соответствовать решению,
которое принимается на её основании.

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

2. Что именно мы оцениваем

Большая часть конфликтов вокруг оценок возникает потому, что разные люди говорят об одном числе, но подразумевают разные объекты.

Объект	Вопрос	Пример
Размер	Насколько один элемент работы больше другого?	«Эта задача примерно вдвое больше базовой»
Трудозатраты	Сколько активной работы потребуется?	«Около четырёх человеко-дней»
Длительность	Сколько календарного времени пройдёт от начала до завершения?	«От пяти до девяти рабочих дней»
Стоимость	Сколько ресурсов будет потрачено?	«Около 400 тысяч рублей с учётом внешнего аудита»
Пропускная способность	Сколько элементов команда обычно завершает за период?	«Обычно 8–12 задач за две недели»
Дата поставки	Когда результат окажется у пользователя?	«С вероятностью 85% — не позднее 18 августа»
Объём к дате	Что мы успеем поставить к заданному моменту?	«К 18 августа вероятнее всего войдут сценарии A и B; C — условный»

Эти вещи связаны, но не равны друг другу.

5 человеко-дней ≠ 5 календарных дней
8 story points ≠ 8 дней
маленькая задача ≠ быстро поставленная задача
много занятых людей ≠ короткий delivery

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

Четыре времени одной задачи

Полезно различать как минимум:

Touch time
время, когда над задачей реально работают.

Waiting time
время ожидания решения, доступа, review, тестовой среды,
другой команды или внешнего ответа.

Cycle time
время от фактического начала работы до завершения.

Customer lead time
время от появления запроса до получения результата пользователем.

Если touch time равен одному дню, а cycle time — двенадцати, требование «разработчики должны кодить быстрее» атакует не то место системы.

3. Estimation, forecast, target, deadline и commitment

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

Estimation — оценка

Оценка — модель размера, усилий или длительности работы на основании текущего знания.

"По текущему пониманию реализация займёт 5–8 рабочих дней".

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

Forecast — прогноз

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

"При текущем scope и составе команды вероятность завершить
до 18 августа составляет примерно 85%".

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

Target — целевая дата

Target — дата, к которой организация хочет получить результат.

"Мы хотим выпустить функцию к 18 августа,
потому что 20 августа начинается маркетинговая кампания".

Желание организации реально и важно. Но само по себе оно не является наблюдением о длительности работы.

Deadline — предельная дата

Deadline — дата, после которой результат резко теряет ценность или наступают внешние последствия.

"С 1 сентября старый протокол перестаёт приниматься регулятором".

Deadline не надо «оценивать». Его надо принять как ограничение и изменить план: уменьшить scope, раньше начать discovery, снять зависимости, подготовить fallback, разделить миграцию на этапы.

Commitment — обязательство

Commitment — принятое обязательство удерживать цель и действовать для её достижения в пределах согласованных условий.

"Мы берём обязательство обеспечить переход обязательных клиентов
на новый протокол к 1 сентября. Для этого фиксируем минимальный scope,
замораживаем необязательные изменения и готовим fallback".

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

В Scrum commitment связан не с обещанием закрыть каждую первоначально выбранную задачу любой ценой, а с Product Goal, Sprint Goal и Definition of Done. Сам Sprint Backlog обновляется по мере появления нового знания, а scope может уточняться и пересогласовываться без разрушения Sprint Goal. Scrum Guide также прямо использует слово forecast, когда говорит о выборе объёма на Sprint. (Scrum Guide)

Сводное различение

Estimate:
сколько, вероятно, потребует работа.

Forecast:
какой результат и к какому моменту вероятен при текущих условиях.

Target:
к какому моменту мы хотим получить результат.

Deadline:
после какого момента возникают существенные последствия.

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

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

Кто-то назвал оценку → оценка превратилась в target →
target объявили deadline → deadline истолковали как commitment →
любое новое знание назвали нарушением обещания.

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

4. Оценка — условное утверждение

Фраза «пять дней» почти ничего не сообщает, если неизвестно, при каких условиях она истинна.

Плохая оценка:
"Сделаем за 3 дня".

Осмысленная оценка:
"Если API внешнего сервиса соответствует документации — 3 дня.
Если понадобится обходить ограничения авторизации — 5–7 дней.
Если выяснится, что нет стабильного sandbox, сначала нужен spike на 1 день".

Полная оценка содержит:

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

Шаблон:

Мы оцениваем: [какой результат считается завершённым].

Диапазон: [от — до].
Уверенность: [низкая / средняя / высокая] или [вероятность].

Оценка действует при условиях:
- ...
- ...

Основные риски:
- ...
- ...

Чтобы повысить уверенность, сначала:
- ...

Следующий пересмотр прогноза:
- [событие или дата].

Неизвестность не исчезает от требования назвать число

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

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

Запрет говорить о неизвестности
не создаёт определённость.

Он создаёт систему, в которой неизвестность запрещено показывать.

5. Откуда возникает неопределённость

«Сложная задача» — слишком грубое описание. Лид должен видеть, какой именно тип неизвестности создаёт разброс.

5.1. Неопределённость требований

Неясно:

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

Действие лида: refinement, примеры, acceptance criteria, прототип, согласование границ.

5.2. Техническая неизвестность

Неясно:

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

Действие лида: spike, прототип, нагрузочный эксперимент, проверка интеграции.

5.3. Неизвестность зависимости

Сама работа понятна, но результат зависит от:

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

Действие лида: владелец зависимости, срок ответа, контракт, эскалация, fallback.

5.4. Неопределённость потока

Задача понятна, но неизвестно, сколько она будет ждать:

свободного разработчика;
review;
QA;
исправления окружения;
решения по архитектуре;
релизного окна.

Действие лида: WIP limits, явные очереди, work item age, устранение bottleneck, изменение политики потока.

5.5. Неопределённость объёма

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

один провайдер или пять;
новый пользователь или миграция существующих;
happy path или полный набор исключений;
одна платформа или web + iOS + Android;
один язык или локализация;
ручной запуск или полноценная автоматизация.

Действие лида: slicing, scope table, обязательное и необязательное, отдельные инкременты.

5.6. Неопределённость качества текущей системы

Изменение локально, но система может быть хрупкой:

нет тестов;
контракты не зафиксированы;
бизнес-правила размазаны;
данные содержат исторические исключения;
нет observability;
сборка нестабильна.

Действие лида: техническая разведка, characterization tests, ограниченная миграция, feature flag, rollback plan.

5.7. Неопределённость человеческой доступности

Нельзя считать всех людей одинаковыми взаимозаменяемыми единицами capacity. Важны:

конкретное знание домена;
отпуск и on-call;
онбординг;
параллельная ответственность;
число переключений контекста;
необходимость наставничества;
реальная способность работать с данным компонентом.

Действие лида: карта компетенций, снижение bus factor, передача контекста, ограничение параллельной работы.

6. Горизонт планирования и предел точности

Чем дальше горизонт, тем меньше конкретных фактов и больше возможных изменений.

Ближайшие 1–3 дня:
можно обсуждать конкретную работу и конкретные блокеры.

Ближайший Sprint:
можно строить достаточно предметный forecast при понятном scope.

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

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

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

На дальнем горизонте планируют:

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

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

Rolling-wave planning

План строится волнами:

Далеко:
грубые контуры и сценарии.

Ближе:
уточнённый scope, зависимости и диапазон.

Непосредственно перед работой:
конкретный исполнимый план.

Во время работы:
перепланирование на основании фактов.

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

7. Способы оценки

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

Вопрос	Подходящий инструмент	Что получится
Какая из инициатив грубо крупнее?	T-shirt sizing	Относительные классы `S / M / L / XL`
Сколько чистого усилия видит команда?	Ideal days или диапазон трудозатрат	Модель активной работы без календарных ожиданий
Насколько задача велика относительно привычных задач этой команды?	Story points	Локальный относительный размер
Какие разные модели задачи находятся в головах команды?	Planning Poker	Обсуждение причин расхождения оценок
Где находится асимметрия риска?	Трёхточечная оценка	Optimistic / most likely / pessimistic scenarios
Сколько обычно проходит от начала до завершения?	Исторический cycle time	Распределение длительности и SLE
Когда, вероятно, завершится фиксированный scope?	Throughput + probabilistic forecast	Диапазон дат с confidence levels
Сколько scope войдёт к фиксированной дате?	Throughput + probabilistic forecast	Диапазон объёма с confidence levels

7.1. T-shirt sizing

Пример шкалы:

XS / S / M / L / XL

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

Подходит для:

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

Не подходит для:

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

Сильный вопрос при sizing:

"Почему это L, а не M? Какое ограничение создаёт разницу?"

Ценность возникает не из буквы, а из вскрытого основания.

7.2. Ideal days

Ideal day — объём работы, который можно было бы выполнить за идеальный день без ожиданий, встреч, переключений, инцидентов и организационного шума.

Это способ обсуждать чистое усилие, но не календарную длительность.

3 ideal days могут превратиться в:
- 3 календарных дня при непрерывной работе;
- 6 дней при review и параллельных задачах;
- 10 дней при внешней зависимости.

Опасность ideal days начинается, когда слово ideal исчезает, а число начинают трактовать как дату.

7.3. Story points

Story points — относительная единица размера работы внутри конкретной команды. Обычно оценка включает некоторую смесь:

объёма;
сложности;
неопределённости;
риска.

Пример относительной шкалы:

1, 2, 3, 5, 8, 13, 21

Story points полезны, если:

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

Scrum не требует использовать story points. Scrum Guide говорит, что элементы Product Backlog получают нужные контексту атрибуты, включая размер, и что за sizing отвечают Developers, но не предписывает конкретную единицу или технику. Поэтому фраза «мы работаем по Scrum, значит обязаны ставить story points» методологически неверна. (Scrum Guide)

Story points становятся вредными, когда:

1 point тайно приравнивают к одному дню;
менеджмент задаёт target velocity;
по points сравнивают команды;
рост velocity объявляют ростом производительности;
выполненные points превращают в KPI человека;
points начисляют за частично законченную работу;
команда тратит часы на спор между 5 и 8, хотя решение от этого не меняется;
большую неопределённую задачу просто называют 21, вместо того чтобы разрезать или исследовать.

Один из людей, стоявших у происхождения story points, Рон Джеффрис, впоследствии отдельно критиковал их использование для сравнения команд, давления через velocity и слабого прогнозирования даты. Он подчёркивает, что исходно points выросли из ideal days и использовались для выбора объёма итерации, а не как универсальная единица производительности. (Story Points Revisited)

Что измеряет velocity

Velocity = объём story points,
который конкретная команда завершила за итерацию.

Velocity не измеряет:

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

Если команда раньше называла задачу 5, а теперь называет похожую задачу 8, velocity может вырасти без какого-либо изменения delivery.

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

7.4. Planning Poker

Planning Poker — способ одновременно показать индивидуальные оценки, а затем обсудить расхождения.

Его ценность не в голосовании и не в достижении красивого консенсуса. Ценность — в обнаружении разных моделей задачи.

Backend: 3
QA: 8
Frontend: 5

Плохая реакция:
"Давайте возьмём среднее — 5".

Нормальная реакция:
"QA, почему 8? Какой сценарий остальные не учитывают?"

После обсуждения может выясниться, что:

нет тестовых данных;
миграция ломает старый сценарий;
mobile-клиент не поддерживает новый contract;
feature flag отсутствует;
требование допускает две разные трактовки.

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

7.5. Трёхточечная оценка

Вместо одного числа команда определяет три сценария:

O — optimistic:
если всё известное проходит без существенных осложнений.

M — most likely:
наиболее вероятный сценарий.

P — pessimistic:
если реализуются разумно предполагаемые риски,
но не происходит катастрофа совершенно другого класса.

Пример:

O = 3 дня
M = 5 дней
P = 10 дней

Самое важное здесь — не вывести математически красивое среднее, а понять асимметрию.

Если optimistic равен 3 дням, most likely — 4, а pessimistic — 20, проблема не в том, что команда плохо считает среднее. В работе есть источник сильного правого хвоста: неизвестная миграция, внешний поставщик, отсутствие тестов или скрытый scope. Его надо исследовать.

7.6. Оценка по историческому потоку

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

Kanban Guide выделяет четыре базовые flow metrics: WIP, throughput, work item age и cycle time. Там же Service Level Expectation описывается как прогноз, содержащий период времени и вероятность, например: «85% элементов завершаются за восемь дней или быстрее». (Kanban Guide)

WIP:
сколько задач начато, но не завершено.

Throughput:
сколько задач завершено за единицу времени.

Work Item Age:
сколько времени уже находится в работе незавершённая задача.

Cycle Time:
сколько времени проходило от начала до завершения задачи.

Исторический поток позволяет отвечать на два разных вопроса:

When will it be done?
Когда заданный scope, вероятно, будет завершён?

How much will be done?
Какой объём, вероятно, будет завершён к заданной дате?

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

8. Confidence level: дата без вероятности неполна

Фраза «будет готово 18 августа» скрывает распределение возможных исходов.

Более честный forecast:

P50 — 12 августа
P85 — 18 августа
P95 — 25 августа

Упрощённо:

P50 — примерно половина моделируемых исходов завершается к этой дате;
P85 — примерно 85% исходов завершаются к этой дате;
P95 — примерно 95% исходов завершаются к этой дате.

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

Ситуация	Разумный режим
Внутренний эксперимент	Можно принять более рискованный прогноз и быстро пересматривать
Обычный продуктовый релиз	Нужен рабочий диапазон и резерв на реальные риски
Публично объявленная дата	Нужна более высокая уверенность или переменный scope
Регуляторный deadline	Нужны высокий confidence, ранняя интеграция, fallback и отдельный контроль критического пути

Confidence — не эмоциональная уверенность лида

Плохо:
"Я уверен процентов на 90, команда сильная".

Лучше:
"За последние четыре месяца 85% сопоставимых задач завершались
за девять дней или быстрее. В этой задаче есть новая внешняя интеграция,
поэтому до spike я снижаю confidence и не считаю историю полностью применимой".

Уровень уверенности должен иметь основание:

исторические данные;
зрелость требований;
проверенные зависимости;
знакомая архитектурная область;
качество slicing;
стабильность состава команды;
количество незавершённой работы;
результаты discovery.

9. Risk buffer

Risk buffer — резерв, который учитывает вариативность и известные риски. Это не тайное число, которое лид добавляет «на всякий случай», и не разрешение не разбираться в работе.

Плохой buffer

Разработчик: 5 дней.
Лид про себя: умножу на 2.
Менеджер про себя: сокращу на 30%.
Бизнес получает: 7 дней.

Никто не знает, откуда взялось число.

В такой системе каждый участник компенсирует недоверие собственной скрытой поправкой.

Осмысленный buffer

Базовый диапазон реализации: 5–7 рабочих дней.
Интеграционная проверка: 2 дня.
Резерв на вариативность внешнего API: 3 дня.

Forecast: 7–12 рабочих дней.
После проверки sandbox пересчитываем внешний риск.

Buffer не заменяет действие

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

Риск → можно проверить → spike.
Риск → можно уменьшить архитектурой → техническое решение.
Риск → можно передать → контракт или владелец.
Риск → нельзя снять → открытый резерв и сценарный план.

Где размещать резерв

Резерв может находиться:

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

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

Если forecast уже построен по историческому распределению cycle time или throughput и выбран, например, уровень P85, обычная вариативность потока уже находится внутри прогноза. Механически добавить сверху ещё 30% означает дважды учесть одну и ту же неизвестность. Дополнительный резерв нужен тогда, когда есть риск, которого нет в выбранной истории: новая внешняя интеграция, регуляторное согласование, миграция другого класса или заранее известное падение capacity.

Fixed date + fixed quality + variable scope

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

10. Spike и discovery task

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

10.1. Spike

Spike — ограниченное по времени техническое исследование.

Примеры вопросов:

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

Хороший spike содержит:

Вопрос:
что именно неизвестно.

Timebox:
сколько времени мы готовы потратить.

Метод проверки:
какой эксперимент проведём.

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

Критерий остановки:
когда исследование считается достаточным.

Пример:

Spike: проверить OAuth flow партнёра.
Timebox: 1 рабочий день.

Результат:
- рабочий запрос к sandbox;
- подтверждённые scopes;
- список расхождений с документацией;
- решение, нужен ли proxy-adapter;
- новая оценка интеграции.

10.2. Discovery task

Discovery task шире технического spike. Она может исследовать:

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

Пример:

Discovery: возврат частично использованного бронирования.

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

Spike и discovery не обязаны дать «положительный» результат

Результат «этот путь не работает» может быть полноценным результатом, если:

гипотеза проверена;
наблюдение зафиксировано;
пространство вариантов уменьшилось;
следующий шаг стал понятнее;
forecast обновлён.

Антипаттерн: бесконечное исследование

"Нам нужно ещё поисследовать"

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

11. Delivery forecast

Delivery forecast — не одно число, однажды выданное перед началом работы. Это живая модель, которая обновляется по мере изменения реальности.

11.1. Forecast для одной задачи

Если есть достаточная история сопоставимых элементов, можно использовать распределение cycle time.

Пример:

За последние 90 дней:
50% задач завершались за 4 дня или быстрее.
85% — за 8 дней или быстрее.
95% — за 13 дней или быстрее.

SLE команды:
"85% стандартных задач завершаются за 8 календарных дней или быстрее".

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

11.2. Forecast даты для заданного scope

Вопрос:

Когда будут завершены эти 24 элемента?

Для ответа можно использовать исторический throughput и вероятностное моделирование, например Monte Carlo simulation.

Принцип без математического театра:

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

P50: 5 сентября
P85: 16 сентября
P95: 24 сентября

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

11.3. Forecast объёма к заданной дате

Вопрос:

Сколько элементов будет готово к 1 сентября?

Ответ может выглядеть так:

P50: не менее 22 элементов.
P85: не менее 17 элементов.
P95: не менее 14 элементов.

Для продукта часто полезнее именно этот вопрос: дата фиксирована, а scope управляем.

11.4. Что делает исторический forecast недействительным

История не является магическим доказательством. Её применимость падает, если:

резко изменился состав команды;
поменялась Definition of Done;
в выборку смешаны задачи разных классов;
элементы стали существенно крупнее;
появилась новая обязательная стадия согласования;
изменилась архитектура или инфраструктура;
возник большой объём незапланированных production-инцидентов;
данные слишком редкие;
workflow раньше измерял start и finish иначе.

Лид не просто показывает график. Он объясняет, почему выбранную историю можно или нельзя использовать для этого решения.

11.5. Reforecast

Прогноз пересчитывается:

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

Изменение прогноза после появления нового факта
не является провалом прогнозирования.

Сокрытие нового факта ради сохранения прежней даты — является.

12. Почему «точно скажи дату» часто является насилием над неизвестностью

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

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

Реальность:
3 дня при сценарии A;
7 дней при сценарии B;
сначала исследование при сценарии C.

Организационный запрос:
"Мне не нужны детали. Назови одну дату".

Получившаяся форма:
"5 дней".

После этого форма начинает обращаться как сама реальность. Условия исчезают, а через пять дней команда обвиняется в нарушении знания, которого изначально не существовало.

Как отвечать

Не надо читать стейкхолдеру лекцию о философии неопределённости. Надо дать форму, пригодную для решения.

"Для внутреннего планирования используйте 18 августа как рабочую дату.
Сейчас confidence около 70%, потому что не подтверждён sandbox партнёра.
Завтра завершаем проверку. Если contract подтверждается,
confidence повысится; если нет — дам новый диапазон и варианты сокращения scope".

Или:

"Если 18 августа — фиксированная дата, я не могу одновременно
зафиксировать весь scope. Предлагаю обязательное ядро A + B.
Сценарий C подключаем, если интеграция проходит до 8 августа".

Или:

"Сейчас точность даты ограничивает не разработка,
а отсутствие решения по правилу возврата.
Если решение будет принято сегодня — forecast 5–8 дней.
Каждый день ожидания сдвигает поставку минимум на день".

Лид не отказывается от определённости вообще. Он показывает, какое действие создаст дополнительную определённость.

13. Как не врать бизнесу

13.1. Не выдавать target за forecast

Плохо:
"Руководство хочет 18 августа, значит план — 18 августа".

Нормально:
"Target — 18 августа. Текущий P85 forecast — 25 августа.
Чтобы сблизить их, можно сократить scope, снять зависимость X
или добавить раннее совместное тестирование с партнёром".

13.2. Не скрывать условия

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

13.3. Не говорить «почти готово»

У задачи должны быть наблюдаемые состояния.

Не:
"Готово на 90%".

А:
"Happy path реализован.
Не завершены миграция данных, обработка повторной доставки
и production rollout. Основной риск сейчас — миграция".

13.4. Не прятать изменение прогноза

Плохая новость, сообщённая рано, является управляемой информацией. Та же новость за день до релиза становится инцидентом управления.

13.5. Не превращать оценку команды в переговорную заготовку

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

Нужно показывать:

базовую работу;
риски;
резерв;
варианты scope;
цену ускорения;
уровень confidence.

14. Как не ломать команду сроками

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

14.1. Не принимать несовместимые ограничения молча

Фиксировано всё одновременно:
- дата;
- scope;
- состав команды;
- качество;
- архитектурный способ;
- внешние зависимости.

Если исходный forecast не помещается, лид обязан показать конфликт. Нельзя передать его вниз в форме «ребята, просто надо поднажать».

14.2. Не использовать overtime как основной buffer

Разовый осознанный рывок и систематическое планирование на переработки — разные режимы.

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

14.3. Не жертвовать невидимой работой

Под давлением первыми исчезают:

тесты;
observability;
документация;
review;
rollback plan;
миграционная безопасность.

Релиз может формально состояться в дату, а реальная стоимость проявится позже в инцидентах и замедлении следующих изменений.

14.4. Не измерять людей точностью оценок

Если человеку предъявляют каждое отклонение как личную ошибку, он учится не вскрывать неизвестность, а выбирать безопасные числа.

Надо разбирать:

Что мы предполагали?
Что оказалось иначе?
Могли ли мы узнать это раньше?
Как изменить discovery, slicing, архитектуру или workflow?

Это анализ причинности. Фраза «надо научиться точнее оценивать» часто просто закрывает анализ.

14.5. Не путать давление и приоритет

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

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

15. Планирование как непрерывный контур

Планирование не заканчивается после planning meeting.

Цель → scope → slicing → зависимости → оценка → forecast →
выполнение → новые факты → reforecast → решение

До начала работы

Лид проверяет:

понятен ли пользовательский и бизнес-результат;
определено ли, что считается Done;
достаточно ли мал первый инкремент;
известны ли внешние зависимости;
какие предположения надо проверить;
какой способ оценки соответствует решению;
есть ли исторические данные;
какая дата является target, а какая deadline;
что можно изменить при несовпадении target и forecast.

Во время работы

Лид смотрит:

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

После завершения

Нужно не «наказать за неточную оценку», а обновить модель системы:

какой тип работы оказался вариативным;
где было ожидание;
какая неизвестность обнаружилась поздно;
помог ли spike;
был ли элемент слишком крупным;
соответствует ли Definition of Workflow реальному процессу;
какую историю использовать в следующих forecasts.

16. Метрики и антиметрики

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

Полезные наблюдения

cycle time по классам работы;
throughput за период;
work item age;
WIP;
blocked time;
доля незапланированной работы;
изменение forecast;
причины отклонений;
доля элементов, прошедших SLE;
частота изменения scope;
время ожидания review, QA и внешних решений.

Опасные подмены

Velocity target
→ команда меняет scale points.

Utilization 100%
→ исчезает резерв системы, растут очереди и cycle time.

Количество закрытых задач
→ работа режется не по ценности, а ради счётчика.

Точность individual estimates
→ люди завышают оценки и скрывают неизвестность.

Количество часов
→ занятость подменяет delivery.

DORA рассматривает software delivery через результаты потока и стабильности поставки, а не через занятость людей: скорость изменения, частоту поставки, долю неудачных изменений и восстановление после них. Это другой класс метрик — они смотрят на способность системы доставлять изменения, а не на количество произведённой активности. (DORA metrics)

17. Полный пример: интеграция платёжного провайдера

Исходный запрос

"Нужно добавить нового платёжного провайдера.
Сколько займёт? Старого мы подключили за неделю".

Плохой ответ

"Раз старого сделали за неделю, этого тоже сделаем за неделю".

Здесь прошлое сходство названия подменяет анализ.

Шаг 1. Определить результат

Нужно выяснить:

только приём платежа или ещё refund;
полные или частичные возвраты;
сохранение платёжного метода;
3-D Secure;
webhooks;
повторная доставка;
reconciliation;
валюты;
mobile и web;
миграция существующих пользователей;
требования PCI DSS;
production certification со стороны провайдера.

Шаг 2. Разделить scope

Slice A — обязательное ядро:
- создание платежа;
- 3-D Secure;
- webhook финального статуса;
- идемпотентность;
- базовый refund;
- feature flag.

Slice B — расширение:
- частичный refund;
- сохранение платёжного метода;
- дополнительные валюты.

Slice C — операционный контур:
- reconciliation dashboard;
- автоматический разбор расхождений;
- расширенная аналитика.

Шаг 3. Выделить неизвестность

Известно:
- внутри системы уже есть payment abstraction;
- основной happy path похож на старого провайдера.

Неизвестно:
- реальное поведение sandbox;
- порядок повторной доставки webhook;
- срок production certification;
- поддержка partial refund.

Шаг 4. Назначить spike

Spike на 1 день:
- выполнить платёж в sandbox;
- проверить подпись webhook;
- повторить событие;
- запросить refund;
- зафиксировать расхождения с документацией.

Шаг 5. Дать предварительный forecast

До spike:

Slice A: 8–15 рабочих дней.
Confidence: низкий.

Главные причины диапазона:
- не подтверждён webhook contract;
- неизвестен certification lead time.

Target бизнеса: 18 августа.
Следующий reforecast: после spike и ответа провайдера по certification.

Шаг 6. Обновить forecast после фактов

Результаты spike:

sandbox работает;
webhook может приходить повторно и не по порядку;
refund поддержан;
certification занимает до пяти рабочих дней.

Новый прогноз:

Разработка и внутреннее тестирование: 7–9 рабочих дней.
Certification: 3–5 рабочих дней.
Общий forecast: 10–14 рабочих дней.

P50: 14 августа.
P85: 19 августа.

Чтобы удержать внешний запуск 18 августа:
- отправить certification package после готовности Slice A,
  не дожидаясь Slice B;
- запускать только обязательное ядро;
- оставить старого провайдера fallback-вариантом через feature flag.

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

18. Язык лида

Когда данных мало

"Сейчас я могу дать только предварительный диапазон,
потому что не проверены два условия: X и Y.
На проверку нужен один день. После неё диапазон станет уже".

Когда target не совпадает с forecast

"Целевая дата — 18 августа. Текущий прогноз — 18–25 августа.
Разрыв можно закрывать не убеждением команды, а изменением условий:
scope, зависимости, последовательность или ресурсы.
Вот три варианта".

Когда дата фиксирована

"При фиксированной дате предлагаю зафиксировать обязательный outcome,
а не весь первоначальный список функций. A и B обязательны.
C входит при прохождении контрольной точки 8 августа".

Когда появилась новая информация

"Прогноз изменился с 18 на 23 августа,
потому что контракт API отличается от документации:
статус платежа нельзя получить синхронно.
Мы уже проверили два варианта. Рекомендую асинхронный adapter;
он добавляет три дня, но сохраняет корректность повторной обработки".

Когда команда не понимает задачу

"Сейчас оценивать рано: у нас есть название функции,
но нет определённого результата. Сначала зафиксируем сценарий,
границы и acceptance criteria. Это займёт два часа совместного refinement,
после чего дадим sizing".

Когда требуют гарантировать дату

"Я могу взять обязательство по плану действий и контрольным точкам.
Гарантировать неизвестное поведение внешнего сервиса я не могу.
Я могу уменьшить его влияние: проверить интеграцию сейчас,
зафиксировать fallback и отделить обязательный scope".

19. Практика модуля

Упражнение 1. Разрезать объекты

Для каждой фразы определить, что это: estimate, forecast, target, deadline или commitment.

1. "Маркетинг хочет запуститься 18 августа".
2. "85% подобных задач завершались за 8 дней".
3. "Мы удерживаем Sprint Goal, но меняем способ реализации".
4. "После 1 сентября старый сертификат недействителен".
5. "Интеграция потребует примерно 5–8 дней активной работы".

Ожидаемый разбор:

1 — target.
2 — историческое основание forecast / SLE.
3 — commitment.
4 — deadline.
5 — estimate.

Упражнение 2. Найти скрытую неизвестность

Исходная задача:

"Добавить экспорт всех отчётов в PDF".

Участник должен выписать вопросы по категориям:

scope;
данные;
производительность;
дизайн;
безопасность;
инфраструктура;
внешние зависимости;
критерий Done.

Упражнение 3. Построить условную оценку

Дано:

Нужно добавить SSO для корпоративного клиента.
IdP клиента неизвестен.
В продукте уже есть OAuth, но нет SAML.
У клиента жёсткая дата пилота.

Участник должен подготовить:

preliminary range;
assumptions;
spike;
обязательный scope;
fallback;
момент reforecast;
сообщение стейкхолдеру.

Упражнение 4. Forecast по истории

Дать участнику историю cycle time и throughput за 12 недель. Попросить:

вычислить основные percentiles cycle time;
предложить SLE;
определить, какие задачи нельзя смешивать в одну выборку;
построить прогноз для фиксированного scope;
построить прогноз объёма к фиксированной дате;
объяснить ограничения прогноза человеческим языком.

Упражнение 5. Переписать ложный status update

Исходник:

"Работа идёт по плану. Фича готова на 80%.
Есть небольшие проблемы с интеграцией, но команда разбирается".

Нужно превратить его в сообщение, содержащее:

завершённый результат;
незавершённые части;
блокер;
влияние на forecast;
варианты решения;
необходимое решение стейкхолдера.

20. Итоговый артефакт: Delivery Forecast Card

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

# Delivery Forecast: [название инициативы]

## 1. Outcome

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

## 2. Scope

### Обязательное ядро

- ...

### Условный scope

- ...

### Не входит

- ...

## 3. Ограничения

- Target date:
- Deadline:
- Fixed constraints:
- Изменяемые параметры:

## 4. Текущий forecast

- P50:
- P85:
- P95:
- Источник данных:
- Класс сопоставимых задач:

## 5. Assumptions

- ...

## 6. Dependencies

| Зависимость | Владелец | Нужна к | Состояние | Fallback |
| --- | --- | --- | --- | --- |
| | | | | |

## 7. Неизвестность

| Неизвестность | Влияние | Способ проверки | Timebox | Результат |
| --- | --- | --- | --- | --- |
| | | | | |

## 8. Риски и резерв

| Риск | Вероятность | Влияние | Действие | Где учтён buffer |
| --- | --- | --- | --- | --- |
| | | | | |

## 9. Контрольные точки

- ...

## 10. Условия reforecast

- изменение scope;
- результат spike;
- срыв зависимости;
- изменение capacity;
- достижение контрольной точки.

## 11. Решение, которое требуется сейчас

- ...

21. Чек-лист лида перед публикацией оценки

[ ] Я понимаю, какое решение будет принято на основании оценки.
[ ] Я указал, что именно считается завершённым.
[ ] Я не смешал усилие и календарную длительность.
[ ] Я различил target, deadline, forecast и commitment.
[ ] Я показал диапазон или вероятность, если исход вариативен.
[ ] Я перечислил ключевые предположения.
[ ] Я назвал внешние зависимости и их владельцев.
[ ] Я выделил неизвестность, которую можно снять через spike/discovery.
[ ] Я не спрятал риск внутрь случайного коэффициента.
[ ] Я проверил, применимы ли исторические данные.
[ ] Я определил момент следующего reforecast.
[ ] Я предложил варианты действий, если forecast не совпадает с target.
[ ] Я не использовал overtime как молчаливое условие плана.
[ ] Я не пожертвовал Definition of Done ради красивой даты.
[ ] Моё сообщение позволяет принять решение, а не просто передаёт тревогу.

22. Главные антипаттерны

Одна дата без условий

"Будет готово 18 августа".

Неясны scope, confidence, зависимости и цена опоздания.

Estimate превращается в deadline

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

Story points превращаются в KPI

Команда оптимизирует scale и количество points вместо результата.

Buffer прячется

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

Spike без вопроса

Исследование не имеет timebox, наблюдаемого выхода и критерия остановки.

Forecast не обновляется

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

Неопределённость передаётся вниз

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

Большая задача получает большое число

Вместо slicing и discovery задача просто оценивается как 21 или XL.

Среднее скрывает хвост

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

План считается доказательством будущего

Любое отличие реальности от первоначального плана объявляется дисциплинарной проблемой, а не источником нового знания.

23. Основные формулы модуля

оценка ≠ обещание
forecast ≠ target
target ≠ deadline
deadline ≠ гарантия
commitment ≠ отрицание неизвестности

размер ≠ усилие
усилие ≠ длительность
длительность ≠ дата поставки
занятость ≠ продвижение
velocity ≠ производительность

неизвестность ≠ некомпетентность
диапазон ≠ уклонение от ответа
изменение прогноза ≠ автоматический провал
план ≠ реальность

И главная формула:

Лид не обязан знать будущее.

Лид обязан:
- показать границу текущего знания;
- сделать неизвестность видимой;
- уменьшить ту неизвестность, которую можно уменьшить;
- построить прогноз на основании фактов;
- отделить прогноз от желания;
- изменить план после появления новой реальности;
- не позволить организации заменить управление производством обещаний.

24. Финальное различение

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

Сильный лид удерживает весь контур:

Какой результат нужен?
Какой scope мы оцениваем?
Что известно?
Что неизвестно?
Что можно проверить?
Что зависит не от команды?
Как вела себя система раньше?
Каково распределение возможных исходов?
Какой confidence нужен для этого решения?
Что меняем, если target и forecast не совпадают?
Когда пересматриваем прогноз?

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

Она становится частью управления технической причинностью.

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