Что такое матрица RACI и как она помогает выполнить проект в срок, не растеряв задачи
Рассказываем про популярный инструмент управления проектами — матрицу ответственности RACI. Показываем на примере, как её построить.
Иллюстрация: Оля Ежак для Skillbox Media
Матрица RACI, или матрица ответственности, — инструмент для управления отношениями в команде; это таблица, с помощью которой распределяют ответственность, полномочия и роли.
Матрица RACI помогает избежать ситуаций, когда непонятно, кто какими задачами занимается и кто за что отвечает.
RACI используют в управлении проектами. Матрицу строят и согласовывают на старте проекта — тогда исполнители уже не смогут перекладывать ответственность друг на друга в процессе.
В статье рассказываем главное о матрице ответственности RACI.
- Что такое матрица RACI и какие у неё бывают модификации
- Как построить матрицу RACI — разбираем на примере IT-проекта
- Какие типичные ошибки возникают при построении RACI
Что такое RACI
Матрица RACI представляет собой таблицу: по вертикали выписывают задачи проекта, по горизонтали — исполнителей.
На пересечении задач и исполнителей ставят буквы, которые обозначают роли в проекте и степень ответственности. Из этих букв состоит аббревиатура RACI:
- R (responsible) — исполнитель задачи или подзадачи проекта. Тот, кто самостоятельно выполняет все работы в рамках задачи.
Если задача масштабная, у неё может быть несколько исполнителей. Однако эффективнее разбить её на подзадачи и назначить исполнителей для каждой из них. - A (accountable) — ответственный за всю задачу. Участник с этой ролью несёт ответственность за то, чтобы задачу завершили в срок, но не обязательно выполняет её сам. Часто A-участники назначают задачи и подзадачи R-участникам.
Важно, чтобы у одной задачи был только один ответственный. При этом сам ответственный может быть одновременно и исполнителем. - C (consult) — эксперт, который консультирует команду по вопросам, находящимся в его компетенции. Он не выполняет задачу, но даёт советы и рекомендации, которые помогают выполнить её эффективнее.
- I (informed) — участник проекта, который должен быть в курсе выполнения задачи. Результат задачи или всего проекта влияет на дальнейшую деятельность I-участников, поэтому им важно следить, что происходит.
Телеграм-канал для диджитал-специалистов и руководителей
Подписывайтесь, в канале мы дарим полезные книги, делимся наваристым контентом, обсуждаем новости и выдаём билетики на бесплатные мероприятия.
ПодписатьсяМодификации матрицы RACI
Некоторым проектам не хватает классического списка ролей. Тогда к RACI можно добавить дополнительные буквы и, соответственно, роли. Вот примеры:
- RACI-VS. Новые роли V (verifier) и S (signatory) — верификатор и подписывающий. Они проверяют, соответствует ли результат установленному стандарту, и согласовывают его. V- или S-участников может быть один или два.
- RACIQ. Новая роль Q (quality) проверяет качество результата.
- RASCI. Новая роль S (support) помогает основному исполнителю выполнять работу.
Важно помнить, что матрица RACI придумана для того, чтобы упростить взаимодействия между участниками команды и эффективнее организовать работы по проекту. Поэтому добавлять дополнительные роли лучше в случае крайней необходимости.
Как построить матрицу ответственности RACI: разбираем на примере
Разберём процесс построения матрицы RACI пошагово, на примере разработки приложения для телефонов.
Шаг 1. Определяем задачи проекта
В таблице по вертикали выписываем задачи, которые нужно выполнить, чтобы получить готовое приложение:
- написать техническое задание для разработки приложения;
- создать дизайн приложения;
- разработать приложение;
- протестировать приложение;
- опубликовать приложение в сторах.
Шаг 2. Определяем участников проекта
По горизонтали выписываем исполнителей проекта — должности либо фамилии сотрудников:
- менеджер проекта;
- дизайнер;
- разработчик;
- тестировщик;
- заказчик.
Получается таблица. На следующем этапе заполним ячейки на пересечении задач и исполнителей.
Шаг 3. Распределяем роли
О том, по какому принципу распределяют роли команды, писали выше. Определим их для участников нашего проекта:
R-участники. Это исполнители задач.
- Писать техническое задание для приложения будет заказчик.
- Заниматься дизайном — дизайнер.
- Разрабатывать и тестировать приложение — разработчик и тестировщик.
- Размещать приложение в магазинах — заказчик.
A-участники. Это ответственные за каждую задачу проекта.
В нашем примере нести ответственность за выполнение всех задач, связанных с созданием приложения, будет менеджер проекта. Все R-участники будут отчитываться ему о ходе выполнения работ и сдавать результаты.
За публикацию приложения будет отвечать заказчик. В нашем случае у него две роли в одной задаче — исполнитель и ответственный.
C-участники. Это консультанты.
В нашем примере дизайнер может проконсультировать заказчика, когда тот будет составлять техническое задание. Например, подсказать, как правильно составить ТЗ на дизайн приложения. На этом же этапе свой совет может дать и разработчик.
I-участники. Это исполнители, которых нужно информировать о ходе работ.
В нашем случае тестировщика нужно проинформировать о том, что разработчик закончил свои задачи, а заказчика — о том, что приложение готово и протестировано.
Типичные ошибки при построении матрицы ответственности RACI
Мало просто построить матрицу ответственности — важно грамотно ей пользоваться.
RACI помогает проанализировать, насколько равномерно распределили задачи и ответственность между участниками команды. Например, она может показать, что у одной задачи несколько ответственных, — так быть не должно. Или что один из участников перегружен задачами, тогда как у другого их почти нет.
Вот типичные ошибки, которые возникают при построении матрицы ответственности:
- Один участник команды — R-исполнитель сразу в нескольких задачах. В этом случае нужно проанализировать, насколько эти задачи масштабные. При необходимости — назначить на некоторые из них дополнительных людей.
- У участника проекта нет R- или A-роли. В этом случае нужно решить, действительно ли этот участник необходим проекту. Возможно, стоит пересмотреть состав команды.
- У задачи много ответственных. Могут возникнуть проблемы при согласовании результата: сколько ответственных, столько и мнений. В идеале на каждую задачу нужно назначать только одну A-роль.
- Несколько букв в одной клетке. Как правило, когда один человек отвечает за всё, это ни к чему хорошему не приводит.
Если двойные буквы встречаются в матрице один или два раза — это нормально. Но когда это происходит почти с каждым участником — нужно пересматривать список задач или зоны ответственности исполнителей. - Много консультантов или участников, которых нужно информировать о промежуточных результатах. Это приводит к лишней коммуникации и отвлекает от основных работ. Назначать C- и I-участников лучше в случае крайней необходимости.
Другие материалы Skillbox Media для менеджеров
- Статья — разбор структуры проекта: зачем нужна структура и как собрать её за семь шагов
- Большой гайд по управлению бизнес-процессами: главное, что должен знать каждый менеджер
- Статья об управлении рисками проекта: как найти и оценить, как составить план защиты от них
- Руководство по дорожной карте проекта: зачем она нужна и как её сделать
- Разбор метода критического пути проекта — как искать взаимосвязанные задачи, как строить критический путь и почему важно его контролировать