RACI matrix как схема закрепления ответственности в Scrum-командах
Многие менеджеры сталкиваются в своей работе с таким феноменом, как «размытие ответственности» — ситуацией, при которой принятие решения или поиск «корней» проблемы осложнялись тем, что в какой-то момент становилось непонятно, кто за что отвечает в команде. Но существуют инструменты, позволяющие описать границы участия каждого в проектах. В этой статье я хочу рассказать об одном из таких удобных инструментов и показать на примере, как его можно применять. Это линейная диаграмма ответственности 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 как и любой другой инструмент: тщательно взвесив все «за» и «против». Пробуйте, масштабируйте и не бойтесь отказываться от технологии, если замечаете, что её внедрение приносит больше проблем, чем пользы.
