Какой был критический момент в работе?

Критический момент в управлении проектом: Часовая миграция данных с риском остановки производства

Самый критический момент в моей практике произошел во время проекта миграции ERP-системы для крупного розничного ритейлера. Мы переходили со старой локальной системы на облачное SaaS-решение. Проект длился 9 месяцев, а «час икс» был назначен на выходные — плановое окно длительностью 48 часов.

Суть кризиса: Отказ при синхронизации финальных данных

По плану, в последние 4 часа окна мы выполняли финальную инкрементальную синхронизацию данных (транзакции, остатки складов), полученных за время копирования основной базы. За 1.5 часа до запуска новой системы выяснилось, что кастомный скрипт синхронизации, написанный вендором, необратимо повредил блок данных о текущих остатках товара на центральном складе. Ошибка заключалась в условии race condition при параллельной обработке, которое не было выявлено при тестировании на устаревших данных.

Без корректных остатков система не могла бы корректно проводить продажи, отгрузки и приемку с понедельника, что означало остановку работы 200+ магазинов с прямыми финансовыми потерями и репутационным ущербом.

Мои немедленные действия: Три фронта работы

Я разделил команду на три группы и действовал по принципу Incident Management:

1. Группа А: Анализ и «откат».

    *   Задачей было определить глубину повреждения и возможность восстановления из бэкапа.
    *   Мы быстро выяснили, что полный откат миграции (на 48 часов назад) неприемлем по срокам. Однако инженеры нашли точку **валидного бэкапа**, сделанного за 30 минут до сбоя.

1. Группа B: Разработка обходного пути (workaround).

    *   Параллельно я поручил техническим лидам и бизнес-аналитикам разработать **процедуру ручного ввода остатков** через упрощенный интерфейс в новой системе. Мы оценили, что на заполнение данных для 20 000 SKU (наиболее критичных товаров) силами 15 подготовленных кладовщиков уйдет ~8 часов.

1. Группа C: Коммуникация и управление ожиданиями.

    *   Я немедленно созвал экстренный созвон с ключевыми стейкхолдерами: IT-директором, COO и руководителем розницы. Четко озвучил проблему, варианты решений и риски по каждому. **Не преуменьшал масштаб**, но акцентировал внимание на плане действий.

Принятие решения и реализация

После 25 минут анализа вариантов, мы приняли гибридное решение:

• Восстановить данные из «свежего» бэкапа (работа Группы А).
• Запустить упрощенный, но проверенный скрипт синхронизации только для модуля остатков, который мы тестировали ранее.
• Подготовить процедуру ручного ввода как fallback-план на случай, если синхронизация затянется.

Ключевым был контроль времени. Я визуализировал оставшееся окно для команды:

До запуска продаж: 8 часов (сейчас 04:00)
│
├── Восстановление бэкапа: 45 мин.
├── Запуск и проверка скрипта: 90 мин.
├── Резерв на ручной ввод (если нужно): 5 часов.
└── Финальное тестирование: 1 час.

Мы успели. Синхронизация прошла за 70 минут. К 06:30 утра система была готова, а к 08:00 мы провели успешную пробную операцию в тестовом магазине.

Извлеченные уроки и изменения в процессах

Этот инцидент привел к ключевым изменениям в моей практике управления проектами:

• Обязательный этап "Final Data Sync Rehearsal". Перед любой миграцией мы теперь проводим как минимум две полные репетиции финальной синхронизации на продуктированной копии с текущими данными, имитируя давление по времени.
• Усовершенствованная стратегия резервного копирования. Мы формализовали правило "Multiple Recovery Points" — создание проверенных точек отката перед каждым ключевым этапом миграции.
• Повышение прозрачности рисков. В планы коммуникации был добавлен обязательный пункт о "Наихудшем сценарии (worst-case scenario)" и четком плане действий по нему для спонсоров.

Этот критический момент стал мощным напоминанием, что управление рисками — это не просто формальность в документах, а живой процесс. Самое важное в кризисе — не паника, а структурированное разделение проблем на технические, коммуникационные и процессные, и быстрая мобилизация команды по этим направлениям. Уверенность стейкхолдеров была сохранена не потому, что ошибок не было, а потому, что управление кризисом было прозрачным, профессиональным и результативным.