Как оценивать сроки и не врать себе: разбор инцидента

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

Инцидент: пять дней превратились в три недели

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

В первый день обнаружилось, что в старой базе есть записи с различными форматами дат. На третий выяснилось, что новый сервис иначе обрабатывает повторную доставку сообщения. Еще два дня ушли на сверку результатов. Затем команда нашла клиентов, для которых часть заказов уже обработал новый код, а часть — старый. Переключение пришлось остановить.

Итоговый план выглядел так:

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

Где сломалась оценка

Оценили написание кода, а не поставку результата

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

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

Одна цифра скрыла неопределённость

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

Прошлый опыт был похож только внешне

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

Как оценивать работу до обещания даты

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

1. Опишите конечный результат. Не «переписать обработчик», а «обработать новые заказы, сверить результат со старым сервисом и иметь проверенный откат». Проверка: у команды есть критерий готовности, который можно показать на тестовом контуре.
2. Разделите работу на части, которые можно проверить за один-два дня. Вынесите отдельно исследование данных, изменения кода, миграцию, тестирование, релиз и наблюдение после него. Проверка: для каждого пункта понятен артефакт — отчёт, миграционный скрипт, тест, дашборд или решение о переключении.
3. Отметьте неизвестные. Запишите вопросы, на которые пока нет ответа: сколько форматов данных существует, можно ли повторить операцию, кто даст доступ, как выполняется откат. Проверка: у каждой неизвестности есть владелец и способ получить ответ.
4. Дайте диапазон и условия. Например: «при доступе к тестовой базе и без новых форматов данных — от шести до девяти рабочих дней; если обнаружится ручная сверка, добавится до пяти дней». Проверка: любой участник может объяснить, что двигает нижнюю и верхнюю границу.
5. Пересмотрите прогноз после первых фактов. После исследования данных или первого сквозного прогона обновите диапазон. Проверка: в задаче сохранены исходный прогноз, новые данные и причина изменения.

Четыре подхода и цена каждого

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

Что измерять, чтобы прогноз не был мнением

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

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

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

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

Где подход ломается

Когда дата уже обещана руководству

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

Когда неизвестность нельзя уменьшить заранее

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

Когда команда использует velocity как производительность

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

Когда резерв превращается в мусорную корзину

Неразмеченный запас времени быстро заполняется любыми проблемами. Разделяйте резерв на категории: неизвестные данные, внешние ожидания, исправления после тестирования и поддержка релиза. Тогда станет видно, что именно системно съедает сроки.

Как говорить о сроках без ложной точности

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

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

Пример формулировки: «Тестовое переключение планируем на 12–14 июня. Прогноз верен, если до 7 июня подтвердим форматы данных и получим доступ к резервной базе. Если сверка выявит расхождения, безопасный релиз переносится, а не маскируется дополнительными часами разработки».

Что делать дальше

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