Как вы действуете, когда понимаете, что не успеваете к дедлайну?

Моя стратегия в такой ситуации строится на прозрачности, проактивности и поиске решений.

1. Немедленная коммуникация Как только становится очевидным риск срыва дедлайна, я информирую тимлида или менеджера проекта. Сокрытие проблемы усугубляет последствия.

2. Анализ причин и переоценка Вместе с командой анализируем, почему оценка была неверной:

• Техническая сложность: Неучтенные нюансы интеграции, баги в сторонних SDK.
• Объем работ: Задача оказалась шире, чем предполагалось.

3. Предложение вариантов решения (Plan B) Я предлагаю конкретные альтернативы на обсуждение:

• Упрощение задачи: Выпуск MVP-версии фичи с отложением части функционала.
• Пересмотр дедлайна: Обоснованный запрос на продление сроков.
• Перераспределение ресурсов: Можно ли подключить другого разработчика?
• Временное решение (Workaround): Реализация, которая закрывает потребность, пока не будет готово полное решение.

Пример из практики:

Задача: Интеграция платежного SDK за 2 дня. Проблема: SDK содержал критический баг, приводящий к крашу. Фикс от вендора занял бы неделю. Предложенное решение:

1. Краткосрочное: Реализовать fallback-оплату через WKWebView и страницу провайдера, чтобы не блокировать релиз.
2. Долгосрочное: Параллельно вести работу с вендором над фиксом и нативной интеграцией. Итог: Функциональность была доставлена в срок, полная интеграция завершена позже.

4. Выводы и улучшение процессов После завершения спринта/проекта важно провести ретроспективу, чтобы улучшить процессы оценки (например, добавить буфер на риски, дробить задачи мельче).