Опишите ситуацию, когда вам пришлось поднять риск наверх до того, как проблема стала видимой.

Эскалация риска до того, как проблема стала видимой

Реальный кейс: мы разрабатывали интеграцию с платёжным шлюзом. За 3 недели до запуска я обнаружил в документации партнёра пометку о плановом обслуживании их Webhook API в нашем launch window. Проблемы ещё не было, но риск был реальным.

Что сделал:

1. Оценил вероятность и влияние. Вероятность: ~60% (обслуживание могло затронуть наш endpoint). Влияние: полный stoppage платежей на 2–4 часа в день запуска, потеря первых конверсий и репутационный ущерб.
2. Подготовил опции до эскалации:
   • Option A: сдвинуть запуск на 1 неделю — полностью избегаем риск.
   • Option B: запустить в плановую дату, но с polling fallback вместо webhook — технически сложнее, запуск в срок.
   • Option C: запустить только для 10% аудитории (feature flag) — ограничиваем потенциальный ущерб.
3. Написал Risk Brief — одностраничный документ:

   # Risk Brief: Payment Integration Launch
   **Дата обнаружения**: 2024-11-12
   **Категория**: Third-party dependency
   **Вероятность**: ~60%
   **Влияние**: Полный stoppage платежей на 2–4 ч в день запуска
   
   ## Контекст
   Документация YooKassa содержит [ссылка] уведомление о плановом обслуживании
   Webhook API 2024-12-03 02:00–06:00 UTC. Наш запуск: 2024-12-03 10:00 MSK (07:00 UTC).
   
   ## Опции
   | Вариант          | Риск     | Стоимость         | Рекомендация |
   |------------------|----------|-------------------|--------------|
   | Сдвиг на 1 нед.  | Устранён | Маркетинговые KPI | Да           |
   | Polling fallback | Низкий   | +3 дня разработки | Альтернатива |
   | 10% rollout      | Средний  | 0                 | Нет          |
   
   **Рекомендация**: Option A или B. Прошу решения до 2024-11-15.
   

4. Эскалировал синхронно — не письмом, а встречей на 20 минут с CPO и Head of Product. Письмо отправил как follow-up с фиксацией решения.

Принципы эскалации рисков:

• Эскалируй с данными, опциями и рекомендацией — не просто «у нас проблема», а «вот что происходит, вот варианты, вот что я рекомендую».
• Ранняя эскалация сохраняет опции — за 3 недели у нас было 3 варианта. За 3 дня остался бы один.
• Не жди уверенности — 60% — достаточно для эскалации. Ждать 95% = ждать пока проблема случится.
• Документируй, что тебя проигнорировали — если эскалировал и получил «не трогай», это решение стейкхолдера, не твоя ответственность. Это должно быть зафиксировано письменно.

Подводные камни

• Эскалация без опций — «у нас риск» без вариантов действий вызывает панику или игнорирование. Всегда приходи с опциями.
• Ожидание уверенности перед эскалацией — к моменту появления уверенности у стейкхолдеров нет времени на реакцию.
• Эскалация через почту без follow-up — письмо может потеряться. Если решение нужно срочно, нужна синхронная коммуникация.
• «Волк» — частые ложные тревоги — если поднимать каждый малейший риск, стейкхолдеры начнут игнорировать. Нужно научиться ранжировать.
• Нет owner у риска — после эскалации риск должен иметь конкретного человека, который следит за его статусом.
• Risk log не ведётся — без истории рисков нельзя улучшить процесс выявления и реакции.
• Путаница между риском и проблемой — риск ещё не случился, проблема уже есть. Разные протоколы реакции.

• Эскалировать слишком поздно.
• Приносить наверх только эмоцию без вариантов.
• Скрывать риск, чтобы не выглядеть слабым.

• Видит risk signals заранее.
• Формулирует options and recommendation.
• Создаёт доверие через прозрачность.