Оценка задач для разработчика: диапазоны вместо точных чисел
Разбираем, почему точная оценка в часах почти всегда ошибается, как декомпозиция снижает неопределённость и почему диапазон с явным учётом неизвестного честнее одного числа.
Разработчика почти всегда просят назвать одно число: сколько времени займёт задача. Проблема в том, что одно число почти никогда не отражает реальность, оно либо занижено из желания выглядеть уверенным, либо завышено настолько, что перестаёт быть полезным для планирования. Более честный и точный подход - называть диапазон, явно декомпозировать задачу на части и отдельно обозначать то, что пока неизвестно.
Почему точное число почти всегда обманывает
Оценка в часах или днях выглядит как результат расчёта, но на деле почти всегда результат одного-единственного предположения: что всё пойдёт по плану, библиотека подключится без сюрпризов, тесты зелёные с первого прогона, ревью пройдёт без замечаний. Любое отклонение от этого идеального сценария, а на практике отклонения случаются почти всегда, превращает точную оценку в заниженную. При этом разработчик, который называет оценку с запасом «на всякий случай», рискует получить репутацию человека, который работает медленнее, чем мог бы, хотя реальная причина в честном учёте рисков.
Диапазон вместо одного числа
Диапазон решает эту проблему прямо: вместо «три дня» разработчик называет «от двух до пяти дней», и в этом диапазоне заложена разница между оптимистичным сценарием без неожиданностей и реалистичным сценарием с одним-двумя типичными сюрпризами. Ширина диапазона - это не признак некомпетентности, а честная мера того, насколько задача на самом деле понятна на момент оценки.
| Тип задачи | Типичная ширина диапазона | Почему |
|---|---|---|
| Повторяющаяся, похожая на уже сделанную | узкий, плюс-минус 20% | мало неизвестного, есть прямой референс |
| Новая фича в знакомом коде | средний, в 1.5-2 раза | код знаком, детали требований не до конца ясны |
| Работа с новой библиотекой или внешним API | широкий, в 2-3 раза | неизвестны реальные ограничения внешней системы |
| Задача с нечёткими требованиями | очень широкий или требует уточнения заранее | основной риск не в коде, а в понимании задачи |
Декомпозиция: три уровня вместо одной большой задачи
Оценивать крупную задачу целиком почти всегда даёт худший результат, чем оценка суммы её частей. Разбиение на подзадачи заставляет явно подумать о шагах, которые иначе остались бы незамеченными: миграция базы данных, обновление документации, настройка мониторинга для новой фичи. Три уровня декомпозиции обычно достаточны для большинства задач среднего размера.
- задача целиком, одна-две строки описания результата
- крупные шаги внутри задачи, от трёх до семи штук
- конкретные технические действия внутри каждого шага, если шаг кажется непрозрачным
Если третий уровень декомпозиции всё равно не даёт ясности, например шаг звучит как «разобраться с интеграцией платёжного провайдера» без понимания, что именно придётся сделать, это верный признак того, что перед оценкой стоит сделать короткую разведку, а не просто дробить формулировку на более мелкие, но такие же туманные фразы.
Явный учёт неизвестного
Полезная практика - выделять в оценке отдельную строку не под конкретную работу, а под неизвестное: интеграцию с системой, поведение которой не до конца понятно, зависимость от команды, которая может ответить не сразу, риск, что требования изменятся в процессе. Это не попытка обмануть оценку искусственным буфером, а честная фиксация того, что часть риска находится вне контроля самого разработчика.
Задача: интеграция с внешним API доставки
- разбор документации и тестовый запрос: 0.5-1 день
- реализация основного сценария отправки: 1-2 дня
- обработка ошибок и повторных попыток: 0.5-1 день
- неизвестное: реальные лимиты API, поведение на проде: 0.5-2 дня
Итог: 2.5-6 дней
Такая форма записи полезна не только самому разработчику, но и тому, кто принимает решение по срокам: видно, где оценка твёрдая, а где основной риск, и на какую часть стоит обратить внимание, если дедлайн действительно критичен.
Буфер на интеграцию, а не только на код
Отдельная частая ошибка оценки: учитывать время на написание кода, но забывать про время на интеграцию этого кода с остальной системой, код-ревью, правки по замечаниям, деплой и проверку на проде. Для задачи среднего размера время на эти шаги в сумме часто сопоставимо с самим написанием кода, особенно если ревью проходит не с первого раза или деплой требует координации с другой командой.
- код-ревью и правки по замечаниям - закладывайте отдельно, не внутри «написать код»
- деплой и проверка на проде - отдельный шаг, особенно если есть миграции данных
- время ожидания ответа от смежных команд - не поддаётся ускорению одной мотивацией разработчика
Как говорить об оценке с теми, кто просит одно число
Опора на прошлые задачи, а не только на интуицию
Самая надёжная точка опоры для оценки - реальные данные о похожих задачах, сделанных ранее этим же разработчиком или командой. Если прошлая фича похожей сложности заняла пять дней вместо изначально названных трёх, это не повод стыдиться, а полезная калибровка: следующая похожая задача получит более реалистичный диапазон с самого начала, если учесть этот опыт, а не оценивать заново с чистого листа на одной интуиции.
Многие команды ведут простую таблицу или заметку: тип задачи, изначальная оценка, фактическое время. Через несколько месяцев такой журнал превращается в личный справочник, который заметно точнее абстрактных правил вроде «умножай оценку на два», потому что отражает реальный опыт конкретного человека в конкретном проекте, а не усреднённое правило из чужой практики.
Разница между оценкой разработчика и обязательством перед бизнесом
Отдельная путаница возникает, когда диапазон разработчика превращается в твёрдое обязательство на уровне бизнеса без указания, что это диапазон, а не гарантия. Если верхняя граница диапазона озвучивается заказчику как единственное число и воспринимается как железный дедлайн, вся польза от честной оценки теряется: при первой же задержке внутри этого диапазона она выглядит как провал, хотя формально укладывается в названные рамки. Разработчику стоит явно проговаривать с тем, кто передаёт оценку дальше по цепочке, какую часть диапазона можно называть ответственно, а какую нет.
Регулярная сверка оценки с фактом полезна ещё и потому, что меняет саму привычку мышления: разработчик, который знает, что через неделю посмотрит на разницу между оценкой и реальностью, начинает оценивать внимательнее с самого начала, учитывая шаги, которые раньше казались слишком мелкими, чтобы считать их отдельно, вроде настройки окружения или обновления документации после изменения.
Важно не превращать этот процесс в наказание: цель сверки оценки с фактом не найти виноватого в задержке, а откалибровать будущие оценки. Команда, где разбор разницы между оценкой и реальностью воспринимается как поиск виновного, быстро получает противоположный эффект: разработчики начинают называть заведомо раздутые оценки для подстраховки, и диапазоны перестают нести реальную информацию о сложности задачи.
Помогает и привычка переоценивать задачу на середине работы, а не только один раз в самом начале. Когда становится ясно, что первоначальное предположение было неверным, например внешний API оказался сложнее документации, честнее сразу пересчитать диапазон и сообщить об этом, чем молча пытаться уложиться в старую оценку ценой качества кода или тестов. Ранний пересчёт даёт больше времени на реакцию, чем признание проблемы в последний день перед дедлайном.
Менеджер или заказчик часто действительно нуждается в одном числе для планирования, и это разумное требование с их стороны. Разработчику стоит не отказываться называть число вовсе, а явно объяснить, какую часть диапазона он называет: нижнюю границу для оптимистичного планирования или верхнюю для надёжного дедлайна, и зафиксировать это словами, а не оставлять на понимание собеседника. Фраза «если всё пойдёт по плану, три дня, но с учётом интеграции и возможных сюрпризов закладывайте пять» работает лучше, чем простое «три дня», даже если собеседник в итоге всё равно запомнит только одно из двух чисел.
Частые вопросы
Как оценивать задачу, если требования ещё не до конца сформулированы?
В этом случае честнее сначала оценить саму стоимость уточнения требований, а не пытаться угадать итоговую реализацию. Можно назвать диапазон для разведки отдельно, а полную оценку реализации дать после того, как требования прояснятся хотя бы в основных чертах, иначе диапазон получится настолько широким, что перестанет быть полезным для планирования.
Стоит ли закладывать буфер на отпуска, больничные и другие задачи параллельно?
Это относится не к оценке самой задачи, а к планированию загрузки разработчика в целом, и эти два уровня лучше не смешивать. Оценка задачи должна отражать, сколько реальной рабочей сосредоточенной работы она требует, а переключение контекста, параллельные задачи и отсутствия на работе учитываются отдельно при построении календарного плана поверх этих оценок.
Почему оценка часто занижается даже у опытных разработчиков?
Основная причина - эффект планирования: человек по умолчанию воображает сценарий без сюрпризов, потому что именно такой сценарий проще всего представить и описать. Явная привычка отдельно выписывать неизвестное и закладывать его в диапазон компенсирует этот эффект лучше, чем попытка просто «быть внимательнее» при оценке на глаз.
