Ответ
В моей практике в DevOps срыв дедлайна часто связан с непредвиденными сложностями в инфраструктуре (например, миграция БД заняла втрое больше времени из-за проблем с сетью). Мой алгоритм действий:
-
Немедленно информирую ответственных. Я не жду дня дедлайна. Как только понимаю, что рискую не успеть, я сообщаю тимлиду или продакт-менеджеру, называю причину и даю реалистичную новую оценку. Например: "Миграция на новый кластер БД застопорилась из-за проблем с пропускной способностью между дата-центрами. Текущая оценка сдвигается на 2 рабочих дня".
-
Предлагаю варианты. Вместо проблемы я приношу варианты решений:
- Минимально жизнеспособный релиз (MVP): "Мы можем выкатить новую конфигурацию Terraform без автоматического переноса данных сейчас, а миграцию данных провести вручную в maintenance-окно. Это позволит уложиться в срок, но добавит 4 часа ручной работы в субботу".
- Перераспределение задач: "Если кто-то из команды поможет мне с настройкой мониторинга для нового сервиса, я смогу сфокусироваться на критичном деплое пайплайна и уложиться в пятницу".
-
Анализирую причину и документирую. После завершения работы я провожу короткий анализ: почему оценка была неверной? Были ли неизвестные риски? Это помогает улучшать процессы планирования в будущем, особенно в части инфраструктурных работ, где много зависимостей.
