Суть. В одном журнале ведут четыре вида записей: риски (может случиться), допущения (считаем верным без проверки), проблемы (уже случилось) и зависимости (от чего мы зависим). У каждой записи есть владелец, срок и статус. Журнал разбирают на каждом статусе проекта.
Какую боль решает
Важное теряется в письмах и чатах. Через месяц никто не помнит, о чём договаривались, кто должен был предоставить доступы и почему сроки сдвинулись.
- Клиент утверждает, что о задержке его не предупреждали
- Допущение о готовности инфраструктуры оказалось неверным в середине проекта
- Проблемы обсуждаются на каждой встрече, но не закрываются
- Проект зависит от поставки оборудования, и об этом вспоминают в последний момент
Ваш ли это случай
Проверьте ситуацию до того, как тратить время на рамку. Если ваш случай в правой колонке — возьмите указанную альтернативу.
| Ситуация | Подходит? | Что взять вместо |
|---|---|---|
| Проект внедрения или интеграции | Да | — |
| Нужно приоритизировать риски | Вместе с | Risk Matrix |
| Нужно найти риски до старта | Перед журналом | Pre-mortem |
| Поток мелких задач команды | Нет | Kanban |
| Сделка в продаже | Частично | Совместный план действий |
Как устроено
| Тип | Определение | Пример | Что делать |
|---|---|---|---|
| Риск | Может случиться и повлиять на проект | Ключевой инженер клиента может уйти в отпуск | Профилактика и ранний сигнал |
| Допущение | Считаем верным без проверки | Серверы клиента готовы к установке | Проверить к сроку, иначе — риск |
| Проблема | Уже случилось и мешает | Доступы не предоставлены | Решить, назначить владельца и срок |
| Зависимость | Результат зависит от другого | Поставка лицензий от вендора | Отслеживать и подтверждать сроки |
Как применять
- Создайте журнал в общем месте, доступном команде и, по возможности, клиенту.
- На старте внесите допущения из предложения и плана — их обычно больше, чем кажется.
- У каждой записи должны быть владелец, срок и статус.
- Разбирайте журнал на каждом статусе: новые записи, изменения, закрытые.
- Допущения, не подтверждённые к сроку, переводите в риски.
- Отправляйте клиенту краткую выжимку после каждого статуса.
Пример: внедрение системы у клиента
В проекте внедрения в журнал на старте внесли восемь допущений, в том числе «клиент предоставит тестовую среду к третьей неделе». К сроку среда не была готова — допущение перевели в проблему, клиент получил письменное уведомление с влиянием на сроки.
Когда в конце проекта возник вопрос о сдвиге сроков, журнал показал, когда и почему он произошёл. Спор занял одну встречу вместо долгой переписки.
Где ломается
| Симптом | Причина | Что делать |
|---|---|---|
| Журнал ведёт один человек для себя | Нет общего доступа | Общий журнал, разбор на статусах |
| Записи без владельцев | Ответственность размыта | Владелец и срок обязательны |
| Допущения не проверяются | Их внесли и забыли | Срок проверки для каждого допущения |
| Журнал не видит клиент | Боязнь показать проблемы | Выжимка клиенту после статуса укрепляет доверие |
До и после
Рамка редко работает одна. Вот что обычно стоит перед ней и что после.
| Этап | Что делаем | Чем |
|---|---|---|
| До | Найти риски | Pre-mortem |
| Вместе | Оценить риски | Risk Matrix |
| Сама рамка | Вести журнал проекта | RAID Log |
| Вместе | Распределить ответственность | RACI |