Используя данный сайт, вы даете согласие на использование файлов cookie
Согласен
  • /
  • /
статья блога

Матрица ответственности RACI: как распределить роли в IT-проекте


Автор: Команда LAN8 | Обновлено: 04.09.2026 | Время чтения: 7 мин
room-business-meeting

Содержание статьи

Что такое матрица ответственности RACI
Почему проект встает, когда роли не закреплены
Какие роли есть в IT-проекте
Матрица RACI для проекта внедрения: готовый пример
Как составить матрицу за пять шагов
Что меняется в маленькой компании и в большой
Пять дыр, из-за которых матрица не работает
Что делать, если ответственного назначить не за кого
Расширенные версии матрицы
Часто задаваемые вопросы
Матрица ответственности RACI – это таблица, в которой видно, кто в проекте делает работу, кто отвечает за результат, с кем нужно советоваться и кого просто держать в курсе. Заводят ее ровно для одного: чтобы задача не зависла между людьми, каждый из которых был уверен, что этим занимается кто-то другой.
Ниже разберем инструмент по частям, покажем заполненную таблицу для проекта внедрения IT-инфраструктуры и ошибки, из-за которых матрица превращается в файл, куда никто не заглядывает

Что такое матрица ответственности RACI

Матрица RACI – это таблица, где по строкам выписаны задачи проекта, по столбцам перечислены роли участников, а на пересечении стоит одна буква. Буква говорит, как именно этот человек участвует в этой задаче: выполняет, отвечает за итог, консультирует или получает информацию.
Инструмент пришел из проектного управления, но работает в любой ситуации, где над одной задачей заняты несколько человек из разных отделов или из разных компаний. Название – аббревиатура из четырех английских слов, которые и обозначают эти четыре способа участия.

Расшифровка RACI: что значат R, A, C и I

R – Responsible, исполнитель. Тот, кто делает работу руками. Исполнителей на одну задачу может быть несколько: например, монтаж ведут два инженера. Общение с ним рабочее и ежедневное.
A – Accountable, ответственный за результат. Тот, с кого спросят, если задача не сделана или сделана плохо. Он не обязан выполнять работу сам, его дело – принять решение, дать ресурсы и подтвердить, что результат достигнут. Ответственный на задачу всегда один.
C – Consulted, консультант. Специалист, без мнения которого решение будет неполным. С ним советуются до того, как работа начата, и общение идет в обе стороны: он не только отвечает, но и возражает.
I – Informed, информируемый. Тот, кого ставят в известность о результате. Связь односторонняя: ему сообщают, его согласия не спрашивают.
Ценность матрицы ответственности не в самих буквах, а в разговоре, который приходится провести, чтобы их расставить. Пока роли не записаны, каждый держит в голове свою версию того, кто за что отвечает, и расхождение вскрывается в худший момент – когда сроки уже сорваны.

Главная путаница – между R и A. Исполнитель делает, ответственный отвечает. Если роли не развести, получится сотрудник, с которого требуют результат, но который не может ни сдвинуть сроки, ни привлечь людей, ни отказаться от невыполнимой задачи. И ответственный должен быть строго один: двое означают, что решение не примет никто.
roli-raci
Четыре роли матрицы: кто выполняет, кто отвечает, с кем советуются и кого информируют

Почему проект встает, когда роли не закреплены

Типичная история выглядит так. Оборудование закуплено, монтаж выполнен, настройка сделана наполовину. Подрядчик считает работы выполненными и ждет подписания, заказчик считает, что сначала надо проверить, как все держится под нагрузкой. Проверить должен был системный администратор, но у него не было ни времени, ни поручения. Проект стоит третью неделю, и при этом никто ничего не нарушил.
Причина не в людях и не в квалификации. Ни в договоре, ни в плане не записано, кто отвечает за приемку и по каким критериям она пройдена. В проектах с распределенной инфраструктурой это стоит особенно дорого: пока не принят один этап, не стартует следующий, а сроки аренды каналов и лицензий уже идут.
Матрица RACI закрывает именно эту дыру. Она не улучшает работу инженеров, а убирает простой между этапами – там, где теряется больше всего времени. Составлять ее удобно вместе с планированием проекта, его этапов и сроков: список работ для обоих документов один и тот же.

Какие роли есть в IT-проекте

  • Со стороны заказчика
    • Владелец бюджета – руководитель компании или финансовый директор. Утверждает деньги и сроки.
    • Куратор проекта – ведет проект со стороны заказчика. Обычно именно он отвечает за большинство этапов.
    • Ответственный за приемку – проверяет результат и подписывает. Часто это тот же куратор, но роль надо назвать отдельно, иначе она теряется.
    • Ключевой пользователь – руководитель подразделения, ради которого делается проект. Говорит, удобно это в работе или нет, до запуска, а не после.
    • Системный администратор – если он в штате есть. Знает, как устроено сейчас, и принимает систему на сопровождение.
  • Со стороны подрядчика
    • Руководитель проекта – держит сроки, состав работ и коммуникацию. Единственная точка входа для заказчика.
    • Архитектор решения – отвечает за то, что схема выдержит нагрузку и состыкуется с тем, что уже работает.
    • Инженер внедрения – выполняет монтаж, настройку, миграцию.
    • Специалист по информационной безопасности – подключается там, где есть персональные данные, удаленный доступ или требования регуляторов.
    • Инженер поддержки – принимает систему после запуска и работает по SLA. Показать его в матрице стоит заранее, чтобы передача не оказалась внезапной.
  • Смежные участники
    • Поставщик оборудования – сроки поставки часто определяют весь график, а влияют на них ни заказчик, ни подрядчик.
    • Аналитик – собирает требования, если проект меняет процессы, а не только железо.
    • Тестировщик – проверяет результат по заранее описанным сценариям.
gruppy-roley
Роли IT-проекта по трем группам: заказчик, подрядчик и смежные участники

Матрица RACI для проекта внедрения: готовый пример

Ниже – заполненная матрица ответственности проекта по замене сетевого оборудования в офисе. Роли сокращены: ВБ – владелец бюджета, КП – куратор от заказчика, СА – системный администратор заказчика, РП – руководитель проекта подрядчика, АР – архитектор решения, ИВ – инженер внедрения.

Задача

ВБ

КП

СА

РП

АР

ИВ

Обследование площадки

I

A

C

R

C

R

Согласование схемы и спецификации

C

A

C

R

R

Утверждение бюджета

A

R

C

C

Закупка и поставка оборудования

I

C

A

R

Монтаж и коммутация

I

I

I

A

C

R

Настройка и миграция сервисов

I

C

C

A

C

R

Обучение сотрудников

A

R

C

R

Приемка работ

I

A

R

C

I

Передача на поддержку

I

A

R

R

C


Смотреть здесь надо на буквы A (ответственные). Бюджет утверждает его владелец, а не руководитель проекта – это единственная строка, где ответственность лежит на первом лице. Все, что касается работ, закреплено за подрядчиком: поставка, монтаж, настройка, потому что только он влияет на эти сроки.
А вот приемка и обучение закреплены за заказчиком, и это принципиально. Подрядчик не может принять работу сам у себя. Если напротив приемки стоит A подрядчика, документ бесполезен: он описывает не проект, а пожелание сдать этап побыстрее.
В строке передачи на поддержку исполнителей двое – администратор заказчика и руководитель проекта. Работу делают с двух сторон, и если не проговорить это заранее, каждая сторона будет ждать другую.

Как составить матрицу за пять шагов

Шаг 1. Выписать задачи. От старта до передачи на поддержку, крупными блоками, от десяти до тридцати строк. Формулировки конкретные: не «внедрение», а «миграция почтовых ящиков».

Шаг 2. Перечислить роли, а не фамилии. В шапку идут должности и функции: люди меняются, а роль остается. Исключение одно – для строки приемки рядом с ролью полезно держать конкретное имя.

Шаг 3. Расставить буквы. Не в одиночку, а на встрече с участниками проекта. Иначе получится документ с вашими предположениями об их работе.

Шаг 4. Проверить по правилам. В каждой строке ровно один ответственный и хотя бы один исполнитель, консультантов не больше двух-трех. Пустые ячейки – нормально, заполнять всю таблицу не нужно.

Шаг 5. Согласовать и положить туда, где смотрят. Матрица RACI должна лежать рядом с планом работ и открываться в один клик. Документ, который надо искать, не работает.

Что меняется в маленькой компании и в большой

Схема одна, но масштаб меняет почти каждый шаг. Ниже – на что смотреть в зависимости от размера бизнеса.

Что

Компания до 50 человек

Компания от 200 человек

Ответственный (A)

как правило один на весь проект – директор или его заместитель

свой на каждое направление: инфраструктура, безопасность, бюджет

Число задач в таблице

10–15, крупными блоками

25–30, с разбивкой по этапам

Как согласовывают

одна встреча на 40 минут

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

Где живет матрица

таблица в общем доступе

в таск-трекере или проектной системе, рядом с задачами

Типичный сбой

один человек во всех ролях сразу

ответственность назначена отделам, а не людям


Малому бизнесу важно не переусложнить: если в проекте пять человек и все на связи, хватит одной таблицы на десять строк. Крупному – наоборот, не упростить: там матрица без привязки к конкретным фамилиям превращается в декларацию.

Пять дыр, из-за которых матрица не работает

Два ответственных на задачу. Выглядит как справедливое разделение, работает как паралич: каждый ждет решения от второго. Лечится просто – оставить одного, второму дать роль консультанта.
Ни одного исполнителя. Строка с ответственным, но без единой буквы R означает, что задачу не делает никто. Такие строки надо искать специально, сами они не всплывут.
Слишком много консультантов. Каждый лишний согласующий добавляет к задаче дни. Проверочный вопрос: что случится, если с ним не посоветоваться. Если ответ «ничего» – он информируемый.
Матрица составлена и забыта. Самая частая. Таблицу сделали на старте, а через месяц состав работ изменился, и документ разошелся с реальностью. Пересматривать RACI имеет смысл на переходе между этапами.
Роли назначены отделам. «Отвечает IT-отдел» – это и есть отсутствие ответственного. В матрице ответственности напротив задачи должен стоять человек с должностью и полномочиями.
И шестая, которую почти не обсуждают: никто не отвечает за приемку и за то, что будет после сдачи. Проект закончился, оборудование работает, а кто чинит его в понедельник утром – не записано нигде. Это прямой путь к простою, стоимость которого обычно выше, чем вся экономия на этапе внедрения. Подробнее о том, во что обходятся незакрытые риски, мы писали в материале про управление рисками IT-проектов.
tipichnye-dyry
Три типичные ошибки в матрице: два ответственных, строка без исполнителя, избыток консультантов

Что делать, если ответственного назначить не за кого

Правило «ответственный должен быть один» упирается в реальность средней компании. Роли, которая отвечала бы за IT-инфраструктуру целиком, там часто просто нет. Есть системный администратор, но он не решает вопросы бюджета и сроков. Есть генеральный директор, но он не может оценить, нужна ли отказоустойчивость и какая именно.
Вариантов честно три. Нанять IT-директора – оправдано, когда инфраструктура большая и меняется постоянно. Назначить ответственным кого-то из бизнеса, чаще финансового директора, и дать ему консультанта с технической стороны. Или передать роль подрядчику, который ведет инфраструктуру и отвечает за решения по ней в рамках договора и SLA.

Проверить, есть ли у вас эта проблема, можно за минуту. Возьмите последний спорный вопрос по IT – продлевать ли лицензии, менять ли сервер, переносить ли почту – и вспомните, кто принял по нему решение. Если решение так и не приняли или его принял тот, кто не разбирается, ответственного за инфраструктуру у вас нет.

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

У классической матрицы RACI есть надстройки. Каждая добавляет к четырем базовым буквам одну-две новые роли под ситуацию, где базовых не хватает.

Вариант

Что добавляет

Когда нужен

RASCI

S – Support, помощник исполнителя

работу делает одна команда, ресурсы дает другая

RACI-VS

V – Verify, проверяющий; S – Sign off, подписывающий

приемка многоступенчатая, с независимым контролем

RACIQ

Q – Quality, контроль качества

есть формальные требования к качеству результата

RACI-DM

D – Decider, решающий; M – Monitor, наблюдающий

в проекте спорят и нужно право последнего слова

CAIRO

O – Omitted, намеренно исключенные

надо явно записать, кого в процесс не вовлекаем

DACI

схема не про работы, а про решения: Driver, Approver, Contributor, Informed

отдельно управляем принятием решений, а не задачами


Общее имя класса – матрица распределения ответственности, или RAM. RACI и ее варианты тут самый распространенный частный случай.
Конструктор матрицы: базовые роли RACI и буквы, которые добавляют расширенные варианты
Начинать с расширенных версий не стоит. Для большинства проектов внедрения хватает четырех базовых ролей, а каждая лишняя буква – это столбец, который придется объяснять команде.

Коротко о главном

Матрица ответственности RACI решает не проблему плохой работы, а проблему пустот между зонами ответственности. Ее ценность в двух местах: строка приемки и правило одного ответственного. Все остальное вторично.
Если при попытке заполнить таблицу выясняется, что напротив половины строк ответственного поставить некого – дело не в таблице. Значит, роль руководителя IT в компании не закрыта, и проекты будут спотыкаться об это снова.
Мы в L8 берем эту роль на себя: ведем инфраструктуру, отвечаем за решения по ней и работаем по SLA с зафиксированным временем реакции. Если хотите разобраться, кто и за что отвечает в вашем IT, начните с виртуального CIO – расскажем, как стратегическое управление ИТ устроено на практике.

Часто задаваемые вопросы

Можно, и чаще всего это руководитель проекта, который и отвечает, и выполняет. Записывается через слэш. Нельзя другое – давать одному человеку все четыре роли: значит, таблицу заполняли формально.
Реализованнные проекты по управлению ИТ проектами
SITA/Аэрофлот — Организация услуги "Сервис управляемого рабочего места"
Обеспечены сервисы по поддержке пользователей и инфраструктуры, поставке оборудования, управлению подменным фондом
30 складов в РФ
8 складов в Европе
Аудит Wi-Fi сети и техническая поддержка офисов для AMWAY
Провели обследование Wi-Fi сети с использованием Ekahau: выявили зоны слабого сигнала и помехи, предложили рекомендации по оптимизации покрытия
Соблюдение SLA
ABB — ИТ-поддержка офисов в 7 странах
Оказываем сервис поддержки офисов ABB в России, Казахстане, Азербайджане, Узбекистане, Эстонии, Латвии и Литве
onsite сопровождение
Читайте также в нашем блоге
Связанные услуги