RACI-матрица: как мы навели порядок в проектах без лишних ролей

В большинстве команд проблемы с дедлайнами и качеством возникают не из-за сложности задач. А из-за простого вопроса: "кто за это отвечает?"

Когда ответа нет:

• задачи "висят" неделями
• решения откладываются
• ответственность размывается
• начинается "это не я", "а я думал, что Петя"

До RACI у нас было именно так. После - появилась прозрачность, ушли конфликты, PM перестал быть "девочкой/мальчиком на побегушках".

В нашей компании это выглядело так:

• задача есть - но никто не чувствует ownership
• несколько человек "вроде отвечают" → никто не отвечает на самом деле
• решения затягиваются, потому что непонятно, кто принимает финальное решение
• при проблемах начинается "а мне не сказали", "это не моя зона"

Причина почти всегда одна: роли не зафиксированы. И чем больше команда - тем сильнее эффект.

У нас не было никакой матрицы. Каждый процесс работал "на честном слове". Пока однажды мы не поняли: так больше нельзя.

RACI - это способ четко определить роли в рамках задачи или процесса. Каждая задача получает 4 типа ролей:

• R (Responsible) - кто делает (исполнитель)
• A (Accountable) - кто несет ответственность за результат (один на задачу)
• C (Consulted) - с кем нужно советоваться ДО
• I (Informed) - кого нужно держать в курсе ПОСЛЕ

Звучит просто. Но главный секрет - не копировать шаблон из интернета, а адаптировать под реальные роли в компании.

В интернете пишут, что для RACI нужно много ролей

В нашем отделе есть ровно 5 ролей:

• Участник команды (разработчик)
• Тимлид (технический лидер команды)
• Руководитель тимлидов (руководитель отдела разработки)
• СТО (ИТ-руководитель направления)
• PM (руководитель проектов)

Мы попробовали честно ответить на вопрос: "Кто реально делает эту работу в нашей компании?" И распределили ответственность между теми, кто есть. Ниже - наша адаптированная матрица, которая наконец-то заработала.

Мы взяли ключевые процессы и для каждого честно назначили R, A, C, I. Вот что получилось:

Формально RACI знают многие. Но на практике делают так:

• назначают несколько "A" → никто не отвечает
• делают всех "R" → работу никто не делает
• игнорируют "C" и "I" → хаос в коммуникации
• копируют шаблон из интернета, не адаптируя под реальные роли

В итоге матрица есть, а ясности нет. Мы пошли другим путем: сначала описали реальные роли, потом - процессы, потом - честно распределили. Никаких "идеальных" схем.

В нашей компании до RACI:

• ответственность за задачи пересекалась
• одни и те же вопросы обсуждались на нескольких встречах
• команды ждали друг друга
• решения затягивались
• postmortem’ы не писала никто

Типичная фраза: "мы думали, что это сделает кто-то другой"

Стало очевидно: проблема не в людях и не в загрузке.

Проблема - в отсутствии системы ответственности.

Мы взяли лист бумаги, выписали все процессы, которые "висят", и для каждого написали: кто делает, кто отвечает. Никакой магии. Просто честность. Именно здесь RACI перестал быть "таблицей" и стал реальным инструментом управления.

1. Начали не с матрицы, а с боли

Спросили команду: где задачи зависают? Где конфликты? Где никто не отвечает? Это и есть точки для RACI.

2. Сделали для процессов, а не для каждой задачи

Не нужно матрицу на каждую мелочь. Достаточно: работа с багами, онбординг, планирование, инциденты.

3. Строго один Accountable на процесс

Критичное правило. Если A два человека - ответственности нет. Один человек говорит "да". Это не про контроль, это про ясность.

4. Ограничили количество Responsible

Если "делают все" - не делает никто. 1–2 R - идеально.

5. Явно прописали Consulted и Informed

Это убрало хаос в коммуникации: лишние встречи, лишние сообщения, неожиданные "а почему меня не спросили".

До:

• баги заводятся как попало (в чат, в трекер, на словах)
• непонятно, кто их разбирает
• разработчики и тимлид дублируют работу
• PM "пушит" всех вручную

После (с нашей RACI):

• R - разработчик (фиксит), PM (координирует)
• A - тимлид
• C - СТО (если критичный баг)
• I - руководитель тимлидов

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

До: инцидент произошел. Все тушат пожар. А потом... ничего. Postmortem никто не пишет, потому что "не до того", "непонятно, чья очередь", "тимлид и так занят".

После: мы честно сказали: директора по эксплуатации у нас нет. Значит, за сбор информации отвечает PM (R), за результат - тимлид (A). Консультируется с СТО (C), уведомляет руководителя тимлидов и команду (I).

Результат: postmortem'ы перестали висеть. Да, это не идеальное распределение, но оно честное и работает в нашей реальности.

На практике мы получили:

• сократилось количество "подвисших" задач
• решения стали приниматься быстрее
• исчезло дублирование работы
• снизилась нагрузка на PM и тимлидов
• рутину (фоллоуапы, отчеты, первичный разбор postmortem) мы отдали ИИ - и PM наконец перестал быть "секретарем", а занялся реальным управлением процессами

PM перестает быть "диспетчером" и становится управленцем, который видит систему, а не тонет в операционке.

Основные причины провалов:

• формальное внедрение "для галочки"
• отсутствие объяснения команде - зачем это нужно
• попытка "сделать красиво", а не решить реальную боль
• отсутствие поддержки со стороны руководителей
• копирование шаблона из интернета без адаптации под реальные роли

Мы сделали иначе: начали с боли, адаптировали под 5 ролей, проговорили с командой, закрепили в процессах. И это сработало.

В нашей системе PM:

• выявляет зоны хаоса (где задачи виснут, где конфликты)
• формализует ответственность (не назначает, а помогает команде договориться)
• договаривается с командами и руководителями
• следит за тем, чтобы система реально использовалась
• передает рутину ИИ (фоллоуапы, сводки, первичные отчеты)

Это уже не операционная роль, а управление системой. Именно это я называю настоящим проектным менеджментом.

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

Главный вывод из нашего опыта: RACI - это не про наличие всех ролей из учебника. Это про честный разговор в команде: "Вот наши люди. Вот задачи. Кто что делает?"

У нас не было матрицы - был хаос. Мы создали матрицу - хаос ушел. Не идеальную, а НАШУ. Адаптированную под 5 реальных ролей. И это сработало.

Начинайте не с матрицы, а с конфликтов. И всегда помните: один Accountable - это не рекомендация, а правило.