Как оценивается нагрузка и сроки в команде
Что проверяют
Понимаете ли вы, откуда берутся сроки и почему оценка это прогноз, а не обещание. Интервьюеру важно, как вы оцениваете свои задачи и что делаете, когда не успеваете. Следом обычно звучит: «приведите случай, когда оценка сильно разошлась с фактом».
Как отвечать
Опишите процесс, в котором работали, и назовите инструменты:
- декомпозиция: задачу режут до кусков на день или два, всё крупнее оценивается плохо;
- относительная оценка: story points по шкале Фибоначчи и Planning Poker, чтобы вскрыть разное понимание задачи. Если один ставит 2, а другой 13, обсуждают, кто что знает;
- ёмкость спринта: средняя скорость команды за последние три-пять спринтов с поправкой на отпуска, дежурства и встречи;
- поток вместо очков: в Kanban смотрят на cycle time и пропускную способность, а срок прогнозируют вероятностно, например методом Монте-Карло по истории задач;
- диапазон вместо точки: «от трёх до пяти дней» честнее, чем «четыре», а трёхточечная оценка
(O + 4M + P) / 6учитывает пессимистичный сценарий.
Для Python-задач в оценку входит не только код: тесты, ревью, миграции Alembic, обновление зависимостей, выкатка. Исследовательские задачи вроде новой библиотеки или ML-эксперимента оценивают через таймбокс: два дня на спайк, потом оценка заново.
Главное в ответе ваш пример с цифрами: оценили в пять дней, ушло восемь, на третий день предупредили лида и предложили урезать объём. Если в команде не оценивали вовсе, так и скажите и объясните, как договаривались о сроках. Вопрос полезно задать и работодателю: по ответу видно, давят ли там дедлайнами или планируют по данным.
Где спотыкаются
Переводят story points в часы по курсу и сравнивают по ним людей. Очки описывают сложность относительно других задач команды, а не производительность разработчика.
Оценивают только написание кода. Ревью, исправления после тестов и выкатка легко удваивают срок.
Молчат о сорванном сроке до последнего дня. Сильный ответ показывает, что вы сообщаете о риске сразу, как только его видите.