AI Enablement at Scale, часть 1: почему мы начали не с агентов, а с оценки 13 команд

Самая опасная фраза в корпоративной AI-трансформации звучит примерно так:

«Давайте сначала выдадим всем инструменты, а потом разберемся, как ими пользоваться».

Инструменты действительно можно развернуть быстро. Подключить Claude Code, ChatGPT, GitHub Copilot, Cursor или Rovo технически проще, чем изменить привычки нескольких сотен инженеров, тестировщиков, аналитиков, продакт-менеджеров и дизайнеров.

Меня зовут Евгений Семенюк. Я работаю как AI Dev/Test Coach, Solution Architect и Quality Architect. Моя роль в этой программе находилась на пересечении разработки, тестирования, архитектуры, coaching и engineering productivity.

В этой серии из трех статей я расскажу, как мы проводили AI Enablement в крупной финансовой организации в США: какие группы участников создали, как оценивали команды, как построили учебные программы, какие ошибки ^[1] допустили и как постепенно перешли от отдельных AI-инструментов к AI-native delivery.

Первая фаза началась с попытки честно ответить на три вопроса:

1. Где люди и команды находятся сейчас?

2. Какие проблемы действительно замедляют разработку?

3. Как организовать программу так, чтобы она не закончилась серией красивых демо?

---

Карта программы: три уровня зрелости

Прежде чем говорить о группах, воркшопах и инструментах, важно определить, куда мы вообще двигались.

Мы использовали три уровня зрелости команды.

Это была зрелость команды, а не оценка отдельного сотрудника.

Позже у нас появилась отдельная лестница развития AI Champions — L1 Contributor, L2 Practitioner и L3 AI Native. Эти модели связаны, но не являются одним и тем же:

• зрелость команды показывает, как работает delivery system;

• уровень Champion показывает вклад и ответственность конкретного человека.

Цель Phase 1

В первой фазе у нас было две разные цели:

• широкую аудиторию программы довести до базового уровня L1 — AI-Engaged;

• 13 Lighthouse-команд провести дальше, в сторону L2 — AI-Enabled.

Мы не ожидали, что все участники сразу начнут создавать сложные агенты. Для большинства первым успехом было безопасно применить доступный инструмент к реальной задаче и получить воспроизводимый результат.

Для Lighthouse-команд планка была выше: они должны были превратить отдельные эксперименты в командные workflows и reusable artifacts.

---

Кто участвовал в программе

В крупной организации нельзя просто пригласить всех на один курс по промптам и назвать это трансформацией.

У нас было несколько уровней участия. Каждый решал свою задачу.

---

1. Общие воркшопы: около 800 участников

Самым широким уровнем были воркшопы для сотрудников разных направлений. Их совокупная аудитория составляла около 800 человек.

В них участвовали:

• разработчики;

• QA-инженеры и специалисты по автоматизации;

• бизнес-аналитики;

• продакт-менеджеры;

• дизайнеры;

• архитекторы;

• руководители;

• другие специалисты, задействованные в создании цифровых продуктов.

Целью этих воркшопов не было сразу превратить каждого участника в AI-эксперта.

Нам нужно было:

• дать общий язык для разговора об AI;

• объяснить правила безопасного использования;

• показать доступные инструменты;

• привести примеры для разных ролей;

• помочь людям найти первые применимые задачи;

• увидеть, кто начинает экспериментировать самостоятельно;

• сформировать базовую AI-грамотность уровня L1.

Широкие воркшопы создавали охват. Но охват сам по себе не создает устойчивого изменения.

Человек может посмотреть демонстрацию, один раз открыть инструмент и через неделю вернуться к старому процессу. Поэтому параллельно нам был нужен более узкий слой команд, в которых можно было работать с реальным бэклогом, репозиториями, тестовыми активами и delivery constraints.

---

2. Три функциональных потока

Мы разделили программу на три направления.

Engineering

Сюда входили разработчики и связанные с инженерией роли.

Основные темы:

• генерация и улучшение кода;

• объяснение legacy-кода;

• unit-тесты;

• рефакторинг;

• code review;

• работа с несколькими файлами;

• контекст репозитория;

• rules для Copilot и Cursor.

Quality Assurance

Сюда входили QA-инженеры, SDET, специалисты по автоматизации и другие участники, отвечающие за качество.

Основные темы:

• анализ требований на тестируемость;

• генерация тестовых сценариев;

• анализ рисков;

• поддержка тестовой автоматизации;

• анализ дефектов;

• выбор регрессионных тестов;

• работа с тестовыми данными;

• анализ результатов тестирования.

Digital/Product

Это был не только бизнес-анализ.

В поток входили:

• продакт-менеджеры;

• бизнес-аналитики;

• дизайнеры;

• специалисты по исследованиям;

• другие продуктовые и digital-роли.

Основные темы:

• подготовка требований;

• user stories и acceptance criteria;

• анализ пользовательской обратной связи;

• синтез исследований;

• продуктовые документы;

• работа с design- и business-контекстом.

Почему мы не сделали один универсальный курс?

Потому что универсальный курс быстро становится одинаково поверхностным для всех.

Опытному разработчику неинтересно несколько недель слушать про базовые промпты. QA-инженер не увидит ценности в демонстрации генерации UI-компонента. Дизайнеру или аналитику мало пользы от лабораторной работы по рефакторингу Java-кода.

Общими для всех оставались:

• ответственное использование AI;

• работа с контекстом;

• проверка результата;

• human-in-the-loop;

• формулирование use case;

• фиксация ограничений;

• сбор evidence;

• создание reusable artifacts.

А практическая часть различалась по трекам.

---

3. Lighthouse-команды: место, где обучение превращалось в изменение процесса

Следующим уровнем стали 13 Lighthouse-команд.

Слово Lighthouse можно перевести как «маяк». Эти команды должны были первыми пройти путь, показать работающие примеры и подсветить дорогу остальным.

Важно: это не была группа «лучших» или «самых инновационных» сотрудников.

Мы искали команды, у которых были:

• реальный продуктовый бэклог;

• достаточно стабильный процесс;

• доступные delivery metrics;

• представители Engineering, QA и Product;

• возможность выделить время на эксперименты;

• проблемы, типичные для других команд организации.

Lighthouse-команда должна была не просто пройти обучение ^[2], а применить AI к реальной работе.

Например:

• проанализировать реальные требования;

• улучшить существующий набор тестов;

• создать rules для реального репозитория;

• автоматизировать часть review-процесса;

• построить repeatable workflow;

• показать результат другим командам.

Именно здесь появлялись доказательства, а не только впечатления ^[3].

---

Мы начали с оценки, а не с готовой учебной программы

Большинство enablement-программ сначала создают курс, а затем пытаются привести под него команды.

Мы пошли в обратную сторону.

Сначала мы оценили 13 Lighthouse-команд, визуализировали их delivery pipelines, нашли ограничения и предложили возможные AI use cases. И только после этого сформировали curricula для трех треков.

Оценка состояла из двух параллельных частей.

---

Оценка готовности людей

Мы хотели понять:

• какие AI-инструменты уже доступны;

• какими инструментами люди действительно пользуются;

• где использование ограничивается разовыми вопросами;

• какие есть опасения и blockers;

• какие форматы обучения предпочитают участники;

• кто уже экспериментирует и делится результатами;

• кто потенциально может стать Champion.

Мы старались смотреть не только на самооценку.

Человек может считать себя продвинутым пользователем, потому что каждый день задает вопросы ChatGPT. Другой может считать себя новичком, хотя уже построил повторяемый workflow с validation и reuse.

Поэтому нам были важны поведенческие признаки:

• использование на реальных задачах;

• практические вопросы вместо абстрактного интереса ^[4];

• готовность показать неидеальный эксперимент;

• фиксация того, что сработало и что не сработало;

• помощь коллегам;

• продолжение работы после workshop;

• желание взять ownership за use case.

---

Анализ и визуализация delivery pipeline

Вторая часть оценки была технической и процессной.

Мы не просто разговаривали с командами. Мы визуализировали их delivery pipeline:

• от появления идеи;

• через требования и planning;

• разработку;

• тестирование;

• release;

• production support.

На схеме отмечались:

• ожидания;

• ручные операции;

• возвраты;

• rework;

• отсутствующие quality gates;

• проблемы с данными и окружениями;

• поздние проверки;

• потенциальные точки применения AI.

Мы смотрели:

• где работа ожидает;

• где возникают дефекты и переработка;

• какие проверки выполняются вручную;

• какие quality gates существуют только в документации;

• сколько времени команды ждут тестовые данные;

• где отсутствуют security-проверки;

• какие задачи повторяются достаточно часто, чтобы их имело смысл автоматизировать.

И здесь обнаружилось то, что сильно повлияло на программу.

Самые заметные возможности находились не только и не столько в генерации кода.

Из 13 команд:

• 10 испытывали проблемы с Test Data Management;

• 12 не имели полноценного DAST-покрытия;

• 11 в значительной степени зависели от ручного тестирования;

• у 9 quality gates существовали скорее как правила, чем как реально выполняемые проверки.

Если бы мы начали с лозунга «давайте ускорим написание кода», мы могли бы сделать быстрее уже сравнительно быстрый участок процесса и оставить нетронутыми главные ограничения.

---

Что было индивидуальным, а что общим

Здесь важно избежать неправильного впечатления.

Мы не создавали отдельную учебную программу для каждой из 13 команд.

И не проводили 13 полностью разных наборов тренингов.

Индивидуальными для каждой команды были результаты assessment:

• текущий уровень зрелости;

• визуализация delivery pipeline;

• основные bottlenecks;

• ограничения и blockers;

• потенциальные Champions;

• предложенные AI use cases;

• возможные критерии результата.

После этого мы агрегировали результаты assessment’ов всех 13 команд и построили один curriculum для каждого функционального трека:

• Engineering curriculum;

• QA curriculum;

• Digital/Product curriculum.

То есть assessment был team-specific, а обучение — track-specific.

Это позволило сохранить две вещи одновременно:

• релевантность реальным проблемам;

• масштабируемость программы.

Примеры и hands-on упражнения брались из повторяющихся проблем, найденных в 13 командах, но сам curriculum не пересобиралась отдельно под каждую команду.

---

Как был устроен ритм Phase 1

Обычно в рамках каждого функционального трека проходила одна или две сессии в неделю.

Форматы включали:

• вводные занятия;

• tool demonstrations;

• hands-on workshops;

• разборы реальных use cases;

• pairing;

• office hours;

• artifact review;

• подготовку демонстраций.

Кроме функциональных сессий были еще два регулярных формата.

AI Champions Sync

Еженедельная рабочая встреча активных Champions.

На ней обсуждали:

• какие use cases находятся в работе;

• что изменилось за неделю;

• какие есть blockers;

• кому нужна помощь;

• какие результаты готовы к review;

• что можно показать на общей встрече.

Lighthouse Session

Еженедельная сессия для демонстрации практических результатов.

На ней команды:

• показывали работающие решения;

• рассказывали о неудачах;

• разбирали ограничения;

• проводили mini-workshops;

• отвечали на вопросы;

• находили команды, которым можно повторно использовать подход.

Lighthouse Session создавала social proof.

Рассказ внешнего коуча о пользе инструмента работает слабее, чем демонстрация коллеги:

«Вот наша задача. Вот как мы решали ее раньше. Вот что изменили. Вот результат. Вот где решение пока ломается».

---

Кто такие AI Champions

Внутри Lighthouse-команд мы выделяли AI Champions.

Champion — это не обязательно самый технически сильный человек и не обязательно руководитель.

Это участник, который:

• пробует AI на реальной работе;

• берет небольшой use case;

• доводит эксперимент до результата;

• документирует подход;

• показывает его коллегам;

• помогает другим повторить решение.

Сначала часть Champions была номинирована менеджерами.

И здесь мы получили неприятный, но полезный результат: примерно 45% номинированных Champions так и не создали видимого результата.

Они могли посещать сессии и интересоваться темой. Но:

• у кого-то не было времени;

• кто-то не выбирал роль добровольно;

• у кого-то не было подходящего use case;

• кому-то не дали доступ;

• кто-то не был готов влиять на коллег.

Мы поняли, что звание Champion ничего не гарантирует.

После этого мы стали оценивать не номинацию, а поведение ^[5]:

• создал ли человек артефакты;

• владеет ли use case;

• показал ли демо;

• помог ли коллегам;

• задокументировал ли ограничения;

• продолжил ли работу после обучения.

Эта модель стала основой масштабирования во второй фазе.

---

План, который пришлось переписать на ходу

Изначально в продвинутой части программы мы планировали использовать CodeMie как основную корпоративную платформу для:

• shared agents;

• подключенного контекста;

• интеграций;

• повторного использования;

• оркестрации нескольких шагов и агентов.

Но внутреннее согласование и approval процесс заняли намного больше времени, чем предполагал календарь программы.

К этому моменту:

• команды уже были выбраны;

• коучи подготовили материалы;

• сессии стояли в календаре;

• участникам рассказали о следующем уровне;

• были сформированы ожидания.

У нас было три варианта.

Первый — остановить программу и ждать.

Второй — продолжить рассказывать об agentic workflows теоретически, без реальной практики.

Третий — перестроить программу вокруг инструментов, которыми команды уже могли пользоваться.

Мы выбрали третий вариант.

Из Phase 1 убрали продвинутые orchestrated agent workflows.

Вместо этого сфокусировались на:

• GitHub Copilot;

• Cursor;

• Rovo;

• ChatGPT;

• отдельных возможностях других доступных инструментов.

При этом сохранили независимые от платформы навыки:

• context engineering;

• workflow design;

• human-in-the-loop;

• quality validation;

• описание ограничений;

• измерение результата;

• reusable artifacts.

Решение позволило сохранить темп. Но оно создало долг, который пришлось выплачивать во второй фазе.

Люди начали строить рабочие решения в доступных инструментах. Когда позже появилась CodeMie, естественной реакцией ^[6] стало:

«А зачем нам еще одна платформа, если у нас уже что-то работает?»

Об этом подробнее — во второй статье.

---

Что мы получили по итогам первой фазы

Phase 1 не должна была превратить всю организацию в AI-native за три месяца.

Ее целью было:

• создать широкую базу людей уровня L1;

• приблизить 13 Lighthouse-команд к L2;

• найти рабочие use cases;

• сформировать активное Champion сообщество;

• подготовить систему к масштабированию.

По итогам фазы мы получили:

• базовую картину готовности;

• assessment и визуализацию pipelines 13 команд;

• три curricula, основанные на агрегированных результатах assessment;

• семь первых готовых к production MVP use cases;

• первые reusable artifacts;

• активное ядро Champions сообщества;

• регулярные Champions Sync и Lighthouse Sessions;

• понимание реальных барьеров и ограничений;

• список ошибок, которые нельзя было повторять ^[7] при масштабировании.

Главный результат первой фазы заключался не в количестве промптов, скилов или агентов.

Мы доказали, что AI можно применять к реальной работе в регулируемой организации и что программу можно строить не вокруг моды на инструмент, а вокруг проблем delivery system.

---

Выводы первой фазы

1. Обучение должно следовать за assessment

Сначала найдите ограничение процесса. Потом выбирайте инструменты и стройте curriculum.

2. Широкие воркшопы и глубокое внедрение — разные задачи

Около 800 участников создают охват. Но трансформационные шаблоны рождаются внутри небольшого набора команд с реальным контекстом.

3. Разным ролям нужна разная глубина

Engineering, QA и Digital/Product не должны проходить один и тот же универсальный курс.

4. Champion определяется поведением

Номинация, должность и посещаемость не заменяют созданный результат.

5. План должен выдерживать задержку инструмента

Если программа зависит от того, что одна платформа будет согласована к конкретной дате, программа слишком хрупкая.

6. Нужно создавать не пользователей, а внутреннюю систему

Первая фаза должна закончиться не только обученными людьми, но и командами, Champions, регулярными встречами, артефактами и evidence, на которых можно строить следующую волну.

Во второй части я расскажу, как мы масштабировали модель с 13 до 37 команд, почему пяти функциональных коучей уже не хватало для одновременного развития двух волн команд, зачем появились AI Mentors и AI Leaders и почему cross-functional workshops оказались одновременно полезным и спорным экспериментом.

Мои контакты:

Сайт: https://ugenius.io ^[8]
TG Канал: https://t.me/ugenius_channe ^[9]l