Матрица RACI: как распределить ответственность в ИТ-команде
«Я думал, это Петя делает»
Задача не сделана. Разработчик говорит, что ждал аналитика. Аналитик — что не получил данные от заказчика. Заказчик — что не знал, что от него что-то требуется. Знакомая картина?
Проблема не в людях, а в отсутствии системы. Когда непонятно, кто за что отвечает, люди перекладывают ответственность друг на друга. Это не злой умысел — это защитная реакция на неопределённость. Матрица RACI — простой инструмент, который отвечает на четыре вопроса: кто делает, кто отвечает, с кем советоваться и кого информировать.
Что такое RACI
Аббревиатура из четырёх букв, каждая обозначает уровень участия.
R — Responsible (Исполнитель), тот, кто делает работу. Их может быть несколько на одну задачу.
A — Accountable (Ответственный), тот, кто отвечает за результат и принимает работу. На каждой задаче должен быть только один A.
C — Consulted (Консультируемый), тот, с кем нужно проконсультироваться до выполнения. Это эксперты.
I — Informed (Информируемый), тот, кого нужно поставить в известность после выполнения.
Правила простые: на каждой задаче ровно один A, A не может быть тем же человеком, что и R (нельзя, чтобы исполнитель сам себе принимал работу), и C и I должны быть только нужными людьми, иначе согласования будут длиться вечно.
Какие проблемы решает RACI
Размытая ответственность — кто делает? R. Если в строке нет R — задача не будет сделана. Долгие согласования — если всех подряд включают в обсуждение, вы оставляете только нужных в C и I. Никто не принимает результат — кто утверждает? A. Если нет A — задачу некому закрыть. Конфликты приоритетов — чьи задачи важнее? A решает. Перегрузка — у кого слишком много A? Это видно в матрице.
Как составить RACI
Выпишите ключевые задачи (10–15 штук). Определите роли в проекте (РП, аналитик, разработчик, тестировщик, архитектор, DevOps, заказчик). Назначьте R — исполнителя, A — ответственного (только одного). Определите C — с кем советоваться, и I — кого информировать. Проверьте правила: один A, A ≠ R, только нужные C и I. И согласуйте матрицу с командой — все должны знать свои роли.
Пример RACI для ИТ-проекта
Возьмём проект по внедрению модуля «Командировки и авансовые отчёты». Роли: РП, аналитик, разработчик, тестировщик, архитектор, заказчик, DevOps.
Согласование требований. Аналитик — Responsible, РП — Accountable, архитектор и заказчик — Consulted.
Разработка модуля. Разработчик — Responsible, РП — Accountable, архитектор — Consulted, заказчик — Informed.
Настройка CI/CD. DevOps — Responsible, РП — Accountable, разработчик — Consulted.
Тестирование интеграции. Тестировщик — Responsible, РП — Accountable, разработчик и DevOps — Consulted.
Приёмка этапа. Заказчик — Responsible, РП — Accountable.
В этом примере РП — Accountable на всех задачах, что нормально для небольших проектов: он отвечает за результат.
Частые ошибки
Несколько A на задачу — ответственность размыта, оставляйте ровно одного. Нет A — задачу некому закрыть, назначайте всегда. A = R — исполнитель сам себе принимает работу, конфликт интересов. Слишком много C и I — согласования тянутся неделями. RACI не согласована с командой — никто не знает, что от него ждут. RACI составлена и забыта — документ устаревает, пересматривайте его после каждой крупной вехи.
Что в понедельник утром
Выпишите 5–7 ключевых задач из вашего проекта. Назначьте для каждой R, A, C, I. Проверьте: на каждой задаче ровно один A. Покажите матрицу команде и спросите: «Все согласны? Что мы упустили?».
Заключение
RACI отвечает на вопросы: кто делает, кто отвечает, с кем советоваться, кого информировать. Правила: один A, A ≠ R, только нужные C и I. И главное — это живой документ, пересматривайте его по мере изменения проекта.
Хотите научиться распределять ответственность в ИТ-проектах на практике? В модуле 4 курса «Мастер управления IT-проектами» мы на воркшопах составляем RACI для ваших реальных проектов. Подробнее о курсе →