В корпоративной ИИ-трансформации часто звучит фраза: «Давайте сначала выдадим всем инструменты, а потом разберемся, как ими пользоваться». Евгений Семенюк, работающий как ИИ Dev/Test Coach, Solution Architect и Quality Architect, утверждает, что такой подход ошибочен. В своей статье на Habr он рассказывает, как в крупной финансовой организации в США проводили ИИ Enablement, начав не с раздачи Claude Code, ChatGPT или Cursor, а с оценки текущего состояния 13 команд.
Первая фаза программы стартовала с трех вопросов: где находятся люди и команды, какие проблемы замедляют разработку и как организовать процесс, чтобы он не закончился демо. Для ответа на них была создана карта зрелости из трех уровней. L1 (ИИ-Engaged) — сотрудники применяют role-specific ассистентов на реальных задачах, но решения проверяет человек. L2 (ИИ-Enabled) — ИИ встроен в повторяемые командные процессы, появляются общие промпты, rules, agents и playbooks. L3 (ИИ-Native) — люди и ИИ работают как единая end-to-end система с оркестрацией и метриками. Эта модель оценивает зрелость команды, а не отдельного сотрудника; для людей была отдельная лестница ИИ Champions.
| Уровень | Название | Как выглядит работа команды |
|---|---|---|
| L1 | AI-Engaged | Люди применяют role-specific assistants и copilots на реальных задачах. Использование в основном индивидуальное, решения проверяет человек |
| L2 | AI-Enabled | AI встроен в повторяемые командные workflows. Появляются общие prompts, rules, agents, playbooks и измеримые use cases |
| L3 | AI-Native | Люди и несколько AI-компонентов работают как одна end-to-end система. Есть orchestration, governance, метрики и внутренние владельцы |
В программе участвовали разные уровни. Самый широкий — общие воркшопы, которые собрали около 800 участников: разработчиков, QA-инженеров, бизнес-аналитиков, продакт-менеджеров, дизайнеров и архитекторов. Целью было дать общий язык, объяснить правила безопасного использования ИИ и помочь найти первые применимые задачи. Параллельно были выделены три функциональных потока: Engineering (генерация кода, объяснение legacy, unit-тесты, code review), Quality Assurance (анализ требований, генерация тестовых сценариев, анализ дефектов) и Digital/Product (подготовка требований, user stories, анализ обратной связи).
Около 800 сотрудников участвовали в общих воркшопах, но фокус был на Lighthouse-командах для углубленной работы.
Для 13 Lighthouse-команд планка была выше: они должны были перейти от отдельных экспериментов к командным workflows и reusable artifacts. По словам автора, для большинства участников первым успехом было безопасно применить инструмент к реальной задаче и получить воспроизводимый результат. Программа не ставила целью сразу создать сложных агентов — сначала нужно было выстроить базовую грамотность и понять, какие процессы замедляют разработку.
Автор отмечает, что охват сам по себе не создает устойчивого изменения: человек может посмотреть демонстрацию и через неделю вернуться к старому процессу. Поэтому узкий слой команд, работающих с реальным бэклогом и тестовыми активами, был необходим. В следующих частях он обещает рассказать о том, как оценивали команды, какие ошибки допустили и как перешли к ИИ-native delivery.
