Оценки не сбываются у всех. Не у слабых команд — у всех. Инженер говорит «три дня», работа занимает восемь, и обе стороны считают, что виноват собеседник: одна — что её торопили, другая — что её обманули.
Это не проблема добросовестности. У ошибки в оценке есть устойчивая структура, и как только её видно, разговор о сроках перестаёт быть спором о характере.
Механику оценивания — story points, покер планирования и скорость команды — разбирает отдельная статья. Здесь про то, что с этим делает лид.
Три источника ошибки
Первый: оценивают только известную работу. Когда инженер говорит «три дня», он оценивает написание кода — то, что представляет себе целиком. За кадром остаются: разбор чужого кода, который надо тронуть; ревью и доработки по замечаниям; тесты; миграция данных; выкат; ответы на вопросы соседней команды; полдня на то, что упало в проде. Ошибка получается не потому, что три дня были неверны, а потому, что оценили не ту работу.
Второй: оценивают в лучшем сценарии. Человек честно представляет, как задача пойдёт, если ничто не помешает. А «не помешает» не бывает почти никогда: непонятная библиотека, отсутствующая документация чужого сервиса, неожиданное поведение старого кода. В хорошем сценарии — три дня, в реальности — распределение с длинным хвостом, среднее по которому заметно правее.
Третий: неопределённость максимальна в начале. Точность оценки зависит от того, что уже известно о задаче. В момент «нам нужна интеграция с платёжным провайдером» разброс достигает нескольких раз в обе стороны, и это не признак некомпетентности — это свойство момента. Разброс сужается по мере того, как задача проясняется, и полностью исчезает в момент, когда работа сделана. Просить точную цифру в начале — просить того, чего в этот момент не существует.
Оценка — не обязательство
Главная путаница в разговоре о сроках: одно слово используется для двух разных вещей.
Оценка — это прогноз: сколько, по нашим данным, займёт работа. У прогноза есть разброс, и он честно принадлежит команде.
Обязательство — это обещание внешнему миру: к такому-то числу будет готово. У обязательства нет разброса, зато есть цена невыполнения.
Проблемы начинаются, когда оценку превращают в обязательство молча: инженер сказал «дня три», через час это уже дата в письме заказчику, а через неделю — «вы обещали».
Что делает лид:
- Разделяет их явно. «Оценка — три-пять дней. Обязательство я дам после того, как посмотрим на зависимости; ориентир — конец следующей недели».
- Держит запас на своей стороне. Обязательство содержит буфер, оценка — нет. Буфер принадлежит лиду, а не размазан по задачам: если запас спрятать внутрь каждой оценки, он будет израсходован весь и незаметно.
- Никогда не передаёт наружу цифру инженера напрямую. Не потому, что она плохая, а потому, что она отвечает на другой вопрос.
Декомпозиция как способ снизить ошибку
Самый надёжный инструмент — не «оценивать точнее», а дробить мельче. Причина арифметическая: ошибки мелких задач частично гасят друг друга, а ошибка одной крупной — нет. Плюс при дроблении вылезает та самая забытая работа: миграция, выкат, совместимость.
Практический ориентир: если кусок не помещается в два-три дня, его дробят дальше. Кусок на две недели — это не оценка, а надежда.
Хорошая проверка декомпозиции — каждый кусок можно закончить и показать. Если куски выглядят как «сделать модель», «сделать сервис», «сделать контроллер», задача разрезана по слоям, и до последнего куска ничего нельзя проверить. Резать надо сквозными срезами: первый кусок — минимальный путь целиком, дальше наращивание.
Отдельная техника для дорогой неопределённости: сначала исследование, потом оценка. Если непонятно, как работает чужой сервис, честный ответ — не цифра, а «дайте день, чтобы посмотреть, после этого оценю». День исследования дешевле недели ошибки.
Считать по факту, а не по вере
Второй надёжный инструмент — исторические данные. Не «сколько, кажется, займёт», а «сколько похожие задачи занимали у нас».
Что стоит смотреть:
- сколько задач команда реально закрывает за итерацию — не сколько берёт, а сколько закрывает;
- как соотносятся оценка и факт по прошлым задачам — устойчивый коэффициент лучше любых благих намерений;
- сколько времени уходит на не запланированное — поддержка, инциденты, чужие просьбы. В большинстве команд это от четверти до трети времени, и планировать полную загрузку — значит планировать срыв.
Отсюда простое правило планирования: в итерацию берём столько, сколько закрывали в среднем за последние несколько итераций, а не столько, сколько «должно поместиться». И отдельная квота на непредвиденное, которая существует в плане явно.
Это же даёт ответ на вечное «а можно быстрее»: можно, если убрать что-то другое. Разговор о сроках всегда сводится к разговору об объёме — третьей переменной там нет.
Разговор о сроках со стейкхолдером
Три приёма, которые заметно меняют этот разговор.
Отвечать диапазоном и условиями, а не точкой. «От двух до трёх недель; ближе к двум, если интеграция ведёт себя как в документации, ближе к трём — если нет. Через неделю смогу сузить». Точка звучит увереннее ровно один раз, диапазон работает всегда.
Показывать, из чего складывается срок. Список кусков с числами убеждает лучше итога. Он же переводит разговор в конструктивный: «а вот это можно во вторую очередь?» — да, можно, и вот новый срок.
Сообщать об отклонении в момент, когда оно стало известно. Не в день сдачи. Сдвиг, о котором сказали за неделю, — это управляемая ситуация; тот же сдвиг в день сдачи — потеря доверия, которая стоит дороже самого сдвига.
И общее: обещания даются только из статистики. Одно выполненное обещание стоит десяти объяснений, почему предыдущее не выполнено. Команде с подорванным доверием стоит специально брать меньше, чем может, — пока несколько обещаний подряд не выполнятся ровно в срок.
Коротко
- Ошибка в оценке системна: оценивают только видимую работу, в лучшем сценарии, в момент максимальной неопределённости.
- Оценка — прогноз с разбросом; обязательство — обещание с датой. Смешивать их нельзя, буфер держит лид, а не каждый инженер внутри своей цифры.
- Мельче куски — меньше суммарная ошибка; кусок больше двух-трёх дней дробят дальше, а сами куски режут сквозными срезами, а не по слоям.
- Непонятную задачу сначала исследуют день, потом оценивают.
- Планируют по фактической пропускной способности и явно оставляют квоту на непредвиденное.
- Наружу — диапазон с условиями, состав срока и раннее предупреждение об отклонении.
Что почитать дальше
- Оценка и планирование: story points и velocity — механика оценивания и почему скорость команды нельзя превращать в показатель.
- Приоритизация: наименьший ценный срез — как резать работу так, чтобы каждый кусок можно было показать.
- Как принять команду: первые 90 дней тимлида — планирование от факта и восстановление доверия обещаниями.