Ответ
В такой ситуации мой подход основан на прозрачности и проактивном решении проблемы.
- Немедленный анализ: Сначала я определяю коренную причину задержки. Это могла быть недооценка сложности (например, необходимость глубокой оптимизации legacy-кода на C++), появление внешних блокировок (ожидание ответа от другой команды) или технические трудности (сложная отладка race condition).
- Срочное информирование: Я сразу сообщаю тимлиду или проджект-менеджеру о ситуации, четко обозначая проблему и ее предполагаемое влияние на сроки. Например: "При оптимизации алгоритма сжатия столкнулся с неожиданным падением производительности на ARM-архитектуре. Требуется дополнительное время на анализ и переработку — текущий дедлайн под угрозой".
- Предложение решений: Вместе с сообщением о проблеме я предлагаю варианты выхода:
- Выделение MVP: Можно выпустить базовую, но рабочую версию фичи, а оптимизацию вынести в отдельную задачу.
- Пересмотр объема: Обсудить, можно ли упростить требования или временно отключить некритичный функционал.
- Перераспределение: Если в команде есть свободные ресурсы, попросить помощи на конкретном узком месте.
- Корректировка срока: Если качество принципиально важно (например, для компонента ядра), обосновать необходимость сдвига дедлайна.
Пример из практики: На одном из проектов я работал над интеграцией новой библиотеки для парсинга JSON. Изначальная оценка была 3 дня, но выяснилось, что библиотека некорректно работала с многобайтовыми кодировками в нашем контексте. Я сразу доложил о проблеме, предложил временно использовать старый, менее эффективный парсер для текущего спринта, а на решение проблемы с новой библиотекой запросил дополнительно 2 дня, которые и были выделены.