RAID Log
RAID Log — практичная альтернатива тяжёлому Risk Register для маленьких/средних проектов. Объединяет в одной таблице 4 категории.
R — Risks
То, что МОЖЕТ произойти и негативно повлиять. Колонки: описание, P, I, mitigation, owner.
A — Assumptions
То, на чём ОСНОВАНЫ планы (но что может оказаться неверным). Например: «Заказчик утвердит дизайн за 1 неделю», «Команда будет работать на full-time». Если assumption нарушается — становится issue или risk.
I — Issues
То, что УЖЕ ПРОИЗОШЛО и требует действий. Например: «3 недели задержка получения доступов», «Один разработчик уволился».
D — Dependencies
Внешние ЗАВИСИМОСТИ от других команд/проектов/событий. Например: «Готовность API от другого проекта», «Получение лицензии».
Когда применять и когда нет
Применять
- Любой проект — простой инструмент
- Хороший компромисс между «ничего» и формальным Risk Register
Не применять
- Очень крупный проект — нужен полный Risk Register
Примеры применения
RAID Log проекта запуска маркетплейса:
R: Сезонный пик нагрузки в декабре (P=4, I=4) → нагрузочное тестирование за 2 месяца до запуска.
A: Партнёр интегрируется за 6 недель (если задержка → issue).
I: Два senior-разработчика заболели → нужно перераспределить задачи.
D: Юридический отдел утвердит публичную оферту до 15 ноября.
Часто задаваемые вопросы
RAID шире — включает 4 категории, не только риски. Проще в ведении, но менее детальный. Risk Register — глубоко по рискам с probability/impact/score. Часто используют вместе: RAID для общего обзора, Risk Register — для детального риск-менеджмента.
Допущение, на котором строится план. Например, «команда будет full-time», «заказчик ответит в течение дня». Если допущение оказывается неверным, оно становится Risk или Issue. Assumptions нужно явно документировать, чтобы команда знала про их хрупкость.