Обсуждение запуска может зайти в тупик, даже если все понимают варианты. Продуктовая команда хочет выпустить функцию, поддержка просит время на подготовку, разработчики предлагают ограниченный запуск. Пока непонятно, кто вправе принять окончательное решение, следующая встреча рискует закончиться тем же спором.
DACI помогает распределить роли в принятии конкретного решения. На общей доске планирования продукта разместите вопрос, участников, варианты и данные для их оценки. Важно, чтобы решение принял уполномоченный человек, а затронутые команды поняли, что оно меняет в их работе.
За что отвечает каждая роль DACI
В руководстве Atlassian Team Playbook выделены четыре роли:
- Driver — координатор: организует работу над решением, собирает данные и мнения, напоминает о согласованном сроке.
- Approver — принимающий решение: один человек, который делает окончательный выбор по этому вопросу. Он не просто формально утверждает чужое решение.
- Contributors — эксперты: участники, чьи знания помогают оценить варианты. Они влияют на выбор своими доводами; DACI не даёт каждому отдельный голос при голосовании.
- Informed — информируемые: люди, которым нужно знать результат, поскольку он затрагивает их работу, но которые не участвуют в принятии именно этого решения.
Указывайте конкретных людей. Запись «продукт и разработка» не определяет, кто принимает решение. При этом DACI не наделяет человека полномочиями, которых у него нет: проверьте, кто вправе решить вопрос в рамках действующего распределения ответственности.
Сформулируйте один вопрос о запуске
Представим команду, которая разрабатывает новый способ обмена файлами. Функция готова к ограниченному выпуску, но масштаб запуска ещё не согласован. Вопрос звучит так: «Предложить новый способ обмена добровольным участникам пилота, открыть его всем пользователям или отложить доступ до завершения подготовки поддержки?»
Команда выбирает масштаб запуска. Она не решает, можно ли пропустить обязательные проверки безопасности или изменить политику доступа. Такие вопросы остаются за пределами полномочий Approver, если у него нет соответствующих прав. Зафиксируйте границы до обсуждения вариантов.
Ответ нужен до планирования сообщений клиентам. Укажите эту реальную зависимость рядом со сроком решения. Произвольный дедлайн может подтолкнуть к поспешному выбору; связь с конкретной работой объясняет, что именно ожидает решения.
Распределите роли в примере
| Роль | Кто её выполняет | Вклад в решение |
|---|---|---|
| Driver | Менеджер продукта | Собирает описания вариантов, запрашивает недостающие данные и готовит обсуждение. |
| Approver | Руководитель продукта с полномочиями на запуск | Выбирает масштаб запуска с учётом согласованных ограничений. |
| Contributors | Руководители разработки и поддержки, исследователь | Объясняют возможности управления выпуском, готовность поддержки и наблюдения за использованием продукта. |
| Informed | Команды, работающие с клиентами, и ответственный за документацию | Получают информацию о масштабе, сроках и необходимых изменениях в своей работе. |
В одном решении человек может быть экспертом, а в другом — только получателем информации. Ответственный за документацию станет Contributor, если запуск зависит от объяснения сложного изменения прав доступа. Назначайте роли под вопрос, а не закрепляйте их навсегда по должностям.
Сравните варианты по одним и тем же вопросам
Для каждого варианта запишите, что он позволяет сделать, какие риски создаёт и какие условия нужны для запуска. Отделяйте ожидаемую пользу от данных, подтверждающих, что она действительно возникнет.
| Вариант | Зачем его рассматривать | Что ещё нужно выяснить |
|---|---|---|
| Пилот с добровольным участием | Позволяет наблюдать за использованием функции в ограниченной группе. | Можно ли определить участников, поддерживать их и при необходимости вернуть прежний интерфейс? |
| Общий запуск | Не придётся поддерживать разные варианты для разных групп. | Готовы ли материалы поддержки и средства управления выпуском для всей затронутой аудитории? |
| Отсрочка доступа | Даёт время закончить подготовку. | Какие конкретно задачи снимут опасения и кто за них отвечает? |
«Разработчики предпочитают пилот» — мнение. «Выпуск можно ограничить выбранными аккаунтами, но поддержка ещё не проверила новые сообщения об ошибках» — информация для решения. Попросите участника, который лучше всего знает вопрос, пояснить основание и ограничения своего утверждения.
Если команда не знает, можно ли безопасно отменить пилот, запишите открытый вопрос и ответственного. Не превращайте «скорее всего, можно» в подтверждённое условие. Следующим действием координатора может быть получение ответа, а не ещё одна общая встреча.
Примите решение, сохранив возражения
Допустим, проверки подтвердили возможность ограниченного пилота, а поддержка готова работать с выбранной группой. Approver выбирает пилот, но откладывает общий запуск до готовности материалов поддержки. Решение можно записать так:
«Запустить ограниченный пилот с добровольным участием после завершения указанных проверок; не расширять доступ до проверки готовности поддержки».
Зафиксируйте и причину: пилот позволяет наблюдать за использованием функции в масштабе, который команда сейчас способна поддержать. Сохраните опасение руководителя поддержки, рассмотренные данные и условие расширения. Ясное решение не требует утверждать, что все неизвестные устранены.
Если обязательная проверка не пройдена, решение не разрешает двигаться дальше вопреки ей. Укажите, приостановлен ли пилот, меняется ли выбранный вариант или нужен ответ другого уполномоченного лица. Фраза «Approver согласовал» не отменяет исходные ограничения.
Оформите решение на доске Boardmix
В верхней части доски Boardmix разместите вопрос и границы решения, рядом — компактный блок DACI. Ниже добавьте три карточки вариантов с одинаковыми полями: причина, опасение, данные и открытый вопрос. Для окончательного выбора оставьте отдельное место, чтобы его не путали с обсуждаемой идеей.
Во время обсуждения добавляйте ответы рядом с вопросами, которые они закрывают. Непроверенные утверждения отмечайте явно. После выбора запишите решение, обоснование, ответственного за следующее действие и получателей информации. Это рабочая визуальная запись: она не автоматизирует согласование и не выдаёт разрешения на выпуск продукта.
Журнал решений поможет сохранить результат после встречи. Добавьте в него ссылку на рабочую доску вместо копирования каждого комментария. Информируемым участникам нужны сам выбор, его последствия для их работы и доступ к обоснованию, а не снимок встречи без пояснений.
Откройте доску Boardmix для вопроса, к которому команда постоянно возвращается. Сначала сформулируйте его и назовите человека, принимающего решение. Если нет согласия даже по этим двум пунктам, начните с них.
