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

Хаос в проектах и бесконечные цепочки согласований – проблемы, которые знакомы большинству руководителей. Однажды услышал от коллег по цеху об «уникальной» системе согласования в одной из компаний. Чтобы внедрить какое-то решение, нужно было:

Распечатать все материалы, включая объемные презентации.
Взять обходной лист и подписать у каждого лица, принимающего решение (ЛПР было 9!).
Начать работу только после получения 9 подписей.

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

Что не так с подобными решениями:

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

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

Что такое матрица RACI

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

Responsible – непосредственно исполнитель. Если задача слишком объемная, лучше разделить ее на подзадачи и назначить исполнителя на каждую из них.
Accountable – человек, который полностью ответственен за всю задачу. Чаще всего он распределяет роли и следит за тем, чтобы исполнители соблюдали сроки, а также заранее принятые правила. Ответственным может быть только один человек, но в маленьких проектах он также может совмещать две роли: ответственного и исполнителя.
Consult – эксперт, который не выполняет задачу, но может помочь, если возникли сложности, либо нужно альтернативное мнение.
Informed – участники, на которых непосредственно влияет результат выполненной задачи. Они сами не делают работу, но должны оставаться в курсе происходящего.

Схематичный пример того, как может строиться схема RACI:

роли в команде

Какие разновидности матриц RACI бывают

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

RACI-VS. В этой модификации матрицы есть две новые роли: верификатор V и тот, кто подписывает решения, – Такие роли добавляют на больших проектах, а также в тех случаях, когда цена ошибки очень велика, поэтому нужно минимизировать риски.
Матрица в такой модификации включает дополнительную роль Q – специалиста, который отвечает за качество (quality) продукта либо услуги.
В этом формате добавляется роль S (support) – нужна в тех случаях, когда непосредственное выполнение задачи требует больших усилий. И тогда специалист S выступает в качестве поддержки для основного исполнителя R.

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

Как построить и внедрить матрицу RACI – пошаговый план

Шаг 1. Определить пул подзадач в рамках одной более крупной задачи.

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

Составить техническое задание.
Разработать дизайн страницы.
Написать код для страницы.
Протестировать работу страницы.
Добавить страницу на сайт.

Шаг 2. Определить список исполнителей с учетом ролей RACI. Этот список может включать отдельных участников команды, всю команду, а также специалистов из других отделов – по ситуации.

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

Каркас матрицы будет выглядеть таким образом:

роли в команде

Шаг 3. Назначить роли согласно матрице RACI. Если окажется, что этих ролей недостаточно, взять другую модификацию матрицы и добавить новые.

роли в команде

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

В моем примере указано, что при составлении технического задания дизайнер и разработчик выступают в роли консультантов. Это означает, что тимлид может обратиться к ним в случае затруднений. А совместное составление ТЗ позволит избежать многих сложностей. Так, дизайнер может подсказать, что выполнение конкретной работы потребует больше времени, поэтому дедлайн нужно изначально увеличить.

Шаг 4. Убедиться, что внутри матрицы не дублируются те роли, которые должен выполнять только один человек.

Напомню, что роли R и A нередко объединяются – и это видно на примере с тимлидом, который составляет техническое задание. Он в этом случае несет полную ответственность за результат и одновременно выполняет основную работу. А вот объединить роли R и C (исполнителя и консультанта) в рамках одной задачи уже нельзя. Но если задачи разные, то один и тот же человек может быть поочередно исполнителем, консультантом или просто участником, которого должны вводить в курс дела (роль I).

Шаг 5. Завалидировать матрицу – обсудить со всеми участниками их роли, полномочия, уровень ответственности. Убедиться, что каждый специалист согласен с тем, что должен делать.

Ошибки при составлении матрицы RACI

Это не самый простой в освоении инструмент, потребуется время, чтобы использовать его эффективно. Но вы сэкономите немало нервов, если заранее учтете распространенные ошибки новичков.

1. Один сотрудник – много R

Это популярная ошибка в командах, где есть опытные сотрудники или «рабочие лошадки». Руководители часто идут по пути наименьшего сопротивления и стараются передать задачи тем, кто на 100% с ними справится. Но большое количество R в матрице на одного человека часто свидетельствует о перегрузке специалиста.

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

2. В задаче отсутствует роль R

Бывает, если в отдельную строку выносят работу, которую нельзя считать отдельной задачей.

Как решить. Скорее всего, задача без R – это часть другой полноценной задачи. Поэтому нужно пересмотреть проект и подумать, с чем объединить эту «пустую» строку.

3. В одной задаче много сотрудников с ролью A

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

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

4. Слишком много ролей C и I

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

Как решить. Объем общения можно безболезненно сократить и оставить только тех C и I, чье участие по-настоящему влияет на результаты.

5. У участников проекта вообще нет ролей A или R

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

Как решить. Еще раз пересмотрите роли C и I – убедитесь, что они важны сами по себе. Такое может быть, если опытный программист подстраховывает новичков. Тогда он не выполняет роли A или R, но всегда находится на связи – на случай, если потребуется его помощь. А вот тех участников C и I, которые попали в матрицу «для галочки», следует исключить.

6. В матрице много ячеек с двумя ролями

Периодически такие ячейки встречаются, особенно если мы говорим про объединение ролей A и R. Но если их слишком много, скорее всего, в проекте недостаточно людей, либо сама матрица составлена неверно.

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