Люди: роли, обучение и пилотная группа
Всё предыдущее (инструменты, процессы, метрики) не работает, если не работают люди. По моему опыту, работа с людьми при внедрении занимает больше времени и сил, чем техническая часть, но именно её чаще всего недооценивают.
Вы технический директор, пилот одобрен, теперь нужно решить, кто в него пойдёт. Сначала выбор, затем результат через квартал, потом разбор: как готовить команды, что делать с сопротивлением, с джунами и с оценкой инженеров.
Кто пойдёт в пилот
Пилот одобрили, бери «Платёжку»: там лучшие ребята, сами просятся, быстро покажут результат. Прикинь заодно: если всё пойдёт, может, джунов в следующем году не нанимаем?
Как вы соберёте пилотную группу?
Панель через квартал
было → сталоЦифры условные, они показывают направление без точной величины. Что измерять на самом деле и как снять baseline, – в блоке 11, а почему смотреть надо по группам вместо средних, объясняет разбор ниже.
Что происходит через квартал: все варианты
Цифры условные, они показывают направление без точной величины. Что измерять на самом деле и как снять baseline, – в блоке 11, а почему смотреть надо по группам вместо средних, объясняет разбор ниже.
Вариант A. Смешанная группа: Скромные цифры, которые повторятся
Генеральный поморщился, но согласился: в группу вошли 2 энтузиаста, 4 средних инженера с сервиса заявок, ведущий разработчик-скептик и инженер ИБ. Обучение состояло из 3 парных сеансов на задачах из бэклога, время на него выделили в спринте. Начали с тестов и документации. Скептик за месяц нашёл 2 проблемы: устаревшую библиотеку в подсказках и разросшиеся пул-реквесты. Через квартал ускорение умеренное, у средних инженеров оно заметнее, чем у энтузиастов, а 2 команды сами попросились во вторую волну. Про джунов вы сказали прямо: данные замену не показывают.
| Метрика | Было | Стало |
|---|---|---|
| Время от коммита до прода (метрика DORA, пилотная группа) | 7 дн | 6,2 дн |
| Доля сбойных изменений (метрика DORA) | 4,0% | 3,9% |
| Время на ревью (медиана по пул-реквесту) | 1,5 дн | 1,6 дн |
| Активное использование (пилотная группа, по данным инструмента) | нет данных | 80% |
| Команды в очереди на вторую волну (попросились сами) | 0 | 2 |
Вердикт: Цифры скромнее, чем хотел генеральный. Зато они про всю компанию, а не про одну лучшую команду, и вторая волна уже просится сама.
Что говорят коллеги после варианта A
Даниил: Состав правильный, но с человеком от ИБ как участником в банке отдельная история. У нас ИБ согласует и в работе не участвует, поэтому инженер ИБ в пилоте означает служебную записку через 2 уровня. Я бы всё равно его добивался: каждое замечание, найденное внутри пилота, экономит месяц, который потом ушёл бы на согласование. Скептика я бы брал из команды старого монолита: там к ИИ относятся хуже всего, и если убедится такой человек, ему поверят остальные скептики.
Мария: Вторую волну мы собирали почти так же, но одну вещь недооценили: энтузиастов надо разгрузить от своих задач. Они помогали остальным в свободное время и к концу второго месяца выгорели. Сейчас обучение у нас записано строкой в планировании спринта, на добрую волю мы больше не рассчитываем. Результаты средних инженеров мы показывали отдельно от энтузиастов. Остальные команды убедили именно эти цифры, средние по группе их не убеждали.
- Даниил: Мария, скептик в пилоте несёт риск. Один громкий скептик в банке может похоронить проект на совещании у зампреда.
- Мария: Громкий может, поэтому нужен конструктивный: тот, кто приносит баги вместо мнений. Такой у тебя на монолите точно есть.
- Даниил: Есть, только он не пойдёт: у него квартальный релиз, отпустить его мне никто не даст.
Итог: Вы собрали пилот, который покажет, что получат все инженеры, включая средних. Это правильный ответ, хотя Даниил прав, что участника от ИБ в корпорации придётся добиваться. Главное из блока: ИИ ускоряет людей и никого не заменяет, при этом эффект у разных групп разный.
Вариант B. Лучшая команда: Блестящий пилот, который не повторился
«Платёжка» за 6 недель показала отличные цифры: время до прода сократилось почти на треть. Генеральный рассказал о них на совете и заодно объявил, что найм джунов на следующий год замораживается. Вторая волна пошла на 2 команды сервиса заявок, но эффекта там почти нет: легаси, ревью встало, сбойных изменений стало больше. Ведущие разработчики говорят «у них сервис другой» и правы. Генеральный спрашивает, почему у всех не так, как у «Платёжки».
| Метрика | Было | Стало |
|---|---|---|
| Время от коммита до прода (метрика DORA, «Платёжка») | 5 дн | 3,5 дн |
| Время от коммита до прода (метрика DORA, вторая волна) | 7 дн | 7 дн |
| Время на ревью (медиана по пул-реквесту, вторая волна) | 1,5 дн | 1,9 дн |
| Доля сбойных изменений (метрика DORA, вторая волна) | 4,0% | 4,8% |
| Активное использование (вторая волна, по данным инструмента) | нет данных | 35% |
Вердикт: Вы показали результат лучшей команды, и теперь его ждут от всех. Заодно генеральный получил повод сокращать людей, хотя данные этого не подтверждают.
Что говорят коллеги после варианта B
Даниил: Я понимаю соблазн: в банке у каждого есть своя «Платёжка», новый сервис на современном стеке, который не стыдно показать правлению. Но большая часть наших изменений идёт в монолите с долгой историей, а цифры с нового сервиса к нему отношения не имеют. Хуже другое: генеральный уже объявил заморозку найма. Отыграть такое назад в банке сложнее, чем запустить новый пилот.
Мария: У нас первый пилот был ровно такой, а потом мы полгода объясняли, почему вторая волна «не взлетела». Она взлетела, просто у сильной команды на удобном сервисе эффект другой, разные группы получают разное. Теперь мы не показываем одну среднюю цифру: смотрим отдельно по сервисам и по опыту инженеров. Кадровых выводов из пилота мы не делаем вообще.
- Мария: Даниил, а ты бы стал вообще пускать «Платёжку» в пилот, раз она так рвётся и сама просится?
- Даниил: Во вторую волну да, а в первую нет: в банке первая цифра становится обещанием, её потом не перепишешь.
- Мария: Я бы взяла их вместе со средней командой. 2 группы дают более точную картину, чем одна, если считаешь их отдельно.
Итог: Блестящий результат лучшей команды не повторился у остальных. Для первой попытки это нормальный исход. Главное из блока: ИИ ускоряет людей и никого не заменяет, при этом эффект у разных групп разный, поэтому пилот на лучших ничего не говорит про остальных. Если захотите, пройдите развилку заново: реплики Даниила и Марии будут другими.
Вариант C. Все сразу и с нормой: Норма выполнена, код хуже
За месяц доля принятых подсказок выросла почти в 3 раза, поэтому отчёт для генерального выглядит отлично. Но инженеры принимают подсказки, чтобы попасть в норму, а потом переписывают руками. Пул-реквесты разрослись, ревью стало узким местом, сбойных изменений больше. ИБ узнала о подключении всех команд постфактум и потребовала согласования. 2 ведущих разработчика, которые не верили в ИИ, теперь не верят и вам: один уже ушёл, второй ходит на собеседования.
| Метрика | Было | Стало |
|---|---|---|
| Доля принятых подсказок (по данным инструмента, все команды) | 22% | 61% |
| Время на ревью (медиана по пул-реквесту) | 1,5 дн | 2,1 дн |
| Доля сбойных изменений (метрика DORA) | 4,0% | 5,1% |
| Время от коммита до прода (метрика DORA) | 7 дн | 7,4 дн |
| Отток инженеров (за квартал) | 2% | 4% |
Вердикт: Инструментом пользуются все, а эффекта нет. Норма привела к имитации, а недовольные молча обновили резюме.
Что говорят коллеги после варианта C
Даниил: Норма использования в банке появляется сама собой: кто-то наверху хочет показатель, а «доля принятых подсказок» отлично ложится в отчёт. Я видел, как это работает: люди принимают подсказку и тут же переписывают её руками, чтобы попасть в план. Для ИБ подключение всех сразу без согласования даёт повод остановить всё.
Мария: Мы тоже вводили норму в первый год, на 2 месяца. Отменили, когда увидели, что пул-реквесты разрослись, а ревьюеры начали пропускать. Теперь мы оцениваем результат вместо использования: дефекты, откаты, качество ревью. Ещё мы даём право не пользоваться ИИ, если человек объяснил почему. Странно, но после этого пользоваться стали больше.
- Даниил: Без нормы у меня через квартал будет 10 процентов использования.
- Мария: Тогда нужен успешный пример коллеги, приказ тут не поможет. 10 настоящих процентов лучше 90 нарисованных.
Итог: Норма дала имитацию вместо эффекта и стоила вам 1 ведущего разработчика. Для первой попытки это нормальный исход. Главное из блока: сопротивление снимают примером и прямым разговором о пределах, норма здесь бессильна. Инженера оценивают по результату, объём использования ИИ для оценки не годится. Если захотите, пройдите развилку заново: реплики Даниила и Марии будут другими.
Люди во внедрении: что работает и что нет
Вы собрали пилот по правилам. Ниже – почему средние инженеры и скептик в группе важнее ярких цифр и что ещё в работе с людьми требует решений.
Обучение нужно, причём практическое. Лекция о возможностях ИИ привычек не меняет, их меняет работа над реальной задачей, когда рядом наставник. Рабочий формат: инженер берёт задачу из своего бэклога, решает её с ИИ в паре с тем, кто уже умеет, а потом разбирает, что получилось. 2–3 таких сеанса дают больше, чем недельный курс.
Чему учить, в порядке важности: формулировать задачу для модели; разбивать большую задачу на части; проверять результат вместо того, чтобы ему доверять; понимать, когда ИИ не нужен. Последнее важно: часть задач быстрее сделать самому, а умение это распознать тоже навык.
Заложите время на обучение в планировании. Если обучение проходит «в свободное время», его не будет.
Сопротивление нужно считать нормальной реакцией, у которой есть причины, саботаж тут ни при чём. Инженеры не доверяют результатам (46% по Stack Overflow 2025, причём часто обоснованно), боятся за профессию, видели плохие демонстрации, не хотят терять контроль над кодом, который считают своим.
Что работает: показывать вместо того, чтобы заставлять, потому что успешный пример коллеги убеждает лучше приказа; начинать с задач, которые инженеры сами ненавидят (миграции, документация, тесты), чтобы ИИ воспринимался как избавление от рутины и не выглядел угрозой; прямо говорить о пределах (данные METR убеждают скептика лучше обещаний); давать право не использовать ИИ на задачах, где человек считает это вредным, при условии, что он объяснит почему.
Что не работает: обязательные метрики использования («каждый должен принять столько-то предложений»). Они дают имитацию и портят код.
Интуитивно хочется выбрать лучших и самых заинтересованных. Это ошибка, о которой я писал в блоке 12: такой пилот не масштабируется.
Рабочий состав пилотной группы: 1–2 энтузиаста, которые будут двигать дело и помогать остальным; несколько средних инженеров, чей результат покажет, что получат все; 1 конструктивный скептик, который найдёт проблемы раньше, чем они проявятся в масштабе; человек от ИБ как участник. Команда должна работать на типичном для компании сервисе, самый удобный сервис для пилота не подходит.
Этот вопрос волнует всех, а данные пока противоречивы. С одной стороны, эксперименты показывают, что менее опытные выигрывают от ИИ больше: в Management Science 2025 на 4 867 разработчиках прирост у менее опытных был выше, чем у опытных. По данным DX, новые сотрудники с ИИ быстрее доходят до первого результата. С другой стороны, есть риск, который пока плохо измерен: джун, который получает код от ИИ, не проходит путь, на котором раньше формировалось понимание. Он быстрее закрывает задачи, но медленнее становится сеньором.
Что делать, пока данных нет: джунам нужны наставник, обязательное объяснение кода на ревью (правило из блока 12) и задачи, которые нужно сделать без ИИ.
Если ИИ берёт на себя часть работы, которую раньше делали джуны, лестница меняется. Ступень «пишет простой код по задаче» исчезает или сжимается. Появляется или усиливается ступень «ставит задачи машине и проверяет результат», которая раньше была частью работы лида.
Это нужно отразить в описании уровней, иначе инженеры не понимают, за что их повышают. Отрасль пока не выработала стандарт, поэтому я предлагаю минимум: в критерии каждого уровня добавить, что ожидается от работы с ИИ. На младших уровнях это «использует ассистент для типовых задач», а на старших «проектирует процесс работы команды с агентами».
Кроме смены критериев по уровням появляются новые роли. Подробная карта на русском языке – в AI-Disrupt PDLC Сбера (раздел 3.2 методологии). Это взгляд вендора, но карта полезна как ориентир: что за работа появляется и кто её будет делать. Описания ниже – мой пересказ простыми словами, в документе названия английские.
| Роль | За что отвечает | Из кого вырастает* |
|---|---|---|
| Product Engineer (продуктовый инженер) | Ведёт фичу от исследования до продакшена и проверяет результат после выкладки. Сам ставит задачи агентам и принимает их работу | Роль собрана из продакт-менеджера, зрелого инженера и техлида |
| AI Orchestrator (оркестратор ИИ) | Управляет потоком задач между замыслом и реализацией: разбивает задачу, распределяет между агентами, следит за передачей | Техлид, старший инженер |
| Guardian Agent Engineer (инженер контроля) | Проектирует проверки (evals), правила эскалации и агента-ревьюера: что агенту можно, где нужен человек, как ловить регрессии | Старший QA-инженер (инженер по качеству), SRE (инженер по надёжности сервисов) или инженер ИБ с пониманием ML |
| Harness Platform Engineer (инженер платформы агентов) | Отвечает за среду, где работают агенты: песочницы, инструменты, долгие процессы, хуки, MCP-серверы | Старший platform engineer, SRE |
| Context Supply Chain Owner (владелец контекста) | Ведёт библиотеку паттернов, реестр спецификаций и правил, следит, чтобы контекст для агентов не устаревал и не «отравлялся» | Старший инженер с практикой спецификаций и хорошим техническим письмом, часто бывший техлид |
| AI Security Officer (офицер безопасности ИИ) | Моделирует угрозы агентных систем, защищает от обхода ограничений модели, даёт пакетные согласования доступов для долгих процессов | Инженер ИБ |
| AgentOps Engineer (инженер эксплуатации агентов) | Наблюдает за агентами в продакшене: отклонение поведения, жизненный цикл, вывод из эксплуатации | SRE, DevOps-инженер |
| Forward-Deployed Engineer (выездной инженер) | Внедряет решение в команду заказчика, адаптирует под её контекст и возвращает удачные паттерны в общую библиотеку | Старший инженер с опытом внедрений |
* По методологии – для продуктового инженера, инженера контроля, инженера платформы агентов и владельца контекста. Для остальных 4 ролей это моя оценка.
2 замечания к таблице. Первое: авторы прямо пишут, что роли появляются только при масштабе, когда функцию нужно выделять, а ранняя специализация даёт бюрократию. Из 8 ролей первыми появляются 4: продуктовый инженер, инженер контроля, инженер платформы агентов и владелец контекста. Остальные либо сохраняют привычный профиль, либо производны от этих 4. Второе: на старте пилота ни одна из ролей не нужна как отдельная ставка. Мой выбор, а не требование методологии: договориться, кто в команде отвечает за 3 вещи: правила и проверки для агентов (будущий инженер контроля), среду и инструменты (будущий инженер платформы) и библиотеку правил и спецификаций (будущий владелец контекста). У Даниила на 200 инженеров это через год превратится в 2–3 выделенных позиции, у Марии на 60 останется зоной ответственности внутри команды.
Старые метрики ломаются: число строк кода и число закрытых задач с ИИ растут и перестают что-либо значить. Остаётся и усиливается другое: качество решений (сколько дефектов, сколько откатов), качество постановки задач (для машины и для людей), качество ревью, вклад в общий контекст (файлы контекста, спецификации, документация), помощь коллегам.
Одно предупреждение: не оценивайте по объёму использования ИИ. Инженер, который сделал задачу без ИИ за час, лучше того, кто сделал её с агентом за 3.
Я намеренно сформулировал это как вопрос. Эксперименты (Peng 2023, Management Science 2025) говорят, что больший прирост получают менее опытные. METR 2025 говорит, что опытные в своём коде работают с ИИ медленнее, хотя в обновлении 2026 года картина, вероятно, развернулась (блок 11). Практики говорят, что сеньоры получают больше от агентов, потому что умеют ставить задачи и проверять результат, а джуны получают больше от ассистентов, потому что им нужна подсказка.
Вероятно, верно всё сразу, а ответ зависит от задачи и инструмента. Для руководителя это означает: не ждите одинакового эффекта у всех, измеряйте по группам и не делайте кадровых выводов из средних цифр.
Данные не поддерживают сценарий замены инженеров. Продуктивность на уровне организации упёрлась в потолок около 10% (DX, 2026), нестабильность растёт (DORA), а ревью стало узким местом (Faros AI). Это картина инструмента, который ускоряет людей и требует от них больше. Инструмент, который заменяет людей, выглядел бы иначе.
Если вы обосновываете внедрение сокращением штата, вы обещаете то, чего в данных нет, а через год вам придётся объяснять, почему не получилось. Обосновывайте ускорением, качеством и возможностями, которых раньше не было.
Что говорят коллеги
Состав правильный, но с человеком от ИБ как участником в банке отдельная история. У нас ИБ согласует и в работе не участвует, поэтому инженер ИБ в пилоте означает служебную записку через 2 уровня. Я бы всё равно его добивался: каждое замечание, найденное внутри пилота, экономит месяц, который потом ушёл бы на согласование. Скептика я бы брал из команды старого монолита: там к ИИ относятся хуже всего, и если убедится такой человек, ему поверят остальные скептики.
Вторую волну мы собирали почти так же, но одну вещь недооценили: энтузиастов надо разгрузить от своих задач. Они помогали остальным в свободное время и к концу второго месяца выгорели. Сейчас обучение у нас записано строкой в планировании спринта, на добрую волю мы больше не рассчитываем. Результаты средних инженеров мы показывали отдельно от энтузиастов. Остальные команды убедили именно эти цифры, средние по группе их не убеждали.
Обсуждение:
Состав пилотной группы
Запишите, кто пойдёт в пилот, на каком сервисе и с каких задач начнёт. Этот состав понадобится в дизайне пилота в блоке 14. Скопируйте промпт в модель, которую разрешила ваша служба ИБ (ChatGPT, Claude, GigaChat, YandexGPT или другую). Модель задаст вопросы по одному и по ответам соберёт документ. Не вставляйте в ответы секреты, персональные данные и код из закрытых систем.
Промпт для документа
скопируйте в свою модельТы – технический директор с опытом пилотов в разработке. Помоги мне собрать документ «Состав пилотной группы». Правила состава: 1–2 энтузиаста; несколько средних инженеров (по ним видно, масштабируется ли эффект); 1 конструктивный скептик; 1 участник от ИБ. Пилот идёт на типичном сервисе, а не на самом новом. Если отдельной службы ИБ в компании нет, её роль в группе берёт технический директор. Если в компании 1–2 команды и группа совпадает со всей разработкой, не требуй её делить. Проверь другое: энтузиасты не делают все задачи пилота сами, у средних инженеров есть свои задачи, скептик есть. Что нужно выяснить: - Кто энтузиасты: имена или роли, их опыт с ИИ, какую задачу они берут на себя в пилоте. Если энтузиастов больше 2, скажи об этом и предложи перевести лишних во вторую волну. - Кто средние инженеры и сколько их. - Кто скептик и какую роль он получит (например, ревью результата на смысл). - Кто участвует от ИБ и что он делает в пилоте. - Какой сервис и почему он типичный. - Какие данные и модули ИБ или регулятор не разрешают брать в пилот. - С каких задач начнём: понимание кода, документация, тесты, миграции. - Сколько часов на человека в спринте выделено на обучение и стоит ли это в плане. - Как будем смотреть результат: какие метрики, как часто, кто собирает обратную связь. Если у меня есть документ «Baseline» из блока 11, предложи взять метрики оттуда. Если в группе одни сильные инженеры или нет скептика, скажи об этом. Правила работы: - Задавай по 1 вопросу за раз и жди моего ответа. - Начни с 4 вопросов о компании, по одному: сколько в ней инженеров; чем она занимается; есть ли жёсткие требования ИБ или регулятора; используете ли вы ИИ в разработке уже сейчас и как. Учитывай ответы дальше. - Если ответ размытый, попроси цифру или конкретный пример. - Если я не знаю ответа, предложи 2–3 варианта и коротко объясни разницу. Не придумывай данные за меня. - Если ответа нет и после вариантов, оставь поле пустым и иди дальше. На слово «собирай» собери документ из того, что есть. - Если новый ответ противоречит прежнему, скажи об этом и спроси, какой ответ верный. Если я не могу выбрать, запиши оба значения в список того, что осталось пустым или слабым. - Когда все вопросы закрыты, собери документ в формате ниже. После документа отдельным списком перечисли, что осталось пустым или слабым и как это закрыть. Формат документа: таблица «Поле | Содержание» со строками: энтузиасты; средние инженеры; скептик; участник от ИБ; сервис; ограничения ИБ и регулятора; первые задачи; время на обучение; как смотрим результат. В строках с людьми – кто и что делает в пилоте.
ПримерСостав пилотной группы у Даниила
Готовый документ для команды сервиса расчёта комиссий. Имена заменены на роли, но в вашем документе должны стоять имена: безымянная группа не собирается.
| Поле | Пример заполнения |
|---|---|
| Энтузиасты (1–2) | Старший инженер, который уже год пользуется ассистентом в личных проектах; инженер среднего уровня, который сам пришёл с предложением пилота. Задача обоих: писать файл контекста и отвечать на вопросы остальных. |
| Средние инженеры (несколько) | 5 человек из основного состава команды, от 2 до 6 лет в банке, ИИ раньше не пользовались или пользовались случайно. Именно по ним видно, масштабируется ли эффект. |
| Конструктивный скептик | Тимлид смежной команды, который на обсуждении сказал: «покажите мне хотя бы одну задачу, где это не сломало больше, чем сделало». Его задача – ревью сгенерированных тестов на смысл и список того, что не работает. |
| Участник от ИБ | Аналитик ИБ, который согласовывал инструмент. Участвует в еженедельной встрече, видит статистику запросов к модели, проверяет синтетические тестовые данные. |
| Сервис | Сервис расчёта комиссий (типичный монолит на Java, 12 лет). |
| Ограничения ИБ и регулятора | Персональные данные клиентов в модель не отправляем, тестовые данные – синтетические. Формулы расчёта комиссий и всё, что идёт в регуляторную отчётность, в пилот не входят. |
| С каких задач начнёте | Понимание кода, документация, тесты – в этом порядке. Миграции – не раньше второго года, после согласования с ИБ. |
| Время на обучение в спринте | 4 часа на человека в спринте на 2 недели, заложены в план как отдельная задача, а не «в свободное время». |
| Как будете смотреть результат | Панель из 5 метрик по понедельникам плюс полчаса разговора с группой по пятницам: что помогло, что мешало, что меняем на следующей неделе. Отдельно следим за средними инженерами: если через 3 недели они не пользуются инструментом ежедневно, проблема в обучении или в окружении, а не в людях. |
пилотная группа – одна команда из 9–10 человек по правилам выше, с представителем ИБ; остальные ждут результатов второй волны.
если в компании 1–2 команды, пилотная группа совпадает со всей разработкой. Правило «1–2 энтузиаста» тогда меняется: энтузиасты не должны делать все задачи пилота сами, иначе результат покажет только их. Остальные правила работают как есть: скептик нужен (иначе никто не скажет, что не работает), обучение на реальных задачах нужно, и метрики смотреть еженедельно нужно. Представителя ИБ заменяет технический директор.
Вы собрали пилот, который покажет, что получат все инженеры, включая средних. Это правильный ответ, хотя Даниил прав, что участника от ИБ в корпорации придётся добиваться. Главное из блока: ИИ ускоряет людей и никого не заменяет, при этом эффект у разных групп разный.
Дальше блок 14 «Первые 90 дней»: Этот блок собирает всё предыдущее в план.