Матрица RACI: полное руководство по распределению ответственности в проектах

Что такое матрица ответственности RACI: полное руководство по методике

Матрица ответственности RACI — таблица, в которой по строкам перечислены задачи проекта, а по столбцам — роли или участники, и на пересечении фиксируется их роль: Responsible, Accountable, Consulted или Informed.
Задача — сделать распределение ответственности прозрачным: у каждой задачи есть тот, кто делает работу, кто за нее отвечает, кто консультирует и кто должен быть в курсе.

По данным TeamGantt и Atlassian, RACI относится к responsibility assignment matrix (RAM) и помогает:

• Убрать размытые ожидания между командами.

• Сократить время на согласования.

• Спланировать нагрузку и полномочия без бутылочных горлышек (RACI Chart Guide, TeamGantt, Матрица RACI, Atlassian).

В классическом определении:

• R — Responsible: кто выполняет задачу.

• A — Accountable: кто единолично отвечает за результат и финальное решение.

• C — Consulted: кто дает экспертное мнение и участвует в согласованиях.

• I–Informed: кого нужно держать в курсе.

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

Расшифровка RACI: роли и зоны ответственности (R, A, C, I)

RACI расшифровывается как Responsible, Accountable, Consulted, Informed — четыре типа участия в задаче. Каждая буква описывает, что именно делает участник, какие решения принимает и как с ним нужно коммуницировать.

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

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

Nielsen Norman Group определяет responsible-ролей как тех, кто планирует, выполняет и завершает работу по конкретному deliverable. Wikipedia и Smartsheet подчеркивают, что в задаче может быть более одного R, но минимум один всегда нужен.

Зона ответственности R:

• Сделать работу в нужном объеме и качестве.

• Участвовать в планировании задачи.

• Информировать Accountable о прогрессе и препятствиях.

Отчетность проста: Accountable принимает результат и подтверждает, что задача завершена.

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

Роль Accountable — единственное лицо, которое формально отвечает за результат задачи и окончательное решение. В каждой строке матрицы должен быть только один A, иначе теряется понятная точка принятия решения.

В Scrum Guide похожий принцип описан через accountability Product Owner: он единолично отвечает за максимизацию ценности продукта и принимает решения о приоритизации и приемке результата. Scrum.org отдельно подчеркивает, что ответственность должна сопровождаться полномочиями: без права принятия решений accountability превращается в фикцию.

Зона ответственности A:

• финально утвердить результат задачи.

• снять блокеры, которые мешают Responsible.

• Обеспечить соответствие задач стандартам качества, сроков и бюджету.

Если назначить несколько A на одну задачу, появляются типичные риски:

• Конфликты решений — разные люди тянут задачу в разные стороны.

• Размытая ответственность — «решал не я».

• Задержки — никто не уверен, кто должен сказать финальное «да».

PMBOK Guide Eighth Edition (PMI, 2025) вводит принцип «Be an Accountable Leader» для обеспечения единственного ответственного за результаты в доменах управления проектами.

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

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

TeamGantt описывает C-роль как носителей экспертизы или стейкхолдеров, на которых повлияет результат задачи (RACI Chart Guide, TeamGantt). EPAM и Triaster в своих материалах по RASCI подчеркивают, что Consulted вовлекают заранее, иначе команда рискует переделывать работу после позднего согласования.

Типичные примеры Consulted в IT-проектах:

• Архитектор, который проверяет решение на соответствие архитектурным стандартам.

• Специалист по информационной безопасности, который согласует обработку данных.

• Специалист по качеству или комплаенсу в банковском или фарм-секторе.

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

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

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

TCGen описывает Informed как заинтересованных лиц, получающих отчеты о прогрессе, задержках и препятствиях без участия в исполнении. BMC Software и Miro акцентируют, что это ключевой элемент прозрачности: информируемые знают, что происходит, не пытаясь управлять задачей.

Типичные Informed:

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

• Смежные команды, зависящие от релиза.

• Служба поддержки, которой нужно подготовиться к изменению продукта.

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

Где и зачем применяется матрица RACI в управлении проектами

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

RACI дает максимум эффекта в таких сценариях:

• Старт сложного проекта. Когда проект включает десятки задач и стейкхолдеров, матрица помогает менеджеру проекта при запуске зафиксировать структуру проекта и роли по этапам, убрав серые зоны и «а я думал, это не мое».

• Кросс-функциональные инициативы. В изменениях, которые затрагивают несколько отделов (продажи, маркетинг, ИТ, финансы), RACI снижает конфликты между участниками и делает видимыми точки согласования.

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

• Инциденты и исправление дефектов. В производстве и IT-поддержке матрица заранее описывает, кто выявляет дефект, кто устраняет, кто информирует руководство (Consuunt, RACI examples in production, 2023).

Как создать матрицу RACI: пошаговая инструкция по построению

Алгоритм построения матрицы RACI состоит из шести шагов: от списка задач до согласования с командой. CIO.com, Asana и TeamGantt описывают схожую последовательность.

Шаг 1. Соберите список задач и этапов (WBS).

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

Шаг 2. Определите список ролей и участников.

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

Шаг 3. Постройте таблицу.

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

Шаг 4. Заполните пересечения задач и ролей буквами R, A, C, I.

Для каждой задачи:

• Назначьте минимум одну роль R.

• Выберите ровно одну роль A.

• Определите, кто C (если нужна экспертиза) и кто I (кого держать в курсе).

Шаг 5. Проверьте матрицу на конфликты и пробелы.

Посмотрите по строкам и столбцам:

• Нет ли задач без R или без A.

• Не сконцентрированы ли A и R у одного человека — это создает узкое горлышко.

• Нет ли лишних C, которые затянут согласования.

Шаг 6. Согласуйте матрицу с командой и обновляйте при изменениях.

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

Пример заполнения матрицы RACI для проекта разработки

Для наглядности рассмотрим пример матрицы RACI для проекта разработки мобильного приложения. В таблице ниже — ключевые задачи и типичные роли.

По опыту консультирования проектных команд это допустимо, если:

• Объем задач не делает такого человека узким горлышком.

• У роли есть реальные полномочия принимать решения.

• Команда осознанно согласовала такое совмещение и зафиксировала его в матрице.

Основные преимущества использования модели RACI в команде

Матрица RACI дает команде и бизнесу несколько ощутимых выгод.

Прозрачность распределения ролей.

• Уходит ситуация «я думал, это не моя задача». Atlassian отмечает, что четкое распределение ролей в начале проекта снижает риск срыва сроков и недопониманий (Матрица RACI, Atlassian).

Снижение конфликтов и дублирования.

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

Улучшение коммуникации.

• Появляются явные каналы «между участниками»: с кем согласуем ©, кого информируем (I). Это сокращает шум и ускоряет согласования, особенно в кросс-функциональных проектах.

Балансировка нагрузки и делегирование.

• По матрице видно, у кого слишком много A или R. Это помогает перераспределить задачи, снять узкие горлышки и вовремя подключить поддержку.

Масштабируемость и онбординг.

• Новые участники команды быстрее понимают свою зону ответственности: вместо устных договоренностей они видят таблицу задач и ролей.

Вариации и альтернативы: RASCI, RACI–VS и другие расширенные модели

Расширенные модели RACI помогают точнее описать роли в специфических отраслях или процессах.

RASCI / RASIC — добавление роли S (Support)

RASCI (иногда RASIC) добавляет к RACI роль S — Support (поддержка). IT@Cornell описывает ее так: Responsible выполняет работу, Accountable один отвечает за результат, Supportive помогает ресурсами и действиями, Consulted советует, Informed информируется.

S полезна, когда:

• У исполнителя много зависимостей от других команд.

• Нужно явно зафиксировать команды поддержки (DevOps, инфраструктура, юристы, служба качества).

RACI–VS — Verify и Sign-off

RACI–VS расширяет модель ролями:

• V–Verify. Проверяет качество и соответствие стандартам.

• S — Sign-off. Формально утверждает завершение задачи.

Interfacing и Perfony приводят RACI–VS как модель для отраслей с высокими требованиями к качеству и регуляторикой: разработка медтехники, фармацевтика, аэрокосмика (What is RASCI / RACI, Interfacing; RACI, RASCI, RACI–VS — which variant is right for you? , Perfony).

Другие модели: RACIQ, RACI-DM, RACIO

• RACIQ. Добавляет роль Q — Quality (контролирующий качество). Он отвечает за проверку результата на соответствие стандартам качества, не вмешиваясь в выполнение.

• RACI-DM. Добавляет роли D — Decider (принимающий решения) и M — Monitor (наблюдающий за процессом). Используется в сложных проектах, где могут быть разные мнения, и необходимо явно указать, кто имеет право последнего слова.

• RACIO. Добавляет O — Omitted для тех, кого специально исключают из коммуникаций, чтобы снизить шум.

Частые ошибки при работе с матрицей RACI и как их избежать

Команды часто допускают одни и те же ошибки при внедрении RACI.

Несколько Accountable или отсутствие A.

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

Отсутствие Responsible.

• Бывает матрица «руководителей», где везде стоят A и C, но почти нет R. Решение: у каждой задачи минимум один R. Если нет кандидата — задачу нужно пересформулировать или исключить.

Перегрузка одного участника ролями A или R.

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

Игнор ролей Consulted и Informed.

• Команда пишет только R и A, а потом сталкивается с неожиданными возражениями от юристов, безопасности или руководства. Решение: для критических задач обязательно определить C и I и встроить коммуникацию в план.

Отсутствие обновлений матрицы.

• Проект меняется, роли меняются, а матрица остается прежней и перестает отражать реальность. Решение: установить периодические ревизии (например, раз в спринт или раз в квартал) и назначить владельца матрицы.

Переусложнение.

• В матрицу заносят сотни задач и десятки ролей, ее становится невозможно читать. Решение: фиксировать в RACI ключевые задачи и стейкхолдеров, а не каждую мелочь.

Чек-лист самопроверки матрицы

1. В каждой задаче ровно один Accountable (A)?

2. Нет ли задач без Responsible ®?

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

4. Включены ли все важные задачи и ключевые роли?

5. Понятны ли участникам их роли, согласны ли они с ними?

6. Определены ли Consulted и Informed для критических задач и событий?

7. Регулярно ли вы пересматриваете матрицу и обновляете ее при изменениях?

Интеграция RACI в современные инструменты управления проектами

Хотя официальных универсальных гайдов по Jira, Asana и Trello немного, на практике команды успешно реализуют RACI в этих системах через плагины и настройки.

Настройка в Jira, Asana, Trello

Jira.

На Atlassian Marketplace есть плагин «RACI Matrix for Jira», который позволяет назначать роли R/A/C/I прямо в задачах и строить матрицу по проекту. Без плагина часто создают пользовательские поля для Responsible, Accountable, Consulted, Informed и используют их в фильтрах и досках.

Asana.

Asana предоставляет шаблоны для матрицы RACI и позволяет привязывать роли к задачам, используя пользовательские поля и описания задач (Матрица RACI, Asana).

Trello.

В Trello распространенный подход — использовать метки или префиксы в именах участников ([R], [A], [C], [I]) и собственные поля в платной версии.

Уведомления для C и I

В Asana пользователи автоматически получают уведомления о изменениях статуса задач, в которых они участвуют; уведомления попадают в раздел «Входящие» и подсвечиваются, пока не прочитаны (Гайд Asana: где место Asana; Входящие и уведомления, Asana). Для ролей C и I достаточно включить их в наблюдатели по задаче.

В Jira можно настроить правило автоматизации: триггер Issue transitioned (смена статуса задачи) и действие Send email или Add comment с упоминанием пользователей, указанных в полях Consulted и Informed (Jira Automation tutorials, Atlassian). Это позволяет автоматически уведомлять консультантов и информируемых при переходе задач в важные статусы (например, «Готово к ревью», «Готово к релизу»).

RACI и Agile/Scrum: совместимость и практики

RACI можно комбинировать с Agile и Scrum, если использовать ее аккуратно — не как жесткую иерархию, а как способ прояснить ожидания по ключевым действиям.

Scrum.org подчеркивает, что в Scrum ответственность в целом командная, но допускает использование матриц ролей для пояснения зон ответственности Product Owner, Scrum Master и команды разработчиков. Atlassian рекомендует RACI для перехода на Agile, чтобы сделать понятным, кто за что отвечает на границе старой и новой моделей управления.

Типовые сопоставления:

• Product Owner. Часто A за задачи, связанные с требованиями и ценностью продукта: формирование и приоритизация backlog, приемка инкремента.

• Scrum Master. R/A за внедрение и поддержку Scrum-процессов, фасилитацию событий, снятие импедиментов.

• Development Team. R за выполнение задач спринта, иногда совместно A за достижение цели спринта.

Проверочный валидатор матрицы (правила качества)

Чтобы быстро проверить качество вашей матрицы RACI, используйте мини-валидатор:

• В каждой строке ровно один A и минимум один R.

• Нет задач без Responsible и Accountable.

• Количество C ограничено: если Consulted слишком много, задачу будет сложно согласовать.

• I назначены хотя бы для ключевых событий и релизов.

• Нагрузка сбалансирована: ни у кого нет чрезмерного количества A и R без обоснования.

• Есть владелец матрицы и периодичность ревизии (например, раз в месяц или раз в спринт).

FAQ. Ответы на частые вопросы

В чем разница между Responsible и Accountable?

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

Может ли у задачи быть несколько исполнителей (ролей R)?

Формально модель RACI допускает несколько Responsible на задачу (это отражено в описаниях Wikipedia и Smartsheet). Однако многие практики (например, Asana) рекомендуют назначать одного основного исполнителя, чтобы команда понимала, к кому идти с вопросами, а остальных оформлять как соисполнителей или Support. На практике хороший компромисс — один «ведущий» R и несколько соисполнителей или роль S в модели RASCI.

Что делать, если у задачи нет Accountable (A)?

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

Как часто пересматривать матрицу?

Минимум при каждом крупном изменении в проекте и не реже раза в месяц или раз в спринт. Иначе матрица перестанет отражать реальность, а команда перестанет ей доверять.

Радикально снизьте операционные затраты

Уберите ручные процессы и избыточные расходы на работу с исполнителями.

Подробнее