45% российских организаций вообще не анализируют причины неудач проектов — такую цифру приводит отчёт B1 по управлению проектами в России 2026. За ней стоит конкретная ситуация: проект закрывается с опозданием или провалом, команда собирается на разбор полётов, и никто не может ответить, где именно и чья ответственность «провалилась». Просто потому что её никто не зафиксировал.
Индекс проектного управления СОВНЕТ за 2-й квартал 2025 года остаётся ниже 40 пунктов — это означает слабую формализацию процессов в среднем по рынку. Формализация ролей — часть этой проблемы.
RACI существует как инструмент с 1980-х. Но сейчас матрица переживает смену формата: из отдельной таблицы, которую заполняют на кикоффе и забывают, она превращается во встроенный слой ответственности внутри таск-трекера. Статья покажет, как именно это сделать — от логики ролей до конкретных полей в карточке задачи.
Что стоит за буквами R, A, C, I — и почему путаница между ними убивает сроки
Главная ошибка при знакомстве с RACI — воспринимать четыре буквы как синонимы слова «ответственный». Это четыре принципиально разных типа участия в задаче, и смешение двух из них — R и A — создаёт большинство «серых зон» в проектах.
Разберём каждую роль не через определение из учебника, а через сценарий:
- Responsible (R) — тот, кто делает руками. Разработчик, который пишет код для фичи. Дизайнер, который делает макет. На задачу должен быть ровно один R — иначе каждый думает, что это сделает другой.
- Accountable (A) — тот, кто апрувит результат и отвечает за него перед стейкхолдерами. Продакт-менеджер, который принимает готовую фичу и подписывается под её качеством перед бизнесом. Один A на задачу — жёсткое правило.
- Consulted (C) — эксперт, чьё мнение запрашивают до начала работы. Юрист, которого спрашивают перед запуском рекламной кампании. Безопасник, который проверяет архитектурное решение. Consulted не делает задачу, но его обратная связь влияет на результат.
- Informed (I) — тот, кого уведомляют о результате. Финансовый директор, которому важно знать, что фича выпущена, потому что это влияет на прогноз выручки. Он не участвует в процессе, но должен быть в курсе.
По рекомендации Asana, у каждой задачи должен быть только один R и только один A. Если их два — ответственности нет ни у кого. На практике задача с двумя исполнителями и двумя «владельцами» — задача, которую никто не считает своей.
Atlassian подчёркивает другой важный момент: RACI строится по задачам и результатам, а не по должностям. Не «кто такой тимлид в нашей матрице», а «кто R в задаче "задеплоить хотфикс до пятницы"». Это различие делает RACI рабочей матрицей, а не оргструктурной схемой.
Типичная путаница между R и A выглядит так: разработчик сделал задачу, считает её готовой — и ждёт. Продакт думает, что разработчик сам знает, когда финализировать. В итоге задача висит в статусе «готово» три дня, никто не апрувит, дедлайн сдвигается.
Если бы A был зафиксирован явно, продакт получил бы уведомление и принял решение в тот же день.
Правильная приоритизация задач начинается именно с понимания, кто за какую задачу отвечает — без этого любой фреймворк приоритизации даёт искажённую картину.
Почему RACI в Excel умирает через две недели
Классическая RACI-таблица в отдельном файле теряет актуальность, как только проект начинает жить. Не потому что матрица плохая — потому что она существует отдельно от рабочего потока.
Вот сценарии, которые повторяются в большинстве команд. Новая задача появилась в середине спринта — срочная, важная, но в матрицу её никто не внёс, потому что файл лежит в Confluence, а все работают в трекере. Разработчик ушёл в отпуск, его заменил другой человек, но матрица этого не отражает — команда продолжает работать по памяти или по старой таблице. Матрица заполнялась на кикоффе, когда скоуп был одним, к середине проекта скоуп изменился, а матрица — нет. И наконец, при масштабировании команды новые участники вообще не знают о существовании файла и строят представление о ролях по устным договорённостям, которые у каждого свои.
Формально матрица существует, но описывает другой проект.
Низкий индекс зрелости проектного управления в российских компаниях — это не только отсутствие методологий. Это ситуация, когда формализация процессов слабая в принципе, и отдельный документ с матрицей в таких условиях не выживает: его не обновляют, не смотрят, не используют.
Проблема не в RACI как модели. Проблема в том, что матрица живёт отдельно от задач. Когда команда работает в трекере каждый день, а RACI лежит в папке «Проектная документация», разрыв неизбежен. Если сотрудник меняется или уходит в отпуск, актуальную информацию о доступности команды важно фиксировать там, где живут задачи — об этом подробнее в материале о матрице доступности команды.
Решение — не отказываться от RACI, а вшить её в тот инструмент, где команда и так работает каждый день.
Как перенести RACI в таск-трекер: пошаговый алгоритм
RACI фиксируется не в отдельном документе, а через конкретные поля и механики карточки задачи. Вот как это делается на практике.
Шаг 1. Определите список задач и deliverables, а не функций
Atlassian рекомендует строить RACI по задачам и результатам, а не по должностям. Это означает: сначала выгрузите бэклог проекта, сгруппируйте задачи по этапам или эпикам — это и будут строки вашей матрицы. Не «кто такой архитектор», а «кто R в задаче "согласовать архитектуру микросервиса"».
Практическое правило: если задача достаточно конкретна, чтобы иметь дедлайн и исполнителя — она достаточно конкретна для RACI.
Шаг 2. Зафиксируйте R и A прямо в карточке задачи
Поле «Исполнитель» в карточке — это ваш R. Один человек, который делает руками. Accountable требует отдельного поля или явной пометки в описании задачи: «Владелец результата: [имя]» или кастомное поле «A».
Если в карточке два исполнителя и непонятно, кто из них апрувит результат — вы уже в серой зоне. Два R на задачу означают, что ни один из них не чувствует полной ответственности.
В Shtab исполнитель карточки — это ваш R. Для фиксации A используйте поле описания с форматом «Владелец результата: @имя» или создайте кастомное поле — настраиваемые поля поддерживаются и отображаются прямо в карточке на доске.
Шаг 3. Добавьте C и I через подписчиков, чек-листы или описание
Consulted добавляется в карточку как участник с пометкой «консультант» в описании или через чек-лист: «Получить ревью от [имя] до начала работы». Главное — это должно быть действие с конкретным именем и сроком, а не просто запись в матрице. Informed — подписчик карточки, который получает уведомления при смене статуса. Никаких дополнительных усилий: сменился статус задачи — человек получил уведомление.
Шаг 4. Проверьте матрицу «по столбцам» — ищите перегрузку
Asana рекомендует анализировать матрицу по столбцам: если у одного участника слишком много ролей R — он перегружен. В таск-трекере это проверяется через фильтр по исполнителю и отчёт по загрузке. Посмотрите, сколько активных задач назначено на одного человека в статусе «в работе» — если больше пяти-шести одновременно, R распределены неравномерно.
Это не разовая проверка на старте, а регулярная процедура: при каждом добавлении нового этапа или крупной задачи.
Кейс: как банк убрал вопрос «кто отвечает за это?» с помощью RACI
OTP Bank столкнулся с классической проблемой растущей команды: задачи есть, дедлайны есть, а ответственность размытая. На Habr команда описала ситуацию до внедрения RACI как постоянные вопросы «кто отвечает за это?» на каждом статусном митинге. Никто не саботировал процесс намеренно — просто роли не были зафиксированы явно, и каждый интерпретировал зону своей ответственности по-своему.
После формализации ролей R/A/C/I по задачам вопрос «кто отвечает» перестал быть темой для обсуждения на митингах — ответ стал виден в карточке задачи. Команда не публиковала количественных данных о результатах, но качественный эффект конкретный: время статусных встреч перестало уходить на выяснение владельцев задач.
Другой показательный пример — кейс Exolve по запуску SMS API. Команда работала над первым сложным проектом по запуску триггерных SMS-кампаний: неясные роли порождали итерации по проектной документации и задержки в согласованиях. После внедрения RACI и уточнения подписантов по каждой задаче первый месяц работы дал 50 000 SMS с доставляемостью 98%. Это не прямой эффект от матрицы — но устранение операционной неразберихи на старте проекта позволило запустить кампанию без сбоев.
Оба кейса подтверждают одно: RACI не ускоряет работу магически. Она убирает потери времени на выяснение «чья это задача».
Неочевидная ловушка: RACI может усилить бюрократию, если применять её ко всему подряд
Честный разговор о RACI невозможен без этого раздела. Матрица полезна не для каждой задачи. Если назначать четыре роли на каждый мелкий тикет, она превращается из инструмента ясности в инструмент замедления.
Когда RACI действительно нужна? Когда над задачей работают люди из разных команд или отделов и непонятно, кто принимает финальное решение. Когда есть внешние подрядчики, и зоны ответственности между ними и внутренней командой не очевидны. Когда задача требует формального апрува перед переходом к следующему этапу — например, согласование архитектуры или юридическая проверка перед запуском.
Для рутинных задач внутри одной команды — «написать unit-тест», «обновить README», «исправить опечатку в интерфейсе» — достаточно одного исполнителя. Перегружать карточку ролями C и I не нужно: это создаёт шум без пользы.
Практический критерий: если вы не можете за пять секунд назвать, кто A по этой задаче — RACI нужна. Если можете — скорее всего, нет.
Ещё один сигнал избыточности: если у одного человека в матрице слишком много ролей одновременно — это не признак его важности, это признак того, что RACI применена там, где она не нужна, или что нагрузка распределена неправильно. Для кросс-функциональных задач с размытыми рисками и зависимостями RACI работает хорошо. Для линейных задач одной команды — добавляет бюрократии без добавления ясности.
Как поддерживать RACI живой: что делать, чтобы матрица не устарела через спринт
RACI — не разовая фиксация. Если пересматривать матрицу только на старте проекта, через месяц она описывает другую реальность.
Пересматривайте роли при каждом крупном изменении скоупа. Новый этап, новый подрядчик, смена приоритетов — повод пройтись по карточкам и проверить, актуальны ли R и A. Это занимает 15–20 минут, если матрица живёт в трекере, и полдня, если нужно искать файл в Confluence.
Используйте ретроспективу для аудита матрицы. Один вопрос на ретро: «Были ли задачи, где было непонятно, кто принимает решение?» Если да — либо RACI не обновлена, либо роли были назначены формально и не соответствуют реальному распределению работы. Это быстрее обнаружить через ретро, чем через постфактум-разбор провала.
Автоматизируйте уведомления для роли I. Если Informed не получает уведомлений автоматически при смене статуса задачи — роль существует только на бумаге. В Shtab это решается подпиской на карточку (функция «Наблюдатель»): подписчик получает уведомление при каждом изменении карточки, и роль I работает без ручного контроля. Никаких «не забудь написать Ивану, что задача закрыта» — система делает это сама.
Обновляйте матрицу при смене участника команды. Когда человек уходит в отпуск, увольняется или переходит на другой проект, его роли R и A не исчезают — они переходят к кому-то другому. Если этот переход не зафиксирован в карточках, задачи зависают без владельца. Простое правило: при любом кадровом изменении пройдитесь по фильтру задач этого участника и переназначьте роли явно.
Все четыре практики объединяет простая экономика: поддержание RACI должно стоить меньше, чем неопределённость, которую матрица устраняет. Если обновление занимает больше времени, чем разбор вопроса «кто отвечает» — что-то настроено неправильно.
FAQ: частые вопросы о матрице RACI
Как называется матрица RACI по-русски?
Матрица распределения ответственности, или матрица назначения ответственности. Аббревиатура RACI не переводится — в профессиональном обороте используются оригинальные термины: Responsible, Accountable, Consulted, Informed. Иногда встречается вариант «РАСО» (Работает, Апрувит, Советует, Оповещён), но он не стандартизирован и в серьёзных проектных командах не прижился.
Чем RACI отличается от RASCI, DACI и других вариаций?
RASCI добавляет роль Support — помощник исполнителя, который участвует в задаче, но не несёт основной ответственности. DACI заменяет Responsible на Driver — тот, кто движет задачу вперёд. Для большинства проектных команд классической RACI достаточно. Усложнение модели оправдано при масштабных кросс-функциональных проектах, где нужно явно разделить «делает» и «помогает делать».
Можно ли использовать RACI в Agile-командах?
Да, с адаптацией. В Scrum роль A часто совпадает с Product Owner для бизнес-результата или со Scrum Master для процесса. RACI особенно полезна на стыке команд — там, где Agile-фреймворк не регламентирует ответственность: например, при взаимодействии продуктовой команды с юридическим отделом или внешним подрядчиком. При масштабировании на несколько команд (SAFe, Agile Release Train) матрица становится ещё важнее: без явной фиксации A на уровне межкомандных зависимостей вопрос «кто владелец этого результата» возникает на каждом PI Planning.
Где скачать шаблон матрицы RACI?
Готовые шаблоны в Excel есть у Smartsheet и ProjectManager. Скачать и заполнить — рабочий вариант для старта. Долгосрочно лучше зафиксировать роли прямо в таск-трекере: тогда матрица остаётся актуальной, а не превращается в документ, который обновляют раз в квартал.
RACI работает, когда она живёт там же, где живут задачи — в карточках трекера, а не в отдельном файле. Перенос ролей R/A/C/I в карточки — это базовая гигиена: каждая задача имеет одного исполнителя, одного владельца результата, и все нужные люди получают информацию автоматически.
Начните с одного проекта. Откройте бэклог и пройдитесь по задачам с вопросом: «Кто R? Кто A?» Там, где ответ неочевиден, зафиксируйте роли прямо в карточке — исполнителя и владельца результата. Затем добавьте подписчиков для роли I. На это уйдёт один рабочий час, а на следующем статусном митинге вы увидите разницу: вместо обсуждения «чья это задача» команда будет обсуждать саму задачу.