RACI: как понять, кто за что отвечает, пока всё не развалилось
RACI: как понять, кто за что отвечает, пока всё не развалилось
Есть неприятный момент в командной работе.
Пока всё идёт нормально, кажется, что все всё понимают.
Кто делает задачу.
Кто принимает решение.
Кого надо спросить.
Кого просто поставить в курс дела.
А потом что-то ломается.
Задача зависает.
Релиз едет.
Решение не принято.
Баг всплыл уже на проде.
Бизнес спрашивает: “А кто за это отвечает?”
И внезапно в комнате становится очень тихо.
Потому что “мы же все договорились” часто означает “каждый понял договорённость по-своему”.
Вот тут полезен RACI.
Не как большая бюрократическая табличка на 40 строк, которую никто не откроет после встречи.
А как простой способ заранее проговорить роли.
RACI — это четыре вопроса:
R — Responsible
Кто реально делает работу?
A — Accountable
Кто отвечает за итоговое решение и результат?
C — Consulted
С кем надо посоветоваться до решения?
I — Informed
Кого нужно просто держать в курсе?
На бумаге звучит очевидно.
В жизни именно на этом часто всё и ломается.
Например, команда делает новую фичу.
Разработчик пишет код.
Аналитик уточняет требования.
QA проверяет.
Тимлид помогает с техническими решениями.
Продакт ждёт результат.
Бизнес хочет “чтобы к пятнице”.
И вроде бы все участвуют.
Но кто принимает финальное решение, можно ли резать скоуп?
Кто отвечает за то, что требования достаточно понятны?
Кого надо обязательно спросить перед изменением поведения?
Кого достаточно просто предупредить?
Если это не проговорить, начинаются знакомые симптомы:
— “я думал, это продакт решает”
— “я ждал подтверждения от аналитика”
— “мы не знали, что это важно для поддержки”
— “почему нас не позвали на обсуждение?”
— “а кто вообще должен был это проверить?”
RACI хорош тем, что быстро подсвечивает серые зоны.
Особенно в местах, где много пересечений:
— релизы
— инциденты
— технический долг
— изменения требований
— интеграции между командами
— найм
— онбординг
— production-ready критерии
— спорные продуктовые решения
Самая частая ошибка — путать Responsible и Accountable.
Responsible — делает.
Accountable — отвечает за итог.
Например, разработчик может быть Responsible за реализацию задачи.
Но Accountable за техническое решение может быть тимлид или техлид.
Или QA может быть Responsible за проверку сценариев.
Но Accountable за качество релиза всё равно может быть команда целиком или конкретный владелец релиза.
Ещё одна ошибка — назначать слишком много Accountable.
Если за итог “отвечают все”, часто не отвечает никто.
В RACI на одну активность лучше иметь одного Accountable.
Не потому что остальные не важны.
А потому что в спорный момент должно быть понятно, кто принимает финальное решение.
И наоборот: Consulted не должен превращаться в “давайте согласуем со всеми”.
Если каждого человека делать обязательным участником решения, процесс быстро встанет.
Иногда человеку достаточно быть Informed: знать, что решение принято, но не блокировать его.
Для тимлида RACI полезен не тем, что добавляет ещё одну управленческую модель.
Он полезен тем, что помогает задавать простые вопросы до того, как начался пожар:
Кто делает?
Кто принимает финальное решение?
Кого надо спросить заранее?
Кого просто предупредить?
Я бы не стал тащить RACI на каждую маленькую задачу.
Но если задача пересекает несколько ролей, команд или зон ответственности, 10 минут на такую раскладку могут сэкономить несколько дней переписок потом.
Мини-упражнение на завтра:
возьмите одну текущую задачу, которая уже начала буксовать, и попробуйте разложить её по RACI.
Не идеально.
Просто честно.
Кто сейчас Responsible?
Кто Accountable?
Кого почему-то не спросили?
Кого, наоборот, зря держат в согласовании?
Очень часто уже на этом этапе становится понятно, почему задача стоит.
Не потому что люди плохо работают.
А потому что команда не договорилась, кто за что отвечает.
А у вас в команде роли обычно проговорены заранее или выясняются уже в момент пожара?
Есть неприятный момент в командной работе.
Пока всё идёт нормально, кажется, что все всё понимают.
Кто делает задачу.
Кто принимает решение.
Кого надо спросить.
Кого просто поставить в курс дела.
А потом что-то ломается.
Задача зависает.
Релиз едет.
Решение не принято.
Баг всплыл уже на проде.
Бизнес спрашивает: “А кто за это отвечает?”
И внезапно в комнате становится очень тихо.
Потому что “мы же все договорились” часто означает “каждый понял договорённость по-своему”.
Вот тут полезен RACI.
Не как большая бюрократическая табличка на 40 строк, которую никто не откроет после встречи.
А как простой способ заранее проговорить роли.
RACI — это четыре вопроса:
R — Responsible
Кто реально делает работу?
A — Accountable
Кто отвечает за итоговое решение и результат?
C — Consulted
С кем надо посоветоваться до решения?
I — Informed
Кого нужно просто держать в курсе?
На бумаге звучит очевидно.
В жизни именно на этом часто всё и ломается.
Например, команда делает новую фичу.
Разработчик пишет код.
Аналитик уточняет требования.
QA проверяет.
Тимлид помогает с техническими решениями.
Продакт ждёт результат.
Бизнес хочет “чтобы к пятнице”.
И вроде бы все участвуют.
Но кто принимает финальное решение, можно ли резать скоуп?
Кто отвечает за то, что требования достаточно понятны?
Кого надо обязательно спросить перед изменением поведения?
Кого достаточно просто предупредить?
Если это не проговорить, начинаются знакомые симптомы:
— “я думал, это продакт решает”
— “я ждал подтверждения от аналитика”
— “мы не знали, что это важно для поддержки”
— “почему нас не позвали на обсуждение?”
— “а кто вообще должен был это проверить?”
RACI хорош тем, что быстро подсвечивает серые зоны.
Особенно в местах, где много пересечений:
— релизы
— инциденты
— технический долг
— изменения требований
— интеграции между командами
— найм
— онбординг
— production-ready критерии
— спорные продуктовые решения
Самая частая ошибка — путать Responsible и Accountable.
Responsible — делает.
Accountable — отвечает за итог.
Например, разработчик может быть Responsible за реализацию задачи.
Но Accountable за техническое решение может быть тимлид или техлид.
Или QA может быть Responsible за проверку сценариев.
Но Accountable за качество релиза всё равно может быть команда целиком или конкретный владелец релиза.
Ещё одна ошибка — назначать слишком много Accountable.
Если за итог “отвечают все”, часто не отвечает никто.
В RACI на одну активность лучше иметь одного Accountable.
Не потому что остальные не важны.
А потому что в спорный момент должно быть понятно, кто принимает финальное решение.
И наоборот: Consulted не должен превращаться в “давайте согласуем со всеми”.
Если каждого человека делать обязательным участником решения, процесс быстро встанет.
Иногда человеку достаточно быть Informed: знать, что решение принято, но не блокировать его.
Для тимлида RACI полезен не тем, что добавляет ещё одну управленческую модель.
Он полезен тем, что помогает задавать простые вопросы до того, как начался пожар:
Кто делает?
Кто принимает финальное решение?
Кого надо спросить заранее?
Кого просто предупредить?
Я бы не стал тащить RACI на каждую маленькую задачу.
Но если задача пересекает несколько ролей, команд или зон ответственности, 10 минут на такую раскладку могут сэкономить несколько дней переписок потом.
Мини-упражнение на завтра:
возьмите одну текущую задачу, которая уже начала буксовать, и попробуйте разложить её по RACI.
Не идеально.
Просто честно.
Кто сейчас Responsible?
Кто Accountable?
Кого почему-то не спросили?
Кого, наоборот, зря держат в согласовании?
Очень часто уже на этом этапе становится понятно, почему задача стоит.
Не потому что люди плохо работают.
А потому что команда не договорилась, кто за что отвечает.
А у вас в команде роли обычно проговорены заранее или выясняются уже в момент пожара?