Шаблон журнала RAID Permalink

Переведено ИИ
· Смотреть на английском

Используйте этот Шаблон, чтобы вести журнал RAID в Quire: храните риски, допущения, проблемы и зависимости в одном месте, расставляйте приоритеты по влиянию в Табличном виде и проводите еженедельно проверку, которая действительно закрывает вопросы.

Вы можете перейти в проект RAID Log и Дублировать его в свою рабочую область — не нужно строить всё с нуля.

Вы также можете просмотреть другие готовые шаблоны, которые ускорят ваш рабочий процесс.

Понимание журналов RAID

RAID расшифровывается как Risks, Assumptions, Issues and Dependencies — риски, допущения, проблемы и зависимости. Журнал RAID — это постоянно обновляемый реестр всех четырёх: что может пойти не так, на что команда делает ставку, не проверив, что уже пошло не так, и что нужно от людей за пределами команды.

Большинство команд отслеживают часть этого где-то. Очень немногие собирают всё четыре в одном месте — а именно здесь и кроется ценность. Отсутствующий бюджетный код выглядит как небольшая административная проблема ровно до тех пор, пока не выясняется, что именно по этой причине поставщик не выдаёт учётные данные, а именно поэтому соглашение о запуске до сих пор не подписано. Одна первопричина, три разных списка, и никто их не связывает.

Журнал структурирован как пять разделов, с вехой, закреплённой вверху, чтобы каждая дата ниже читалась относительно ключевого дедлайна.

разделы шаблона журнала RAID для рисков, допущений, проблем и зависимостей в Quire


Четыре раздела содержат сами Категории. Пятый, раздел управления RAID, определяет регламент проверок — именно он решает, переживёт ли журнал второй месяц. Двадцать одна образцовая запись уже заполнена, чтобы вы могли увидеть структуру качественного описания, прежде чем заменять их своими.

Журнал RAID или реестр рисков

Quire предоставляет оба инструмента, и они отвечают на разные вопросы. Реестр рисков — глубокий инструмент для одной категории: матрица 5×5, числовые оценки рисков, пять формальных стратегий реагирования и регламент проверок — всё Под риском. Журнал RAID — более поверхностный инструмент для четырёх категорий: оценивает риск лишь по вероятности и влиянию, но охватывает допущения и зависимости, которым в реестре нет места.

Используйте журнал, когда нужно одно место для всего, что может поставить проект под угрозу. Используйте реестр, когда управление рисками — это основная задача и оценки должны быть защищаемы. Многие команды ведут оба инструмента: журнал как рабочую запись, реестр — как официальный артефакт.

Шаблон поставляется с документом, описывающим настройку, правила категорий и типичные ошибки, которых стоит избегать.

документ «как использовать этот журнал RAID» внутри шаблона Quire


Второй Документ содержит повестку еженедельной проверки, чтобы ведущий совещания не придумывал порядок обсуждения утром того же дня.

Как отличить четыре категории друг от друга

Категории постоянно путают, и спор о том, к какой из них относится та или иная запись, — верный способ потратить первые десять минут проверки впустую. Четыре теста разрешают почти все подобные ситуации.

Категория Время На какой вопрос отвечает Тест
Риск Будущее, неопределённость Что может пойти не так? Можно ли записать это как «если X, то Y»?
Допущение Настоящее, непроверенное На что мы делаем ставку? Вы были бы удивлены, если бы это оказалось ложным?
Проблема Настоящее, определённость Что сейчас идёт не так? Это уже произошло?
Зависимость Будущее, чужая ответственность Что нам нужно от других? Следующее действие находится вне вашей команды?

Три правила решают остальное.

  1. Реализовавшийся риск — больше не риск. Перенесите его в раздел проблем и закройте запись о риске с пометкой, куда она перемещена, — не оставляйте открытым в обоих местах.
  2. Допущение, оказавшееся ложным, — не просто ошибка: оно влечёт последствие. Закройте допущение и зафиксируйте это последствие как риск или проблему.
  3. Зависимость, которую вы перестали преследовать, — это риск. Пересчитайте её оценку при ежемесячной очистке.


Образцовая запись A-01 в шаблоне — это проработанный пример второго правила, привязанный к возникшей проблеме.

Работа с журналом в Табличном виде

Табличный вид доступен только в планах Professional, Premium, Enterprise. Подробности — на нашей странице тарифов.

Табличный вид — это и есть журнал RAID в полном смысле. Он отображает все пользовательские поля рядом с записью, а сортировка по влиянию превращает верхнюю часть списка в повестку совещания.

журнал RAID в Tabличном виде Quire с колонками RAID ID, тип, вероятность, влияние и дата последней проверки


Семь полей ведут журнал.

Поле Назначение
RAID ID Стабильный идентификатор, например R-01 или D-05, чтобы участники совещания могли ссылаться на запись, не зачитывая заголовок. Никогда не используйте номер повторно, даже после закрытия записи.
Тип Намеренно дублирует раздел. Разделы организуют список; Тип позволяет фильтровать, группировать или выбирать одну категорию в рамках портфеля.
Вероятность Только для рисков. Проблемы уже произошли, поэтому для них колонка остаётся пустой.
Влияние Применяется ко всему. Именно эту колонку сортируют и именно она определяет, что эскалируется.
Дата создания Когда запись была зафиксирована.
Последняя проверка Поле, которое выявляет запущенность. Отсортируйте по нему при ежемесячной очистке и работайте снизу вверх, начиная с самых старых.
Зависит от Указывает команду, поставщика или человека, несущего ответственность. В основном используется для зависимостей, но полезно везде, где запись застряла за пределами вашего контроля.

Дата создания и дата последней проверки выглядят как бюрократия. Но запись, созданная в марте, проверенная в апреле и по-прежнему открытая в сентябре, не управляется — и только эти две даты позволяют увидеть этот факт, не замечая его случайно.

Примечание: Если вы обнаруживаете, что заполняете поле «Вероятность» для проблемы, скорее всего, это риск, который не был переклассифицирован. Проблемы уже произошли, поэтому их вероятность равна ста процентам.

Восемь меток охватывают все четыре категории: Бюджет, Планирование, Технический аспект, Объём, Клиент, Поставщик, Персонал и Соответствие. Они отвечают на другой вопрос, нежели Тип: не что это такое, а откуда это возникло.

Как написать запись, которая будет полезна

Разница между полезным журналом RAID и артефактом для галочки почти целиком определяется тем, как написаны записи. Каждая образцовая запись в шаблоне следует одной и той же четырёхчастной структуре.

запись о риске в журнале RAID в Quire с формулировкой «если — то», влиянием, ответом и триггером


Описание начинается с формулировки «если X, то Y», затем указывает последствие в единицах, которые кого-то волнуют, затем называет ответное действие и, наконец, задаёт триггер для наблюдения. Работа по снижению риска фиксируется в записи как подзадачи, так что план и запись хранятся в одном месте.

Пять правил определяют качество.

  • Формулируйте риски как причину и следствие. «Задержка поставщика» — это тревога. «Если поставщик не выполнит обязательства к 6 августа, то тестирование аутентификации начнётся без рабочих учётных данных и тестирование сдвинется на две недели» — это то, с чем команда может работать.
  • Дайте каждому риску триггер. Наблюдаемый момент, при котором риск перестаёт быть гипотетическим. Без триггера эскалация происходит поздно и на ощущениях.
  • Назовите ответное действие. Избежать, снизить, передать или принять. «Мониторинг» — это не ответное действие, а способ написать «мы ещё не решили».
  • Указывайте влияние в единицах, которые кого-то волнуют. Недели, деньги, клиенты, репутация. «Высокое влияние» ничего не говорит спонсору.
  • Ставьте дату на всё. Запись без срока не будет проработана никогда.


Назначайте одного конкретного человека на каждую запись. Команда никогда ничего не преследует, потому что никто в ней не считает эту задачу конкретно своей.

Отслеживание движения в виде Доски

Вид Доски с группировкой по статусу показывает движение, а не инвентарь — это другая и более честная картина.

записи журнала RAID, сгруппированные по статусу на Доске Quire с колонкой «Эскалировано»


Шесть статусов ведут журнал.

Статус Когда использовать
Открыто Зафиксировано и назначено, но работа ещё не начата.
В работе Кто-то активно занимается этим вопросом.
Эскалировано Вопрос вышел за рамки команды проекта и требует решения на более высоком уровне.
Ожидание ответа Мяч действительно на стороне другого человека.
Закрыто Решено, снято с повестки или утратило актуальность.
Подтверждено Допущение проверено и признано верным.

«Ожидание ответа» — это статус, который оправдывает своё существование. Без него «В работе» приходится охватывать и «я работаю над этим», и «я отправил письмо девять дней назад», хотя эти два состояния требуют совершенно разных последующих действий.

Совет: Наблюдайте за колонкой «Эскалировано» на протяжении нескольких недель, а не читайте её однократно. Если она заполняется быстрее, чем опустошается, — это более надёжный сигнал о состоянии проекта, чем любой отчёт о статусе.

Сквозные представления с помощью Подсписков

В плане Free Subscription вы можете создать два подсписка для каждого проекта, а этот шаблон поставляется с 4. После дублирования оставьте два, которые команда открывает чаще всего, или перейдите на более высокий план подписки, чтобы использовать все четыре. Подробности — на нашей странице тарифов.

Разделы отвечают на вопрос «что это за вид записи». Четыре Подсписки отвечают на вопросы, которые охватывают сразу все четыре категории — именно здесь ведение одного журнала вместо четырёх начинает приносить дивиденды.

  • Эскалировать сейчас — все записи с критическим влиянием, которые ещё открыты, независимо от категории. Это материал для руководящего комитета. Если список превышает примерно шесть позиций, проектом скорее наблюдают, чем управляют.
  • Ожидание чужого действия — всё, следующий шаг по чему не за вами. Открывайте перед каждым статус-коллом и преследуйте три верхние позиции.
  • Непроверенные допущения — список, который никто не читает, пока не становится слишком поздно. Зачитывайте вслух раз в квартал.
  • Цепочка поставщика — это проработанный пример, а не фильтр.


Последний стоит открыть первым, потому что он демонстрирует весь аргумент в пользу единого журнала в четырёх записях.

подсписок «цепочка поставщика», прослеживающий одну первопричину через три категории RAID в Quire


Незакрытый счёт на оплату — это проблема. Она блокирует согласование заказа финансами — это зависимость. Это блокирует поставку поставщиком рабочих учётных данных — ещё одна зависимость. И именно поэтому соглашение о запуске до сих пор не подписано — зафиксировано как риск. Три категории, одна первопричина, видимая только потому, что они живут в одном журнале. Записи связаны реальными зависимостями задач, поэтому цепочка соблюдается, а не просто описывается.

Поддержание честности журнала

Журнал без проверки — это Документ, а не процесс. Раздел управления содержит четыре Повторяющиеся задачи, чтобы ритм попадал в Планирование, а не зависел от чьей-то памяти.

Периодичность Что происходит
еженедельно 30-минутная проверка, отсортированная по влиянию. Верхняя часть списка — это повестка.
ежемесячно Закрыть устаревшие записи и пересчитать открытые риски. Риск, оценённый в марте, редко остаётся правильно оценённым в июле.
Ежеквартально Повторно проверить допущения. Это проверка, которую все пропускают, и именно она выявляет больше всего проблем.
По необходимости Эскалировать красные позиции в руководящий комитет.

Три причины объясняют большинство «мёртвых» журналов RAID, и их стоит назвать — они подкрадываются незаметно.

  1. Журнал превращается в кладбище. Пятьдесят открытых записей, большинство устарели, люди перестают его открывать. Запись, которую никто не трогал два месяца, либо не является реальной, либо за ней никто не следит.
  2. Всё отмечено как высокоприоритетное. Если весь журнал красный, он перестал что-либо ранжировать. Четыре критических записи из двадцати — это правдоподобный проект. Четырнадцать — это проект, о котором никто серьёзно не думал.
  3. Журнал обновляется только перед совещанием руководящего комитета. В этот момент он незаметно превращается из инструмента управления в отчётный.


У всех трёх одно и то же непривлекательное решение: короткая еженедельная проверка и агрессивное закрытие записей.

Читайте подробнее в нашем блоге о том, как оценивать риски и поддерживать реестр в рабочем состоянии.


Часто задаваемые вопросы

Что такое журнал RAID?

Журнал RAID — это единый постоянно обновляемый реестр: что может пойти не так, на что команда делает ставку без проверки, что уже пошло не так, и что нужно от людей за пределами команды. Хранить всё четыре в одном месте — это то, что позволяет увидеть, что разрозненные проблемы имеют одну первопричину.

Как расшифровывается RAID?

Risks, Assumptions, Issues and Dependencies — риски, допущения, проблемы и зависимости. Встречается и расшифровка Risks, Actions, Issues and Decisions, которая чаще используется в программном управлении. Шаблон Quire использует первый вариант, поскольку допущения и зависимости — это именно те категории, которые команды реже всего отслеживают где-либо ещё.

В чём разница между риском и проблемой?

Разница во времени и определённости. Риск — будущий и неопределённый, формулируется как «если X, то Y». Проблема — настоящая и определённая: она уже произошла. Когда риск реализуется, он перестаёт быть риском — перенесите его в раздел проблем и закройте запись о риске с пометкой, куда она перемещена.

В чём разница между журналом RAID и реестром рисков?

Реестр рисков — глубокий инструмент для одной категории: матрица 5×5 и формальные стратегии реагирования. Журнал RAID — более поверхностный инструмент для четырёх и охватывает допущения и зависимости, которым в реестре нет места. Многие команды ведут оба.

Кто отвечает за журнал RAID?

Менеджер проекта отвечает за сам журнал: за регулярность проверок, закрытие устаревших записей и эскалацию. Каждая отдельная запись требует одного конкретного человека — никогда команды, потому что команда никогда ничего не преследует.

Как часто следует проверять журнал RAID?

еженедельно — весь журнал, около 30 минут, отсортированный по влиянию. ежемесячно — закрывать устаревшие записи и пересчитывать открытые риски. Ежеквартально — повторно проверять допущения. Шаблон содержит все три проверки как Повторяющиеся задачи, чтобы они попадали в Планирование сами по себе.

Что должна содержать запись журнала RAID?

Стабильный идентификатор, например R-01, Категория, оценка влияния, один конкретный ответственный, Дата выполнения и письменный ответ. Риски дополнительно требуют вероятности и триггера — наблюдаемого момента, при котором риск перестаёт быть гипотетическим и кто-то обязан действовать.

Почему журналы RAID перестают быть полезными?

Три причины: журнал превращается в кладбище устаревших записей, всё помечается как высокоприоритетное и ничего не ранжируется, или журнал обновляется только перед совещанием руководящего комитета. Решение для всех трёх — короткая еженедельная проверка и агрессивное закрытие записей.

Есть ли готовый Шаблон журнала RAID в Quire?

Да. Перейдите в проект RAID Log и Дублируйте его в свою рабочую область — вы получите четыре раздела категорий плюс раздел управления, семь пользовательских полей, шесть статусов, восемь Меток, четыре сквозных Подсписки и двадцать одну образцовую запись, уже настроенных и готовых к работе.

Последнее обновление:

Пожалуйста свяжитесь с нами, если вам необходима дополнительная помощь.