Блок 3. Говорить о рисках и эскалации
Шпаргалка: каскад причинности
В контексте витка
Как вырасти из junior в middle: видимый вклад, решения и риски
Где обычно проявляется
Чаще всего актуально на переходе Junior → Middle
Как читать дальше
После этого переходи к блоку «Блок 4. Как выглядит сильный результат».
Контекст витка
Как вырасти из junior в middle: видимый вклад, решения и риски
Как сделать работу видимой, перейти от задач к решениям и показать бизнес-эффект — конкретные практики для перехода junior → middle.
Блок 4 из 9
Если нужно снова увидеть весь маршрут, вернись к обзору витка.
Оглавление витка
Дальше открыть
4 ясности карьерного роста: процессы, решения, ожидания и роль
Фреймворк карьерного роста в корпорации: диагностика по 4 блокам, матрица приоритетов и выбор следующего витка — от junior до head.
Инструмент 1: Управление ожиданиями руководства
Управление ожиданиями руководства для скептиков — практические инструменты.
Готовые примеры заполнения
Готовые примеры заполнения шаблонов фреймворка.
Фокус этого блока
Шпаргалка: каскад причинности
Шпаргалка: каскад причинности
Для любой инициативы используй шаблон causal chain (каскад причинности):
Root cause (корневая проблема) →
Intervention (что мы делаем) →
Immediate metric (ближайшая метрика, которая изменится) →
Отложенный результат (downstream outcome): бизнес-результат через 1–2 шага
Пример: Низкое удержание (retention, root) → Улучшить процесс онбординга (intervention) → Увеличить долю активации (immediate metric) → Рост пожизненной ценности клиента (LTV) на X% за Y месяцев (downstream outcome).
Даже приблизительные оценки демонстрируют коммерческое мышление. Практикуй презентацию таких цепочек кратко -- руководство ценит ясность и бизнес-интуицию, а не идеальные прогнозы.
Инструмент: проговаривание рисков
Проблема: Ты предлагаешь решение, скрывая риски. Потом что-то идёт не так -- доверие падает.
Решение: Открыто обсуждай риски и план Б.
Формат:
Предложение: [решение]
Риски:
1. [риск] — вероятность [низкая/средняя/высокая]
Митигация: [что делаем, если случится]
2. [риск] — вероятность [...]
Митигация: [...]
План действий если что-то пойдёт не так: [конкретные шаги]
Пример:
Предложение: Изменить процесс маршрутизации входящих заявок
Риски:
1. Ошибочная маршрутизация части кейсов — вероятность средняя
Митигация: запускаем пилот на 20% потока и ежедневно проверяем выборку
2. Рост нагрузки на одну функцию — вероятность средняя
Митигация: вводим лимит и резервный маршрут
3. Падение скорости обработки в первые дни — вероятность низкая
Митигация: временно усиливаем смену и держим ручной override
План Б: Если в первые 24 часа метрика SLA ухудшится более чем на 10%
— возвращаемся к предыдущей схеме по заранее согласованной процедуре.
Шаблон: risk card
Для более крупных инициатив используй расширенную карточку риска:
| Поле | Описание | Пример |
|---|---|---|
| Risk ID | Уникальный номер | R-001 |
| Описание | Что может пойти не так (конкретно) | Ошибочная маршрутизация 15-20% заявок в первую неделю |
| Категория | Тип: операционный, технический, людской, внешний | Операционный |
| Вероятность | Низкая (1-33%) / Средняя (34-65%) / Высокая (66-99%) | Средняя (~50%) |
| Impact | Низкий / Средний / Высокий -- описать в бизнес-терминах | Средний: рост SLA breach на 5-10% |
| Risk Score | Вероятность × Impact (для приоритизации) | Средний × Средний = Средний |
| Митигация (Plan A) | Что делаем, чтобы риск НЕ реализовался | Пилот на 20%, ежедневный мониторинг выборки |
| Contingency (Plan B) | Что делаем, ЕСЛИ риск реализовался | Rollback на предыдущую схему за 2 часа |
| Trigger | Как узнаём, что риск начал реализовываться | SLA breach > 10% за 24 часа |
| Владелец (Owner) | Кто отвечает за мониторинг и реакцию | [Имя], руководитель команды операций (Team Lead Operations) |
Техника: pre-mortem
Что это: Техника, предложенная Gary Klein и продвигаемая McKinsey. Вместо того чтобы планировать успех, ты начинаешь с допущения, что инициатива уже провалилась -- и обратным ходом ищешь причины.
Почему работает: Исследования Mitchell et al. (1989) показали, что «prospective hindsight» -- представление, что событие уже произошло -- увеличивает количество сгенерированных причин на ~30%. А McKinsey отмечает, что premortems снижают сверхуверенность команд значительно сильнее, чем другие методы критического анализа.
Как провести (30 минут):
-
Установка (2 мин): «Представьте, что прошло 6 месяцев. Наша инициатива провалилась. Полный провал. Что произошло?»
-
Индивидуальная генерация (5 мин): Каждый участник молча пишет причины провала -- без обсуждения (это важно для борьбы с groupthink)
-
Сбор (10 мин): Каждый по кругу называет одну причину, пока не исчерпаются все. Записываем на доску
-
Приоритизация (5 мин): Голосование -- какие 3-5 причин наиболее вероятны и опасны?
-
Митигация (8 мин): Для top-3 рисков -- что мы можем сделать прямо сейчас, чтобы этого не произошло?
Ключевое преимущество: Pre-mortem создаёт безопасное пространство, где поднимать проблемы -- это не обструкция, а проявление дальновидности. Участники даже соревнуются, кто поднимет самую серьёзную проблему.
Шаблон: RAID-лог
Для текущего управления рисками в рамках инициативы используй RAID-лог -- единый документ, который отслеживает четыре типа потенциальных проблем:
| Компонент | Что это | Пример |
|---|---|---|
| R -- Risks | Возможные будущие проблемы | «Ключевой разработчик может уйти в отпуск в середине проекта» |
| A -- Assumptions | То, что мы считаем истинным, но не проверили | «Бюджет на инструменты будет одобрен до марта» |
| I -- Issues | Проблемы, которые УЖЕ произошли | «API партнёра не поддерживает нужный формат данных» |
| D -- Dependencies | Зависимости от внешних команд/ресурсов | «Запуск зависит от готовности инфраструктуры командой DevOps» |
Правила ведения:
-
Заводи на стартовой встрече (kickoff), обновляй еженедельно
-
Каждый пункт имеет owner -- конкретного человека, ответственного за мониторинг
-
Assumptions должны быть провалидированы до момента, когда они становятся критичными
-
Нерешённые задачи (issues) эскалируются через работу с руководством (Managing Up) (Инструмент #1, аспект 5)
Антипаттерны коммуникации рисков
| Антипаттерн | Что происходит | Как исправить |
|---|---|---|
| «Всё под контролем» | Скрываешь риски -> потом сюрприз -> доверие падает | Открыто назови top-3 риска и свой план |
| «Катастрофизация» | Перечисляешь 20 рисков без приоритизации -> парализуешь решение | Приоритизируй: top-3 + «остальное мониторим» |
| «Риск без плана» | «Может не сработать» -- и всё | Каждый риск = митигация + trigger + owner |
| «Общие слова» | «Есть технические риски» | Конкретизируй: «Риск деградации API при нагрузке >1000 rps» |
| «Один раз обсудили» | Риски обсудили на старте и забыли | Еженедельный review: появились ли новые? изменились ли старые? |
| «Оптимистичный bias» | Все риски «низкая вероятность» | Используй pre-mortem для калибровки |
Матрица эскалации рисков
Не все риски нужно эскалировать одинаково. Вот простая матрица:
Impact
Low High
┌──────────┬──────────┐
Probability │ Monitor │ Mitigate │
High │ weekly │ + Escalate│
│ │ to boss │
├──────────┼──────────┤
Probability │ Accept │ Mitigate │
Low │ & log │ + Monitor │
│ │ closely │
└──────────┴──────────┘
Правило эскалации:
-
High × High -> Немедленно эскалируй руководителю + готовь Plan B
-
High × Low -> Мониторь еженедельно, escalation не нужен
-
Low × High -> Готовь митигацию заранее, информируй руководителя при изменении вероятности
-
Low × Low -> Логируй и периодически проверяй
Формулировки для разных аудиторий
Один и тот же риск звучит по-разному в зависимости от аудитории:
| Аудитория | Формулировка |
|---|---|
| Команда | «Есть риск, что API не выдержит нагрузку. Вот что мы делаем: нагрузочные тесты на этой неделе. Если подтвердится -- переходим на Plan B с кэшированием» |
| Руководитель | «Основной риск -- производительность при масштабировании. Митигация в процессе, результаты будут в пятницу. Если риск подтвердится, нам потребуется дополнительная неделя на Plan B» |
| Топ-руководство | «Мы управляем одним ключевым техническим риском, который может сдвинуть запуск на неделю. Вероятность средняя, митигация запущена, update будет в пятницу» |
Принцип: чем выше аудитория -- тем короче, конкретнее и ближе к бизнес-эффекту.