RACI-матрица

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

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

Типичная проблема без RACI выглядит так:

Все считали, что этим занимается кто-то другой.

RACI превращает это «кто-то» в явную схему.

Расшифровка RACI

R — Responsible

Исполнитель.

Тот, кто непосредственно выполняет работу:

  • пишет код;
  • готовит документ;
  • проводит тестирование;
  • настраивает инфраструктуру;
  • собирает требования;
  • исправляет дефект.

Для одной задачи может быть несколько Responsible, хотя слишком большое количество исполнителей часто размывает фактическое владение.

A — Accountable

Тот, кто несёт окончательную ответственность за результат.

Он не обязательно выполняет работу своими руками, но именно он:

  • принимает итоговый результат;
  • утверждает решение;
  • отвечает за то, что задача действительно завершена;
  • принимает последствия ошибки;
  • имеет право сказать: «готово» или «не готово».

Для одной задачи обычно должен быть один Accountable.

Это центральное правило RACI.

Если Accountable несколько, возникает раскол ответственности:

«Я думал, что последнее решение принимает он».

Если Accountable нет, задача становится бесхозной.

Различие между R и A принципиальное:

  • R делает;
  • A отвечает за конечный результат.

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

C — Consulted

Тот, с кем нужно проконсультироваться до принятия решения или завершения работы.

Это двустороннее взаимодействие:

  • ему показывают решение;
  • у него спрашивают мнение;
  • он предоставляет экспертизу;
  • его ответ может повлиять на результат.

Примеры:

  • специалист по безопасности;
  • архитектор;
  • юрист;
  • владелец соседнего сервиса;
  • DBA;
  • представитель бизнеса.

Consulted не обязательно утверждает решение. Он помогает избежать ошибки в области, где обладает значимой экспертизой.

I — Informed

Тот, кого нужно проинформировать.

Он не участвует в обсуждении и не принимает решение. Ему сообщают:

  • что задача начата;
  • что решение принято;
  • что произошли изменения;
  • что задача завершена;
  • что появился риск или задержка.

Это односторонняя коммуникация.

Разница между C и I:

  • C: мы ждём от человека обратную связь;
  • I: мы только сообщаем ему результат или статус.

Пример RACI-матрицы

Допустим, команда внедряет авторизацию через SSO.

Задача Product Owner Tech Lead Backend Developer Security Engineer DevOps
Определить бизнес-требования A C I C I
Спроектировать интеграцию C A/R R C C
Реализовать backend I A R C I
Проверить безопасность I C R A/R I
Настроить production I C C C A/R
Сообщить о запуске A/R I I I I

Например, в строке «Реализовать backend»:

  • Backend Developer является R, потому что пишет код;
  • Tech Lead является A, потому что отвечает за технический результат;
  • Security Engineer является C, потому что консультирует по безопасности;
  • Product Owner и DevOps являются I, потому что им достаточно знать статус и результат.

Как читать RACI-матрицу

По горизонтали находятся участники или роли.

По вертикали находятся:

  • задачи;
  • решения;
  • этапы;
  • документы;
  • результаты;
  • зоны процесса.

В каждой клетке указывается одна или несколько букв:

  • R;
  • A;
  • C;
  • I;
  • иногда A/R, когда один человек одновременно выполняет работу и отвечает за неё.

Что именно описывает RACI

RACI не отвечает на вопрос:

Кто выше по должности?

Она отвечает на другой вопрос:

Как распределено участие людей в конкретном результате?

Например, Engineering Manager может быть руководителем разработчика, но в конкретном архитектурном решении:

  • разработчик может быть R;
  • архитектор — A;
  • Engineering Manager — I.

То есть организационная иерархия и RACI-распределение не обязаны совпадать.

Зачем RACI нужна

1. Устранить бесхозные задачи

Если у задачи нет A, никто окончательно за неё не отвечает.

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

2. Разделить исполнение и ответственность

Человек, который выполняет работу, не всегда должен самостоятельно утверждать собственный результат.

Например:

  • разработчик реализует миграцию;
  • DBA проверяет её;
  • Tech Lead отвечает за техническое решение;
  • Product Owner отвечает за допустимость бизнес-последствий.

RACI показывает, где заканчивается исполнение и начинается ответственность за решение.

3. Предотвратить коллективную безответственность

Фраза:

За это отвечает вся команда.

часто означает:

Персонально за это не отвечает никто.

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

4. Снизить количество лишних согласований

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

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

Давайте ещё согласуем с архитектурой, безопасностью, эксплуатацией, аналитиками, платформенной командой и владельцем соседнего продукта.

RACI помогает заранее установить, кто действительно консультирует, а кого достаточно проинформировать.

5. Сделать явными права принятия решений

Ответственность без права решения является фикцией.

Если человек обозначен как A, но не может:

  • выбрать вариант;
  • отклонить результат;
  • остановить запуск;
  • изменить приоритет;
  • потребовать исправления;

то фактически он не Accountable, а декоративный носитель ответственности.

Хорошая RACI-матрица

У каждой строки обычно должно быть:

  • хотя бы одно R;
  • ровно одно A;
  • только необходимые C;
  • разумное количество I.

Пример нормальной строки:

Задача Разработчик Tech Lead Security Product Owner
Реализовать API оплаты R A C I

Плохая RACI-матрица

Задача Разработчик Tech Lead Архитектор Manager Product Owner
Реализовать API оплаты R A A A A

Здесь четыре Accountable.

На бумаге ответственность распределена широко. В реальности она уничтожена.

Другой плохой вариант:

Задача Разработчик Tech Lead Security Product Owner
Реализовать API оплаты R C C I

Здесь нет A. Код кто-то пишет, но окончательного владельца результата нет.

RACI и управление ИТ-проектом

В разработке RACI особенно полезна на границах команд и систем.

Например, при запуске нового сервиса нужно явно определить:

  • кто проектирует архитектуру;
  • кто создаёт инфраструктуру;
  • кто отвечает за безопасность;
  • кто проводит нагрузочное тестирование;
  • кто принимает решение о production-запуске;
  • кто отвечает за rollback;
  • кто уведомляет пользователей;
  • кто становится владельцем сервиса после запуска.

Без этого легко возникает архитектурная щель:

Команда разработки считала, что мониторинг настроит DevOps.
DevOps считал, что мониторинг входит в Definition of Done команды разработки.
После запуска сервис упал, но ответственность обнаружилась только постфактум.

RACI позволяет увидеть эту щель до запуска.

RACI не является планом проекта

Она не показывает:

  • сроки;
  • последовательность задач;
  • зависимости;
  • объём работы;
  • статус выполнения;
  • трудозатраты;
  • критический путь.

Для этого нужны другие инструменты:

  • roadmap;
  • Gantt chart;
  • Kanban board;
  • backlog;
  • dependency map;
  • project plan.

RACI отвечает только за слой ролей и ответственности.

RACI не является организационной структурой

Оргструктура говорит:

Кто кому подчиняется.

RACI говорит:

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

Один человек может быть:

  • A в одной задаче;
  • R в другой;
  • C в третьей;
  • I в четвёртой.

Главная логика RACI

RACI разделяет четыре разных действия, которые в обычной речи часто сливаются в слово «отвечает»:

  1. выполняет работу;
  2. несёт окончательную ответственность;
  3. участвует экспертизой;
  4. получает информацию.

Именно это различение является основной ценностью матрицы.

Без него фраза «задача на Петрове» ничего не говорит:

  • Петров должен сделать её сам?
  • Он должен только утвердить?
  • С ним нужно посоветоваться?
  • Его нужно просто уведомить?

RACI разбирает эту туманную конструкцию на явные роли.

Формула для запоминания

  • R — делает
  • A — отвечает за итог
  • C — консультирует
  • I — информируется
Прокрутить вверх