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