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

Введение

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

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

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, эскалации, допустимые компромиссы и частоту пересмотра прогноза.

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

Сначала чью-то оценку принимают за 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 дня	Конкретную работу и блокеры
Ближайший цикл работы	Достаточно предметный прогноз при понятном объёме
Несколько месяцев	Диапазоны, сценарии, зависимости и регулярный пересмотр
Год	Точные задачи и даты малообоснованны, если в работе остаётся существенная продуктовая и техническая неизвестность

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

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

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

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

Rolling-wave planning

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

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

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

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 — объём работы, который можно было бы выполнить за идеальный день без ожиданий, встреч, переключений, инцидентов и организационного шума.

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

Три ideal days могут превратиться в:

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

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

7.3. Story points

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

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

Пример относительной шкалы: 1, 2, 3, 5, 8, 13, 21.

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

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

Velocity — сумма story points по элементам, которые конкретная команда завершила за итерацию. Как локальное историческое наблюдение она может помочь выбрать объём следующей итерации.

Story points и velocity начинают вредить, когда:

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

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? Когда заданный объём, вероятно, будет завершён?
How much will be done? Какой объём, вероятно, будет завершён к заданной дате?

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

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

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

Более честный forecast показывает даты вместе с вероятностями:

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

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

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

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

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

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

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

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

9. Risk buffer

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

Плохой buffer

Разработчик оценивает работу в пять дней.
Лид молча удваивает оценку.
Менеджер молча сокращает результат на 30%.
Бизнес получает срок семь дней без объяснения его происхождения.

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

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

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

Прогноз составляет 7–12 рабочих дней. После проверки sandbox резерв на внешний риск пересматривают.

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

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

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

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

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

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

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

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

Фиксированная дата + фиксированное качество + переменный объём.

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

10. Spike и discovery task

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

10.1. Spike

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

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

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

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

Элемент	Что зафиксировать
Вопрос	Что именно неизвестно
Timebox	Сколько времени готовы потратить
Метод проверки	Какой эксперимент проведём
Выход	Прототип, измерения, вывод, ограничения, обновлённую оценку или ADR
Критерий остановки	Когда исследование считается достаточным

Пример spike: проверить OAuth flow партнёра за один рабочий день. Ожидаемый результат:

рабочий запрос к 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. Почему «точно скажи дату» часто является насилием над неизвестностью

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

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

В действительности возможны разные исходы:

три дня при сценарии A;
семь дней при сценарии 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. Не принимать несовместимые ограничения молча

Конфликт возникает, когда одновременно фиксируют:

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

Если исходный 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 реальный процесс; сократить WIP или устранить конкретное ожидание.
Время заняли незапланированные инциденты: учитывать эту нагрузку при выборе объёма следующего цикла.

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

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

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

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

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

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

Что делают целью	К чему это приводит
Целевая velocity	Команда меняет шкалу story points
Загрузка людей на 100%	Исчезает резерв системы, растут очереди и cycle time
Количество закрытых задач	Работу режут ради счётчика, а не по ценности
Точность индивидуальных оценок	Люди завышают оценки и скрывают неизвестность
Количество отработанных часов	Занятость подменяет delivery

Итоги модуля

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

Результат планирования можно проверить по следующим признакам:

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

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

Источники

The Kanban Guide (May 2025) — определения метрик потока и Service Level Expectation.