DACI: как перестать ходить по кругу и наконец принять решение
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?
И часто сразу становится понятно, почему решение не принимается.
Не потому что люди плохо думают.
А потому что команда не договорилась, кто ставит точку.
А у вас в команде решения обычно принимаются явно или выясняется уже по ходу, кто “должен был решить”?
Есть задачи, которые не блокируются технически.
Их не стопорит код, инфраструктура или отсутствие людей.
Их стопорит отсутствие решения.
Например:
— выбрать вариант реализации;
— согласовать 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?
И часто сразу становится понятно, почему решение не принимается.
Не потому что люди плохо думают.
А потому что команда не договорилась, кто ставит точку.
А у вас в команде решения обычно принимаются явно или выясняется уже по ходу, кто “должен был решить”?