Как оценивать время на задачи
Что проверяют
Понимаете ли вы, из чего складывается срок, и умеете ли работать с неопределённостью.
Как отвечать
Опишите процесс.
1. Прояснить задачу. Оценивать неоднозначную формулировку бессмысленно: сначала уточняющие вопросы, критерии готовности, что входит и что не входит.
2. Разбить на части. Куски по половине дня оцениваются заметно точнее, чем задача целиком. Если разбить не получается, задача не понята, и нужен короткий исследовательский заход, чтобы снять неопределённость.
3. Посчитать всё, а не только написание кода. Во фронтенде обычно забывают: вёрстку под разные разрешения и состояния (загрузка, ошибка, пустой список), доступность, поддержку тёмной темы, интеграцию с бэкендом, который может быть ещё не готов, ревью и правки после него, правки после дизайн-ревью, тесты.
4. Дать диапазон. Оптимистичная, реалистичная и пессимистичная оценки честнее одной цифры и сразу показывают степень риска. Одно число создаёт иллюзию точности, которой нет.
5. Назвать риски прямо. Незнакомая библиотека, зависимость от чужой команды, неготовый контракт API. Это не оправдание, а вводные для планирования.
Про относительные оценки: во многих командах считают в очках по сравнению с эталонной задачей, а срок получают через скорость команды. Это снимает бесплодный спор о том, чьи это часы, и работает лучше на горизонте спринта.
Калибровка важнее самой методики: полезно сравнивать оценку с фактом по прошлым задачам. Почти у всех есть устойчивое смещение в оптимизм, и знание своего коэффициента помогает больше, чем любая формула.
И про поведение: как только стало понятно, что срок сдвигается, об этом сообщают сразу. Ранняя новость позволяет перепланировать, поздняя ставит команду перед фактом.
Где спотыкаются
Оценивают только основной сценарий, забывая состояния ошибок и загрузки.
Дают одну цифру, которую воспринимают как обещание.
Не закладывают ревью и правки.
Никогда не сравнивают оценку с фактическим временем.