Продолжаю тему вопросов и ответов по курсу “Управление ИТ-проектами”.
В своей публикации “Устав писать Устав” я много рассуждала о том, как полезно умение договариваться на берегу. Как известно, у каждого человека в голове своя картина мира. И эта картина нередко бывает устроена довольно причудливым образом - например, бухгалтер может искренне быть уверенной в том, что какие-то задачи решаются сами собой и не видеть трудоемкости задач для разработки. А разработчики, наоборот, могут считать, что бухгалтерии совсем не сложно протестировать какие-нибудь печатные формы, и когда они не сообщают разработчикам сразу о косяках - это исключительно из вредности.
В целом, многие конфликты в ходе проектов происходят как раз из-за конфликта ожиданий, и из-за нечетких договоренностей, кто чем должен заниматься.
И здесь я хочу поговорить про инструмент, который может помочь договориться, кто за какие задачи в проекте отвечает. Этот инструмент - матрица ответственности. Сразу хочу оговориться - разумеется, любой инструмент, любой документ - это не панацея. Как известно, “Автоматизация хаоса приводит к автоматизированному хаосу” - если сотрудник разгильдяй, и если он не готов выполнять свои прямые обязанности, то документы помогают не очень сильно. Тем не менее, помогают. За счет чего - расскажем несколько ниже.
Итак, матрица ответственности, она же RACI-матрица (от сокращений английских слов Responsible-Accountable-Consulted-Informed).
По вертикали выписываем результаты, которые встречаются на проекте. Детализация может быть самой разной - можно указывать в матрице только самые высокоуровневые задачи, можно - детализировать до конкретных задач (некоторые применяют матрицу ответственности прямо в диаграмме Ганта в MS Project - указывая в графе “назначенные ресурсы” тех, кто за ту или иную задачу отвечает). В общем, все зависит от ваших целей.
А по горизонтали - разные роли на проекте (РП, архитектор, сисадмин, бизнес-аналитик и т. п.). А на их пересечении указывается, какое отношение к этой задаче какая роль имеет.
В самом простом варианте матрица включает в себя 4 позиции.
Р - разрабатывает (в английском R - responsible). Это непосредственный исполнитель по тому или иному результату. Обратите внимание, что в предлагаемой градации речь идет не про “разрабатывает” в значении “разработка/программирование” - у вас может программирования по той или иной задаче вообще не быть, скажем, речь идет про подготовку документа или описание бизнес-процесса.
У - утверждает (или О - отвечает, в английском - A - accountable). Это, образно говоря, “крайний” за тот или иной результат, тот кто его утверждает, “подписывает”. По замыслу авторов матрицы “Утверждает” и “Ответственный” - это синонимы. Обе позиции предполагают включенность участников в процесс, и ответственность за результат. Причудливость организации работы в некоторых проектных командах такова, что “утверждает” - это часто роль только на бумаге, то есть человек просто ставит подпись, не участвуя в процессе и не вникая результат. Это, как не трудно догадаться, с позиции оптимального результата не очень целесообразно…
К - консультирует (в английском C - consulting) - человек, не занимающийся непосредственно выполнением задачи (см. пункт “разрабатывает”), но привлекаемый в процессе выполнения задачи.
И - информируется (вот это “тся” иногда вызывает определенные вопросы - но обычно под буквой И обозначается именно тот, кого нужно информировать, а вовсе не тот, кто должен информировать, в английском I - Informed). Это тот сотрудник, которого нужно уведомить, когда тот или иной результат исполнен. В этом и главное различие между ролями “Консультирует” и “Информируется” - “К” относится к работе в процессе, а “И” - к работе, когда она уже сделана.
Расширенный вариант матрицы.
На самом деле, этими буквами картинка на проекте, разумеется не ограничивается. Я не возьмусь сказать, что есть какой-то универсальный подход, который бы подошел “абсолютно всем”. Зависит от ваших целей, и от того, как планируется использование матрицы.
Какие буквы могут добавляться?
Поделюсь здесь практическим опытом из моего окружения:
С - Согласование. Согласующих, в отличие от утверждающих, может быть несколько по каждой задаче.
О - Ответственный, отдельно от У - Утверждающий. О - тот, кто представляет готовый проект на подпись, У - тот, кто подписывает (принимает работу, условно говоря).
Одна команда использует отдельные буквы: И - Исполняет, ПУ - принимает участие. Имеется в виду, что “И” - это член команды, активно работающий над задачей, а “ПУ” - нечто среднее между “Консультирующим” и “Исполняющим” - помогает при необходимости ))).
Может быть конкретное разделение по задачам внутри пункта “Р - Разрабатывает”:
СТ - Собирает требования
Р - Разрабатывает
Т - Тестирует
О - Обучает
Д - пишет документацию (кстати, очень ценный пункт!)
На практике может оказаться, что около одной роли по одному результату несколько букв.
Я обещала озвучить, за счет чего матрица ответственности помогает?
Мы фиксируем обязанности и сообщаем их тем, к кому они относятся (разумеется, если РП просто нарисовал матрицу у себя в блокноте и никому не показал, она ничем не поможет)
Но если мы обсуждаем матрицу ответственности и с представителями ИТ, и с представителями бизнеса, мы можем, условно говоря, “сверить часы” - понять, где у нас точки зрения не сходятся. И либо договориться, либо эскалировать вопрос “наверх”, чтобы нам помогли договориться.
Кстати сказать, и в том случае, когда сотрудники явно не выполняют свои обязанности просто по причине низкой заинтересованности, сам факт существования матрицы, в которых они указаны как ответственные, уже помогает. Во-первых, он все-таки самодисциплинирует. Во-вторых, если ситуацию таки приходится эскалировать наверх, то прописанные обязанности лучше работают как аргумент.
В процессе подготовки самой матрицы всплывают сложности взаимодействия. Например, становятся наглядно видны проблемные места.
В моей практике часто встречаются, например, такие проблемы:
- Спорная зона ответственности руководителя проекта со стороны исполнителя и со стороны заказчика. Кто отвечает за результат, кто принимает решения?
Хороший работающий вариант, как правило - это когда РП со стороны заказчика (ну, или ответственный представитель со стороны бизнеса, если речь идет о внутреннем проекте, когда ИТ-отдел внедряет что-то по запросу бизнес-подразделений/бухгалтерии и т. п.) берет на себя роль “Владельца продукта” - то есть описывает финальную картинку, и видит целевой результат - как то или иное прикладное решение должно работать с позиции пользователя.
А РП со стороны исполнителя (или ответственный айти-специалист, опять же, когда проект внутренний) - отвечает за архитектуру и техническую реализацию. - Практически за все задачи отвечает один и тот же человек (РП?). Он и швец, и жнец и на дуде игрец. И вообще с тоской думает, как ему разорваться на много маленьких “рпшничков”, чтобы успеть сделать если не всё… То хотя бы всё самое необходимое…
На этом месте иногда можно увидеть, что команды проекта-то на самом деле нет. Что всё делает полтора человека, остальные, максимум, готовы проконсультировать… - Проблема, что никто не хочет брать на себя ответственность. Люди не любят принимать решения, особенно в бюрократизированных организациях, где они понимают, что за неправильное решение им может влететь. Вообще, уговорить матерого руководителя что-то подписать - это отдельная история ))). Хотя чаще всего (если есть хоть какая атмосфера сотрудничества и взаимного доверия), уже даже подтверждение на словах/в электронной почте, что “да, я со всем принципиально согласен” - уже помогает дальнейшему взаимодействию. Я уже рассказывала, что в моей практике были ситуации, когда Устав по той или иной причине уполномоченные лица так и не подписывали, но сам факт наличия этого документа, принципиально согласованного, пусть даже и без подписи - уже помогал улучшить взаимодействие.
- Еще одна проблема, которая часто оказывается заметна - это суровая незаменимость. Есть ровно один человек, у которого в голове есть картинка, как должен выглядеть проект. Если этот человек заболевает (или даже просто уходит в отпуск) - никто не представляет, какая ситуация на проекте.
Также благодаря матрице часто можно увидеть спорные пункты, увидеть “выпавшие” куски, которые находятся на стыке обязанностей, и каждая сторона пытается “спихнуть” их на другую.
Коль скоро мы увидели проблемные и спорные места - можно попытаться их обсуждать и разрешать.
А какие проблемы с распределением ответственности встречаются в ваших проектах?
Как получается их разрешать? Поделитесь!
Подробнее об управлении ИТ-проектами вы можете узнать на моих онлайн-курсах
