AI-трансформация — это не про “все начали пользоваться агентами”
Прочитал статью AI Transformation Journey: 3 Myths and Learnings по докладу Vinay Perneti из Augment Code.
Главная мысль простая:
если команда просто начала использовать AI-агентов, это ещё не значит, что она стала AI-native.
Потому что AI не встраивается в команду магическим образом.
Он не чинит процессы.
Он не убирает очереди.
Он не делает требования понятнее.
Он не ускоряет ревью, если ревью и так было бутылочным горлышком.
Он просто усиливает то, что уже есть.
Если в команде нормальная постановка задач, быстрые проверки, понятные границы ответственности и хорошая инженерная культура — AI может дать сильный эффект.
Если в команде хаос, мутные требования, вечные согласования и пять задач “почти готово” на каждого разработчика — AI поможет быстрее производить ещё больше незавершённой работы.
И это, конечно, прогресс. Просто в сторону более дорогого хаоса.
В статье хорошо разбираются три мифа.
Миф 1. AI-native — это когда все используют агентов
Нет. Использовать ChatGPT как более умный Stack Overflow и уметь оркестрировать несколько агентов вокруг задачи — это разные уровни зрелости.
Команде нужны новые рабочие привычки:
писать более качественные спеки, заранее думать о проверке результата, понимать, где человек должен принимать решение, а где можно отдать работу агенту.
Миф 2. AI-трансформацию можно спустить сверху
Можно сказать: “Теперь все используем AI”.
Можно даже добавить это в OKR, потому что иначе, видимо, цивилизация рухнет.
Но настоящая трансформация не случается приказом.
Команда должна сама найти, где AI реально помогает, где мешает, какие новые проблемы появляются и какие правила работы нужно менять.
Сверху можно дать пространство, инструменты и ожидания.
Но рабочие практики рождаются снизу, там, где люди каждый день сталкиваются с реальными задачами.
Миф 3. Это чисто техническая проблема
Нет. Это ещё и человеческая проблема.
Люди не просто “осваивают инструмент”.
Они пересобирают свою профессиональную идентичность.
Если разработчик 10 лет строил ощущение ценности вокруг умения писать код, а теперь слышит “код будет писать агент”, у него не всегда первая реакция:
“О, чудесно, наконец-то больше времени на архитектуру”.
Иногда первая реакция:
“А я тогда кто?”
И это нельзя игнорировать.
Для тимлида здесь важный вывод: AI-трансформация — это не закупка подписок и не рассылка “гайда по промптам”.
Это изменение системы:
— где теперь бутылочное горлышко;
— как мы ставим задачи;
— как проверяем результат;
— как ревьюим код;
— как не превращаем скорость генерации в склад незавершёнки;
— где человек создаёт максимальную ценность.
Мне особенно понравилась мысль из статьи: когда AI ускоряет написание кода, bottleneck просто переезжает в другое место.
Раньше команда могла упираться в реализацию.
Теперь она может упереться в постановку задач, ревью, тестирование, принятие решений или деплой.
И если не смотреть на систему целиком, можно радостно ускорить один участок и получить пробку на следующем.
AI не отменяет инженерный менеджмент.
Он делает его важнее.
Потому что чем быстрее команда может производить изменения, тем дороже становится плохой фокус, слабая постановка задач и медленная обратная связь.
Оригинальная статья:
https://newsletter.eng-leadership.com/p/ai-transformation-journey-3-myths
Прочитал статью AI Transformation Journey: 3 Myths and Learnings по докладу Vinay Perneti из Augment Code.
Главная мысль простая:
если команда просто начала использовать AI-агентов, это ещё не значит, что она стала AI-native.
Потому что AI не встраивается в команду магическим образом.
Он не чинит процессы.
Он не убирает очереди.
Он не делает требования понятнее.
Он не ускоряет ревью, если ревью и так было бутылочным горлышком.
Он просто усиливает то, что уже есть.
Если в команде нормальная постановка задач, быстрые проверки, понятные границы ответственности и хорошая инженерная культура — AI может дать сильный эффект.
Если в команде хаос, мутные требования, вечные согласования и пять задач “почти готово” на каждого разработчика — AI поможет быстрее производить ещё больше незавершённой работы.
И это, конечно, прогресс. Просто в сторону более дорогого хаоса.
В статье хорошо разбираются три мифа.
Миф 1. AI-native — это когда все используют агентов
Нет. Использовать ChatGPT как более умный Stack Overflow и уметь оркестрировать несколько агентов вокруг задачи — это разные уровни зрелости.
Команде нужны новые рабочие привычки:
писать более качественные спеки, заранее думать о проверке результата, понимать, где человек должен принимать решение, а где можно отдать работу агенту.
Миф 2. AI-трансформацию можно спустить сверху
Можно сказать: “Теперь все используем AI”.
Можно даже добавить это в OKR, потому что иначе, видимо, цивилизация рухнет.
Но настоящая трансформация не случается приказом.
Команда должна сама найти, где AI реально помогает, где мешает, какие новые проблемы появляются и какие правила работы нужно менять.
Сверху можно дать пространство, инструменты и ожидания.
Но рабочие практики рождаются снизу, там, где люди каждый день сталкиваются с реальными задачами.
Миф 3. Это чисто техническая проблема
Нет. Это ещё и человеческая проблема.
Люди не просто “осваивают инструмент”.
Они пересобирают свою профессиональную идентичность.
Если разработчик 10 лет строил ощущение ценности вокруг умения писать код, а теперь слышит “код будет писать агент”, у него не всегда первая реакция:
“О, чудесно, наконец-то больше времени на архитектуру”.
Иногда первая реакция:
“А я тогда кто?”
И это нельзя игнорировать.
Для тимлида здесь важный вывод: AI-трансформация — это не закупка подписок и не рассылка “гайда по промптам”.
Это изменение системы:
— где теперь бутылочное горлышко;
— как мы ставим задачи;
— как проверяем результат;
— как ревьюим код;
— как не превращаем скорость генерации в склад незавершёнки;
— где человек создаёт максимальную ценность.
Мне особенно понравилась мысль из статьи: когда AI ускоряет написание кода, bottleneck просто переезжает в другое место.
Раньше команда могла упираться в реализацию.
Теперь она может упереться в постановку задач, ревью, тестирование, принятие решений или деплой.
И если не смотреть на систему целиком, можно радостно ускорить один участок и получить пробку на следующем.
AI не отменяет инженерный менеджмент.
Он делает его важнее.
Потому что чем быстрее команда может производить изменения, тем дороже становится плохой фокус, слабая постановка задач и медленная обратная связь.
Оригинальная статья:
https://newsletter.eng-leadership.com/p/ai-transformation-journey-3-myths
👍2
Age of Work: как найти задачи, которые начали тухнуть
Есть неприятный тип задач: они вроде бы в работе, но на самом деле давно никуда не едут.
В Jira статус нормальный.
Исполнитель есть.
Blocked не стоит.
На daily человек говорит: «занимаюсь».
А потом внезапно выясняется, что задача висит уже вторую неделю, контекст потерян, ожидания разъехались, а завершение всё ещё где-то за горизонтом.
Вот для таких случаев полезна метрика Age of Work.
Если совсем просто, Age of Work показывает, сколько времени задача уже находится в активной работе.
Не сколько она лежала в бэклоге.
Не сколько прошло с момента создания.
А именно сколько она живёт в потоке delivery: взяли в работу — и с этого момента пошёл возраст.
Почему это важно?
Потому что старые задачи часто становятся невидимой проблемой команды.
Они занимают WIP.
Они держат контекст в голове.
Они создают ощущение занятости.
Они мешают брать новое.
Они увеличивают вероятность, что всё придётся переделывать.
И самое опасное: старая задача не всегда выглядит заблокированной.
Она может быть «почти готова».
«Осталось только проверить».
«Жду ответа, но не блокер».
«Надо чуть-чуть допилить».
«Там небольшой рефакторинг всплыл».
Классика жанра: задача не заблокирована, она просто медленно тухнет.
Age of Work помогает увидеть такие задачи раньше, чем они превратятся в археологический слой спринта.
Но здесь есть важный момент.
Эту метрику нельзя использовать как дубинку.
Если на daily тимлид открывает доску и говорит:
«Так, Петров, почему твоя задача уже 8 дней в работе?» —
это не управление потоком. Это публичный ритуал обвинения.
После такого люди быстро учатся не улучшать delivery, а защищаться:
- дробить задачи формально;
- двигать статусы туда-сюда;
- скрывать проблемы;
- объяснять, почему всё нормально.
Метрика становится токсичной не потому, что она плохая.
А потому что её используют для поиска виноватых.
Нормальный вопрос не «кто виноват?», а что мешает задаче закончиться?
По старым задачам полезно спрашивать:
- задача всё ещё актуальна?
- что должно случиться, чтобы она завершилась?
- есть ли там скрытый блокер?
- не слишком ли большой получился кусок работы?
- нужен ли созвон, ревью, решение, помощь другого человека?
- можно ли отрезать часть и довести хотя бы что-то до результата?
- стоит ли остановить задачу, если она больше не важна?
Это совсем другой тон.
Не «почему ты так долго делаешь?», а «давайте поможем работе пройти через систему».
Особенно хорошо Age of Work связывается с daily.
Daily вообще не должен быть отчётом по кругу в формате «вчера делал, сегодня буду». Иначе он быстро превращается в стендап ради стендапа.
Гораздо полезнее смотреть на поток:
- какие задачи давно в работе?
- какие не двигались со вчера?
- где вырос возраст задачи?
- что близко к завершению?
- что мешает закрыть старое перед тем, как брать новое?
То есть daily становится не проверкой занятости людей, а короткой синхронизацией вокруг движения задач.
И здесь Age of Work хорошо дополняет WIP.
WIP показывает, сколько работы мы одновременно тащим.
Age of Work показывает, какая работа уже слишком долго не доезжает до финиша.
Вместе они помогают увидеть классическую проблему: команда вроде постоянно занята, но результат выходит медленно.
Много начатого.
Мало завершённого.
Старые задачи копятся.
Новые всё равно берутся.
Поток начинает вязнуть.
Что можно попробовать без сложной аналитики:
Раз в день или пару раз в неделю смотреть на задачи в работе и выделять самые старые.
Не для наказания.
Для разговора.
Например:
«У нас есть несколько задач, которые давно в работе. Давайте поймём, что им нужно, чтобы завершиться: помощь, решение, декомпозиция или остановка».
Это маленькая смена фокуса, но она сильно меняет разговор.
Команда перестаёт обсуждать занятость.
И начинает обсуждать движение.
А это и есть смысл метрик без насилия: не давить на людей цифрами, а подсвечивать места, где системе нужна помощь.
Есть неприятный тип задач: они вроде бы в работе, но на самом деле давно никуда не едут.
В Jira статус нормальный.
Исполнитель есть.
Blocked не стоит.
На daily человек говорит: «занимаюсь».
А потом внезапно выясняется, что задача висит уже вторую неделю, контекст потерян, ожидания разъехались, а завершение всё ещё где-то за горизонтом.
Вот для таких случаев полезна метрика Age of Work.
Если совсем просто, Age of Work показывает, сколько времени задача уже находится в активной работе.
Не сколько она лежала в бэклоге.
Не сколько прошло с момента создания.
А именно сколько она живёт в потоке delivery: взяли в работу — и с этого момента пошёл возраст.
Почему это важно?
Потому что старые задачи часто становятся невидимой проблемой команды.
Они занимают WIP.
Они держат контекст в голове.
Они создают ощущение занятости.
Они мешают брать новое.
Они увеличивают вероятность, что всё придётся переделывать.
И самое опасное: старая задача не всегда выглядит заблокированной.
Она может быть «почти готова».
«Осталось только проверить».
«Жду ответа, но не блокер».
«Надо чуть-чуть допилить».
«Там небольшой рефакторинг всплыл».
Классика жанра: задача не заблокирована, она просто медленно тухнет.
Age of Work помогает увидеть такие задачи раньше, чем они превратятся в археологический слой спринта.
Но здесь есть важный момент.
Эту метрику нельзя использовать как дубинку.
Если на daily тимлид открывает доску и говорит:
«Так, Петров, почему твоя задача уже 8 дней в работе?» —
это не управление потоком. Это публичный ритуал обвинения.
После такого люди быстро учатся не улучшать delivery, а защищаться:
- дробить задачи формально;
- двигать статусы туда-сюда;
- скрывать проблемы;
- объяснять, почему всё нормально.
Метрика становится токсичной не потому, что она плохая.
А потому что её используют для поиска виноватых.
Нормальный вопрос не «кто виноват?», а что мешает задаче закончиться?
По старым задачам полезно спрашивать:
- задача всё ещё актуальна?
- что должно случиться, чтобы она завершилась?
- есть ли там скрытый блокер?
- не слишком ли большой получился кусок работы?
- нужен ли созвон, ревью, решение, помощь другого человека?
- можно ли отрезать часть и довести хотя бы что-то до результата?
- стоит ли остановить задачу, если она больше не важна?
Это совсем другой тон.
Не «почему ты так долго делаешь?», а «давайте поможем работе пройти через систему».
Особенно хорошо Age of Work связывается с daily.
Daily вообще не должен быть отчётом по кругу в формате «вчера делал, сегодня буду». Иначе он быстро превращается в стендап ради стендапа.
Гораздо полезнее смотреть на поток:
- какие задачи давно в работе?
- какие не двигались со вчера?
- где вырос возраст задачи?
- что близко к завершению?
- что мешает закрыть старое перед тем, как брать новое?
То есть daily становится не проверкой занятости людей, а короткой синхронизацией вокруг движения задач.
И здесь Age of Work хорошо дополняет WIP.
WIP показывает, сколько работы мы одновременно тащим.
Age of Work показывает, какая работа уже слишком долго не доезжает до финиша.
Вместе они помогают увидеть классическую проблему: команда вроде постоянно занята, но результат выходит медленно.
Много начатого.
Мало завершённого.
Старые задачи копятся.
Новые всё равно берутся.
Поток начинает вязнуть.
Что можно попробовать без сложной аналитики:
Раз в день или пару раз в неделю смотреть на задачи в работе и выделять самые старые.
Не для наказания.
Для разговора.
Например:
«У нас есть несколько задач, которые давно в работе. Давайте поймём, что им нужно, чтобы завершиться: помощь, решение, декомпозиция или остановка».
Это маленькая смена фокуса, но она сильно меняет разговор.
Команда перестаёт обсуждать занятость.
И начинает обсуждать движение.
А это и есть смысл метрик без насилия: не давить на людей цифрами, а подсвечивать места, где системе нужна помощь.
❤3👍1
Почему code review тормозит delivery сильнее, чем кажется
Разработчик говорит:
"Я задачу сделал".
В Jira задача почти готова.
Код написан.
PR открыт.
Осталось только ревью.
И вот это "только" иногда длится три дня.
Формально работа почти завершена.
Фактически ценность ещё не доставлена.
Потому что написанный код сам по себе ничего не меняет для пользователя. Он начинает иметь значение только после ревью, тестов, merge и релиза.
До этого момента это всё ещё незавершённая работа. Просто она лежит не в статусе "In Progress", а в более социально приемлемом месте: в pull request.
И вот тут у многих команд начинается болото.
PR висят по несколько дней.
Ревьюеры перегружены.
Непонятно, кто должен смотреть.
Комментарии превращаются в длинные философские ветки.
Автор ждёт. Контекст остывает. Задача вроде бы "почти готова", но delivery не двигается.
Причин обычно несколько:
- PR слишком большие;
- нет договорённости по SLA на ревью;
- ревьюеры заняты своей работой;
- ревьюеры назначаются неявно;
- в комментариях смешиваются must-fix и nice-to-have;
- автор PR плохо описывает контекст;
- нет общего чеклиста ревью;
- команда открывает больше PR, чем способна обработать.
Отдельно это становится заметно с AI.
AI помогает быстрее писать код.
Разработчик быстрее открывает PR.
PR может стать больше.
Количество изменений растёт.
Но ревьюеры не стали в два раза быстрее.
Архитектурный контекст не появился сам.
Ответственность за качество никуда не делась.
В итоге команда ускоряет производство изменений, но не ускоряет их принятие.
Скорость просто превращается в очередь.
И это важный момент для тимлида: смотреть надо не только на то, как быстро задачи переходят в "Review", а на то, сколько они там живут.
Я бы смотрел хотя бы на такие сигналы:
- сколько PR открыто прямо сейчас;
- сколько PR старше 1–2 дней;
- среднее время до первого комментария;
- среднее время до merge;
- размер PR;
- сколько раз PR возвращается на доработку;
- есть ли "вечные ревьюеры", через которых проходит почти всё.
Если всё упирается в ревью, ускорять написание кода почти бессмысленно.
Что можно сделать практически:
1. Договориться о SLA на первый взгляд ревью
Не "когда-нибудь посмотрю", а, например, первый ответ в течение рабочего дня.
2. Уменьшать размер PR
Большой PR почти всегда ревьюится хуже и дольше.
3. Назначать ревьюеров явно
Если никто конкретно не отвечает, PR легко становится ничьим.
4. Добавить нормальное описание контекста в шаблон PR
Что меняется, зачем, как проверено, где риск.
5. Разделять must-fix и nice-to-have
Не каждое замечание должно блокировать merge.
6. Спорные обсуждения выносить в голос
Если в PR уже 40 комментариев, это часто не ревью, а плохо организованная встреча.
7. Считать review time частью delivery
Не "задача почти готова", а "задача всё ещё в системе и не доставлена".
Code review нужен. Он защищает качество, знания и архитектуру.
Но если ревью стало бутылочным горлышком, команда начинает путать активность с поставкой. Код пишется, PR открываются, статусы двигаются, а ценность до пользователя доходит медленно.
Написанный код — это ещё не delivery.
Delivery начинается там, где изменение прошло через всю систему и оказалось в руках пользователя.
А у вас PR чаще зависают из-за нехватки ревьюеров, больших изменений или бесконечных обсуждений в комментариях?
Разработчик говорит:
"Я задачу сделал".
В Jira задача почти готова.
Код написан.
PR открыт.
Осталось только ревью.
И вот это "только" иногда длится три дня.
Формально работа почти завершена.
Фактически ценность ещё не доставлена.
Потому что написанный код сам по себе ничего не меняет для пользователя. Он начинает иметь значение только после ревью, тестов, merge и релиза.
До этого момента это всё ещё незавершённая работа. Просто она лежит не в статусе "In Progress", а в более социально приемлемом месте: в pull request.
И вот тут у многих команд начинается болото.
PR висят по несколько дней.
Ревьюеры перегружены.
Непонятно, кто должен смотреть.
Комментарии превращаются в длинные философские ветки.
Автор ждёт. Контекст остывает. Задача вроде бы "почти готова", но delivery не двигается.
Причин обычно несколько:
- PR слишком большие;
- нет договорённости по SLA на ревью;
- ревьюеры заняты своей работой;
- ревьюеры назначаются неявно;
- в комментариях смешиваются must-fix и nice-to-have;
- автор PR плохо описывает контекст;
- нет общего чеклиста ревью;
- команда открывает больше PR, чем способна обработать.
Отдельно это становится заметно с AI.
AI помогает быстрее писать код.
Разработчик быстрее открывает PR.
PR может стать больше.
Количество изменений растёт.
Но ревьюеры не стали в два раза быстрее.
Архитектурный контекст не появился сам.
Ответственность за качество никуда не делась.
В итоге команда ускоряет производство изменений, но не ускоряет их принятие.
Скорость просто превращается в очередь.
И это важный момент для тимлида: смотреть надо не только на то, как быстро задачи переходят в "Review", а на то, сколько они там живут.
Я бы смотрел хотя бы на такие сигналы:
- сколько PR открыто прямо сейчас;
- сколько PR старше 1–2 дней;
- среднее время до первого комментария;
- среднее время до merge;
- размер PR;
- сколько раз PR возвращается на доработку;
- есть ли "вечные ревьюеры", через которых проходит почти всё.
Если всё упирается в ревью, ускорять написание кода почти бессмысленно.
Что можно сделать практически:
1. Договориться о SLA на первый взгляд ревью
Не "когда-нибудь посмотрю", а, например, первый ответ в течение рабочего дня.
2. Уменьшать размер PR
Большой PR почти всегда ревьюится хуже и дольше.
3. Назначать ревьюеров явно
Если никто конкретно не отвечает, PR легко становится ничьим.
4. Добавить нормальное описание контекста в шаблон PR
Что меняется, зачем, как проверено, где риск.
5. Разделять must-fix и nice-to-have
Не каждое замечание должно блокировать merge.
6. Спорные обсуждения выносить в голос
Если в PR уже 40 комментариев, это часто не ревью, а плохо организованная встреча.
7. Считать review time частью delivery
Не "задача почти готова", а "задача всё ещё в системе и не доставлена".
Code review нужен. Он защищает качество, знания и архитектуру.
Но если ревью стало бутылочным горлышком, команда начинает путать активность с поставкой. Код пишется, PR открываются, статусы двигаются, а ценность до пользователя доходит медленно.
Написанный код — это ещё не delivery.
Delivery начинается там, где изменение прошло через всю систему и оказалось в руках пользователя.
А у вас PR чаще зависают из-за нехватки ревьюеров, больших изменений или бесконечных обсуждений в комментариях?
❤2
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