Какие были критические ситуации?

Управление критическими ситуациями в проекте

В моей практике IT Project Manager критические ситуации возникали регулярно — это неотъемлемая часть управления сложными проектами. Их разрешение требует сочетания технического понимания, коммуникационных навыков и строгого процессного подхода. Я разделю ответ на три ключевые категории: технические кризисы, кризисы сроков/ресурсов и кризисы коммуникации/доверия.

1. Технические кризисы: масштабный сбой при интеграции систем

Ситуация: В проекте по замене legacy CRM для крупного банка во время этапа интеграции с платежным шлюзом произошел катастрофический сбой. Новый API возвращал некорректные статусы транзакций, что приводило к дублированию операций в тестовой среде. Сбой был обнаружен в пятницу вечером, а понедельник был назначен как день начала пилотного запуска для первых 100 пользователей.

Мои действия:

• Немедленная трианализация и коммуникация: Созвал виртуальный «war room» с ключевыми разработчиками, архитектором и представителем вендора платежного шлюза. Первым шагом было четкое определение масштаба: сбой затрагивал только один тип транзакций, но критически важный.
• Приоритизация и временное решение: Вместо полной остановки мы решили реализовать временный патч-фикс. Команда разработала дополнительный слой логики на стороне нашего приложения для валидации статусов.

# Пример концепции временного решения (валидационный фильтр)
def validate_transaction_status(api_response, legacy_status_map):
    """
    Фильтр для корреляции статусов нового API и старой системы.
    Если статус неизвестен, транзакция помечается для ручной проверки.
    """
    mapped_status = legacy_status_map.get(api_response.get('status'), 'UNKNOWN')
    if mapped_status == 'UNKNOWN':
        # Логирование для ручного разбора и остановка автоматического потока
        log_critical_alert(api_response)
        return {'status': 'MANUAL_REVIEW', 'original_data': api_response}
    return {'status': mapped_status, 'original_data': api_response}

• Прозрачность с бизнесом: Я немедленно проинформировал Sponsor проекта и руководителя пилотной группы. Вместо того чтобы откладывать запуск, мы согласовали измененный план: первые пользователи будут работать с временным решением, а их транзакции в «ручном режиме» будут дополнительно мониториться двумя выделенными сотрудниками. Это позволило сохранить доверие и избежать полной остановки проекта.
• Пост-кризисный анализ: После стабилизации мы провели глубокий Root Cause Analysis (RCA). Основная проблема оказалась не в нашем коде, а в неполной документации API вендора. Результатом стало обновление контракта с вендором и создание внутреннего стандарта на тестирование интеграций с двойной валидацией.

2. Кризисы сроков и ресурсов: потеря ключевого архитектора перед релизом

Ситуация: На финальной стадии проекта по разработке нового мобильного приложения главный архитектор, отвечающий за всю серверную часть, внезапно ушел из компании. Это произошло за 3 недели до запланированного релиза, и его знания о специфичных оптимизациях и конфигурациях live-серверов были уникальными.

Мои действия:

• Стресс-тест плана и рисков: Я быстро пересмотрел план релиза, выделив все задачи, зависимые от уникальных знаний архитектора. Обнаружилось, что 40% предрелизных задач (конфигурация, деплой, настройка мониторинга) находились в зоне высокого риска.
• Мобилизация альтернативных ресурсов и знаний: Вместо поиска нового архитектора на рынке (что было слишком долго), я использовал внутренние резервы:

    *   Организовал интенсивный «knowledge transfer» сессию между уходящим архитектором и двумя senior backend-разработчиками в течение его последних двух дней. Все сессии записывались.
    *   Временно перераспределил часть бюджета на привлечение внешнего консультанта-архитектора из партнерской компании на 10 дней для поддержки и проверки решений.

• Реструктуризация релиза: Мы решили разделить релиз на две фазы:

    1.  **Фаза A:** Выпуск только клиентского мобильного приложения с базовым функционалом, использующим временные, более стандартные конфигурации серверов.
    2.  **Фаза B:** Выпуск полной оптимизированной серверной части через 4 недели, когда команда полностью освоила знания.

• Коммуникация с стейкхолдерами: Я представил измененный план руководству продукта и команде маркетинга, четко объяснив, что Фаза A все же даст пользователям ключевую ценность, а отсрочка части функций позволит обеспечить надежность. План был принят.

3. Кризисы доверия: конфликт между командами разработки и QA

Ситуация: В длительном проекте по созданию SaaS-платформы накопилась токсичная атмосфера между командой разработки и командой тестирования. Разработчики считали, что QA создают искусственные барьеры и тормозят процесс, возвращая баги с низким приоритетом. QA, в свою очередь, чувствовали, что их критикуют незаслуженно, а качество кода падает. Это начало напрямую влиять на скорость и количество дефектов в production.

Мои действия:

• Отделение эмоций от данных: Я остановил общие планерки, где происходили конфликты, и вместо этого начал собирать данные:

    *   Метрики о времени между коммитом и завершением тестирования.
    *   Классификацию возвращаемых багов по реальной критичности (Severity vs Priority).
    *   Статистику дефектов, обнаруженных уже после релиза (escape defects).

• Структурированная медиация и процессные изменения: На основе данных я организовал совместную workshop-сессию:

    *   Показал, что большая часть delays вызвана не «придирками» QA, а плохо составленными задачами (типы «As a user…») и отсутствием четких критериев приемки (Acceptance Criteria).
    *   Мы совместно разработали новый протокол передачи задачи в тестирование.

### Новый шаблон задачи для разработчика перед отправкой в QA
**Задача:** TASK-123 — Добавить валидацию email в форме регистрации.
**Критерии приемки (Acceptance Criteria):**
1.  Система должна отклонять адреса без символа '@'.
2.  Система должна отклонять адреса без доменной части (например, 'test@').
3.  При успешной валидации должно появляться зеленое сообщение "Email valid".
4.  При ошибке — красное сообщение "Invalid email format".
**Тестовые данные для QA (предоставляет разработчик):**
-   Валидный адрес: `user@domain.com`
-   Невалидные адреса: `user`, `user@`, `@domain.com`

• Введение совместных ритуалов: Мы внедрили короткие ежедневные sync-сессии между lead разработчиком и lead QA на 15 минут для обсуждения статуса текущих задач и потенциальных проблем. Это создало постоянный канал связи и сняло напряжение.

Общий вывод: Ключ к управлению критическими ситуациями — не паника, а системный подход: немедленная оценка масштаба, прозрачная коммуникация со всеми сторонами, быстрая мобилизация ресурсов (людей, знаний, процессов) и обязательный пост кризисный анализ для улучшения системы на будущее. Каждая такая ситуация — это возможность усилить процессы и построить более resilient команду.