Многие менеджеры сталкиваются в своей работе с таким феноменом, как «размытие ответственности» — ситуацией, при которой принятие решения или поиск «корней» проблемы осложнялись тем, что в какой-то момент становилось непонятно, кто за что отвечает в команде. Но существуют инструменты, позволяющие описать границы участия каждого в проектах. В этой статье я хочу рассказать об одном из таких удобных инструментов и показать на примере, как его можно применять. Это линейная диаграмма ответственности RACI.
Что такое RACI
RACI — это схема эффективного распределения полномочий и ответственности. Описывает участие разных ролей в задачах и результатах проекта. RACI-матрицу можно разработать и применять не только для целого проекта, но и для его частей — например, для отдельных бизнес-процессов.
Название инструмента представляет собой аббревиатуру из первых букв основных обязанностей участников:
- Responsible (исполняет) — так обозначают непосредственного исполнителя работы.
- Accountable (подотчётный) — обозначение того, кто несёт ответственность за результаты работы исполнителя.
- Consulted (консультирует) — так обозначают специалистов, оказывающих услуги консультаций в процессе выполнения работы.
- Informed ( информирует) — используется в случае необходимости информирования о результатах работы конкретного специалиста или роли.
Что важно учесть перед разработкой матрицы распределения ответственности RACI
Для разработки RACI-матрицы нужно определить следующие атрибуты: роли, которые будут участвовать в каждом процессе и сами процессы, в которых будут участвовать эти роли.
Для RACI-матрицы существуют ограничения: для каждого процесса матрица должна содержать минимум одного Исполнителя и одного Ответственного.
Стоит отметить, что допускается, хотя и строго не рекомендуется:
- Совмещение ответственностей Исполнителя и Ответственного. В этом случае важно подробно описать процесс валидации результатов.
- Наличие более чем одного Исполнителя в одном процессе. Здесь нужно чётко описать, какая работа и как должна выполняться каждым Исполнителем.
Собираем RACI-матрицу для Scrum-команды
1. Определяем процессы
Предположим, что наша Scrum-команда так или иначе пересекается со следующими процессами:
- Формирование роадмапа
- Формирование бэклога спринта
- Декомпозиция задач
- Тестирование задач
- Аналитика
- Выпуск релиза
- Разработка
- Фасилитация мероприятий
2. Определяем роли
Наша Scrum-команда представлена следующими специалистами: 2 senior-разработчика, 2 middle-разработчика, 1 бизнес-аналитик, 1 scrum-мастер, 1 product owner, 2 специалиста по тестированию. Исходя из этого можно попробовать получить роли внутри команды:
- Разработчик
- QA специалист
- Аналитик
- Scrum master
- Product owner
3. Делаем черновик RACI-матрицы для представленных ролей и процессов
Исходя из набора ролей внутри Scrum-команды в целом и команды разработки в частности, получилось собрать вот такую черновую схему распределения ответственности. Она не идеальна и в ней есть очевидные недочёты, которые мы либо исправим, либо примем как ограничения.
4. Исправляем недочёты и принимаем ограничения
Большое количество AR
В нашей команде есть домены, которые являются и Исполнителями и Ответственными за процесс. Считаем это недочётом.
Как исправить: использовать существующую или описать новую схему валидации. Как правило, для большинства процессов схемы валидации уже будут. Так, для процесса «Аналитика» валидно, если есть объём задач на спринт, а для процессов «Разработка» и «Тестирование» есть готовый механизм Sprint Review и т.д. Для процессов, которые команда не может отвалидировать (например «Формирование Roadmap»), можно построить матрицу ответственности для Product Owner, его руководителя и стейкхолдеров.
Много ролей в одном процессе участвуют как консультанты
Самая очевидная проблема в этой ситуации — то, что каждая роль в рамках одной задачи будет иметь разный набор данных. Недочёт.
Как исправить: например, вести внутреннюю документацию и использовать её как основной источник информации.
Когда стоит считать схему правильной?
Ограничение: только после согласования с командой. До тех пор, пока не выявлены все процессы и пока совместно с командой не собраны принципы участия каждой роли в каждом процессе, RACI нужно считать черновиком.
Когда эта схема может быть полезна?
При формировании бизнес-процессов внутри предприятия. Она на это и рассчитана.
Если мы говорим про вышеописанный кейс применения, то можно использовать RACI как один из артефактов Kick-off встречи или как один из инструментов онбординга сотрудника в команду.
Когда мы говорим про трансформацию процессов, RACI может быть полезна в качестве инструмента формализации как as-is так и to-be.
Заключение
RACI — отличный инструмент усиления бюрократии в её хорошем смысле. Но возможно она вам будет нужна только для определения вертикальных взаимодействий.
Появление RACI не гарантирует нормализацию процессов и коммуникаций. Это не более, чем инструмент визуализации, который помогает наглядно представить, как распределены полномочия и ответственности в команде или компании.
Используйте RACI matrix как и любой другой инструмент: тщательно взвесив все «за» и «против». Пробуйте, масштабируйте и не бойтесь отказываться от технологии, если замечаете, что её внедрение приносит больше проблем, чем пользы.
Источник: slowkazak.medium.com
«Я не ответственный, я — Responsible» — как объяснить бабушке, что такое RACI-матрица
Приехала я год назад к друзьям играть в настолки. А они ссорятся. Из-за того, что Маша сказала Саше вынести мусор / убрать носки / погулять с хомяком, а он не сделал, потому что тупо забыл. Рассказала я Саше и Маше про 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 матрицы, на бытовых примерах из жизни:
И в обоих шуточных примерах допущены ошибки при составлении, которые в реальном проекте могут мешать. Ниже всего два раздела, рекомендации — «как стоит делать», и чек-лист для проверки — «как не стоит делать».
Рекомендации по составлению матрицы
Я порылась в Википедии, почитала, что пишут иностранные коллеги и собрала все рекомендации по составлению матрицы.
- В RACI матрицу включают не фичи продукта, а этапы проекта, хотя их еще называют таски/задачи. Это может быть задача по разработке, проектированию, подготовке отчетности по завершению проекта, но не задача «передвинуть кнопочку.
- Матрица лучше работает, когда рассматривают от 10 до 25 этапов проекта.
- Этап проекта должен выражаться через конкретный глагол, вроде «провести ревью», «опубликовать отчет», «оценить сроки», «составить расписание», «собрать данные», «утвердить концепцию».
- В матрице лучше использовать роли, а не имена. Если завтра Васю сбивает автобус, пусть это цинично, но его роль будет исполнять другой человек.
- Разрабатывать RACI матрицу лучше группой от 4 до 10 человек. Из одной головы можно неверно оценить ситуацию, а слишком большое количество человек — просто долго и сложно для обсуждения. Но перед утверждением RACI матрицы, каждый, кто будет в ней участвовать, должен увидеть свою роль и согласиться с ней.
- Лучше устанавливать A и R на минимальный соответствующий уровень.
- Назначать на A — Accountable, т.е. наделять ответственностью можно только человека с полномочиями.
- Сведите к минимум позиции I и С.
- Если вы составили матрицу, то оповестите всех участников проекта о матрице, об их роли в проекте и уточните, уточните, согласны ли они с этой ролью. Если нет, матрицу придется дорабатывать.
- 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-матрицей.
- RACI matrix
- RACI матрица
- матрица ответственности
- проектный менеджмент
- управление проектами
- управление командой
- планирование
- распределение ответственности
Источник: habr.com
