Как Atlassian делает групповые решения проверяемыми: практика DACI
Ситуация: решение тонет между «все участвовали» и «никто не решил»
В проекте может быть много разумных людей и достаточно данных, но решение всё равно зависает. Руководитель ждёт мнений, специалисты ждут постановки, затронутые команды узнают об изменении после факта. На следующей встрече разговор начинается заново: неясно, кто собирает основания, кто выбирает вариант и кого нужно услышать до выбора
В Atlassian для сложных групповых решений используют DACI. В инженерном handbook компания прямо называет DACI рамкой, которую широко применяют внутри компании, когда команде нужно принять непростое решение. Решение документируют по стандартному шаблону в Confluence, а не оставляют в памяти встречи
Как устроен механизм
DACI распределяет не работу вообще, а роли вокруг одного решения:
- **Driver** собирает информацию, задаёт рамку вопроса, связывает участников и ведёт решение к согласованной дате
- **Approver** один принимает окончательное решение
- **Contributors** дают рекомендации и предметные данные, но не получают право блокировать решение голосованием
- **Informed** не участвуют в выборе, но узнают об итоге, потому что их работа будет затронута
На странице Team Playbook Atlassian предлагает сначала описать текущий статус, влияние, участников, срок и ожидаемый результат. Затем собрать релевантные исследования, данные или обратную связь, назвать факторы выбора и варианты с плюсами, минусами и требуемыми ресурсами. Лишь после этого команда собирает входящие мнения, а Approver делает выбор и итог фиксируют в общем документе
Это не правило «решает начальник». У Driver есть обязанность сделать основание решения видимым, а у Approver есть право и обязанность завершить выбор. Поэтому экспертное мнение не исчезает, но не подменяет решение бесконечным согласованием
Где практика применена в действительности
Atlassian описывает DACI не как внешнюю методику для клиентов. В инженерном handbook компания пишет, что использует её внутри и фиксирует решения стандартным шаблоном в Confluence. В отдельном материале команда Atlassian приводит пример: DACI применяли для решений при подготовке ежегодной конференции Atlassian Summit, от выбора спикеров до площадки для вечернего мероприятия
Это важная граница кейса. Мы не утверждаем, что DACI гарантирует результат проекта или заменяет исследование. Практика решает более узкую задачу: делает явными владельца процесса, конечного решающего, источники рекомендаций и круг людей, которым нужен итог
Что здесь близко к МетаРешениям
Логика МетаРешений начинается с вопроса: на чём стоит решение и чья перспектива осталась за кадром. DACI не является МетаРешением, но поддерживает ту же дисциплину:
Вопрос -> факты и критерии -> роли участников -> варианты -> выбор -> зафиксированный итог
Особенно полезна разница между Contributor и Informed. Владелец часто зовёт на обсуждение всех, кого коснётся изменение. Но человеку может быть важно знать итог, не обязательно участвовать в выборе. И наоборот, эксперт, который даёт основание для решения, не всегда должен нести финальную ответственность за него
Как применить в небольшой компании
Возьмите одну развилку, которая не закрывается больше недели: смена канала привлечения, выбор подрядчика, новая услуга или перераспределение роли в команде. На одной странице ответьте:
- Какой конкретный вопрос должен быть решён и к какой дате
- Кто Driver и кто единственный Approver
- Какие два-три человека дадут данные или рекомендации как Contributors
- Кого затронет итог и кому достаточно сообщить решение
- Какие факты, критерии и варианты должен собрать Driver до выбора
- Где будет зафиксирован итог и почему выбрали именно этот вариант
Если после такой страницы решение всё ещё нельзя принять, проблема обычно не в количестве встреч. Значит, не хватает данных, критерий не назван или у выбора пока нет владельца
Если хотите разобрать свою развилку до первой встречи, пройдите мини-разбор МетаРешений
Источники
- Atlassian Engineering handbook о DACI
- Atlassian Team Playbook: DACI Decision-Making Framework
- Atlassian о применении DACI в командных решениях
Разберите одну управленческую развилку
Пять вопросов помогут отделить факт от версии и выбрать следующий проверяемый шаг
Пройти мини-разбор