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

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

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

Какие проблемы решает RACI

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

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

Роли R, A, C и I

Частая путаница возникает между R и A: оба слова переводят как «ответственный». Поэтому в команде лучше говорить «исполнитель» и «владелец результата». Исполнитель готовит макет, владелец результата проверяет его по согласованным критериям и принимает. Это может быть один человек, но тогда в ячейке прямо указывают R/A.

C — это двусторонний разговор, I — сообщение. Если вы ставите C всем заинтересованным людям, вы создаёте очередь согласований. Если ставите I человеку, без экспертизы которого нельзя принять решение, консультация произойдёт слишком поздно. Каждую спорную букву стоит объяснить конкретной потребностью задачи.

Заполненный пример: запуск лендинга

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

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

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

Другая спорная клетка — руководитель в строке разработки. Если каждое изменение требует его решения, I не соответствует реальности. Либо команда действительно получает полномочия, либо матрица честно отражает согласование. Таблица не должна изображать автономность, которой в работе нет.

Как составить матрицу за пять шагов

1. Назовите результаты. Запишите этапы или задачи с проверяемым завершением. «Подготовлен текст страницы» лучше, чем «маркетинг».
2. Определите участников. Используйте роли или имена, но не смешивайте их без пояснений. Для внешнего подрядчика укажите контактного человека.
3. Назначьте R и A. Сначала договоритесь, кто делает и кто принимает. Убедитесь, что люди знают о назначении и могут выполнить эту роль.
4. Добавьте C и I. Оставьте только необходимые консультации и получателей информации. Зафиксируйте, когда им нужен результат.
5. Проверьте матрицу вместе. Пройдите по строкам и столбцам, разберите конфликтующие ожидания и установите дату следующего пересмотра.

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

Если участники не могут выбрать A, выясните, какое решение скрывается в строке. Возможно, «запуск продукта» объединяет техническую готовность, коммерческое решение и юридическое разрешение. Разделите результаты, вместо того чтобы ставить три A и надеяться, что они договорятся в последний момент.

Правила проверки

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

Проверьте столбцы: если у одного человека A почти везде, он может стать узким местом. Если у сотрудника много R одновременно, спросите о загрузке. RACI не содержит календаря, поэтому сроки и зависимости лучше показать отдельно — например, на диаграмме Ганта онлайн.

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

RASCI, RACI-VS и DACI

RASCI добавляет S — Support: людей, которые помогают исполнителю ресурсами или отдельными действиями. Это полезно, если помощь регулярно забывают планировать. Но новую букву стоит вводить только тогда, когда команда понимает отличие помощника от исполнителя и консультанта.

RACI-VS отдельно выделяет проверку результата (V — Verify) и формальное утверждение (S — Sign-off). Такая детализация может пригодиться при обязательной независимой проверке. Не добавляйте её автоматически к каждой строке: сначала определите, какой результат и по каким критериям проверяют.

DACI относится прежде всего к принятию решений: Driver ведёт вопрос, Approver утверждает, Contributors дают экспертизу, Informed получают информацию. Если ваш спор звучит «как выбрать вариант», этот формат может быть удобнее. Если нужно распределить выполнение работ, начните с RACI.

RACI, структура проекта и карта стейкхолдеров

Должность руководителя не делает его A во всех строках. Эксперт не обязан быть R только потому, что лучше всех знает предмет. Обсудите полномочия, доступное время и критерии результата; иначе матрица закрепит старые недоразумения красивыми буквами.

Как работать с матрицей на общей доске

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

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

Частые ошибки

Главная ошибка — назначить людей без разговора с ними. Следующая — смешать обязанность сделать работу с правом утвердить её. Ещё одна — использовать RACI как инструмент поиска виноватого после неудачи. Матрица нужна для ясных ожиданий, а не для замены нормального управления и обратной связи.

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

Сверить определения можно в руководстве Atlassian по RACI. Пример запуска лендинга в статье учебный; роли следует согласовать с вашей командой.

Как разбирать конфликт ответственности

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

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

Если человек не согласен с ролью, выясните причину до утверждения таблицы. Возможно, у него нет доступа, бюджета, компетенции или времени. Назначение буквы не устраняет ни одно из этих ограничений. Иногда правильное решение — изменить объём результата, передать часть работы или сдвинуть срок, а не убеждать человека принять заведомо невыполнимое обязательство.

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

После первого этапа проверьте матрицу по реальным событиям. Кто фактически принимал решения? Какие консультации оказались лишними? Где информация пришла поздно? Исправьте договорённости и сохраните дату версии. Ценность RACI определяется тем, помогает ли она работать, а не тем, насколько аккуратно заполнены все клетки.

Вопросы и ответы

Сколько A может быть в одной строке RACI?

Один. Если окончательные решения принимают разные люди, разделите результат на отдельные задачи с понятными границами.

Может ли один человек быть R и A?

Да, если он и выполняет работу, и имеет полномочия принять результат. Это явно обозначают как R/A.

Чем C отличается от I?

C участвует в консультации до решения, I получает информацию. Информирование не подразумевает обязательного согласования.

Нужна ли RACI маленькой команде?

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