Матрица RACI для проектной команды: как разделить работу и решения

Матрица RACI показывает, кто выполняет работу, кто отвечает за итог, с кем нужно посоветоваться и кого достаточно уведомить. Её применяют к конкретным результатам или решениям проекта, а не к каждой мелкой задаче. Смысл таблицы прост: у результата должен быть один владелец окончательного ответа и понятный путь согласования. Тогда команда не тратит дни на вопрос «кто должен был это сделать?», а заказчик знает, к кому обращаться за решением.

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

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

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

I — Informed: участники, которым сообщают о принятом решении или состоянии результата. Они не согласуют работу и не блокируют её, но без сообщения могут начать действовать по старому плану. После утверждения интерфейса команде поддержки полезно знать, что изменится для клиентов. Если у адресата есть право остановить выпуск, это уже не роль I; нужно прояснить его полномочия.

RACI не заменяет описание ролей и ответственности участников проекта. Роль «аналитик» говорит о профессии и обычных обязанностях, а буква в матрице — о конкретном результате. Один и тот же аналитик может готовить требования как R, принимать набор данных как A и давать совет по другому этапу как C. Именно это меняющееся сочетание помогает увидеть таблица.

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

Поводом может быть повторяющийся спор. Два руководителя одновременно дают исполнителю разные указания. Результат возвращается после демонстрации, потому что «настоящий» согласующий впервые его увидел. Команда сделала работу, но никто не готов поставить финальную отметку. Или, наоборот, несколько людей говорят «я отвечаю», а в конце никто не проверил качество. Эти ситуации различаются, но у всех общий корень: полномочия не совпали с реальным потоком работы.

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

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

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

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

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

Указав роль I, договоритесь о моменте уведомления. Поддержке может быть бесполезен рассказ о каждом промежуточном варианте входа, но необходимо знать итоговый сценарий до запуска, чтобы подготовить ответы пользователям. Матрица показывает, кого информировать; план коммуникаций проекта уточняет, когда и в каком виде это делать.

Если у вас уже есть журнал решений проекта, свяжите с ним строки матрицы. RACI отвечает на вопрос, кто участвует; журнал показывает, какое решение принято и почему. Вместе они снимают спор «мы думали, что вы одобрили», который не решить одним списком ролей.

Сначала посмотрите на строки без A. Это результаты, которые могут быть сделаны, но не приняты. Назначьте владельца с реальным правом сказать «готово» или «нужно исправить». Затем найдите строки с двумя и более A. Может оказаться, что это разные решения, ошибочно собранные в одну строку. Разделите их либо договоритесь, кто принимает финальное решение после консультации другого участника.

Много R в одной строке не всегда ошибка, но требует уточнения: как люди разделят работу, кто соберёт части и кто сообщит о готовности? Если каждый предполагает, что общий результат объединит кто-то другой, строка не работает. Много C — возможный признак слишком широкого согласования. Спросите у каждого консультанта, какую экспертизу он добавляет и какое решение невозможно принять без неё.

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

Пройдите по одному реальному результату от начала до конца. Исполнитель знает критерии готовности? Консультант понимает, когда его спрашивают? Владелец A действительно доступен для приёмки? Получатели I понимают, после какого события им придёт сообщение? Если хотя бы на один вопрос нет ответа, матрица ещё не стала рабочим правилом. Уточните момент передачи и срок реакции рядом с соответствующей строкой.

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

Есть и проверка по времени. Для каждого обязательного C спросите, когда именно нужно его мнение: до начала работы, перед демонстрацией или при финальной приёмке. Если консультация появляется только в конце, она может превратиться в дорогую переделку. Роль I тоже привяжите к событию: уведомление после утверждения, после выпуска или после изменения сроков. Одно и то же сообщение в разные моменты способно либо помочь, либо создать ложные ожидания.

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

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

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

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

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

Первая ошибка — детализировать всё до отдельных действий. В матрице появляются строки «написать письмо» и «проверить опечатку», она быстро устаревает. Оставьте там результаты, пересечения функций и решения. Конкретные шаги живут в задачах. Тогда таблица остаётся достаточно стабильной, чтобы участники могли ей доверять.

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

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

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