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

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

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

Аббревиатура RACI отражает четыре базовые роли участников проекта:

1. R — Responsible. Это исполнитель — тот, кто непосредственно выполняет закрепленную за ним задачу в рамках проекта.
2. A — Accountable. Это ответственный — тот, кто оценивает и принимает результат выполнения какой-то задачи, отвечает за качество и сроки сдачи сегмента проекта. Именно его вызовут «на ковер», если результат окажется неудовлетворительным.
3. C — Consulted. Это роль эксперта-консультанта, к нему обращается исполнитель (R) для получения дополнительной информации, уточнения и согласования деталей. Такой человек должен обладать достаточной компетенцией в области задачи, где ему назначена роль С.
4. I — Informed. Это участник, которому важно отследить процесс выполнения задачи, чтобы координировать их со своей частью работы. Остальные участники процесса должны информировать его о решениях, которые они принимают, о сроках выполнения задач и результатах.

Сама матрица ролей выглядит как таблица, где в ячейках по горизонтали располагают участников, а в ячейках по горизонтали формулируют задачи в рамках проекта или бизнес-процесса, под который составлена эта конкретная матрица. На пересечении двух ячеек буквенным кодом обозначаются роли участников.

Шаблон матрицы RACI выглядит так:

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

Преимущества и недостатки матрицы RACI

Матрица проекта заметно помогает в работе:

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

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

Упростите коммуникацию с сотрудниками и работу над любыми проектами с экосистемой коммуникационных сервисов MANGO OFFICE. Портфель коммуникационных продуктов с поддержкой 24/7:

• виртуальный номер и АТС;
• облачный контакт-центр;
• речевая аналитика;
• интегрированные многоканальные коммуникации: веб-чат, FB, VK, Telegram, Viber;
• статический и динамический коллтрекинг;
• голосовые роботы и чат-боты;
• корпоративный мессенджер Mango Talker (софтфон)
• и многое другое.

Модификации матрицы RACI

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

• RASCI. В этой модели добавлена роль Support — это человек, который помогает исполнителю. От С (консультанта) от отличается степенью вовлеченности в процесс. Задача консультанта — только предоставлять информацию. Специалист поддержки активно участвует в решении текущей задачи и заинтересован в результате.
• RACIO. Здесь введена дополнительная роль, которая ограничивает выбранных участников проекта в правах: получивший такую роль в матрице исключается из указанного процесса и не должен его касаться.
• RACI-VS. В этой модификации появляются сразу две новых роли. Verifier — специалист, который должен сверять результат с определенными параметрами, и Signatory — человек, одобрение и подпись которого подтверждает достижение нужного результата в конкретном сегменте проекта.
• RACIQ. В этом варианте матрицы вводят дополнительную роль Quality. Это специалист, который контролирует качество промежуточных и итоговых результатов.

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

Построение матрицы ответственности RACI

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

Итак, построим матрицу ответственности для проекта «Создание и запуск страницы компании в социальной сети».

1.Определение задач проекта

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

• Разработать визуальное оформление страницы.
• Разработать контент-план и стратегию продвижения.
• Подготовить ТЗ для дизайнера и копирайтера.
• Написать тексты для постов в социальной сети согласно контент-плану.
• Создать и заполнить страницу компании в социальной сети.
• Настроить и запустить рекламу страницы.

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

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

3.Распределение ответственности

На этом этапе определяются роли каждого участника в выполнении каждой задачи. Можно заполнять все ячейки в соответствии с компетенцией сотрудников и их ролями в бизнес-процессах.

• Маркетолог назначен менеджером проекта: как исполнитель R он разрабатывает стратегию продвижения страницы нашей компании в соцсети, как ответственный А отвечает за то, какой в итоге получится страница и как ее будут рекламировать, и выступает консультантом С во всех вопросах, связанных с продвижением.
• Дизайнер нарисует все картинки по ТЗ как исполнитель R, и его нужно проинформировать (I) о готовности ТЗ и о стратегии продвижения, чтобы согласовать с ней визуал страницы.
• Копирайтер должен знать, когда будет готово ТЗ и как позиционируется компания в данной соцсети (I), а также напишет все тексты как исполнитель R.
• SMM ставит задачи дизайнеру и копирайтеру как R и отвечает за итоговый результат их работы (А). Также он создает и заполняет страницу контентом (R).
• Задача таргетолога как исполнителя R — настроить и запустить рекламу и поставить в известность SMM.

Типичные ошибки при заполнении матрицы

Типичные ошибки в матрице RACI обычно связаны с тем, что ее перегружают и излишне усложняют. Поэтому после заполнения таблицы ее нужно проверить, ответив на такие вопросы:

• Сколько R-ролей у каждого участника? Если больше двух, оцените, насколько они объемные, не перекрывают ли друг друга по срокам, точно ли с ними справится один человек без потери качества и срыва дедлайна.
• Сколько А-ответственных у каждой задачи? Оптимальный вариант — один. Это поможет избежать разногласий и перекладывания ответственности на коллег.
• У всех ли участников есть R либо A роль? Если в матрице есть люди без таких ролей, точно ли они нужны на проекте? Иногда это так: например, эксперт-консультант может сам не выполнять никаких задач и не отвечать ни за один сегмент, но его помощь будет важна. А иногда таких людей можно безболезненно исключить из проекта и перенаправить на более актуальные задачи.
• Сколько ролей ложится на плечи одного участника в рамках одной задачи? В идеале их должно быть не больше двух, иначе в руках одного участника концентрируется слишком большая часть командной работы.

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

Главное о матрице RACI