Раздел 2
Что это и зачем
RAID-лог — единый документ для отслеживания рисков и неопределённости в инициативе. Расшифровка: Risks, Assumptions, Issues, Dependencies. На J/M-грейде это базовая дисциплина управления любой инициативой длиннее двух недель.
Зачем нужен:
- Не теряются риски и зависимости между статус-встречами
- Видно, какие допущения нужно валидировать до того, как они станут критичны
- Issues эскалируются с историей, не «вдруг сегодня всплыло»
- Стейкхолдеры видят полную картину неопределённости в одном месте
ШаблоныГотово к копированию
Шаблон
| Компонент | Что это | Пример |
|---|---|---|
| R — Risks | Возможные будущие проблемы | «Ключевой разработчик может уйти в отпуск в середине проекта» |
| A — Assumptions | То, что мы считаем истинным, но не проверили | «Бюджет на инструменты будет одобрен до марта» |
| I — Issues | Проблемы, которые уже произошли | «API партнёра не поддерживает нужный формат данных» |
| D — Dependencies | Зависимости от внешних команд/ресурсов | «Запуск зависит от готовности инфраструктуры командой DevOps» |
Раздел 4
Правила ведения
- Завести на стартовой встрече (kickoff) инициативы. Не позже. Если завели позже — половина рисков уже стала issues.
- Обновлять еженедельно. Лучше всего — за 10 минут перед статус-встречей с руководителем.
- У каждого пункта — owner. Конкретный человек, ответственный за мониторинг. Без owner'а строка в RAID-логе — мусор.
- Assumptions должны быть провалидированы до момента, когда они становятся критичными. Если допущение не подтверждено к контрольной точке — оно становится Risk или Issue.
- Issues эскалируются через managing up к руководителю по матрице эскалации (см. Шаблон: Risk card).
Раздел 5
Структура записей
Для каждого типа (R/A/I/D) минимальные поля:
ID: [R-001, A-002, I-003, D-004]
Описание: [конкретно, что именно]
Owner: [имя]
Дата заведения: [когда]
Дата проверки: [когда мониторим]
Статус: [open / mitigated / resolved / escalated]
Заметки: [что произошло, что сделали]
Раздел 6
Пример короткого RAID-лога для инициативы «миграция CRM»
RISKS
R-001 | Уход ключевого разработчика в отпуск март | Иван П. | open
Митигация: knowledge transfer ко 2 чел. до 25 февраля
R-002 | Деградация API при нагрузке >800 rps | Мария С. | open
Митигация: load test до пилота
ASSUMPTIONS
A-001 | Бюджет на лицензии будет одобрен до 15 марта | Александр Р. | open
Проверка: запрос на согласование отправлен 1 марта
A-002 | Партнёр успеет обновить SDK до конца Q1 | Дмитрий К. | validated 12 февраля
ISSUES
I-001 | API партнёра не поддерживает поле X | Дмитрий К. | escalated
Эскалирована руководителю 8 февраля, ждём ответа партнёра
DEPENDENCIES
D-001 | Готовность инфраструктуры от DevOps | Артём Л. | open
Дата: 20 февраля. Статус 12 февраля: подтверждено
Раздел 7
Как использовать на статус-встречах
- Только изменения с прошлой недели: новые риски, изменения статуса, эскалации
- Не пересказывайте весь лог — это документ для чтения, не для зачитывания
- Закрытые (resolved) пункты — отдельной секцией, не удаляйте, оставляйте историю
Раздел 8
Когда RAID-лог избыточен
- Инициатива на 1–2 недели в одной команде — достаточно списка задач
- Рутинная разработка — есть backlog, RAID удваивает
- Личная задача — никому не нужен формальный документ
Раздел 9
Связанное
- Шаблон: Risk card — для каждого значимого риска детальнее
- Деталь: Pre-mortem — упреждающее наполнение Risks-секции
- Ясность процессов — как делать видимым прогресс по инициативе
- Ясность решений — как обсуждать риски с руководителем
Следующий шаг
Заведите на kickoff инициативы. Без него риски и зависимости теряются.