RACI-матрица

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

Аудитория: PM, функциональные руководители, команда.

Статус: устоявшийся инструмент (PMBOK Guide, область Project Resource Management).

Не путать с: организационной структурой команд (формальная иерархия подчинения), моделью Митчелла-Агле-Вуда (приоритизация стейкхолдеров, а не распределение задач) и Job Description (описание должности, а не участие в конкретных работах).

Общее #

RACI-матрица — таблица распределения ответственности по задачам проекта: по строкам — задачи, по столбцам — роли, в клетках — буква, обозначающая тип участия. Название складывается из четырёх ролей: Responsible (исполнитель), Accountable (ответственный), Consulted (консультируемый) и Informed (информируемый).

RACI — наиболее распространённая форма матрицы назначения ответственности (RAM, Responsibility Assignment Matrix). Обобщённая идея RAM известна с середины XX века: матрицы «задачи × исполнители» применялись в крупных инженерных и оборонных программах, где количество участников и параллельных работ превышало возможности неформального распределения обязанностей. Точный первоисточник не зафиксирован — инструмент вырос из практики организационного проектирования, а аббревиатура RACI закрепилась в управленческом консультировании к 1980-м годам. Позднее матрица вышла за пределы отдельных проектов: в портфельном управлении RACI используют для распределения ответственности между управляющими структурами портфеля и программ (Kendall, Rollins. Advanced Project Portfolio Management and the PMO, 2003).

В стандартах PMI матрица занимает определённое место: PMBOK Guide (6-е издание, 2017) включает RAM в область знаний «Управление ресурсами проекта» (Project Resource Management) как инструмент процесса планирования управления ресурсами и приводит RACI в качестве канонического примера RAM. В седьмом издании (2021), построенном вокруг принципов и доменов производительности вместо процессов, матрицы ответственности упоминаются среди методов работы с командой — сам инструмент за десятилетия практики не устарел и не был заменён.

Краткая история #

Идея табличного закрепления обязанностей старше самой аббревиатуры. В 1950–60-е годы в американских аэрокосмических и оборонных программах (где параллельно родились PERT и сетевое планирование) матрицы «работы × подразделения» использовались для координации тысяч исполнителей — бумажные предки современной RAM. Параллельно организационные социологи разрабатывали матричные схемы распределения прав и ответственности (распределение решений по уровням: «утверждает — согласует — исполняет — информируется»), из которых выросла буква не только RACI, но и родственных вариаций.

Собственно аббревиатура RACI распространилась в 1970–80-е через управленческий консалтинг и внутренние стандарты корпораций. С 1990-х инструмент вошёл в учебники проектного управления, а с выходом PMBOK Guide получил статус стандартизованного: третье издание (2004) уже упоминает RAM, шестое (2017) прямо иллюстрирует её RACI-примером. С распространением Agile-методологий отношение к матрице уточнилось, но не стало негативным: RACI сместилась с уровня задач на уровень ролей фреймворка и кросс-командных взаимодействий (подробнее — в разделе «Применение в Agile»).

Матрица решает одну из самых частых организационных проблем проекта — неопределённость ответственности. Типичные симптомы, при которых RACI полезна:

• две команды независимо делают одну и ту же работу (дублирование);
• задача «повисает», потому что каждый считал её чужой («дыра» в ответственности);
• решение не может быть принято, потому что «утверждающих» несколько и они спорят;
• исполнитель сделал работу, но никто не принял и не подписал результат;
• людей, которых «забыли предупредить», узнают о результатах последними.

Ключевой принцип инструмента: у каждой задачи — ровно один Accountable. Это главный инвариант RACI, из которого следуют все остальные правила: ответственность не должна фрагментироваться между несколькими людьми, но и безымянной остаться не должна. Если в строке два и более A — возникает конфликт полномочий; если ни одного — задача «ничья», и ответственность за неё фактически несёт тот, кто забыл её назначить.

Вторая важная особенность: RACI распределяет роли, а не людей. Человек может играть несколько ролей (PM нередко одновременно A по управлению рисками и R по составлению плана коммуникаций), и одну роль могут попеременно занимать разные люди. Поэтому столбцы матрицы — это роли («Tech Lead», «QA», «Бизнес-аналитик»), а не фамилии, хотя на практике для небольших команд допустим столбец-человек с оговоркой, что при ротации буква переходит вместе с ролью, а не с фамилией.

Наконец, RACI не следует путать с оргструктурой: оргструктура отвечает на вопрос «кому кто подчиняется», RACI — «кто участвует в какой работе и в каком качестве». Человек может быть A по задаче, которую выполняет сотрудник другого подразделения, не находящийся у него в подчинении. Матрица ответственности и оргструктура дополняют друг друга: первая описывает участие в работах, вторая — административные линии; конфликт между ними (например, A не имеет формальных полномочий над R) — повод пересмотреть либо матрицу, либо полномочия.

Когда RACI нужна, а когда избыточна #

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

Избыточна матрица в маленьких командах с устоявшимся разделением труда: три человека, полгода работающие вместе, распределяют ответственность разговором за минуты, и формализация не добавит информации. Отдельная зона риска — стабильные процессы с регламентами (бухгалтерия, эксплуатация), где ответственность уже закреплена процедурами; дублирующая RACI начнёт конкурировать с регламентом. Во всех этих случаях достаточно короткой матрицы верхнего уровня — или никакой.

Место матрицы в документации проекта:

• исходный перечень задач берётся из декомпозиции работ (WBS — Work Breakdown Structure) или дорожной карты;
• перечень ролей — из анализа стейкхолдеров и штатного расписания;
• ключевые роли верхнего уровня фиксируются в уставе проекта, детальная RACI живёт приложением к плану управления проектом или ресурсами;
• буквы C и I превращаются в строки плана коммуникаций: кого консультировать в ходе работы и кого информировать о результате.

Четыре буквы RACI #

R — Responsible (Исполнитель) #

Исполнитель — тот, кто делает работу: пишет код, проводит анализ, готовит документ. У задачи может быть несколько R: разработку функции ведут три разработчика, текст устава пишет PM вместе с аналитиком. Единственное требование — хотя бы один R в строке: задача без исполнителя не выполняется сама.

R — это про труд, а не про принятие результата. Исполнитель не утверждает готовую работу и не отвечает за неё перед заказчиком — он отвечает за то, чтобы работа была сделана. Смешение R с A приводит к двум характерным сбоям, разобранным в разделе «Критика и типичные ошибки».

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

A — Accountable (Ответственный) #

Ответственный — тот, кто принимает и подписывает результат и отвечает за успех задачи перед проектом: «с кого спросят», если задача провалена. Правило RACI: ровно один A на задачу. Несколько исполнителей — допустимо, несколько ответственных — нет: при двух A каждый предполагает, что подстрахует другой, и в итоге не отвечает никто. Формула классической управленческой мудрости «если за задачу отвечают двое — не отвечает никто» здесь превращена в конструктивное ограничение.

A может совмещаться с R в одной клетке (в матрице пишется «A, R»): небольшую задачу человек и делает, и закрывает. Чем крупнее задача, тем полезнее развести эти роли: ответственный контролирует ход и принимает результат, исполнитель — работает.

Проверочный вопрос для A: «может ли этот человек не принять работу, потребовать переделки — и его слово будет последним?» Если нет — это не Accountable, а наблюдатель.

Примеры: Tech Lead, принимающий архитектурное решение; PM, отвечающий за релиз перед спонсором; Product Owner, принимающий пользовательскую историю.

C — Consulted (Консультант) #

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

Роль C — самая дорогая в матрице: каждая консультация — это чьё-то время. Разумная матрица содержит немного C на задачу: двух-четырёх ролей обычно достаточно. Знак типичной ошибки: если роль стоит C, но к ней фактически не обращаются, буква стоит «для галочки» — честнее убрать её или перевести в I.

I — Informed (Информируемый) #

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

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

Различие C и I — это различие направления коммуникации: C — диалог «до и во время», I — монолог «после». Смешение этих ролей порождает либо срывы сроков (всех превращают в C и согласовывают всё со всеми), либо конфликты (кого-то «забыли» спросить, хотя он ждал, что его спросят). Практическое разделение: C участвует в создании результата, I — его потребитель.

Сводная таблица #

Как построить RACI-матрицу #

Шаг 1. Составить список задач #

Источники — WBS (иерархическая декомпозиция работ), дорожная карта, бэклог продукта, реестр процессов проектного управления. Уровень детализации определяет применимость матрицы: слишком мелкие задачи превращают RACI в микроменеджмент, слишком крупные — в бессмыслицу («разработка» из одной строки не распределяет ничего). Рабочее правило — задачи того же уровня, что и в расписании или бэклоге верхнего уровня: от 10 до 50 строк.

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

Шаг 2. Составить список ролей #

Столбцы — роли, а не люди: «PM», «Tech Lead», «QA», «Представитель бизнеса». Роль переживает отпуск, ротацию и увольнение; фамилия в шапке таблицы превращает матрицу в персональное расписание, которое устаревает при первом же кадровом изменении. Количество ролей — 4–8: при большем числе матрица становится нечитаемой; «всех остальных» разумно собрать в агрегированные столбцы («Смежные команды», «Спонсор»).

Здесь же решается вопрос охвата: включает ли матрица внешних участников (заказчика, подрядчиков, регулятора). Общее правило — включать те внешние роли, которые участвуют в решениях (C) или потребляют результаты (I); чисто административные контакты в матрице не нуждаются.

Шаг 3. Заполнить клетки #

Для каждой пары «задача × роль» проставляется буква (или пусто, если роль в задаче не участвует). Порядок заполнения: сначала A (кто принимает результат), затем R (кто делает), затем C и I. Работать лучше в фасилитационной сессии с участниками — матрица, составленная PM в одиночку за столом, отражает его представления, а не договорённости команды, и не получит признания.

Формат сессии: задачи выводятся списком, для каждой строки участники отвечают на два вопроса — «кто примет результат?» и «кто будет делать?». Конфликты, вскрывшиеся на сессии (два претендента на A, задача без желающих R), — не сбой процесса, а его главный результат: именно их сессия и должна выявить.

Практика совмещения: A и R в одной клетке пишутся как «A, R» и означают, что роль и делает работу, и закрывает её. Это нормально для небольших задач и технических ролей.

Шаг 4. Проверить матрицу #

Заполненная матрица прогоняется через набор проверок (sanity checks, см. раздел «Правила и проверки»): один A на строку, минимум один R на строку, отсутствие перегруженных колонок, осмысленность C и I. Проверка — не формальность: именно на этом шаге всплывают дыры в ответственности и узкие места.

Дальше матрица публикуется, согласуется и живёт: пересматривается при изменении состава работ, реорганизации команды или по расписанию (например, раз в квартал). Технически матрицу ведут в таблице, вики-странице (Confluence и аналоги) или приложением к плану проекта; критерий выбора инструмента один — матрица должна быть доступна всем участникам в актуальной версии.

Чек-лист построения #

• Список задач одного уровня детализации, 10–50 строк.
• Столбцы — роли, не фамилии; 4–8 столбцов.
• Клетки заполнены в порядке A → R → C → I, лучше на совместной сессии.
• Каждая строка проверена: ровно один A, минимум один R.
• Каждая колонка проверена: нет перегруза по R/A, нет колонок из одних I.
• У матрицы есть владелец и дата актуальности.
• Матрица доступна участникам и связана с планом коммуникаций.

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

Проект разработки нового веб-сервиса: пять ролей — PM, Tech Lead (TL), бизнес-аналитик (BA), разработчики (Dev), тестировщики (QA). Десять укрупнённых задач:

Как читать пример:

• Каждая строка содержит ровно один A (в двух случаях совмещённый с R) и минимум один R — базовый инвариант соблюдён.
• Пустые клетки допустимы: QA не участвует в уставе, PM — в дизайне API. Матрица не обязана быть заполненной целиком; «принудительное участие» искажает картину.
• Совмещение A и R встречается там, где масштаб задачи не требует отдельного приёмщика: архитектурные решения Tech Lead и делает, и утверждает.
• Разделение A и R показано в строках 4, 5 и 8: дизайн API делает Dev, но принимает TL; деплой выполняет TL, но ответственность перед проектом несёт PM. Это защита от конфликта интересов: человек, делающий работу, не должен единолично подписывать её результат там, где цена ошибки высока.
• Распределение A по колонкам: PM — Accountable в пяти строках, но это «его природные» зоны (устав, релиз, коммуникации, риски); TL — A в трёх. Если бы A по разработке стоял у одного Dev на двадцати строках, матрица сигнализировала бы о перегрузе (см. следующий раздел).

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

Адаптация под контекст:

• внешний проект добавляет столбцы «Заказчик» и «Подрядчик»: заказчик обычно C по требованиям и I по приёмкам, подрядчик — R по своим работам;
• матричная организация — столбцами становятся руководители функциональных направлений, и матрица фиксирует разграничение проектного и функционального подчинения;
• компактные команды наоборот укрупняют: пять ролей сводятся к трём (например, BA входит в Dev-колонку), чтобы таблица оставалась читаемой, а не «правильной».

Правила и проверки (sanity checks) #

Заполненная матрица проверяется по строкам (задачи) и по столбцам (роли). Основные проверки:

Разбор проверок по смыслу:

• Один A. Это структурная проверка: она ловит не ошибки заполнения, а ошибки управления. Задача без A — область, про которую проект молчит; задача с двумя A — область, в которой рано или поздно столкнутся два полномочия. Оба случая дешевле найти в таблице, чем в кризисе.
• Минимум один R. Задача с A, но без R — «приёмка без работы»: ответственный есть, исполнителя нет. Так часто выглядят задачи, которые все считают чужими: A назначен формально, а выполнения никто не ведёт.
• C/I в строке. Строка из одних A и R — работа в изоляции. Иногда это корректно (локальный рефакторинг), но для задач, меняющих общие контракты или видимых заказчику, отсутствие C и I — надвигающийся конфликт.
• Колонка из I. Роль, которую только информируют, — не участник работ, а адресат рассылки. Оставлять её в матрице — значит размывать понятие ответственности. Исключение — спонсор на верхнем уровне матрицы: его I — осознанное управленческое решение.
• Перегруз колонки. Считается по R и A: эти буквы требуют времени и внимания. Колонка, где R или A стоит в большинстве строк, — узкое место проекта; матрица позволяет увидеть это до того, как очередь на утверждение станет графиком задержек.

Дополнительные практические проверки:

• Доля клеток с A — обычно не больше 10–15 % всех заполненных клеток: A — редкая роль по определению.
• Строки с A, R у одной роли и полным набором C у остальных — признак псевдосогласования: согласующих много, решение всё равно принимает один.
• Повторяющиеся комбинации одинаковых строк (у всех задач одна и та же раскладка) — матрицу можно укрупнить: несколько задач с одинаковой конфигурацией ролей сводятся в одну строку.

Разбор дефектных строк #

Как выглядят ошибки в живой матрице:

Проверки имеет смысл выполнять вдвоём: PM смотрит строками (полнота задач), функциональный руководитель — колонками (реалистичность загрузки).

Вариации RACI #

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

RASCI #

Добавляется буква S — Support (Поддержка): те, кто помогает исполнителю (выделяет ресурсы, выполняет вспомогательные операции), но не отвечает за результат. Полезна, когда важно отделить «делающих главное» от «обеспечивающих»: Dev — R, админы инфраструктуры — S. Обратная сторона — соблазн размазать ответственность: граница между R и S в спорных случаях проводится вопросом «чья фамилия стоит в задаче».

RACI-VS #

Добавляются V — Verifier (Проверяющий) и S — Signatory (Подписант): Verifier проверяет соответствие результата стандартам и регламентам, Signatory ставит формальную подпись (акты, регуляторные документы). Вариация возникла в регулируемых отраслях — фармацевтика, авиация, оборонные контракты, — где приёмка результата и юридическое утверждение разделены по нормативным требованиям: принял работу один человек, а подписал документ другой, и оба несут различные виды ответственности.

DACI #

Популяризирована Atlassian: Driver (ведущий, «тянет» решение), Approver (утверждающий — ровно один), Contributor (вкладчики-эксперты), Informed (информируемые). Отличие от RACI — акцент на принятии решений, а не на выполнении работ: DACI-матрица отвечает на вопрос «кто и как принимает это решение», поэтому её естественный масштаб — отдельное решение или класс решений (выбор технологии, изменение цены, приём крупного клиента), а не план проекта. Driver в DACI ближе к R (ведёт работу над решением), Approver — единственный A.

PARIS #

Расшифровывается как Participant (участник), Accountable (ответственный), Review (рецензент), Input (поставщик входных данных), Sign-off (подписант). Вариация подчёркивает входы и рецензирование: отдельно фиксируется, от кого исполнитель получает исходные данные и кто рецензирует результат до утверждения. Встречается реже прочих, в основном в корпоративных стандартах отдельных компаний.

Когда использовать расширенные варианты #

Практическое правило: расширять алфавит стоит только при наличии требования, которое базовая RACI не отражает, — каждая дополнительная буква увеличивает стоимость ведения матрицы и число споров о классификации. Начинать разумно с RACI и уточнять, если реальные конфликты показывают, какой именно роли не хватает.

Типичная эволюция в организации: проектные команды живут на базовой RACI; офис управления проектами (PMO) ведёт реестр решений в DACI; регулируемые или контрактные производства добавляют Verifier/Signatory. Смешение всех алфавитов в одной таблице — антипаттерн: чем больше букв, тем меньше вероятность, что матрицу кто-то прочитает без переводчика.

Применение в Agile #

RACI в Scrum #

Scrum уже содержит встроенное распределение ответственности, которое можно описать как RACI:

Чтение таблицы:

• Product Owner — Accountable за ценность: порядок бэклога, состав релиза, критерии приёмки — его зона единоличной ответственности (и одновременно R по содержанию бэклога);
• Scrum Master — Accountable за процесс: эффективность Scrum, фасилитация событий, устранение препятствий;
• Команда разработки — Responsible за доставку инкремента; за технические решения команда отвечает коллективно — A здесь не персона, а вся роль;
• стейкхолдеры — C и I: их консультируют на refinement и review, информируют о результатах спринта.

Уровень применения #

В Agile RACI работает на уровне инициатив, эпиков и кросс-функциональных активностей — «запустить платёжный шлюз», «миграция на новую инфраструктуру», «выход на рынок» — а не микро-задач из спринт-бэклога. Побуквенное распределение задач, которые команда сама разбирает на планировании, разрушает самоорганизацию — одно из базовых свойств Agile-команды, — и возвращает микроменеджмент под видом «прозрачности». Состав спринта и распределение задач внутри него — зона ответственности команды, зафиксированная одним A (коллективным или Tech Lead-ом в зависимости от культуры).

Рабочий горизонт RACI в Agile: строки — эпики, инициативы и «фоновые» обязанности (релизный поезд, поддержка, инциденты), столбцы — роли фреймворка и смежных функций. Такая матрица получается высотой в 10–20 строк и обновляется на плановых границах (квартал, релизный цикл).

Кросс-командные матрицы #

Наиболее полезна RACI в масштабном Agile: SAFe, LeSS, несколько команд над одним продуктом. Когда над эпиком работают три команды, вопросы «кто A за интеграцию», «кто R за общий контракт данных», «кого информировать о смене сроков» не решаются самоорганизацией отдельных команд — нужны явные соглашения поверх команд. Кросс-командная RACI на уровне эпика или программного инкремента закрывает именно эти щели: столбцами в ней выступают роли фреймворка (Product Management, System Architect, RTE, команды), строками — кросс-командные работы и зависимости.

Такая матрица — рабочий артефакт планирования (например, PI Planning в SAFe), а не административный документ: она пересматривается на каждой плановой сессии, и конфликты за букву A на ней — нормальная часть планирования, а не бюрократия.

Типичный фрагмент кросс-командной матрицы для эпика «Единый вход (SSO)», над которым работают команда фронта, команда бэкенда и платформенная команда:

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

Критика и типичные ошибки #

RACI «в столе» #

Самая частая судьба матрицы — быть составленной, согласованной и положенной в папку. Признаки: фактические решения противоречат матрице, при конфликтах на неё не ссылаются, новые участники проекта о ней не знают. Причины — матрицу составили в одиночку, не провели сессию с участниками, не назначили владельца документа и не встроили её в процесс (ссылка из задач трекера, чек-пункт на статус-встречах). Лечение простое: матрица должна быть местом, куда смотрят при споре об ответственности, — иначе она не работает. Мерило живости — спор «посмотрим в RACI» должен решать конфликт, а не порождать второй.

Признаки живой матрицы, в отличие от «стольной»:

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

Перегрузка Accountable #

«Один руководитель — A по ста задачам» — матрица честно показывает узкое место: все решения и приёмки стекаются к одному человеку, очередь на его утверждение становится ограничением скорости проекта. Санити-правило: количество зон, где человек единственный A, — порядка 5–9; остальное делегируется (A сдвигается вниз по цепочке, а бывший A становится C или I). Игнорирование перегрузки превращает RACI из инструмента разгрузки в её фиксацию.

Путаница R и A #

Классическая ошибка — считать A «главным исполнителем». Accountable не делает работу, а принимает её и отвечает за результат; смешение ролей даёт два симметричных сбоя. Руководитель, ставящий себе A и R везде, — микроменеджер и узкое место; исполнитель с A, у которого нет полномочий принимать результат (включать его в релиз, подписывать акт), — «стрелочник», отвечающий за то, на что он не влияет. Проверочный вопрос тот же: «чьё слово последнее при приёмке?» Если ответ не совпадает с буквой A — матрица врёт.

Игнорирование ротации и устаревания #

Матрица описывает момент запуска проекта. Через полгода состав работ, команда и структура изменились, а таблица осталась прежней — и уже дезинформирует. Практика: у документа есть владелец (обычно PM) и расписание ревизии; триггеры пересмотра — кадровая ротация, смена этапа проекта, реорганизация, новые классы задач. Поскольку столбцы — роли, а не фамилии, плановая ротация людей минимально травмирует матрицу; смена структуры ролей требует её переработки. Полезная дисциплина — дата актуальности прямо в документе: устаревшая без даты матрица выглядит действующей.

Границы применимости #

RACI не заменяет другие управленческие инструменты: она не описывает нагрузку во времени (для этого нужны ресурсные планы и гистограммы загрузки), не задаёт требования к компетенциям (это Job Description и матрицы навыков), не определяет подчинённость (это оргструктура) и не приоритизирует стейкхолдеров (это модель Митчелла-Агле-Вуда). Ожидание от RACI того, чего она не делает, — источник разочарования в инструменте, а не его дефект.

Отдельная линия критики — жёсткость: противники инструмента указывают, что формализация ролей противоречит самоорганизации и скорости изменений. Ответ практики — в уровне применения (см. раздел «Применение в Agile»): RACI на эпиках и кросс-командных зависимостях усиливает команду, снимая споры о границах; RACI на задачах дня — действительно душит инициативу.

Заключение #

RACI-матрица — простой табличный инструмент с одним жёстким правилом и набором проверок. Сильные стороны и ограничения резюмируются четырьмя тезисами:

• Главный инвариант — ровно один Accountable на задачу: ноль A — дыра в ответственности, два и больше — конфликт полномочий.
• RACI распределяет роли, а не людей: человек играет несколько ролей, роль переходит к другому человеку; поэтому столбцы матрицы — роли.
• Матрица нуждается в проверке: sanity checks (дыры, перегрузки, роли «для галочки») — обязательный шаг, а не формальность.
• В Agile RACI применяется на уровне ролей фреймворка и кросс-командных работ (эпиков, инициатив), а не задач спринта.

При соблюдении этих правил RACI даёт проекту то, ради чего создавалась: однозначный ответ на вопрос «кто за что отвечает».

См. также #

• Модель Митчелла-Агле-Вуда — приоритизация стейкхолдеров, перечень которых ложится в основу столбцов матрицы.
• План коммуникаций — куда превращаются роли C и I: кого консультировать, кого информировать.
• Устав проекта — фиксация ключевых ролей и полномочий, детализируемых затем в RACI.
• Scrum — встроенное распределение ответственности между Product Owner, Scrum Master и командой.
• Организационная структура команд — формальная иерархия, которую RACI дополняет, но не заменяет.