Как решить проблему неправильной оценки задач и сжатых сроков
Что проверяют
Есть ли у вас рабочая привычка оценивать и сообщать о рисках заранее, или вы узнаёте о сорванном сроке в день релиза. Следом обычно просят конкретный случай: что пошло не так и что вы поменяли после.
Как отвечать
Стройте ответ на своём примере по схеме: ситуация, что сделали, что изменилось. Цифры берите реальные, пусть скромные. Опорные действия:
- декомпозиция: задачу «сверстать страницу оплаты» режете на части объёмом в день-два. Фронтенд прячет работу в мелочах, и их стоит перечислять явно: состояния загрузки, пустое и ошибочное, адаптив, валидация форм, доступность, проверка в Safari;
- оценка диапазоном: «три-пять дней, если API готов к четвергу» честнее одной цифры. Неизвестное выносите в отдельную исследовательскую задачу с ограниченным временем;
- развязка с бэкендом: договоритесь о контракте и работайте на моках, например через MSW, чтобы задержка API не съедала ваш срок;
- ранний сигнал: как только видите, что не успеваете, идите к менеджеру с вариантами. Урезать объём до минимально полезного, спрятать недоделанное за фиче-флагом или сдвинуть дату;
- разбор после: сравнить оценку с фактом и понять, где ошиблись. Обычно это интеграция, правки дизайна и ревью.
Если процессы команды вы не меняли, так и скажите, и расскажите, как справлялись со своей задачей: разбили, вовремя предупредили, согласовали урезанный вариант. Это тоже зрелый ответ.
Где спотыкаются
Предлагают решать сжатые сроки переработками. Интервьюер слышит, что других инструментов у кандидата нет, а качество к концу такого спринта обычно проседает.
Рассказывают, как «внедрили Agile и продуктивность выросла на 30%». Выдуманный процент без способа замера сразу вызывает уточняющий вопрос, на который нечего ответить.
Перекладывают вину на менеджера или бэкенд. Спрашивают про вашу роль, поэтому говорите о том, что зависело от вас.