Чеклист внедрения AI в компании
AI уже в команде. Вопрос — в какой точке вы находитесь и что делать дальше. Чеклист построен на реальном опыте внедрения: ошибки, которые повторяются из компании в компанию, и практики, которые стабильно работают.
Перед тем как идти по чеклисту, пройдите диагностику → — она покажет, какие зоны горят красным именно у вас.
Четыре фазы
| Фаза | Главный вопрос | Главная ошибка |
|---|---|---|
| 1. Осмысление | Зачем мы это делаем? | Начать без ответа на «зачем» |
| 2. Подготовка | Готова ли среда и есть ли правила? | Раздать доступы без контекста |
| 3. Запуск | Кто отвечает и как проверяем? | Отсутствие договорённости об ответственности |
| 4. Масштабирование | Почему ускорение не сократило доставку? | Масштабировать до того, как заработало на одной команде |
Фаза 1. Осмысление
До того как кто-то получил доступ к AI-инструменту.
Что проверять
- Цель сформулирована через работу. «Сократить Lead Time на 20%», «повысить покрытие автотестами», «освободить senior-ов от рутинных задач». Цель привязана к работе, а не к факту использования AI.
- Цель разделена командой. Если на вопрос «зачем» три человека называют три разных ответа — горит зона «Цель и метрики». Вернитесь и договоритесь.
- Метрики выстроены по уровням, а не одна. Четыре уровня метрик, от промежуточных к конечным:
- Привычка работать с AI — сколько людей реально работает с инструментами (MAU, W50 — доля использующих AI в 50%+ рабочих дней)
- Доставка — изменились ли метрики доставки: Lead Time, Throughput, время ревью, число багов после релиза
- Guardrails — не ломаем ли по пути: Defect Rate, число инцидентов с AI-участием, безопасность данных
- ROI — бизнес-эффект: сокращение времени доставки фич, снижение стоимости разработки, перераспределение людей на более сложные задачи
- Привычка работать с AI — промежуточный сигнал. Результат — изменение доставки. Чаты — туризм: зашли, посмотрели, ушли. Артефактов в работе нет. Рост активности без изменения доставки — имитация внедрения.
- Выбран стартовый сценарий. Выберите один-два конкретных сценария: написание тестов, ревью кода, генерация документации, рефакторинг легаси.
Что не работает
- Email-рассылки и вебинары — знание не передаётся, экспертиза не растёт
- Реестры инструментов — никто не открывает сам
- «Надо использовать» — сопротивление и статус-кво
- Привычка работать с AI как единственная метрика успеха
Красные флаги
- Разные команды называют разную цель — и никто не замечает разницы
- 80% людей работают с AI, Lead Time стоит — имитация внедрения
- «Руководство сказало внедрить» без дальнейшей конкретики
- Метрик эффекта нет, есть только число пользователей
Что делать
Соберите команду и ответьте на три вопроса письменно:
- Какую рабочую метрику мы хотим изменить?
- Как поймём, что AI дал результат, а не просто «использовался»?
- Что перестанем делать, когда AI возьмёт часть работы?
Фаза 2. Подготовка
У вас есть цель. Теперь — чтобы инструмент вошёл в привычку, а не в обход.
Что проверять
- Инструмент видит контекст работы. Ассистент подключён к репозиторию, знает архитектуру, интегрирован в IDE и CI. Если инженер копирует файлы вручную в чат — среда не готова.
- Быстрая установка. Люди уходят до первого результата не из-за сложности AI. Причина проще: инструмент невозможно поставить. Одна команда в терминале — и всё работает.
- Правила использования записаны. Что можно отправлять в AI-сервис, что нельзя. Какие данные под compliance. Конкретный список вместо общих предупреждений: production-конфиги — нет, анонимизированные логи — да, персональные данные — нет.
- Сценарии на реальных задачах команды. Проверьте на задачах самой команды. Если на демо показывают чужой пример, а свой никто не пробовал — люди скажут «у нас по-другому» и уйдут.
Красные флаги
- Теневые инструменты: часть команды уже пользуется своими AI-сервисами в обход официального
- Production-конфиги уходят в публичный сервис, потому что «быстрее»
- «Сказали нельзя — непонятно что именно» → люди либо боятся всего, либо игнорируют запрет
- Инструмент есть, им никто не пользуется — слишком неудобно
Что делать
- DevEx-аудит: пройдите один реальный сценарий руками инженера и замерьте, сколько лишних действий.
- Напишите правила на одной странице: что можно, что нельзя, что под вопросом (и кто решает).
- Выберите одну пилотную команду. Не две, не три — одну.
Фаза 3. Запуск
Пилот работает. Теперь — чтобы использование AI не создало новых проблем.
Что проверять
- Ответственность размечена. Человек, отдавший задачу ассистенту, владеет результатом. В pull request — краткий контекст: что задано, какие ограничения, какие файлы видел агент. На ревью «это AI написал» — не оправдание.
- Роли пересмотрены явно. Кто теперь делает ревью AI-кода? Кто проверяет output на безопасность? Кто решает «этот сценарий можно отдать, этот нельзя»? Зафиксируйте письменно.
- Тревога за роль и рост проговорена. Senior, который запрещает джунам AI из страха за их рост — симптом. Нужен разговор: как теперь выглядит рост, если часть кода генерирует агент?
- Работа с людьми идёт системно. 70% трансформаций проваливаются, потому что не работают с людьми. С системным подходом к изменениям — 88% успешных. Модель ADKAR даёт простую карту работы с людьми на каждом этапе изменений.
Что работает на практике
- Воркшопы на реальных задачах команды. Реальный тикет из трекера. Мини-группы: 1 эксперт на 2–3 человека. Участник за рулём, эксперт — штурман. Данные с практики: до 88% участников продолжают пользоваться через полгода.
- Руководители — предусловие трансформации. Руководители команд критично должны сами уметь работать с AI. Их вовлечение даёт кратный рост использования AI в команде. Без них системное изменение не запускается.
- Первый опыт на своей задаче критичен. Кто попробовал агентов на реальной рабочей задаче — продолжают пользоваться. Кто пробовал на чужом примере — бросают.
Красные флаги
- «Это AI написал» звучит на ревью как оправдание
- Никто не знает, кто отвечает за AI-результат
- Senior-ы саботируют использование AI младшими
- Команда использует AI, роли не поменялись
Что делать
- AI Working Agreement (шаблон — в AI Resistance Map): один документ на команду.
- Разговор про роли: «что перестаём делать руками и что начинаем проверять».
- Воркшоп на реальных задачах.
- Ретро пилота до масштабирования.
Фаза 4. Масштабирование
Пилот сработал. Теперь — чтобы ускорение на входе не создало пробку на выходе.
Что проверять
- Поток измеряется целиком. AI ускорил написание кода. Что с ревью, QA, релизом, поддержкой? Если PR-ов стало в разы больше, а ревьюеров столько же — ускорения нет. Узкое место переместилось.
- Все роли участвуют в агентизации. Если разработчики активно используют AI, а тестировщики, DevOps и аналитики — нет, Lead Time не двинется. Скорость системы = скорость самого медленного элемента.
- Агентизация ролей. Каждая специальность автоматизирует свою часть работы. QA учат агентов писать тест-кейсы и матрицы трассировки. Аналитики — генерировать спецификации. DevOps — конфигурировать пайплайны.
- Опыт первой команды упакован. Вторая команда получает готовый пакет: рабочие промпты, шаблон AI Working Agreement, список проверок на ревью, примеры реальных задач. Запускает пилот за недели вместо месяцев.
- Формат внедрения подбирается под контекст команды.
Три проблемы AI-first команд (чеклист для профилактики)
- Когнитивная нагрузка — e2e-ответственность за весь SDLC давит на одного. Решение: оцифровать предметную область — guardrails и контекст, агент берёт нужное сам в нужный момент.
- Валидация — агенты генерят быстрее, чем человек успевает проверять. Решение: человеку только самое важное, агента тренировать проверять результат.
- Горлышко — бизнес-эксперт нужен везде одновременно. Решение: эксперт становится хранителем предметной области.
Суть сдвига: специалист больше не делает — он держит стандарт. Люди — gatekeepers качества на своих этапах. AI — дополнительные руки.
Красные флаги
- PR-ов больше, а время до релиза не сократилось или выросло
- Качество ревью упало — ревьюеры пропускают ошибки из-за объёма
- Каждая новая команда «изобретает AI заново» с нуля
- Активность в AI растёт, метрики доставки стоят
- Ускорили только разработчиков — остальные специальности не в игре
Что делать
- Value stream mapping с AI: нарисуйте поток, отметьте, где AI ускорил, а где пробка.
- Пакет для следующей команды: рабочие промпты, шаблон AI Working Agreement, список проверок, примеры задач.
- Ограничьте WIP на ревью, если объём AI-кода растёт.
- Запускайте агентизацию ролей с самой отстающей специальности.
Как пользоваться чеклистом
- Пройдите диагностику — 12 вопросов, 5 минут.
- Посмотрите, какие зоны горят красным.
- Найдите свою фазу в чеклисте и пройдите по контрольным точкам.
- Перенесите 1–3 красные зоны в AI Resistance Map и оформите черновик AI Working Agreement.
Чеклист — живой документ. Если у вас сработало что-то, чего здесь нет — напишите. Добавлю.