Как вы действуете, когда критический (Blocker) баг не был исправлен разработчиком к согласованному сроку?

Блокирующий баг, не исправленный в срок, — это риск для проекта, требующий проактивного управления, а не пассивного ожидания.

Стратегия эскалации и управления рисками:

1. Немедленная коммуникация: Связываюсь с разработчиком и тимлидом для выяснения причины задержки (техническая сложность, недооценка, конфликт приоритетов). Уточняю реалистичный ETA (estimated time of arrival).
2. Оценка воздействия: Четко документирую, что блокирует баг:
   • Тестирование других функциональностей?
   • Выпуск релиза?
   • Работу смежных команд?
3. Поиск временных решений (workaround): Обсуждаю с командой возможность:
   • Отключения проблемной фичи через feature toggle.
   • Разработки временного патча или «хотфикса».
   • Изменения последовательности тестирования.
4. Формальная эскалация: Если новый ETA неприемлем для сроков релиза, информирую менеджера проекта (PM) и/или руководителя о рисках, предоставляя варианты решений.
5. Документирование: Все обсуждения, решения и новые сроки фиксирую в тикете бага.

Пример комментария в Jira/YouTrack:

**Статус эскалации** [05.03.2024]
*   Оригинальный дедлайн (01.03) пропущен.
*   Причина задержки (со слов DEV): сложность в интеграции с легаси-модулем X.
*   Новый ETA от разработчика: 07.03.
*   **Влияние на проект:** Блокирует smoke-тестирование всего модуля Y. Перенос финального тестирования на 2 дня невозможен.
*   **Предложенное решение:** На время фикса использовать feature-flag для отключения проблемного сценария. Создана задача DEV-123 для реализации флага.
*   **Следующие шаги:** PM принял решение о внедрении временного флага. Тестирование модуля Y продолжится с флагом в выключенном состоянии.

Цель: Не обвинить, а устранить блокер и минимизировать ущерб для проекта, сохраняя прозрачность для всех заинтересованных сторон.