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

#статьи

  • 9 авг 2022

  • 0

Рассказываем про популярный инструмент управления проектами — матрицу ответственности RACI. Показываем на примере, как её построить.

Иллюстрация: Оля Ежак для Skillbox Media

Ксеня Шестак

Рассказывает просто о сложных вещах из мира бизнеса и управления. До редактуры — пять лет в банке и три — в оценке имущества. Разбирается в Excel, финансах и корпоративной жизни.

Матрица RACI, или матрица ответственности, — инструмент для управления отношениями в команде; это таблица, с помощью которой распределяют ответственность, полномочия и роли.

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

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

В статье рассказываем главное о матрице ответственности RACI.

  • Что такое матрица RACI и какие у неё бывают модификации
  • Как построить матрицу RACI — разбираем на примере IT-проекта
  • Какие типичные ошибки возникают при построении RACI

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

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

  • R (responsible) — исполнитель задачи или подзадачи проекта. Тот, кто самостоятельно выполняет все работы в рамках задачи.

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

  • A (accountable) — ответственный за всю задачу. Участник с этой ролью несёт ответственность за то, чтобы задачу завершили в срок, но не обязательно выполняет её сам. Часто A-участники назначают задачи и подзадачи R-участникам.

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

  • C (consult) — эксперт, который консультирует команду по вопросам, находящимся в его компетенции. Он не выполняет задачу, но даёт советы и рекомендации, которые помогают выполнить её эффективнее.
  • I (informed) — участник проекта, который должен быть в курсе выполнения задачи. Результат задачи или всего проекта влияет на дальнейшую деятельность I-участников, поэтому им важно следить, что происходит.

Пример готовой матрицы RACI
Инфографика: Майя Мальгина / Skillbox Media

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

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

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

Разберём процесс построения матрицы RACI пошагово, на примере разработки приложения для телефонов.

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

  • написать техническое задание для разработки приложения;
  • создать дизайн приложения;
  • разработать приложение;
  • протестировать приложение;
  • опубликовать приложение в сторах.

По горизонтали выписываем исполнителей проекта — должности либо фамилии сотрудников:

  • менеджер проекта;
  • дизайнер;
  • разработчик;
  • тестировщик;
  • заказчик.

Получается таблица. На следующем этапе заполним ячейки на пересечении задач и исполнителей.

Подготовка к распределению ролей проекта — перечень основных задач и исполнителей
Инфографика: Евгений Рыбкин / Skillbox Media

О том, по какому принципу распределяют роли команды, писали выше. Определим их для участников нашего проекта:

R-участники. Это исполнители задач.

  • Писать техническое задание для приложения будет заказчик.
  • Заниматься дизайном — дизайнер.
  • Разрабатывать и тестировать приложение — разработчик и тестировщик.
  • Размещать приложение в магазинах — заказчик.

A-участники. Это ответственные за каждую задачу проекта.

В нашем примере нести ответственность за выполнение всех задач, связанных с созданием приложения, будет менеджер проекта. Все R-участники будут отчитываться ему о ходе выполнения работ и сдавать результаты.

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

C-участники. Это консультанты.

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

I-участники. Это исполнители, которых нужно информировать о ходе работ.

В нашем случае тестировщика нужно проинформировать о том, что разработчик закончил свои задачи, а заказчика — о том, что приложение готово и протестировано.

Так выглядит готовая матрица RACI для проекта разработки приложения
Инфографика: Евгений Рыбкин / Skillbox Media

Мало просто построить матрицу ответственности — важно грамотно ей пользоваться.

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

Вот типичные ошибки, которые возникают при построении матрицы ответственности:

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

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

  • Много консультантов или участников, которых нужно информировать о промежуточных результатах. Это приводит к лишней коммуникации и отвлекает от основных работ. Назначать C- и I-участников лучше в случае крайней необходимости.

Другие материалы Skillbox Media для менеджеров

Научитесь: Профессия Менеджер проектов
Узнать больше

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

Что такое матрица ответственности RACI

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

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

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

Матрица RACI

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

R – расшифровывается как «Responsible», что означает «ответственный за работу» – это человек, который непосредственно выполняет задание. Данный сотрудник самостоятельно работает в рамках текущей задачи. При постановке масштабных задач, для них могут быть назначены несколько исполнителей. Однако рекомендуется разбивать большие задачи на подзадачи и определять исполнителей для каждой из них.

A – обозначает «Accountable», это тот, кто несет ответственность за всю задачу и результаты работы исполнителя. Участник с такой ролью следит за тем, чтобы задача была завершена в срок, но не обязательно решает ее сам. A-участники достаточно часто назначают задачи сотрудникам, исполняющим R-роль. Важный нюанс: у одной задачи должен был только один ответственный, чтобы все члены команды понимали, к кому обращаться за информацией или с какими-либо вопросами, однако при этом сам ответственный может являться одновременно и исполнителем.

C – сокращение от «Consult before doing», что переводится на русский как «консультирует до исполнения», то есть это специалист, оказывающий услуги консультаций в процессе выполнения работы по вопросам, входящим в зону его компетенции. Данный эксперт не выполняет задачу сам, а только дает советы и рекомендации для ее более эффективного выполнения.

I – первая буква английской фразы «Inform after doing», которая означает «оповещает после исполнения». Буквой I в таблице матрицы ответственности RACI обозначают участника проекта, который обязан быть в курсе принимаемых решений и хода выполнения задачи. I-участники по большей части не вовлечены в другие аспекты достижения результата, однако, поскольку результат влияет на их дальнейшую деятельность, им важно следить, за тем, что происходит.

Командная работа в проекте

Встречаются вариации матрицы RACI, включающие дополнительные буквы и роли:

  • RACI-VS V, от «Verifier», означает «верификатор», то есть тот, кто проверяет результат работы на соответствие заблаговременно согласованным критериям, а S («Signatory» – «подписывающий»), обозначает лицо, отвечающее за сдачу работы заказчику.
  • RASCI – в этой аббревиатуре добавлена буква S (от «Support» – «поддержка»), она обозначает участника, который помогает ответственному лицу выполнять его работу.
  • RACIQ – здесь Q – первая буква слова «Quality», что в переводе с английского значит «качество», и, как не трудно догадаться, роль этого участника – проверка качества результата работы.

Комьюнити теперь в Телеграм

Подпишитесь и будьте в курсе последних IT-новостей

Подписаться

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

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

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

Для RACI-матрицы существует правило: для каждого процесса таблица должна обязательно содержать минимум одного исполнителя и одного ответственного. 

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

Предположим, что перед командой стоит 5 задач:

  1. Обновление кнопок с призывом к действию на главной странице веб-сайта.
  2. Обновление истории компании на главной странице.
  3. Обновление дизайна сайта.
  4. Увеличение скорости загрузки главной страницы.
  5. Обновление дизайна главной страницы.

Матрицу RACI в этом случае следует заполнить следующим образом:

Задача 1. Обновить CTA-кнопки на главной странице сайта: R (исполнитель) – копирайтер, A (ответственный) – веб-разработчик, C (консультирующий) – администратор сайта, I (оповещаемый после исполнения) – дизайнер.

Задача 2. Обновить историю клиента на главной странице: R – копирайтер, A – веб-разработчик, C – администратор веб-сайта, I – дизайнер.

Задача 3. Обновить видео на главной странице: R – дизайнер, A – веб-разработчик, C – администратор веб-сайта, I – копирайтер.

Задача 4. Добиться увеличения скорости загрузки главной страницы: R – веб-разработчик, A – веб-разработчик, C – администратор веб-сайта, I – копирайтер и дизайнер.

Задача 5. Обновить дизайн главной страницы: R – дизайнер, A – веб-разработчик, C – администратор веб-сайта, I – копирайтер.

Плюсы матрицы RACI и рекомендации по построению

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

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

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

Несколько рекомендаций по составлению таблицы RACI

  • Если R-участник задействован сразу в нескольких задачах, стоит подумать, не назначить ли на некоторые из них дополнительных исполнителей. 
  • Помните, что в идеале на каждую задачу следует назначать только одну A-роль. Если у задачи несколько ответственных, при согласовании результата могут возникать проблемы из-за расхождения во мнении.
  • Следите, чтобы в ячейках таблицы не стояло по несколько букв. Хотя наличие 1-2 ячеек с двойными буквами считается нормальным. 
  • Если у какого-то участника нет ни R-, ни A-роли, возможно, вам стоит пересмотреть состав команды и решить, так ли уж необходим проекту этот специалист.
  • C- и I-участников следует назначать только в случае необходимости. Наличие множества консультантов, а также участников, которых требуется информировать о промежуточных результатах, будет отвлекать от выполнения основной работы.

Читайте также

Этапы оценки проекта: основные принципы и полезные инструменты

Гибридный формат работы: плюсы и минусы





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

Что такое матрица распределения ответственности или RACI матрица?

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

Часто понятие “матрица распределения ответственности” сокращают до просто “матрица ответственности”, но идеологически это не совсем верно. Даже в оригинале инструмент называется Responsibility assignment matrix, то есть подчеркивает то, что его цель – назначить или распределить ответственность. Но называть можно как угодно, вас в любом случае поймут.

Расшифровка RACI:

  1. R (Responsible) – тот, кто будет делать работу. Например, модуль Х будет писать разработчик Вася. Для каждой задачи должен быть как минимум один “R”, можно больше.
  2. A (Accountable) – тот, кто примет итоговую работу и будет нести за нее ответственность. Принимать у Васи модуль Х и отвечать перед руководителем проекта головой за то, что он заработает, будет его тимлид Петя. “А” для каждой задачи должен быть только один, отсутствовать “А”, также как и “R”, в задаче не может. В исключительных случаях (обычно для совсем маленьких команд) “А” и “R” будут одним и тем же человеком, тогда достаточно указать просто “А”. Но вообще это нехорошая практика.
  3. C (Consulted) – тот, кто будет в обязательном порядке консультировать остальных при выполнении задачи. Чтобы модуль Х работал как надо, и Васе и Пете надо будет согласовать свои идеи по реализации с Инной, главной за информационную безопасность в компании, и Еленой, архитектором проекта. “C” в задаче может быть, а может и не быть.
  4. I (Informed) – тот, кто должен быть в курсе принимаемых решений или хода выполнения задачи, но влиять на них никак не будет. Руководитель поддержки Иван, которого пользователи уже запинали в ожидании модуля Х, будет грустно читать статусы и рассылки о ходе разработки модуля, смотреть таски в JIRA и тяжело вздыхать. По аналогии с “C”, “I” в задаче может быть, а может и не быть.

Пример матрицы распределения ответственности

Самый простой и наглядный пример RACI матрицы проекта “поездка на дачу” (как всегда, взято в сети):

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

А вот более “корпоративный” пример:

Тут, как вы видите, приведены уже роли, а не люди, плюс используется цветовая кодировка (что лишнее, как по мне).

Как и где используется матрица распределения ответственности?

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

Итак, где может быть полезна матрица распределения ответственности?

  1. Конечно, в первую очередь при управлении проектом. Самый правильный момент создания RACI матрицы – на этапе планирования проекта. Поможет избежать кучи проблем и недопониманий в дальнейшем.
  2. При разработке нового или формализации существующего бизнес-процесса. При создании RACI матрицы для существующего процесса как правило выясняется много нового и интересного.
  3. При создании нового продукта, когда процессов как таковых еще нет. Если договориться на берегу, кто тут за продажи, а кто за производство – есть вероятность даже не поругаться и как минимум продукт запустить.
  4. В любой другой ситуации, когда надо жестко разграничить, кто и за что отвечает и в чем участвует (а иногда – и в чем не участвует, см.вариации RACI ниже).

Разработка матрицы распределения ответственности

Построить RACI матрицу несложно, все, что нужно, это:

  1. Определить и выписать по вертикали задачи/промежуточные результаты проекта, шаги бизнес-процесса или другой набор действий, для которого вы хотите обозначить ответстенных.
  2. Определить и выписать по горизонтали все роли или конкретных людей.
  3. Проставить “А” для каждой задачи. Этот пункт, кстати, здорово прочищает мозги, так как сказать, “кто будет делать – легко”, а вот “за кем будет последнее слово” – уже сложнее.
  4. Проставить “R” для каждой задачи.
  5. Посмотреть на остальные роли/людей, прикинуть, нужно ли будет с ними консультироваться или хотя бы держать в курсе происходящего, и проставить соответствующие буквы.

Делать все это, конечно, стоит с командой, а не в гордом одиночестве, чтобы потом не удивляться, что ваша идеальная картина мира не совпала с реальностью.

Поздравляю, ваша матрица распределения ответственности готова!

Само составление – примитивнее некуда, а вот согласование – гораздо интереснее. Тут же начинается политика и прочие замечательные вещи, поэтому при разработке RACI матрицы стоит эту перспективу сразу учитывать.

Другие виды матрицы распределения ответственности

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

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

Вот такие варианты можно встретить чаще всего:

  • RASCI – к обычной RACI добавляется S (Support), то есть тот, кто будет помогать ответственному (R) выполнять задачу.
  • RACIQ – к обычной RACI добавляется Q (Quality), то есть тот, кто будет проверять результат на предмет соответствия заявленному качеству.
  • RACI-VS – к обычной RACI добавляется V (Verifier) и S (Signatory), которые, соответственно, будут принимать продукт с точки зрения критериев приемки и согласовывать передачу его в эксплуатацию.
  • RACIO (или CAIRO, просто буквы в другом порядке) – к обычной RACI добавляется O (Out of the loop), или тот, кого в задаче видеть вообще не хотят (чтобы сразу его выпилить, ну, например, не хотим мы, чтобы архитектор Елена мешалась под  ногами у разработчика Васи). В жизни такого не видела, но очень хотела бы.
  • И так далее.

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

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

Вариантов “как из RACI матрицы сделать бессмысленную бумажку” много, но вот самые частые и поэтому самые любимые:

  1. Указываем везде спонсора (ну или хотя бы заказчика или любого топ-менеджера на выбор) в качестве “А”. В итоге большим дядям не до вас, ничего толком не принято, ответственных нет.
  2. Пихаем по несколько букв в одну клетку матрицы. Нет, такие редкие исключения, конечно, бывают, но если у вас вся матрица пестрит A/R и C/I – значит, вы сами не разобрались то ли с инструментом, то ли с ответственностью.
  3. Всех информируем изо всех сил. Или со всеми консультируемся. И в итоге получаем массу лишней коммуникации и генерацию белого шума в проекте или процессе.
  4. Использование имен вместо ролей. Мало того, что придется переделывать при любом изменении в команде, так еще и потом для истории этот документ будет бессмысленным.

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

Используете RACI матрицу у себя? Расскажите!

Скачать шаблон RACI матрицы вы можете прямо сейчас всего за 99 руб. После оплаты  на почту вы получите архив с шаблоном в формате docx. Сэкономьте свое время, оно стоит намного дороже! Скачайте шаблон и начните создавать свою матрицу ответственности прямо сейчас на основе лучших практик!

Купить шаблоны за 99 руб.

Шаблон шаблоном, но вообще RACI матрица – это одновременно про управление рисками и про работу со стейкхолдерами, а не просто бумажка ради бумажки.

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

Купить курс за 2990 руб

Подробнее про курс

А если вы хотите лучше работать со стейкхолдерами и уметь на них влиять – то посмотрите наш большой курс по управлению стейкхолдерами. Пакет шаблонов в подарок!

Купить курс за 2990 руб

Подробнее про курс





Информация полезна? Поддержи развитие проекта!

На кофе и новые материалы для читателей блога :)

Еще статьи

Показать еще

комментарии

Подписаться на нашу рассылку

Еженедельная рассылка полезных материалов

Приехала я год назад к друзьям играть в настолки. А они ссорятся. Из-за того, что Маша сказала Саше вынести мусор / убрать носки / погулять с хомяком, а он не сделал, потому что тупо забыл. Рассказала я Саше и Маше про ToDoList и таск-трекеры и нарисовала им на холодильнике импровизированную асану. Маша наклеила стикеры с задачами и сроками, Саша терпеливо кивнул. Настолки состоялись.

Недавно я снова заглянула в гости. Стикеры на холодильнике висят, а Маша и Саша опять ссорятся. Точнее, громко выясняют, кто хотел починить стол / вывести холодильник / искупать кота, кто по-факту должен был это делать, и почему до сих пор ничего не сделано. Я промолчала, т.к. в чужие семейные разборки со своим PMBOK-ом не лезут.

Но потом решила, что всё нормально, лезут, т.к. вспомнила, что видела RACI-матрицу для распределения ответственности с шуточным объяснением через поездку семьи на дачу. Полезла искать эту картинку для Саши с Машей, нашла, а в ней куча ошибок:

Простите. Не могу промолчать. Не надо так.

Общая суть

Есть в проектном менеджменте такой инструмент — RACI матрица PMBOK Guide (9.1.2.1 Organization Charts and Position Descriptions, Matrix-based charts)

RACI — это аббревиатура:

R — Responsible
A — Accountable
C — Consulted
I — Informed

И вокруг этой матрицы есть путаница. Responsible и Accountable можно перевести на русский язык одинаково — ответственный, иногда это можно использовать как синонимы, но не в RACI matrix. В матрице ответственности между Responsible и Accountable семантическая пропасть, вот вам мостик через неё. 

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

Responsible  — тот, кто будет выполнять этап, прям физически, к примеру, Вася делает кликабельный прототип приложения. Он Responsible за этап проекта «прототипирование».

Accountable — тот кто апрувит результат и отвечает за него. В некоторых вариациях звучит как Authorize. В зависимости от команды, это может быть менеджер Васи, может быть старший дизайнер Васи, а если в команде 2,5 человека, то это может быть и сам Вася. Но такая практика сгодится только для супер-маленьких команд, не надо к ней прилипать. 

Informed и Consulted тоже кажутся близки по смыслу. Основное отличие в том, что у C двусторонняя коммуникация в проекте, а у I — односторонняя. C может влиять на проект, а I — нет. 

Я нашла в сети еще объяснения RACI матрицы, на бытовых примерах из жизни:

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

Рекомендации по составлению матрицы

Я порылась в Википедии, почитала, что пишут иностранные коллеги и собрала все рекомендации по составлению матрицы.

  1. В RACI матрицу включают не фичи продукта, а этапы проекта, хотя их еще называют таски/задачи. Это может быть задача по разработке, проектированию, подготовке отчетности по завершению проекта, но не задача «передвинуть кнопочку.
  2. Матрица лучше работает, когда рассматривают от 10 до 25 этапов проекта. 
  3. Этап проекта должен выражаться через конкретный глагол, вроде «провести ревью», «опубликовать отчет», «оценить сроки», «составить расписание», «собрать данные», «утвердить концепцию».
  4. В матрице лучше использовать роли, а не имена. Если завтра Васю сбивает автобус, пусть это цинично, но его роль будет исполнять другой человек.
  5. Разрабатывать RACI матрицу лучше группой от 4 до 10 человек. Из одной головы можно неверно оценить ситуацию, а слишком большое количество человек — просто долго и сложно для обсуждения. Но перед утверждением RACI матрицы, каждый, кто будет в ней участвовать, должен увидеть свою роль и согласиться с ней. 
  6. Лучше устанавливать A и R на минимальный соответствующий уровень.
  7. Назначать на A — Accountable, т.е. наделять ответственностью можно только человека с полномочиями.
  8. Сведите к минимум позиции I и С.
  9. Если вы составили матрицу, то оповестите всех участников проекта о матрице, об их роли в проекте и уточните, уточните, согласны ли они с этой ролью. Если нет, матрицу придется дорабатывать.
  10. RACI матрицу иногда приходится обновлять по ходу проекта, т.к. она может устареть.

Проверка матрицы

Проверяют матрицу по двум направлениям: по вертикали и по горизонтали. Вот чек-лист, как проверить свою RACI матрицу на вшивость.

Вертикальная (по ролям)

Т.е. оценивается насколько сбалансированы роли в проекте

Слишком много R

 

Проверочный вопрос: «Вывезет человек на этой роли так много задач?»

Нет пустых мест

Проверочный вопрос: «Человеку в этой роли действительно необходимо участвовать во всех этапах проекта?»

Слишком много A

Проверочный вопрос: «Можно ли снизить количество процессов, в которых человек в этой роли принимает решение и отчитывается за них?»

Нет R или A

Проверочный вопрос: «Это нужная роль? Можно ли перераспределить часть ответственности на другие роли или передать часть ответственности с других ролей на эту?»

Двойные позиции A/R, или A/I

A/R, A/C, R/C — возможная картина для очень маленькой компании, но лучше избегать.
A/I, R/I, C/I- свидетельствует о непонимании RACI матрицы как инструмента.

Общая картина

Проверочный вопрос: «Соответствует ли количество ответственности на проверяемой роли уровню подготовки человека / его вовлеченности в проект?

Горизонтальная (по этапам)

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

Нет R 

Нет исполнителя данного этапа. Проверочный вопрос: «Кто будет это делать?»

Слишком много R

Работа может замедлиться. Проверочный вопрос: «Можно ли разбить этап на более конкретные задачи, чтобы снизить количество исполнителей в этапе?»

Нет A

Нет ответственных, нет выполненной работы. Проверочный вопрос: «У кого есть полномочия из участников проекта, чтобы принять окончательное решение и иметь дело с последствиями данного этапа?» Т.е. кто отдает команду в каком направлении атаковать, и кому снесут голову с плеч, если направление оказалось неверным.

Больше, чем одна A

Первое правило RACI матрицы — только одна А для каждого этапа проекта.

Все ячейки заполнены на каждом этапе

Проверочный вопрос: «Действительно ли нужны все участники проекта на каждом этапе? Есть при преимущества от их участия?»

Нет C/I

Возможно вы кого-то забыли. Проверочный вопрос: «Вы учли всех участников проекта? Коммуникация между «отделами» налажена? Могут ли отделы начать выполнять какой-то этап параллельно или без учета последних изменений? »

Слишком много C

Замедляет проект. Проверочные вопросы: «Действительно нужно консультироваться со всеми C? Затраты часов на эти консультации окупаются? Можно просто проинформировать эти роли?»

Слишком много I

Проверочные вопросы: «Приносит ли это информирование пользу проекту? Или просто создает лишние созвоны и совещания? Можно информировать людей на этих ролях только в исключительных обстоятельствах? Можно ли отказаться от информирования людей на этих ролях?»

Много двойных позиций

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

Непоняточки

Т.к. матрица разделяет Responsible и Accountable, то складывается впечатление, что R не несет ответственность за свои действия. Дело в том, что на каждом этапе может быть много R, и нужен человек, который может решать, соответствует ли результат поставленной задаче. R отвечает только за свою работу, а A чаще отвечает за работу других. Если полетят головы, то начинать будут с A.

RACI матрица не регулирует, кто будет планировать этап. С другой стороны, это гибкость, можно менять условия под свою команду/проект. 

RACI матрица не регулирует, будет ли C (консультант) давать консультацию только по запросу, или он будет сам вмешиваться в проект, когда сочтет, что его консультация необходима, и позже сможет убедиться, что его рекомендации реализовали. 

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

Ошибки из примера

А теперь, с чек-листом, я проведу проверку шуточной матрицы из интернетов, из-за которой я начала писать:

Горизонтальная проверка (по этапам)

− Подготовить машину.

Нет R (исполнителя), того, кто будет это делать: пойдет выгонять машину из гаража, проверять масло и т.д.

+ Купить еду.

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

± Взять игрушки.

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

Если речь идет о настолках для всей семьи, тогда распределение ролей выглядит логично, что мама дала задание взять с собой развлекухи, сын пошел искать «Монополию» в шкафу, а папа попросил взять не «Монополию», а «Манчкин».

+ Взять одежду.

Все окей: мама скомандовала всем взять теплые кофты, все взяли теплые кофты. Все в порядке.

− Взять алкоголь

Та же ошибка, что и с подготовкой машины, нет R. Непонятно, кто побежит в магазин за пивом. Да и польза этапа для всего проекта сомнительная. Убираем этот этап.

+ Замариновать шашлык

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

+ Взять рассаду

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

− Взять инструмент

Опять нет R, кто этим будет заниматься — непонятно.

− Оценить погоду

Сын решил, что важно посмотреть, будет ли на выходных дождь. И опять, кто этим будет заниматься — неизвестно, т.к. R не назначили.

Итого, 4 или 5 из 9 этапов требуют корректировки.

Вертикальная проверка (по ролям)

Папа

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

Мама

В целом роль выглядит сбалансированной, но т.к. в ходе горизонтальной проверки, мы нашли этапы, на которых нет R (исполнителей), Мама может стать R на этапе «Оценить погоду». Если мама маленькая и хрупкая (некомпетентная), то она не сможет стать R на этапе «Взять инструмент», но обычно мама знает, где что лежит, так что может выступить C (консультантом).

Сын

В целом роль выглядит сбалансированной. Если сын большой и сильный мальчик, то на этапе «Взять инструмент», может стать R (исполнителем).

Бабушка

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

Кот

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

В итоге, получаем матрицу без очевидных ошибок:

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

Меня вдохновила вот эта штука: Как объяснить бабушке, что такое Agile за 15 минут с картинками

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

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

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

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

  • Ответственное лицо (Responsible). Это человек, на которого непосредственно возложена работа. У каждой задачи должно быть только одно ответственное лицо, чтобы все знали, к кому обращаться за информацией или с вопросами. Если в задаче несколько ответственных, теряется чёткость и возникает путаница. Вместо этого лучше приглашать дополнительных участников, имеющих другие роли по RACI, в которых может быть больше одного человека.

  • Подотчётное лицо (Accountable). Подотчётное лицо отвечает за ход выполнения задач в целом, хотя при этом может не принимать непосредственного участия в работе. Есть два способа определения подотчётного лица. Иногда это менеджер проекта (или даже ответственное лицо, хотя в таком случае оно будет выполнять две разные роли в процессе выполнения задачи). В подобных случаях подотчётное лицо отвечает за выполнение всей работы. В других случаях это топ-менеджер или руководитель, отвечающий за утверждение работы, прежде чем она будет считаться выполненной. Как и в случае с ролью ответственного лица, роль подотчётного лица должен выполнять только один человек.

  • Консультирующее лицо (Consulted). Этот человек или люди проверяют и визируют работу перед её сдачей. У каждой задачи, вехе проекта или ожидаемому результату может быть несколько таких специалистов.

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

Попробовать Asana для управления проектами

Когда следует создавать матрицу RACI?

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

Эти матрицы (с учётом отличий от PERT-графиков) особенно полезны, если заинтересованные лица могут выполнять разные роли по ходу проекта. Например, кто-то может быть ответственным лицом по одному ожидаемому результату, но информируемым по другому. В матрице RACI можно чётко прописать эту информацию, чтобы все знали, кто и за что отвечает.

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

Чтобы построить матрицу RACI, создайте список всех задач, вех или ожидаемых результатов проекта. Затем определите, кто будет ответственным, подотчётным, консультирующим и информируемым лицом (лицами) в каждом случае.

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

  • Копирайтер

  • Дизайнер

  • Администратор веб-сайта

  • Веб-разработчик

Вам нужно создать матрицу RACI по пяти задачам и ожидаемым результатам:

  • Обновить кнопки, призывающие к действию, на главной странице

  • Обновить историю клиента на главной странице

  • Обновить дизайн веб-сайта

  • Увеличить скорость загрузки главной страницы

  • Обновить дизайн главной страницы

Вот как будет при этом выглядеть матрица RACI:

Обновить кнопки, призывающие к действию, на главной странице

  • Ответственное лицо: копирайтер

  • Подотчётное лицо: веб-разработчик

  • Консультирующее лицо: администратор веб-сайта

  • Информируемое лицо: дизайнер

Обновить историю клиента на главной странице

  • Ответственное лицо: копирайтер

  • Подотчётное лицо: веб-разработчик

  • Консультирующее лицо: администратор веб-сайта

  • Информируемое лицо: дизайнер

Обновить видео на главной странице

  • Ответственное лицо: дизайнер

  • Подотчётное лицо: веб-разработчик

  • Консультирующее лицо: администратор веб-сайта

  • Информируемое лицо: копирайтер

Увеличить скорость загрузки главной страницы

  • Ответственное лицо: веб-разработчик

  • Подотчётное лицо: веб-разработчик

  • Консультирующее лицо: администратор веб-сайта

  • Информируемые лица: копирайтер и дизайнер

Обновить дизайн главной страницы

  • Ответственное лицо: дизайнер

  • Подотчётное лицо: веб-разработчик

  • Консультирующее лицо: администратор веб-сайта

  • Информируемое лицо: копирайтер

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

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

Преимущества матриц RACI

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

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

Подводные камни матриц RACI (и как их избегать)

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

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

Матрицы RACI ограничены в своих возможностях, потому что не могут адаптироваться к нуждам вашего проекта в реальном времени. Чтобы задать чёткие ожидания и устранить путаницу на уровне проекта, вам необходимо средство управления проектами.

Выведите матрицы RACI на новый уровень с помощью управления проектами

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

Матрица RACI — инструмент управления работами Asana

Читать о трёх способах визуализации плана проекта: хронология, календарь и доска

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

Контроль того, кто, что и когда делает

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

Понравилась статья? Поделить с друзьями:

Не пропустите также:

  • Как найти поставщика украшений
  • Как найти косинус угла если даны координаты
  • Как найти все драйвера на нетбук
  • Как можно исправить прямую челку
  • Как найти место жительства человека по инн

  • 0 0 голоса
    Рейтинг статьи
    Подписаться
    Уведомить о
    guest

    0 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии