На проде эксплуатируется уязвимость в критичном сервисе. ИБ фиксирует её три недели назад и заводит тикет на патч. Тикет уходит в очередь к ИТ. Инженеры патчат тестовый стенд, но изменение на проде требует подтверждения владельца сервиса, потому что меняет его конфигурацию. Окно на изменения бывает раз в неделю. Владелец сервиса в отпуске, а тот, кто его замещает, не в курсе про тикет вообще. Через три недели происходит инцидент.

Разбор полётов. ИБ говорит: мы нашли и завели тикет, наша работа сделана. Инженеры говорят: мы всё пропатчили на тесте, ждали подтверждения владельца и ближайшее окно. Замещающий говорит: мне не передавали контекст. Владелец, вернувшись из отпуска, говорит: я вообще не знал, что меня кто-то ждёт. Все выполнили ровно то, что от них требовалось. Патч так и не встал на прод.

Что, кто-то плохо работал? Нет. Дело в построении системы, в которой за конечный результат, "уязвимость закрыта на проде", конкретно отвечает - никто. За куски процесса, да: обнаружение, подготовка патча, согласование, передача дел на время отпуска. Каждый кусок закрыт. Результат все равно не достигнут. Может просто у них нет RACI? Да есть конечно. Только крутится вокруг задач, а не результата.

Что я имею в виду?

Первое. Стройте RACI не на уровне задач, а на уровне результата. Не "кто отвечает за патч", а "кто отвечает за то, что уязвимость закрыта на проде к такой-то дате". Это разные вопросы, и вторая формулировка сразу показывает, есть ли реальный владелец или их пять штук с разной степенью причастности.

Второе. У каждого результата должен быть один Accountable, даже если Responsible пять человек из разных команд. Если на вопрос "кто отвечает за то, что это закрыто" вы получаете список отделов, а не одно имя (да-да вы правильно поняли роль\должность), RACI не работает, независимо от того, насколько красиво он оформлен в Confluence.

Третье. Провели постмортем? Одним из результатов должна быть перепроверка RACI. Это также нужно, чтобы сделать систему «чуть менее тупой». Задайтесь вопросом: "кто должен был предотвратить именно это, а не общую категорию похожих проблем". Общие роли в регламенте почти всегда расходятся с конкретной ситуацией. Пересмотрите правила игры.

Четвертое. Явно фиксируйте, что происходит, если владелец результата временно недоступен. Без этого ответственность уехала загорать на пляж. Она не переходит на кого-то другого автоматически, как бы вам ни хотелось или мечталось.

И снова вам домашнее задание: возьмите один активный проект или сервис и посмотрите на него под углом не "кто в нём участвует", а "кто отвечает, если результата не будет". Если на этот вопрос нет одного "имени", у вас есть скрытая угроза.