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?
И часто сразу становится понятно, почему решение не принимается.
Не потому что люди плохо думают.
А потому что команда не договорилась, кто ставит точку.
А у вас в команде решения обычно принимаются явно или выясняется уже по ходу, кто “должен был решить”?
❤2👍1
Flow Efficiency: почему задача больше ждёт, чем делается
Задача попала в работу в понедельник.
На прод уехала в следующую пятницу.
На календаре — 10 дней.
Выглядит так, будто команда 10 дней делала задачу. Но если разложить путь по этапам, картина обычно менее героическая:
- разработка заняла 1 день;
- ревью — 2 часа;
- тесты — полдня;
- остальное время задача просто ждала.
Ждала уточнений.
Ждала ревью.
Ждала тестирования.
Ждала согласования.
Ждала релиза.
Ждала, пока кто-нибудь вспомнит, что она вообще существует.
Вот это и показывает Flow Efficiency.
Простыми словами:
Flow Efficiency — это доля времени, когда задача реально двигалась, по сравнению со всем временем её жизни в процессе.
Есть active time: над задачей пишут код, ревьюят, тестируют, выкатывают.
Есть waiting time: задача лежит в очереди и ничего полезного с ней не происходит.
Формула без страданий:
Flow Efficiency = время активной работы / общее время прохождения задачи
Если задача ехала 10 дней, а реально над ней работали 2 дня, то проблема, скорее всего, не в том, что разработчики медленно печатают.
Проблема в ожиданиях между этапами.
Для тимлида это полезная метрика, потому что она показывает не «кто виноват», а где поток ломается:
- задачи копятся перед ревью;
- требования долго уточняются;
- тестирование становится бутылочным горлышком;
- согласования съедают сроки;
- у людей слишком много параллельной работы;
- WIP раздут, поэтому всё начато и почти ничего не закончено.
И это очень хороший разговор с бизнесом.
Потому что иногда запрос звучит так:
«Давайте разработчики будут быстрее писать код».
А Flow Efficiency показывает:
«Даже если код писать в два раза быстрее, общий срок почти не изменится, потому что задача большую часть времени ждёт ревью, тестов и согласований».
Это неприятно, зато честно.
Теперь важная часть из рубрики «метрики без насилия».
Flow Efficiency не надо использовать как палку.
Не надо:
- мерить каждого разработчика отдельно;
- требовать 100% эффективности;
- делать выводы по одной задаче;
- сравнивать баг, исследование и большую фичу как одинаковые сущности;
- превращать метрику в повод для охоты на виноватых.
100% Flow Efficiency — это не цель. Это почти фантазия.
У нормальной команды задачи иногда ждут. Вопрос не в том, чтобы убрать ожидание полностью. Вопрос в том, чтобы увидеть, где ожидание стало системой.
Что делать, если Flow Efficiency низкая:
- уменьшить WIP;
- договориться о правилах ревью;
- быстрее уточнять требования;
- назначить владельцев согласований;
- резать крупные задачи;
- автоматизировать ручные проверки;
- явно подсвечивать задачи без движения;
- улучшать один участок за раз, а не «чинить весь процесс» разом.
Главный вывод такой:
Низкая Flow Efficiency часто означает не то, что люди медленно работают.
Она означает, что система плохо пропускает задачи через себя.
Люди могут быть заняты весь день. Календарь может быть забит. Чаты могут кипеть. Но если задачи при этом лежат в очередях, поток всё равно медленный.
А если разложить ваши задачи по времени, где будет больше ожидания: требования, ревью, тесты, согласования или релиз?
Задача попала в работу в понедельник.
На прод уехала в следующую пятницу.
На календаре — 10 дней.
Выглядит так, будто команда 10 дней делала задачу. Но если разложить путь по этапам, картина обычно менее героическая:
- разработка заняла 1 день;
- ревью — 2 часа;
- тесты — полдня;
- остальное время задача просто ждала.
Ждала уточнений.
Ждала ревью.
Ждала тестирования.
Ждала согласования.
Ждала релиза.
Ждала, пока кто-нибудь вспомнит, что она вообще существует.
Вот это и показывает Flow Efficiency.
Простыми словами:
Flow Efficiency — это доля времени, когда задача реально двигалась, по сравнению со всем временем её жизни в процессе.
Есть active time: над задачей пишут код, ревьюят, тестируют, выкатывают.
Есть waiting time: задача лежит в очереди и ничего полезного с ней не происходит.
Формула без страданий:
Flow Efficiency = время активной работы / общее время прохождения задачи
Если задача ехала 10 дней, а реально над ней работали 2 дня, то проблема, скорее всего, не в том, что разработчики медленно печатают.
Проблема в ожиданиях между этапами.
Для тимлида это полезная метрика, потому что она показывает не «кто виноват», а где поток ломается:
- задачи копятся перед ревью;
- требования долго уточняются;
- тестирование становится бутылочным горлышком;
- согласования съедают сроки;
- у людей слишком много параллельной работы;
- WIP раздут, поэтому всё начато и почти ничего не закончено.
И это очень хороший разговор с бизнесом.
Потому что иногда запрос звучит так:
«Давайте разработчики будут быстрее писать код».
А Flow Efficiency показывает:
«Даже если код писать в два раза быстрее, общий срок почти не изменится, потому что задача большую часть времени ждёт ревью, тестов и согласований».
Это неприятно, зато честно.
Теперь важная часть из рубрики «метрики без насилия».
Flow Efficiency не надо использовать как палку.
Не надо:
- мерить каждого разработчика отдельно;
- требовать 100% эффективности;
- делать выводы по одной задаче;
- сравнивать баг, исследование и большую фичу как одинаковые сущности;
- превращать метрику в повод для охоты на виноватых.
100% Flow Efficiency — это не цель. Это почти фантазия.
У нормальной команды задачи иногда ждут. Вопрос не в том, чтобы убрать ожидание полностью. Вопрос в том, чтобы увидеть, где ожидание стало системой.
Что делать, если Flow Efficiency низкая:
- уменьшить WIP;
- договориться о правилах ревью;
- быстрее уточнять требования;
- назначить владельцев согласований;
- резать крупные задачи;
- автоматизировать ручные проверки;
- явно подсвечивать задачи без движения;
- улучшать один участок за раз, а не «чинить весь процесс» разом.
Главный вывод такой:
Низкая Flow Efficiency часто означает не то, что люди медленно работают.
Она означает, что система плохо пропускает задачи через себя.
Люди могут быть заняты весь день. Календарь может быть забит. Чаты могут кипеть. Но если задачи при этом лежат в очередях, поток всё равно медленный.
А если разложить ваши задачи по времени, где будет больше ожидания: требования, ревью, тесты, согласования или релиз?
❤2
Definition of Ready: как не отдавать в разработку задачу-тыкву
Задача попадает в разработку.
Исполнитель назначен.
Срок уже обсуждают.
В Jira статус «В работе».
Через час появляются первые вопросы:
— а какую проблему решаем?
— какой сценарий основной?
— кто принимает результат?
— что делать с пограничными случаями?
— где макеты?
— а зависимость от соседней команды точно закрыта?
Формально задача в работе.
Фактически команда только начала выяснять, что вообще нужно сделать.
И вот здесь начинается дорогой жанр: разработка как способ уточнения требований.
Команда может быстро писать код, оперативно ревьюить и регулярно выкатываться. Но если на вход приходит задача без цели, контекста и критериев готовности, delivery ломается ещё до первой строки кода.
Для этого и нужен Definition of Ready.
Definition of Ready, или DoR, — это договорённость команды о минимальных условиях, при которых задачу можно брать в работу.
Не огромный чек-лист.
Не новая церемония.
Не бюрократический забор вокруг разработки.
А простой фильтр от задач вида:
- «сделайте примерно как у конкурента»;
- «надо срочно, детали уточним потом»;
- «там всё понятно»;
- «начните пока, а бизнес определится по ходу».
То есть от классического управленческого оптимизма, оплаченного временем разработчиков.
Что может входить в DoR для обычной продуктовой задачи:
- понятна цель изменения;
- описан ожидаемый результат;
- есть критерии приёмки;
- определены основные сценарии;
- известны зависимости;
- доступны макеты, контракты или нужные данные;
- понятно, кто отвечает на вопросы;
- задача достаточно мала, чтобы её можно было закончить;
- команда видит основные риски.
Важно: DoR зависит от типа задач.
Для бага он один.
Для продуктовой фичи другой.
Для исследования третий.
Для срочного инцидента вообще могут быть отдельные правила.
Если сделать один универсальный список на 37 пунктов, команда быстро научится его ненавидеть. И будет права.
DoR должен помогать стартовать осознанно, а не превращать подготовку задачи в археологическую экспедицию.
Простой пример.
Без DoR задача уходит в разработку, а потом:
- два дня ждут уточнений;
- переделывают решение после первого показа;
- внезапно находят зависимость от другой команды;
- выясняют, что критерии приёмки все понимали по-разному.
С DoR часть проблем всплывает до старта:
- нет решения по спорному сценарию;
- не готов контракт;
- объём слишком большой;
- непонятно, кто принимает результат.
Задача стартует позже на день, но заканчивается раньше на неделю.
Иногда «быстрее начать» и «быстрее закончить» находятся по разные стороны здравого смысла.
Теперь важное ограничение.
DoR тоже можно испортить.
Он вреден, если:
- чек-лист используют механически;
- аналитики месяцами готовят «идеальную» задачу;
- разработчики прячутся за DoR и отказываются обсуждать неопределённость;
- DoR становится способом перебрасывать ответственность;
- одно правило применяют к фичам, багам, исследованиям и инцидентам.
Хороший DoR не говорит: «мы не начнём, пока всё не идеально».
Он говорит: «мы понимаем достаточно, чтобы начать без очевидного самообмана».
Как внедрить без MBA и процессного театра:
1. Возьмите пять последних задач, которые задержались.
2. Посмотрите, какой информации не хватало на старте.
3. Найдите 4–6 повторяющихся пунктов.
4. Сделайте из них первый Definition of Ready.
5. Через месяц проверьте, стало ли меньше зависаний и переделок.
Не надо начинать с идеального процесса.
Начните с того, что реально болит.
Хороший Definition of Ready не гарантирует, что задача пройдёт идеально.
Он просто снижает вероятность, что разработка станет местом, где команда впервые начинает понимать требования.
А какая информация чаще всего отсутствует в ваших задачах на старте: цель, критерии приёмки, макеты, зависимости или владелец решения?
Задача попадает в разработку.
Исполнитель назначен.
Срок уже обсуждают.
В Jira статус «В работе».
Через час появляются первые вопросы:
— а какую проблему решаем?
— какой сценарий основной?
— кто принимает результат?
— что делать с пограничными случаями?
— где макеты?
— а зависимость от соседней команды точно закрыта?
Формально задача в работе.
Фактически команда только начала выяснять, что вообще нужно сделать.
И вот здесь начинается дорогой жанр: разработка как способ уточнения требований.
Команда может быстро писать код, оперативно ревьюить и регулярно выкатываться. Но если на вход приходит задача без цели, контекста и критериев готовности, delivery ломается ещё до первой строки кода.
Для этого и нужен Definition of Ready.
Definition of Ready, или DoR, — это договорённость команды о минимальных условиях, при которых задачу можно брать в работу.
Не огромный чек-лист.
Не новая церемония.
Не бюрократический забор вокруг разработки.
А простой фильтр от задач вида:
- «сделайте примерно как у конкурента»;
- «надо срочно, детали уточним потом»;
- «там всё понятно»;
- «начните пока, а бизнес определится по ходу».
То есть от классического управленческого оптимизма, оплаченного временем разработчиков.
Что может входить в DoR для обычной продуктовой задачи:
- понятна цель изменения;
- описан ожидаемый результат;
- есть критерии приёмки;
- определены основные сценарии;
- известны зависимости;
- доступны макеты, контракты или нужные данные;
- понятно, кто отвечает на вопросы;
- задача достаточно мала, чтобы её можно было закончить;
- команда видит основные риски.
Важно: DoR зависит от типа задач.
Для бага он один.
Для продуктовой фичи другой.
Для исследования третий.
Для срочного инцидента вообще могут быть отдельные правила.
Если сделать один универсальный список на 37 пунктов, команда быстро научится его ненавидеть. И будет права.
DoR должен помогать стартовать осознанно, а не превращать подготовку задачи в археологическую экспедицию.
Простой пример.
Без DoR задача уходит в разработку, а потом:
- два дня ждут уточнений;
- переделывают решение после первого показа;
- внезапно находят зависимость от другой команды;
- выясняют, что критерии приёмки все понимали по-разному.
С DoR часть проблем всплывает до старта:
- нет решения по спорному сценарию;
- не готов контракт;
- объём слишком большой;
- непонятно, кто принимает результат.
Задача стартует позже на день, но заканчивается раньше на неделю.
Иногда «быстрее начать» и «быстрее закончить» находятся по разные стороны здравого смысла.
Теперь важное ограничение.
DoR тоже можно испортить.
Он вреден, если:
- чек-лист используют механически;
- аналитики месяцами готовят «идеальную» задачу;
- разработчики прячутся за DoR и отказываются обсуждать неопределённость;
- DoR становится способом перебрасывать ответственность;
- одно правило применяют к фичам, багам, исследованиям и инцидентам.
Хороший DoR не говорит: «мы не начнём, пока всё не идеально».
Он говорит: «мы понимаем достаточно, чтобы начать без очевидного самообмана».
Как внедрить без MBA и процессного театра:
1. Возьмите пять последних задач, которые задержались.
2. Посмотрите, какой информации не хватало на старте.
3. Найдите 4–6 повторяющихся пунктов.
4. Сделайте из них первый Definition of Ready.
5. Через месяц проверьте, стало ли меньше зависаний и переделок.
Не надо начинать с идеального процесса.
Начните с того, что реально болит.
Хороший Definition of Ready не гарантирует, что задача пройдёт идеально.
Он просто снижает вероятность, что разработка станет местом, где команда впервые начинает понимать требования.
А какая информация чаще всего отсутствует в ваших задачах на старте: цель, критерии приёмки, макеты, зависимости или владелец решения?
👍2