Были ли стрессовые ситуации в проекте

Управление стрессовыми ситуациями: опыт и методология

Безусловно, стрессовые ситуации — неотъемлемая часть управления IT-проектами. За 10+ лет моего опыта я прошел через множество таких эпизодов, и именно они стали ключевыми точками роста для меня как менеджера и для команд. Главный вывод: стресс не должен быть стихийным бедствием, а стать управляемым процессом, который вскрывает проблемы и позволяет системе стать устойчивее.

Конкретный кейс: критический сбой на проде перед релизом

Один из самых показательных случаев произошел в рамках проекта по миграции монолитного банковского приложения на микросервисную архитектуру. За неделю до планового релиза основного модуля "Платежи" автоматические нагрузочные тесты выявили деградацию производительности на 70% при пиковой нагрузке, что являлось блокером для go-live. Одновременно с этим ключевой Senior Backend-разработчик, отвечавший за ядро сервиса, внезапно ушел на больничный.

Создалась классическая стрессовая триада:

• Технический кризис (критический баг);
• Ресурсный кризис (потеря экспертизы);
• Временной прессинг (дедлайн и обязательства перед бизнесом).

Мои действия и применяемые практики

Моя первая реакция — привести в порядок собственные эмоции по принципу "сохранять хладнокровие ради команды", а затем действовать по отработанному алгоритму.

1. Немедленная прозрачность и перепланирование

• Провел экстренную встречу с ключевыми стейкхолдерами (Product Owner, Head of Development, CTO). Не стал сглаживать углы, а четко представил ситуацию, матрицу рисков и предварительный план действий.
• Внутри команды провел short-notice incident meeting по принципам Agile: без поиска виноватых, только анализ фактов.
• Использовал Miro-доску для визуализации проблемы и поиска корневой причины (подход 5 Why's).

Проблема: Падение производительности на 70%.
1. Почему? Сервис платежей не справляется с concurrent requests.
2. Почему? Блокировка на уровне базы данных при обработке транзакций.
3. Почему? Некорректная конфигурация пула соединений HikariCP в новом коде.
4. Почему? Конфигурация была "подобрана" на глаз, а не протестирована под load.
5. Почему? Не было выделенного нагрузочного тестирования для этого модуля в рамках спринта (срезали ради скорости).

2. Решение кадрового вопроса и перераспределение нагрузки

• Связался с заболевшим разработчиком (с его согласия), чтобы получить critical knowledge transfer по архитектурным нюансам.
• Временно перераспределил задачи внутри команды: привлек двух Middle.
• Сам погрузился в технические детали, чтобы быть эффективным посредником между командой и архитектором.

3. Техническое решение и контроль

• Команда нашла решение: "hot-fix" конфигурации + экстренное написание скрипта для симуляции реалистичной нагрузки.
• Я внедрил прозрачную hourly-отчетность в общем Slack-канале. Каждый час ведущий разработчик постил: что сделано, что мешает, план на следующий час.
• Ввел два коротких daily-standup'а (утром и вечером) для поддержания фокуса и оперативного снятия блокеров.

4. Работа с ожиданиями

• Постоянно информировал бизнес о статусе. Предложил fallback-план: выпустить релиз с degraded functionality (ограничением по количеству операций) и "тихо" обновить конфиг уже на проде в ночное время, если фикс не будет готов. Это сняло 80% паники у заказчика.

Результат и извлеченные уроки

Релиз состоялся с задержкой в 48 часов, но с полной функциональностью. Пост-мортем анализ (blameless retrospective) привел к важным изменениям в процессе:

• Внедрение обязательного этапа load & stress testing для всех критичных сервисов в Definition of Done.
• Создание "страховочной" матрицы знаний (knowledge matrix) по ключевым модулям, чтобы снизить bus factor.
• Формализация процедуры инцидент-менеджмента с четкими ролями (Incident Manager, Communicator, Tech Lead).

Итог: Стрессовая ситуация стала катализатором положительных изменений. Моя роль как PM была не в том, чтобы тушить пожар лично, а в том, чтобы создать структурированную среду, в которой команда может эффективно этот пожар тушить, минимизировать ущерб и извлечь системные уроки. Ключевые инструменты в таких ситуациях — это экстремальная прозрачность, фокус на процесс (а не на людей) и наличие заранее подготовленных "планов Б". Умение проходить через такой стресс, сохраняя доверие команды и заказчика, — это, пожалуй, главный навык зрелого проект-менеджера.