Какие варианты решения проблемы срыва сроков в команде
Что проверяют
Умеете ли вы искать причину, а не виноватого, и видите ли свою роль в сроках, даже если вы не тимлид. Почти всегда следом просят конкретный случай: «Расскажите, когда вы сами не успели, и что сделали».
Как отвечать
Каркас из трёх шагов, каждый подкрепите своим примером с цифрами.
Ранний сигнал. Риск озвучивается, как только стал виден, а не в день дедлайна: «На второй день интеграции я понял, что контракт соседнего сервиса не совпадает с документацией, и сразу сказал об этом на стендапе».
Причина. Типичные для Go-команд:
- недооценка интеграций: чужой API, миграции базы, согласование protobuf-контрактов занимают больше, чем сама бизнес-логика;
- скрытая работа: код-ревью висит днями, нестабильные тесты в CI, дежурства и инциденты съедают время;
- размытые требования: задачу начали раньше, чем договорились, что считать готовым.
Рычаги. Их немного: урезать объём до минимально полезной версии, сдвинуть срок, поменять приоритеты, спрятать незаконченное за фиче-флагом и выпустить остальное. Добавлять людей в горящий проект обычно поздно (закон Брукса): новичку нужно время на погружение, а команда тратит своё на его ввод.
Профилактика: декомпозиция до задач на один-два дня, оценка диапазоном, а не точной датой, явный Definition of Done с тестами и ревью, контракты между сервисами фиксируются до реализации, а зависимую сторону разблокируют моками.
Если вы не руководили командой, говорите о своём уровне: как оценивали свои задачи, когда предупредили о риске, как предложили разбить работу. Это честный ответ, и ценится он не меньше.
Где спотыкаются
Перекладывают вину на менеджера, заказчика или соседнюю команду. Даже если это правда, интервьюер ждёт, что сделали лично вы.
Называют решением переработки. Разовый рывок бывает, но как система это путь к выгоранию и следующему срыву.
Перечисляют Scrum, Kanban и Planning Poker без сути. Названия процессов не отвечают на вопрос, почему сроки срывались и что изменилось после.