Каталог решений - Мы в ответе за то, чего вовремя не послали. Матрица ответственности в проектах внедрения

Продолжаю тему вопросов и ответов по курсу “Управление ИТ-проектами”.

В своей публикации “Устав писать Устав” я много рассуждала о том, как полезно умение договариваться на берегу. Как известно, у каждого человека в голове своя картина мира. И эта картина нередко бывает устроена довольно причудливым образом — например, бухгалтер может искренне быть уверенной в том, что какие-то задачи решаются сами собой и не видеть трудоемкости задач для разработки. А разработчики, наоборот, могут считать, что бухгалтерии совсем не сложно протестировать какие-нибудь печатные формы, и когда они не сообщают разработчикам сразу о косяках — это исключительно из вредности.
В целом, многие конфликты в ходе проектов происходят как раз из-за конфликта ожиданий, и из-за нечетких договоренностей, кто чем должен заниматься.  

И здесь я хочу поговорить про инструмент, который может помочь договориться, кто за какие задачи в проекте отвечает. Этот инструмент — матрица ответственности. Сразу хочу оговориться — разумеется, любой инструмент, любой документ — это не панацея. Как известно, “Автоматизация хаоса приводит к автоматизированному хаосу” — если сотрудник разгильдяй, и если он не готов выполнять свои прямые обязанности, то документы помогают не очень сильно. Тем не менее, помогают. За счет чего — расскажем несколько ниже.

Итак, матрица ответственности, она же RACI-матрица (от сокращений английских слов Responsible-Accountable-Consulted-Informed).

По вертикали выписываем результаты, которые встречаются на проекте. Детализация может быть самой разной — можно указывать в матрице только самые высокоуровневые задачи, можно — детализировать до конкретных задач (некоторые применяют матрицу ответственности прямо в диаграмме Ганта в MS Project — указывая в графе “назначенные ресурсы” тех, кто за ту или иную задачу отвечает). В общем, все зависит от ваших целей. 
А по горизонтали — разные роли на проекте (РП, архитектор, сисадмин, бизнес-аналитик и т. п.). А на их пересечении указывается, какое отношение к этой задаче какая роль имеет.  
В самом простом варианте матрица включает в себя 4 позиции.
Р — разрабатывает (в английском R — responsible). Это непосредственный исполнитель по тому или иному результату. Обратите внимание, что в предлагаемой градации речь идет не про “разрабатывает” в значении “разработка/программирование” — у вас может программирования по той или иной задаче вообще не быть, скажем, речь идет про подготовку документа или описание бизнес-процесса. 
У — утверждает (или О — отвечает, в английском — A — accountable).  Это, образно говоря, “крайний” за тот или иной результат, тот кто его утверждает, “подписывает”. По замыслу авторов матрицы “Утверждает” и “Ответственный” — это синонимы. Обе позиции предполагают включенность участников в процесс, и ответственность за результат. Причудливость организации работы в некоторых проектных командах такова, что “утверждает” — это часто роль только на бумаге, то есть человек просто ставит подпись, не участвуя в процессе и не вникая результат. Это, как не трудно догадаться, с позиции оптимального результата не очень целесообразно…  
К — консультирует (в английском C — consulting) — человек, не занимающийся непосредственно выполнением задачи (см. пункт “разрабатывает”), но привлекаемый в процессе выполнения задачи. 
И — информируется (вот это “тся” иногда вызывает определенные вопросы — но обычно под буквой И обозначается именно тот, кого нужно информировать, а вовсе не тот, кто должен информировать, в английском I — Informed). Это тот сотрудник, которого нужно уведомить, когда тот или иной результат исполнен. В этом и главное различие между ролями “Консультирует” и “Информируется” — “К” относится к работе в процессе, а “И” — к работе, когда она уже сделана.

Расширенный вариант матрицы.

На самом деле, этими буквами картинка на проекте, разумеется не ограничивается. Я не возьмусь сказать, что есть какой-то универсальный подход, который бы подошел “абсолютно всем”. Зависит от ваших целей, и от того, как планируется использование матрицы.

Какие буквы могут добавляться?

Поделюсь здесь практическим опытом из моего окружения:
С — Согласование. Согласующих, в отличие от утверждающих, может быть несколько по каждой задаче.
О — Ответственный, отдельно от У — Утверждающий. О — тот, кто представляет готовый проект на подпись, У — тот, кто подписывает (принимает работу, условно говоря).
Одна команда использует отдельные буквы: И — Исполняет, ПУ — принимает участие. Имеется в виду, что “И” — это член команды, активно работающий над задачей, а “ПУ” — нечто среднее между “Консультирующим” и “Исполняющим” — помогает при необходимости ))).

Может быть конкретное разделение по задачам внутри пункта “Р — Разрабатывает”: 
СТ — Собирает требования
Р — Разрабатывает
Т — Тестирует
О — Обучает
Д — пишет документацию (кстати, очень ценный пункт!)

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

Я обещала озвучить, за счет чего матрица ответственности помогает?

Мы фиксируем обязанности и сообщаем их тем, к кому они относятся (разумеется, если РП просто нарисовал матрицу у себя в блокноте и никому не показал, она ничем не поможет)
Но если мы обсуждаем матрицу ответственности и с представителями ИТ, и с представителями бизнеса, мы можем, условно говоря, “сверить часы” — понять, где у нас точки зрения не сходятся. И либо договориться, либо эскалировать вопрос “наверх”, чтобы нам помогли договориться. 
Кстати сказать, и в том случае, когда сотрудники явно не выполняют свои обязанности просто по причине низкой заинтересованности, сам факт существования матрицы, в которых они указаны как ответственные, уже помогает. Во-первых, он все-таки самодисциплинирует. Во-вторых, если ситуацию таки приходится эскалировать наверх, то прописанные обязанности лучше работают как аргумент.    
В процессе подготовки самой матрицы всплывают сложности взаимодействия. Например, становятся наглядно видны проблемные места.

В моей практике часто встречаются, например, такие проблемы:

• Спорная зона ответственности руководителя проекта со стороны исполнителя и со стороны заказчика. Кто отвечает за результат, кто принимает решения? 
  Хороший работающий вариант, как правило — это когда РП со стороны заказчика (ну, или ответственный представитель со стороны бизнеса, если речь идет о внутреннем проекте, когда ИТ-отдел внедряет что-то по запросу бизнес-подразделений/бухгалтерии и т. п.) берет на себя роль “Владельца продукта” — то есть описывает финальную картинку, и видит целевой результат — как то или иное прикладное решение должно работать с позиции пользователя. 
  А РП со стороны исполнителя (или ответственный айти-специалист, опять же, когда проект внутренний) — отвечает за архитектуру и техническую реализацию.
• Практически за все задачи отвечает один и тот же человек (РП?). Он и швец, и жнец и на дуде игрец. И вообще с тоской думает, как ему разорваться на много маленьких “рпшничков”, чтобы успеть сделать если не всё… То хотя бы всё самое необходимое… 
  На этом месте иногда можно увидеть, что команды проекта-то на самом деле нет. Что всё делает полтора человека, остальные, максимум, готовы проконсультировать…
• Проблема, что никто не хочет брать на себя ответственность. Люди не любят принимать решения, особенно в бюрократизированных организациях, где они понимают, что за неправильное решение им может влететь. Вообще, уговорить матерого руководителя что-то подписать — это отдельная история ))). Хотя чаще всего (если есть хоть какая атмосфера сотрудничества и взаимного доверия), уже даже подтверждение на словах/в электронной почте, что “да, я со всем принципиально согласен” — уже помогает дальнейшему взаимодействию. Я уже рассказывала, что в моей практике были ситуации, когда Устав по той или иной причине уполномоченные лица так и не подписывали, но сам факт наличия этого документа, принципиально согласованного, пусть даже и без подписи — уже помогал улучшить взаимодействие.  
• Еще одна проблема, которая часто оказывается заметна — это  суровая незаменимость. Есть ровно один человек, у которого в голове есть картинка, как должен выглядеть проект. Если этот человек заболевает (или даже просто уходит в отпуск) — никто не представляет, какая ситуация на проекте.

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

Коль скоро мы увидели проблемные и спорные места — можно попытаться их обсуждать и разрешать.

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

Подробнее об управлении ИТ-проектами вы можете узнать на моих онлайн-курсах