Зелёная зонаразрешить широко
AI-шторм: между бизнесом
и разработкой. Как
внедрить нейросети, не
потеряв сеньоров и
выполнив KPI
Дмитрий Чуканов
СберТех
Штабная игра · управляемое внедрение AI
AI-шторм:
между бизнесом и разработкой
Как внедрить нейросети, не потеряв сеньоров и выполнив KPI
Сюжет
CEO требует ускорить разработку на 30–50% после закупки AI-ассистентов. Нужно представить директору управляемый план внедрения AI на следующий квартал.
Структура борда команды
- Карта симптомов и причин
- Дерево целей и метрик
- Архитектура компромисса
- Карта страхов сторон
- Защита на краш-тесте
01Карта симптомов и причин02·21
Зона 01 · Карта симптомов // 01–09
Базовые симптомы
для всех команд
- 01Количество merge request выросло на 35%.
- 02Медианное время ревью увеличилось с 8 до 21 часа.
- 03Доля повторных открытий задач выросла.
- 04Сеньоры проводят больше времени на ревью.
- 05QA получает больше регрессий.
- 06Бизнес видит рост количества закрытых задач, но релизы не ускоряются.
- 07Сотрудники используют AI неравномерно.
- 08Некоторые разработчики скрывают использование AI.
- 09CTO требует показать эффект от лицензий через квартал.
01Карта симптомов и причин03·21
Зона 01 · Карта симптомов // 10–14
Симптомы про
качество кода
- 10Средний размер merge request вырос.
- 11В MR стало больше сгенерированных тестов, но они чаще проверяют happy path.
- 12В коде стало больше однотипных решений, но меньше понимания архитектурного контекста.
- 13Ревьюеры чаще находят ошибки в edge cases.
- 14Увеличилось количество замечаний по поддерживаемости кода.
01Карта симптомов и причин04·21
Зона 01 · Карта симптомов // 15–19
Симптомы про
поток разработки
- 15В очереди ревью стало больше задач, которые выглядят «почти готовыми».
- 16Lead time от начала задачи до попадания в релиз не сократился.
- 17Cycle time разработки сократился, но cycle time до production вырос.
- 18Больше задач доходит до стадии «готово к ревью», но меньше проходит дальше без возврата.
- 19Возрос WIP: одновременно открыто больше задач и MR.
01Карта симптомов и причин05·21
Зона 01 · Карта симптомов // 20–24
Симптомы про
людей и поведение
- 20Джуны чаще приносят решения, которые не могут подробно объяснить.
- 21Сеньоры стали чаще переписывать код вместо ревью.
- 22Разработчики стали реже просить консультации до начала реализации.
- 23Часть команды считает AI «обязательной нормой», часть — угрозой качеству.
- 24Люди спорят не о требованиях, а о том, «можно ли доверять AI».
01Карта симптомов и причин06·21
Зона 01 · Карта симптомов // 25–29
Симптомы про
управление
- 25Руководство смотрит на количество закрытых задач, но не видит роста rework.
- 26Команды начали оптимизироваться под видимую активность: больше MR, больше коммитов, больше закрытых ticket status.
- 27Эстимейты уже сокращены, но входные требования не стали яснее.
- 28Продуктовые требования всё ещё неоднозначные, и AI ускоряет реализацию неверно понятых задач.
- 29У менеджмента нет agreed baseline: с чем сравнивать эффект AI до и после.
01Карта симптомов и причин07·21
Зона 01 · Карта симптомов // 30–33
Симптомы про
безопасность и compliance
- 30В коде чаще появляются зависимости, предложенные AI, но не проверенные командой.
- 31Security review стал получать больше мелких, но шумных замечаний.
- 32Появились подозрения, что часть кода или данных могла уходить во внешние AI-сервисы.
- 33Не все понимают, какие данные можно отправлять в AI-ассистент, а какие нельзя.
01Карта симптомов и причин08·21
Зона 01 · Карта симптомов
Примеры комбинаций
Лидер задаёт команде вопросы:
- Какие симптомы здесь являются следствиями, а какие могут быть причинами?
- Что изменилось после внедрения AI?
- Где выросла нагрузка?
- Где поток начал застревать?
- Что стало ограничением системы?
Переформулировка // от симптома к системе
| Плохая формулировка | Системная формулировка |
|---|---|
| Джуны генерируют мусор | AI увеличил объём изменений без новых критериев качества |
| Сеньоры тормозят ревью | Экспертная проверка стала ограничением потока |
| QA не справляется | На QA попадает больше дефектов из-за слабого pre-merge контроля |
| Бизнес давит | Управление смотрит на output-метрики, а не на delivery-метрики |
01Карта симптомов и причин09·21
Зона 01 · Разбор кейса
Наблюдаемые симптомы
и причинная цепочка
1.Наблюдаемые симптомы
- Количество MR выросло на 35%.
- Медианное время ревью выросло с 8 до 21 часа.
- Сеньоры проводят больше времени на ревью.
- QA получает больше регрессий.
- Релизы не ускоряются, хотя закрытых задач стало больше.
2.Причинная цепочка
AI увеличил скорость генерации кода
+
Definition of Done не изменился
↓
В MR попадает больше непроверенных изменений
↓
Растёт нагрузка на senior review
↓
Очередь MR увеличивается
↓
Время ревью растёт с 8 до 21 часа
↓
Релизы не ускоряются
↘Параллельная ветка
В MR попадает больше непроверенных изменений
↓
QA получает больше регрессий
↓
Растёт rework
↓
Закрытые задачи чаще переоткрываются
01Карта симптомов и причин10·21
Зона 01 · Вывод
Системная причина
и ограничение
3. Предполагаемая системная причина
AI ускорил создание изменений, но процесс контроля качества не был перестроен: Definition of Done, требования к тестам, правила ревью, размер MR и критерии приёмки остались прежними.
4. Ограничение системы
Ограничением стала экспертная проверка изменений перед merge: senior review и pre-merge quality gate.
5. Короткая формулировка для директора
AI уже увеличил объём создаваемых изменений, но это не привело к ускорению релизов, потому что ограничение системы сместилось в ревью и контроль качества. Поэтому следующий квартал должен быть не про «писать больше кода», а про управляемое внедрение AI с новыми правилами качества, ревью и измерения эффекта до релиза.
02Дерево целей и метрик11·21
Зона 02 · Дерево целей и метрик
Что нам нужно
выбрать на этом этапе
Цель бизнесавыберите 1
Ограничение системыиз этапа 1
Метрики
- 1 · Бизнес-результатвыберите 1
- 2 · Метрика потокавыберите 2
- 3 · Ограничитель качествавыберите 1
- 4 · Ограничитель нагрузки на командувыберите 1
02Дерево целей и метрик12·21
Зона 02 · Каталог карточек
Синие карточки
Бизнес-результат
B-01Медианное время от утверждённого требования до production.
B-02Время вывода приоритетных фич на рынок.
B-03Частота релизов со значимыми изменениями.
B-04Доля выполненного квартального объёма обязательств.
B-05Время ожидания клиентского изменения.
02Дерево целей и метрик13·21
Зона 02 · Каталог карточек
Зелёные карточки
Метрики потока
F-01Время ожидания ревью.
F-02Длительность цикла ревью.
F-03Объём незавершённой работы перед merge.
F-04Время от старта задачи до production.
F-05Время цикла от первого коммита до merge.
F-06Время блокировки задачи.
F-07Медианный размер MR/PR.
F-08Время от merge до production.
F-09Время ожидания проверки безопасности.
F-10Время блокировки на QA.
02Дерево целей и метрик14·21
Зона 02 · Каталог карточек
Красные карточки
Ограничители качества
Q-01Доля переоткрытых задач.
Q-02Доля регрессий на QA.
Q-03Дефекты, найденные после релиза.
Q-04Доля откатов и срочных исправлений.
Q-05Доля неуспешных деплоев.
Q-06Серьёзные замечания на ревью на один MR/PR.
Q-07Security findings после merge.
Q-08Падения автотестов после merge.
02Дерево целей и метрик15·21
Зона 02 · Каталог карточек
Жёлтые карточки
Ограничители нагрузки на команду
T-01Нагрузка сеньоров на ревью.
T-02Доля времени на переделки.
T-03Количество отвлечений сеньора в неделю.
T-04Переработки и работа вне рабочего времени.
T-05Доля времени сеньоров на сложные инженерные задачи.
T-06Удовлетворённость разработчиков процессом работы с AI.
T-07Серьёзные замечания на MR/PR.
T-08Время переделок из-за security fixes.
02Дерево целей и метрик16·21
Зона 02 · Каталог карточек
Фиолетовые карточки
Диагностика использования AI
AI-01Доля MR/PR с явно указанной AI-помощью.
AI-02Доля AI-assisted изменений с выполненной самопроверкой.
AI-03Использование AI по типам задач.
AI-04Доля AI-assisted MR/PR с обновлёнными тестами.
AI-05Доля переоткрытых AI-assisted изменений.
AI-06Длительность ревью AI-assisted MR/PR.
AI-07Доля отклонённых AI-предложений.
02Дерево целей и метрик17·21
Зона 02 · Стресс-тест метрик
Соседняя команда придумывает,
как сломать метрики накруткой
Пример
| Метрика | Как её можно накрутить | Чем защититься |
|---|---|---|
| Время вывода на рынок | Брать только мелкие задачи | Отдельно считать приоритетные фичи |
| Время ожидания ревью | Мержить без полноценного ревью | Ограничитель качества: доля переоткрытых задач или доля регрессий |
| Объём незавершённой работы перед merge | Закрывать MR/PR и открывать новые | Считать объём незавершённой работы во всём delivery-потоке |
| Доля переоткрытых задач | Не переоткрывать задачи, а заводить новые | Считать связанные дефекты и follow-up задачи |
| Нагрузка сеньоров на ревью | Скрывать консультации и не учитывать async-помощь | Считать отвлечения, переделки или делать выборочный self-report |
03Архитектура компромисса18·21
Зона 03 · Архитектура компромиса
TRIZ-инверсия:
«Как гарантированно
уничтожить кодовую базу?»
стресс-тест
Вопрос к командам
Что нужно сделать, чтобы через шесть месяцев AI-внедрение гарантированно разрушило кодовую базу и заставило лучших инженеров уйти?
- Быстро нарезаем типовые ответы
- Перенести метрики, которые закрывают эти проблемы из предыдущего пункта.
03Архитектура компромисса19·21
Зона 03 · Архитектура компромиса
Матрица AI-зон
Команда распределяет сценарии применения AI по матрице:
Легко проверить автоматически
Требуется экспертная проверка
Низкая цена ошибки
Жёлтая зонаразрешить ограниченно
Высокая цена ошибки
Жёлтая зонаразрешить с guardrails
Красная зоназапретить или оставить человеку
▸Показать примеры по зонам · что отдавать AI
ЗелёнаяДокументация, unit-тесты для существующего поведения, миграция шаблонного кода, мок-объекты, черновики SQL-запросов
ЖёлтаяРефакторинг локального модуля, генерация API-клиента, тестовые данные, типовые CRUD-операции
КраснаяАвторизация, криптография, расчёт денег, миграции данных без rollback, конкурентный код, изменение архитектурных границ
04Карта страхов сторон20·21
Зона 04 · Карта страхов сторон
Карта эмпатии
Карта эмпатии фиксирует, что сторона говорит, думает, делает и чувствует, что видит и слышит — и где её скрытая мотивация и страхи. Команда заполняет карту на ту сторону, которую нужно убедить.
01Внутренний мир
- Что он думает?
- Что он чувствует?
- Скрытая мотивация
02Информационное поле
- Что он видит?
- Что он слышит?
03Линия защиты
- Что он говорит?
- Что он делает?
04Ключи к сделке
- Чего боится потерять?
- Личная победа
- Фрейминг (Как заходить)
▸Показать заполненный пример · Этап 2 — чек-лист карты эмпатии
Этап 2. Чек-лист карты эмпатии
01Внутренний мир
- Что он думает?Его реальные мысли о вашем проекте, например: «Это убьет тайминги»
- Что он чувствует?Эмоциональный фон: раздражение, страх потери контроля
- Скрытая мотивация:Его истинная цель: не пустить грязный код в систему
02Информационное поле
- Что он видит?Объективные ограничения: контракты, SLA, метрики
- Что он слышит?Давление среды: жалобы девопсов, новости рынка
03Линия защиты
- Что он говорит?Его дежурные возражения: «Как вы гарантируете результат?»
- Что он делает?Его действия-блокеры: требует схемы, рубит по NFR
04Ключи к сделке
- Чего боится потерять?Loss Aversion: годовой бонус, аптайм, репутацию
- Личная победа:Какая архитектура/метрика сделает его героем?
- Фрейминг (Как заходить):Ваш питч в одном предложении
05Защита на краш-тесте21·21
Зона 05 · Финал · краш-тест
Давящие вопросы
Колода:
60
Вытяните карту, дайте команде прочитать вопрос, затем запустите таймер. За ответ — балл. На ответ — 60 сек.
Нажмите «Вытянуть карту»
От CEO //
Про итоговые метрики
Какие итоговые метрики вы предлагаете показывать мне и совету директоров? Объясните, почему именно они доказывают влияние AI на бизнес, а не просто активность разработчиков.
Я вижу, что количество merge request выросло на 35%. Почему это нельзя назвать ростом производительности? Какой показатель вы поставите рядом?
Дайте мне 3 метрики. Какая из них главная? Если она не изменится, признаем ли мы внедрение неуспешным?
Какая из ваших метрик может выглядеть хорошо, даже если разработка в действительности стала медленнее?
Какая метрика покажет мне результат через квартал, а не через год? И чем вы защитите её от накрутки?
Я не хочу видеть двадцать технических графиков. Назовите три показателя, по которым я смогу понять: AI помогает, не помогает или вредит.
Вы говорите, что релизы не ускорились из-за нового ограничения. Как ваши метрики доказывают, где именно возник затор?
Использование AI растёт каждый месяц, но time-to-market не меняется. Как мы поймём, в чём проблема? Какие ваши метрики помогут локализовать ограничение?
Cycle time разработки сократился, но время до production выросло. Это успех или провал? Есть какие-то другие показатели, которые мы должны посмотреть?
Про экономическую ценность
Мы потратили деньги на лицензии и обучение. Как по вашим метрикам понять, что инвестиция окупается?
Что именно стало дешевле или быстрее благодаря AI: написание кода, выпуск изменений или получение бизнес-результата? Почему для меня важен выбранный вами уровень?
Если AI сократил время написания кода на 40%, но я так понимаю затраты на ревью и QA выросли, какой итоговый эффект?
Какова ваша стратегия? Какой наблюдаемый результат должен получить бизнес через квартал? Не команда разработки, а бизнес.
Про сокращения и эффективность персонала
По вашим метрикам всё выглядит хорошо: задачи выполняются быстрее, качество не ухудшается. Может быть, пора сокращать часть сеньоров?
Если AI увеличивает производительность разработчиков, почему численность команды должна остаться прежней?
Про KPI и давление сверху
Я хочу поставить руководителям KPI: AI должен использоваться минимум в 80% задач. Предложите более сильный показатель или примите мой.
Почему процент использования AI — плохой KPI? Что вы предложите вместо него, чтобы я всё равно видел масштаб внедрения?
Почему я не могу просто сократить эстимейты ещё на 20%, если AI уже ускоряет написание кода? Какие ваши данные доказывают, что это опасно или обоснованно?
Совет директоров ожидает ускорения на 30–50%. Что вы покажете, если получили только 15%, но одновременно снизили регрессии и нагрузку на команду?
Поставщик AI обещает ускорение на 50%. Почему ваша целевая метрика отличается от его цифры?
Про доверие к отчётности
Почему я должен доверять метрикам, которые выбрала сама команда? Она ведь заинтересована доказать, что планы завышены.
Как команда может накрутить ваши показатели и сделать вид, что AI работает?
Какая ваша метрика наиболее уязвима для манипуляций? Почему вы всё равно решили её использовать?
Если разные команды используют AI для разных типов задач, как вы будете сравнивать их результаты?
Про управленческие решения
По каким значениям метрик мы будем принимать решение: продолжать, менять подход или признавать, что внедрение не даёт эффекта?
Какой результат заставит вас честно сказать мне: «AI в этой части процесса не помогает»?
Какие данные заставят вас изменить собственную стратегию, даже если команда к ней уже привыкла?
В одной команде AI даёт эффект, в другой — нет. Как понять, проблема в инструменте, процессе, типе задач или зрелости команды?
Какой неудобный факт, метрику о внедрении AI вы обязаны показать мне, даже если он ухудшит квартальный отчёт?
От токсичного сеньора //
Про перенос нагрузки
Джуны теперь создают код быстрее, но мы тратим больше времени на проверку. Почему я должен поддерживать инструмент, который ухудшает мою работу?
Покажите мне метрику, которая доказывает, что AI снимает нагрузку с команды, а не перераспределяет её на самых опытных.
Про деградацию инженерных навыков
Если модель будет писать всё больше кода, как джуны научатся проектировать и принимать решения?
Какая ваша метрика покажет, что разработчики научились быстрее выдавать код, но перестали понимать систему?
Если джун выполняет больше задач, но чаще требует помощи при нестандартной проблеме, это рост производительности или деградация компетенции?
Какие задачи разработчик должен по-прежнему проходить самостоятельно, даже если AI может сделать их быстрее?
Как вы поймёте, что команда стала зависимой от AI и уже не может работать без него?
Про качество и технический долг
Если тесты генерирует та же модель, что и код, можно ли считать прохождение тестов независимым доказательством качества?
Если AI генерирует одинаковые решения во всей кодовой базе, как вы поймёте, что вместе с единообразием распространилась одна системная ошибка?
Как ваши правила отличают ускорение разработки от ускоренного накопления технического долга?
Про доверие к руководству
Что произойдёт, если ваши метрики покажут, что AI ухудшает процесс?
Какие результаты заставят руководство признать, что проблема не в «консервативных сеньорах», а в самой модели внедрения?
Про статус и роль сеньора
Если моя основная функция теперь проверять то, что сгенерировала модель, в чём руководство видит мою профессиональную ценность?
AI забирает быструю и заметную часть работы, а нам оставляет сложные риски и ответственность. Как это будет учтено при оценке результатов?
Пожалуйста, оставьте
свой отзыв
Дмитрий Чуканов
СберТех
@ChukanovDK
i@chukanovdk.ru
