Как ответить
Оценка сроков — это всегда компромисс между точностью и скоростью. Мой подход состоит из трёх шагов: декомпозиция, оценка с учётом неопределённости и калибровка на исторических данных.
1. Декомпозиция задачи
Сначала я разбиваю задачу на подзадачи размером не более одного дня работы. Для каждой подзадачи определяю чёткий критерий готовности (Definition of Done). Например, для фичи «добавить пагинацию» подзадачи могут быть: написать SQL-запрос с LIMIT/OFFSET, добавить параметры в API-контроллер, написать юнит-тесты на слой репозитория, обновить OpenAPI-спецификацию.
2. Оценка с поправкой на риски
Для каждой подзадачи я даю три оценки: оптимистичную (всё идёт идеально), наиболее вероятную (учитываю типичные блокеры — нужно подождать ревью, нет доступа к тестовым данным) и пессимистичную (вылезает неожиданная сложность, меняются требования). Итоговую оценку беру по формуле (O + 4*N + P) / 6 (PERT-оценка). Затем добавляю буфер: 20–30% от суммы, если задача новая для команды, и 10–15%, если похожая уже делалась.
3. Калибровка
После завершения задачи я сравниваю фактическое время с оценкой и записываю расхождение в общий лог. Если систематически ошибаюсь — пересматриваю метод: может, игнорирую этап код-ревью или время на прогон CI/CD. Раз в месяц анализирую тренды — это помогает точнее оценивать однотипные задачи.
Бывает, что сроки навязывают сверху (например, дедлайн релиза). В таком случае я открыто говорю, какой объём функциональности гарантированно успеем, а что — срезаем или переносим. Приоритеты расставляем с продактом через MoSCoW или WSJF.
Из инструментов использую Planning Poker на ретроспективах для сложных историй и простую таблицу (задача — оценка в часах — факт) в Confluence. Главное — не обещать точные даты до того, как проведена декомпозиция, и не бояться пересмотреть оценку, когда появилась новая информация.