DACI: как перестать ходить по кругу и наконец принять решение

Есть задачи, которые не блокируются технически.

Их не стопорит код, инфраструктура или отсутствие людей. Их стопорит отсутствие решения.

Например:

— выбрать вариант реализации; — согласовать MVP-объём; — решить: переносим релиз или режем scope; — выбрать владельца спорной зоны; — договориться, что важнее: быстро или красиво.

Вроде бы все участвуют. Все хотят как лучше. Все “за качество”. Но решения нет.

Встречи повторяются. Обсуждения возвращаются к тем же аргументам. Каждый ждёт, что кто-то другой поставит точку.

В итоге задача стоит не потому, что команда не умеет работать. А потому что непонятно, кто принимает решение.

Вот здесь полезен DACI.

Не как бюрократия, а как простой способ заранее разложить роли в решении.

D — Driver Кто двигает процесс: собирает вводные, организует обсуждение, доводит до решения.

A — Approver Кто принимает финальное решение.

C — Contributors Кто даёт экспертизу, аргументы и ограничения.

I — Informed Кого нужно держать в курсе, но не вовлекать в согласование.

Главная польза DACI — он отделяет обсуждение от принятия решения.

Потому что часто проблема не в том, что мало мнений. Проблема в том, что слишком много людей пытаются быть Approver.

Если финальное решение принимают “все”, обычно его не принимает никто.

Например, команда спорит, как реализовать фичу.

Разработчики предлагают варианты. QA говорит о рисках. Аналитик уточняет требования. Продакт держит в голове ценность для бизнеса. Тимлид думает о сроках и техдолге.

Все важны. Но не все должны ставить финальную точку.

DACI помогает заранее спросить:

Кто ведёт процесс? Кто принимает решение? Кто даёт вводные? Кого просто информируем?

Это особенно полезно, когда:

— решение спорное; — есть несколько сильных мнений; — участвуют разные роли или команды; — решение влияет на сроки, scope или архитектуру; — обсуждение уже пошло по третьему кругу.

Частая ошибка — путать Driver и Approver.

Driver не обязан быть самым главным. Он отвечает за движение процесса.

Approver не обязан собирать все детали сам. Он отвечает за финальное “да/нет”.

Ещё одна ошибка — превращать Contributors в согласующих.

Contributor помогает принять решение, но не должен блокировать его бесконечно.

DACI не нужен для каждой мелкой задачи.

Но если обсуждение буксует, достаточно 10 минут, чтобы разложить роли:

Кто Driver? Кто Approver? Кто Contributors? Кто Informed?

И часто сразу становится понятно, почему решение не принимается.

Не потому что люди плохо думают. А потому что команда не договорилась, кто ставит точку.

А у вас в команде решения обычно принимаются явно или выясняется уже по ходу, кто “должен был решить”?