RACI открывают, когда в проекте слишком много пересечений ролей, «все вроде участвуют, но никто явно не отвечает», а решения зависают между людьми. В такой среде PM постоянно доуточняет, кто должен согласовать, кто выполняет, кого нужно держать в курсе и где вообще проходит граница ответственности.
Что это за подход
RACI полезен как матрица распределения ролей и ответственности. Для PM это способ перевести размытое «мы же договорились» в более явную модель участия: кто отвечает, кто выполняет, кто консультирует и кого информируют.
Когда он нужен
- много ролей и пересечений ответственности;
- проект многослойный или межфункциональный;
- решения зависают на неясности ownership;
- нужно снизить конфликт ожиданий между участниками.
Когда он не нужен
- очень маленькая команда с и так прозрачными ролями;
- если матрицу создают ради галочки и не используют в работе;
- если проблему слабой коммуникации пытаются решить одной таблицей без дальнейшего сопровождения.
Что из него реально применимо для PM
- прояснять ownership по ключевым потокам и решениям;
- снижать путаницу в согласованиях;
- использовать RACI как часть рамки проекта, а не отдельную бюрократию;
- улучшать ожидания вокруг ролей и handoff.
Какие артефакты, ритуалы и правила важны
- ограниченный набор действительно важных зон ответственности;
- явные роли по критичным решениям и артефактам;
- согласование матрицы с участниками, а не создание в одиночку;
- пересмотр при изменении состава или логики проекта.
Какие ошибки чаще всего делают при внедрении
- заполняют матрицу на всё подряд;
- делают слишком много consulted/informed без реальной пользы;
- не используют RACI в живых ситуациях;
- считают, что матрица сама решит ролевой конфликт.
Чем можно заменить или упростить
- короткой ролевой картой по ключевым решениям;
- картой стейкхолдеров, если важнее влияния и ожидания, а не формальная матрица;
- явной фиксацией владельцев в артефактах и статусе.