RASCI Matrix

Команда работает над задачей, в которой формально участвуют три человека — все трое активно вовлечены, дают вклад, участвуют в обсуждениях. Но когда задача застревает на финальном решении, выясняется, что все трое считают себя «ответственными» в разной степени, и ни один явно не понимает, что именно от него требуется: принять решение, выполнить работу руками, дать экспертную помощь исполнителю или просто быть в курсе. Классическая матрица RACI решает эту проблему для трёх из этих четырёх сценариев — но намеренно смешивает в одну роль Consulted и человека, который реально ПОМОГАЕТ исполнителю руками, и эксперта, которого просто спрашивают мнение один раз до начала работы. RASCI — практическое расширение RACI пятой ролью Support (S), явно разделяющее эти два принципиально разных вклада, — но, в отличие от самой RACI, у RASCI нет единого исторического автора или канонической даты появления: это практическая надстройка, органично выросшая внутри крупных, комплексных программ (прежде всего ИТ-инфраструктурных проектов), где различие между «человеком, который реально делает часть работы вместе с исполнителем» и «экспертом, к которому обращаются один раз за консультацией» оказалось слишком значимым, чтобы смешивать их в одной роли Consulted.

Что такое RASCI и когда он нужен

RASCI нужен именно там, где стандартной матрицы RACI уже не хватает — то есть в достаточно крупных, сложных проектах с распределённым исполнением, где часть людей реально выполняет работу РУКАМИ вместе с основным исполнителем (а не просто консультирует его словами). Если в команде и так нет путаницы между «помогает делать» и «даёт совет один раз», пятая роль — не преимущество, а лишняя сложность: RACI с четырьмя ролями проще создать и поддерживать, и для большинства небольших и средних задач её достаточно. RASCI имеет смысл выбирать осознанно, а не по умолчанию — только когда реальная практика показывает, что роль Consulted в RACI регулярно смешивает два разных типа вклада.

RASCI и её ближайшие родственники решают разные задачи: RASCI распределяет роли в ИСПОЛНЕНИИ уже понятной задачи, тогда как RAPID решает вопрос, кто именно ПРИНИМАЕТ РЕШЕНИЕ по сложному многостороннему вопросу, — методики дополняют друг друга, а не конкурируют. Область ролей RASCI также стоит отличать от общей практики делегирования полномочий, которая закрепляет постоянную зону ответственности руководителя, а не роли под конкретную задачу.

Происхождение и исследовательская база

RASCI развивает классическую матрицу RACI, широко применяемую в управлении проектами и процессами начиная с 1950-1970-х годов, добавляя роль Support (S) — участника, оказывающего реальную ресурсную или экспертную помощь исполнителю в самом процессе работы, в отличие от Consulted, чьё участие ограничивается консультацией до или во время принятия решения. У расширения, в отличие от самой RACI, нет единого признанного автора или точной даты первого формального описания — оно, по всем доступным источникам, «выросло» постепенно внутри практики управления крупными, комплексными программами (в частности, масштабными ИТ-инфраструктурными проектами), где стало заметно, что роль Consulted в классической RACI перегружена: под ней оказываются одновременно и человек, реально выполняющий часть работы вместе с исполнителем, и эксперт, дающий разовое мнение. Часто встречающаяся в источниках атрибуция Smith и Erwin (авторы широко используемого практического руководства «Role & Responsibility Charting», Project Management Institute) относится к систематизации практики RACI-чартинга в целом, а не конкретно к созданию пятибуквенного расширения RASCI, — честная формулировка происхождения важнее удобной, но неточной привязки к одному имени.

Вовлечённость нескольких людей в задачу — это нормально, но единоличная подотчётность за итоговое решение должна быть закреплена ровно за одним человеком; если Accountable не назначен явно и однозначно, задача рискует застрять именно в момент, когда нужно решение, а не ещё одно мнение.

Ключевые идеи и принципы

1. Пять чётко разграниченных ролей

   Responsible — непосредственно выполняет работу; Accountable — единолично отвечает за итоговый результат и принимает окончательное решение; Support — оказывает реальную ресурсную или экспертную помощь исполнителю в процессе выполнения работы; Consulted — даёт мнение или консультацию до или во время принятия решения, но не выполняет работу руками; Informed — уведомляется о ходе или результате, но не участвует в самой работе или решении. На практике удобно представлять пять ролей вдоль оси вовлечённости в решение и исполнение: Accountable и Responsible — обязательные роли с реальными полномочиями и обязательствами; Support — обязательная роль с реальным вкладом, но без единоличной ответственности; Consulted и Informed — необязательные роли информационного характера, без прямого вклада в результат.

2. Ровно один Accountable на задачу

   В отличие от роли Responsible, которую могут разделять несколько человек, роль Accountable должна закрепляться ровно за одним человеком на каждую задачу — назначение нескольких Accountable размывает подотчётность и создаёт ситуацию «отвечают все, значит не отвечает никто»; отсутствие явно назначенного Accountable создаёт ту же проблему другим путём — решение просто не принимается, пока кто-то не возьмёт на себя эту роль явно.

3. Роль Support разгружает Responsible без переноса ответственности

   Роль Support явно фиксирует, что человек оказывает реальную помощь в выполнении задачи (в отличие от Consulted, который лишь высказывает мнение до решения), но при этом не несёт ответственности наравне с Responsible и не может быть спутан с ним при оценке результата. Это разграничение особенно ценно в проектах, где часть работы физически распределена между несколькими людьми, но только один из них формально числится исполнителем.

4. Практический тест на выбор между RACI и RASCI

   Простой диагностический вопрос: перечислите всех, кого сейчас помечаете как Consulted в текущей матрице RACI, и для каждого честно ответьте — этот человек РЕАЛЬНО делает часть работы вместе с исполнителем, или просто высказывает мнение один раз? Если для большинства Consulted-ролей ответ «просто высказывает мнение» — RACI достаточно. Если для значимой доли ответ «реально помогает делать» — это сигнал, что нужна отдельная роль Support, и переход на RASCI оправдан. Этот тест стоит проводить честно и явно, а не интуитивно на глаз: если из десяти человек, помеченных как Consulted в текущей RACI-матрице проекта, реальную ручную помощь оказывают трое или больше, — это статистически значимая доля, оправдывающая переход на RASCI; если один-два человека из тридцати — проще явно выделить их исключением, чем перестраивать всю матрицу под редкий случай.

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

Типовые ошибки

1. Ошибка 1: на одну задачу назначено несколько человек с ролью Accountable или ни одного.

   Матрица не соблюдает ключевое правило — ровно один Accountable на задачу, — что либо размывает ответственность между несколькими людьми, либо вовсе не назначает единоличного ответственного за итоговый результат.

   Как избежать

   строго проверять, что каждая задача имеет ровно одного человека с ролью Accountable, не больше и не меньше.

2. Ошибка 2: роли Support и Consulted путаются между собой.

   Участник, реально помогающий выполнять задачу, ошибочно назначается как Consulted (только консультирующий), или наоборот — консультирующий эксперт ошибочно назначается как Support, что искажает реальную картину распределения работы.

   Как избежать

   явно разграничивать Support (реальная помощь в выполнении) и Consulted (консультация до принятия решения) при назначении ролей, используя простой диагностический вопрос «этот человек реально делает часть работы?».

3. Ошибка 3: RASCI применяется по умолчанию там, где хватило бы более простой RACI.

   Команда добавляет пятую роль механически, потому что «так правильнее» или «так полнее», не проверив, действительно ли в проекте реально есть значимое число людей, оказывающих именно ручную/ресурсную помощь, а не консультацию.

   Как избежать

   сначала честно проверить через диагностический тест, оправдана ли пятая роль реальной структурой вклада участников, и только тогда выбирать RASCI вместо более простой RACI.

4. Ошибка 4: формулировки ролей не зафиксированы явно внутри команды перед заполнением матрицы.

   Поскольку у RASCI нет единого официального стандарта, разные участники команды интуитивно понимают границы ролей (особенно Support и Consulted) немного по-разному, что приводит к несогласованному заполнению матрицы.

   Как избежать

   до начала заполнения матрицы явно зафиксировать и согласовать с командой рабочее определение каждой роли — особенно границу между Support и Consulted.

5. Ошибка 5: матрица заполняется один раз и не пересматривается при изменении состава команды или задач.

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

   Как избежать

   регулярно пересматривать матрицу при изменении состава команды или содержания задач, а не считать её составленной раз и навсегда.

Как измерить эффект

• Доля задач с ровно одним Accountable: целевой ориентир — 100%, без исключений «на всякий случай».

• Частота путаницы между Support и Consulted при заполнении: снижение со временем по мере закрепления явного рабочего определения ролей в команде.

• Доля задач, где реально была задействована роль Support, а не только Consulted: подтверждает, что пятая роль оправдана структурой проекта, а не добавлена формально.

• Регулярность пересмотра матрицы: соответствие фактическому пересмотру при значимых изменениях состава команды или содержания задач.

План внедрения

• Неделя 1: составить список ключевых задач или процессов, требующих распределения ролей; проверить диагностическим тестом, оправдана ли пятая роль Support, а не только RACI.

• Неделя 2: явно зафиксировать и согласовать с командой рабочее определение каждой роли — особенно границу между Support и Consulted.

• Неделя 3: назначить роли R/A/S/C/I для каждого участника по каждой задаче.

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

• Далее: регулярно пересматривать матрицу при изменении состава команды или содержания задач.

Как работать с фреймом «RASCI Matrix» в OrgDevTools

Фрейм «RASCI Matrix» в OrgDevTools реализует настоящую матрицу задачи × люди: клик по ячейке циклично переключает роль (—/R/A/S/C/I). Встроенная автоматическая проверка ключевого правила метода отслеживает, что у каждой заполненной задачи ровно один Accountable, — нарушение (ноль или больше одного Accountable) подсвечивается визуально прямо в матрице, а не обнаруживается только при ручной проверке постфактум.

Чего фрейм не делает. Фрейм проверяет только формальное правило «ровно один Accountable» — он не проверяет содержательно, правильно ли разграничены роли Support и Consulted (самая частая типовая ошибка метода): ячейка технически переключается между ними одинаково легко, различение остаётся содержательной дисциплиной заполнения. Он также не хранит определения ролей, согласованные командой, и не напоминает о необходимости пересмотра матрицы при изменении состава команды.

Инструмент: ❌ нет. Отдельного инструмента для распределения ответственности с полноценным документооборотом на платформе не предусмотрено — фрейм фиксирует матрицу ролей с автопроверкой единственности Accountable как учебный тренажёр.

Книги и источники

• Michael L. Smith, Janice Erwin — «Role & Responsibility Charting (RACI)» (Project Management Institute). Широко используемое практическое руководство по чартингу ответственности, систематизирующее практику RACI, на основе которой органично выросли расширения вроде RASCI.