Всё, что менеджеру проектов нужно знать о RACI

Одна из важнейших функций руководителя проектов — распределение обязанностей. Да, если команда проекта состоит из вас, разраба и дизайнера, она, пожалуй, излишня, но если под вашим руководством человек 45-50 с лидами, без RACI-матрицы не обойтись.

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

Что означает аббревиатура RACI?

• R — тот, кто фактически работает над исполнением задачи, исполнитель.
• A — тот, кто отвечает за исполнение задачи.
• С — тот, кто консультирует по задаче.
• I — тот, кого нужно держать в курсе дел по задаче.

Давайте разберём каждый термин.

Расшифровка

Responsible (R)

Исполнитель. Непосредственно делает задачу. Как правило, это линейный сотрудник, разработчик, дизайнер, аналитик, тестировщик. Исполнителей у задачи вполне может быть несколько, это норм. Менеджер проекта также может быть исполнителем менеджерской задачи, вроде подготовки отчёта.

Accountable (A)

Ответственный. Держит под контролем исполнителей, отвечает за то, чтобы они понимали суть задачи и выполняли её в срок. Ответственный может быть только один. Это менеджер проекта при операционной схеме или лид при функциональной (тимлид, лид аналитиков, лид тестирования, лид дизайна).

Consult (C)

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

Консультантов может быть несколько.

Informed (I)

Информированный. Это сотрудник, которого нужно держать в курсе работ над задачей, однако консультироваться с которым не требуется. Обычно это кто-то из руководства или стейкхолдеров проекта. Информировать тоже можно несколько человек.

Дополнительные роли

Матрицу можно расширить дополнительными ролями, если это необходимо:

Некоторым проектам не хватает классического списка ролей. Тогда к RACI можно добавить дополнительные буквы и, соответственно, роли. Вот примеры:

• RACI-VS. Новые роли V (verifier) и S (signatory) — верификатор и подписывающий. Они проверяют, соответствует ли результат установленному стандарту, и согласовывают его. V- или S-участников может быть один или два.
• RACIQ. Новая роль Q (quality) проверяет качество результата.
• RASCI. Новая роль S (support) помогает основному исполнителю выполнять работу. Что-то вроде инструмента формирования иерархии.

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

Когда RACI матрица действительно нужна

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

Как составить RACI матрицу

Для создания матрицы RACI нужно выполнить следующие действия:

1. Определить задачу: сформулировать перечень критичных верхнеуровневых активностей по проекту. Если у вас ИСР на 1500 задач, нет нужды каждую добавлять в матрицу. В то же время, должна быть достаточная детализация, чтобы матрица была полезной.
2. Составь список членов команды: а вот тут нужно перечислить всех. Сотрудников команды, консультантов, влияющих лиц. Если у вас текучка, необязательно пофамильно, можно по ролям.
3. Распределить роли: определить для каждой задачи роль сотрудника. Не забыть, что ответственный за каждую задачу только один.
4. Выполнить валидацию матрицы: показать матрицу всем сотрудникам, убедиться, что они понимают свои роли и ни у кого нет возражений. Этот этап может затянуться, но он крайне важен.

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

	Пиэм	Дизайнер	Разработчик	Тестировщик	Заказчик
Написать ТЗ	A	C	C		R
Создать дизайн	A	R
Написать код приложения	A		R	I
Протестировать приложение	A		R	I
Опубликовать приложение в сторах					AR

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

Типичные ошибки

• Один участник команды — R-исполнитель сразу в нескольких задачах. Контроль перегрузки не является задачей RACI-матрицы, его нужно контролировать в диаграмме Ганта, но если вы видите, что сотрудник должен одновременно пилить три-четыре задачи, это повод насторожиться и разнести эти задачи по разным исполнителям.
• У участника проекта нет R- или A-роли. Возможно, сотрудник бесполезен для проекта.
• У задачи много ответственных. Будет трудно согласовать требования к задаче, каждый ответственный будет вносить свою лепту. Ответственный должен быть один.
• Несколько букв в одной клетке. Как правило, когда один человек отвечает за всё, это ни к чему хорошему не приводит.
• Много консультантов. Приводит к избыточному объёму коммуникаций. Возможно, среди людей, которых нужно информировать, лишние люди.

Какие плюсы и минусы матрицы RACI?

В целом, у этой матрицы больше плюсов, но решение о её использовании/неиспользовании нужно принимать осознанно.

Плюсы:

• Ясное распределение ответственностей и ролей в команде.
• Уменьшение дискоммуникаций и конфликтов из-за возможной путаницы в ролях.
• Усиление порядка на проекте с точки зрения организации работ.
• Как следствие — рост качества получаемого на выходе продукта.

Минусы:

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

Заключение

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