От QA к AI Transformation: как 14 лет процессного опыта работают на внедрение AI в команды

Когда я переходил из QA в AI восемь месяцев назад, думал что начинаю с нуля. Что вокруг — новый мир, новые инструменты, и 14 лет в IT-качестве остаются в прошлом как “интересный бэкграунд, но к делу не относится”.

Через месяц понял противоположное: процессный бэкграунд — это не лишний груз, а главный мультипликатор. AI Transformation в компании — это не “техническая интеграция AI”. Это change management в новой среде. Те же законы, те же сопротивления, те же baseline-метрики — только инструмент новый.

Этот пост — про четыре конкретные параллели, которые я увидел, и почему я бы лучше нанял процессного человека с 6 месяцами в AI, чем AI-инженера с 6 месяцами в процессах.

Table of contents

Почему “просто AI-инженер” не вытянет внедрение

Большая часть AI-проектов в компаниях буксует не на технике. Buksuет на людях:

• Команда не понимает, какие задачи отдать AI, а какие — нет
• Прежние процессы не приспособлены к интеграции AI — куда вставлять, где review
• Сотрудники сопротивляются — потому что не понимают, как это меняет их работу
• Нет baseline-метрик “как было до AI”, поэтому невозможно показать эффект
• Успешный пилот не масштабируется — нет процесса передачи практики между командами

Каждая из этих проблем — классическая задача change management. Не задача архитектора или ML-инженера.

AI-инженер закроет первые два пункта. С остальными он, как правило, ничего сделать не может. Не потому что глупый — потому что никогда этого не делал.

Процессный человек все эти пять пунктов умеет. Ему остаётся освоить технический слой AI. Это решаемо за 6 месяцев интенсивной практики. Освоить change management — это 5-10 лет.

Параллель 1: Baseline metrics

В QA первое, что делают перед изменением — фиксируют baseline. Сколько багов в проде сейчас, сколько time-to-release, сколько коверейдж, какая частота regressions. Без baseline вы не сможете показать что стало лучше.

В AI Transformation — то же самое. Перед тем как “внедрять AI в работу команды”, вы должны зафиксировать:

• Сколько часов команда тратит на класс задач, который собираемся отдать AI?
• Какое качество выходного результата сейчас (по конкретным критериям)?
• Какая частота ошибок / переделок / эскалаций?
• Какой реальный throughput команды (а не “по плану”)?

Если этих цифр нет — через 3 месяца вы не сможете сказать “AI помог”. Вы скажете “вроде стало лучше”. Это слабая позиция перед руководством.

В MERLION я выстроил систему сбора 12 метрик качества для 500+ IT-специалистов. Потом оптимизировал до 3 ключевых. Эта работа в AI Transformation один-в-один. Baseline-метрика, инструмент сбора, dashboard, periodic review.

Параллель 2: Change management через сопротивление

В EY я принял QA-команду с бэклогом 200 задач, отрицательным трендом и срывом сроков на 2 месяца. За 2 месяца переломил тренд. Это не про “техническое решение”. Это про переговоры, перераспределение нагрузки, работу с сопротивлением и эскалацией.

В AI Transformation это работает один-в-один:

• “AI заменит мою работу” → нужно объяснить, что меняется и что остаётся (через диалог, не через презентацию)
• “Я не доверяю AI” → нужно дать конкретный пилот с малым риском
• “Это медленнее чем я делаю руками” → нужно показать что окупается на длинной дистанции
• “Это плохо работает в моём кейсе” → нужно разобрать конкретный кейс и либо адаптировать AI, либо честно сказать “тут AI не работает”

Каждый из этих диалогов — это диалог, который человек с change-management опытом ведёт по навыку. Без этого опыта — это диалог, в котором обе стороны просто закрепляются в своих позициях.

В Детский Мире я менторил и вырастил 4 специалиста из техподдержки в QA и DevOps. Это ровно тот же навык, который нужен для перевода команды на AI-инструменты: переквалификация через сопровождение, а не через “обучение в формате курса”.

Параллель 3: Scaling практик между командами

В МойОфис у меня было 20+ продуктовых команд. Когда одна команда находила улучшение QA-процесса, моя задача была — упаковать это и распространить на остальные 19. Без потери качества, без потери смысла, без копипасты ради копипасты.

В AI Transformation проблема идентична:

• Одна команда нашла, как использовать AI для X — это работает, экономит часы
• Как сделать так, чтобы другие 5 команд этим воспользовались?
• Что упаковать (промпты, чек-листы, процессы)?
• Что НЕ упаковывать (доменная специфика, личные предпочтения)?
• Как избежать “AI cargo cult” — когда команды копируют форму, не понимая зачем?

Здесь process-человек знает: сначала упаковать в воспроизводимый формат, потом устроить session по обмену, потом дать time на адаптацию, потом снять метрики. AI-инженер обычно даёт прямую инструкцию и удивляется, что её не применяют.

Мой собственный паттерн skills (с триггер-фразой и обязательными pre-steps) — это инструмент scaling. Не “я разово делаю X”, а “я зафиксировал X как воспроизводимый протокол”.

Параллель 4: Менторство и переквалификация

В Детский Мир я не нанимал готовых QA — я переквалифицировал людей из техподдержки. За 5 лет 4 человека вышли из техподдержки в QA / DevOps. Это требовало времени, доверия, понимания где зона роста, где зона комфорта.

В AI Transformation то же самое нужно делать в обратную сторону: брать людей с глубокой доменной экспертизой и переквалифицировать в работу с AI. Не “обучать новой технологии”, а переучивать рабочий процесс.

Это медленный процесс. Курсы не работают. Работает: руководитель сидит рядом, кейс за кейсом разбирает с человеком, корректирует, поощряет, отпускает. Через 2-3 месяца человек выходит на самостоятельность.

Без этого опыта вы получите команду, которая прошла “тренинг по AI” и продолжает работать как раньше.

Что НЕ переносится из QA в AI

Чтобы быть честным — не всё переносится. Есть зона, где надо учиться с нуля:

1. Технический слой AI — модели, кэш, промпт-инжиниринг, агентная архитектура. Эту часть пришлось осваивать систематически: статьи, эксперименты, собственная инфраструктура
2. Экосистема инструментов — API, фреймворки, интеграции, типы агентов. Меняется каждые 3 месяца
3. Понимание ограничений AI — где он галлюцинирует, где надёжен, где требует supervision. Это только через практику, не через теорию

Эти три слоя в моём кейсе закрывались параллельно с переездом: 8 месяцев активной работы + 80+ проанализированных статей + собственный production-проект.

Почему фаундеру нужен такой профиль

Если вы фаундер или Head, который хочет внедрить AI в команду — задайте себе вопрос:

Что вам нужнее: специалист, который знает технику AI, но не умеет менять процессы — или специалист, который умеет менять процессы, но осваивает AI последние 6 месяцев?

Первый сделает вам пилот. Второй сделает вам внедрение, которое масштабируется.

Это не теория. Это эмпирическое наблюдение по объявлениям о вакансиях AI Transformation Lead, AI Operations Manager, AI Integrator — все они требуют сочетание: процесс + AI. Чисто AI-инженерных вакансий на эти роли почти нет, потому что наниматели уже обожглись.

Что делать если ты процессный человек, который хочет в AI

Простой план, который я прошёл:

1. Не “учитесь AI с нуля” — начните применять AI в своей текущей работе. У вас есть рутины — автоматизируйте их через AI. Это даст реальные кейсы, а не “учебный проект”
2. Заведите минимальную инфраструктуру — иерархия конфигов, журналы решений и ошибок, отдельные сценарии. Это даёт вам архитектурный взгляд на работу с AI, а не “я нажимаю кнопки в чате”
3. Сделайте 1-2 публичных артефакта — продукт, статья, кейс. Это становится якорем, на который смотрят рекрутёры
4. Используйте свой process-опыт как преимущество, не маскируйте его. На вакансиях AI Transformation Lead про вас написано прямо — не нужно “становиться AI-инженером”, нужно оставаться процессным человеком, который освоил AI

Заключение

AI Transformation — это не задача про AI. Это задача про изменение работы команды, где AI — новый инструмент.

Если вы 10+ лет управляли процессами, командами, change management — у вас на руках главный навык для этой роли. Освоить технический слой AI — это вопрос 6-12 месяцев интенсивной практики. Освоить change management в нагрузке — это годы.

Не списывайте свой бэкграунд как “несовременный”. Он именно тот, который нужен сейчас рынку.

Если вы фаундер или Head, у которого пилот AI стоит на месте — посмотрите внимательно: вам не хватает технического решения, или вам не хватает человека, который умеет переводить команду на новый процесс?