Раздать командам AI-инструменты оказалось недостаточно: после масштабирования удачного пилота компания получила почти нулевой бизнес-эффект. А потом переделала внедрение ИИ так, что time-to-market, по ее оценке, сократился примерно вдвое. Для российских IT-команд это полезный холодный душ: проблема часто не в модели и не в лицензиях, а в самом процессе доставки изменений.
Об этом сообщает Habr / Карьера со ссылкой на кейс Евгения Симоновича из Ви.Tech. История началась вполне по учебнику. В пилот взяли несколько команд, дали им ассистента в IDE, генерацию кода и автотестов, получили заметный локальный прирост и решили раскатывать практику шире. На масштабе картина рассыпалась. По словам автора, часть сотрудников просто не приняла новый инструмент, часть попробовала неудачно и быстро записала его в бесполезные, а реально ощутимый буст получили лишь те, кто сам разобрался и дотащил подход до рабочих сценариев. В публикации приводится характерная оценка: условный прирост в 20% случился у 5% команд. Для бизнеса это почти ничто, если остальные работают по-старому.
Ключевой вывод звучит неприятно, но знакомо любому, кто переживал корпоративные трансформации: внедрение ИИ не равно закупке лицензий. Инструмент сам себя не встраивает в ежедневную работу. Более того, ускорение одного участка не гарантирует ускорения всего контура. Если узкое место находится не в кодинге, а в аналитике, тестировании, приемке или релизе, то выигрыш разработчиков просто сдвинет очередь дальше по цепочке. Поэтому команда перестала смотреть только на cycle time разработки и переключилась на более жесткие метрики: общий time-to-market по фиче и количество «перекладок», когда артефакт переходит из рук в руки и на каждом этапе переписывается заново. Для e-commerce и крупных продуктовых команд это, пожалуй, самая практичная часть кейса: локальный выигрыш разработчика не всегда превращается в выигрыш компании.
Дальше провалились два популярных сценария, которыми рынок обычно пытается лечить такие истории. Первый: «давайте всех обучим». Идея понятная, но общий курс «про ИИ» быстро устаревает и почти не отвечает на вопрос, что конкретно делать аналитику, тестировщику или backend-инженеру в его процессе и стеке. Второй: «давайте выберем амбассадоров». Здесь проблема уже не в мотивации, а в полномочиях. Люди, которым нравятся новые модели, не обязательно хорошо знают реальный производственный поток конкретного домена, а главное, не могут сказать команде: теперь работаем так. Энтузиазм без мандата редко меняет стандарт работы, особенно если у команды за плечами уже были инициативы, которые приносили много презентаций и мало пользы.
Рабочая схема у Ви.Tech появилась, когда фокус сместили с инструментов на доменные компетенции. Вместо вопроса «какой ассистент выдать» появился другой: кто отвечает за работу конкретного домена с ИИ. Так возникли лиды компетенций по направлениям вроде аналитики, архитектуры, бэкенда, фронтенда и тестирования. На старте, по словам автора, хватило чуть больше десятка таких людей на весь контур. Их задача не в том, чтобы вдохновлять коллег слайдами, а в том, чтобы руками проверять инструменты на своих задачах, измерять эффект, формализовать работающие практики и превращать их в новый стандарт домена. Важная деталь: у этих людей должны быть права на изменение процесса, а не роль доброжелательного евангелиста без рычагов. Заодно компания получила побочный, но ценный эффект: для сильных инженеров появился вариант горизонтального роста без обязательной миграции в менеджмент.
Отдельно кейс показывает, что внедрение ИИ быстро упирается не только в людей, но и в артефакты. Если аналитик пишет одно, тестировщик пересобирает это в свой формат, а разработчик потом еще раз адаптирует под себя, LLM лишь делает старую нестыковку заметнее. В компании сформулировали простой принцип: формат артефакта задает тот, кто принимает эстафету, а не тот, кто ее передает. Если следующий шаг делает агент, значит артефакт должен быть машиночитаемым, например в виде JSON и набора use case, а не многостраничного текста ради ритуала. Параллельно пришлось менять техническую среду: доступ к моделям через внутреннюю прослойку, отдельные внутренние LLM для чувствительных данных, контроль того, что можно отправлять наружу, и инфраструктуру под длинные агентные запуски. Автор прямо пишет, что желание оставить агента работать на 20 часов и закрыть ноутбук быстро приводит к Kubernetes, а не к еще одной вкладке в браузере.
Финал у этой истории не рекламный, а потому и полезный. По оценке команды, после смены подхода time-to-market сократился примерно в два раза, минимальный срок доставки изменения уменьшился с месяца до двух недель, а среднее ускорение составило около 50%. При этом затраты выросли: лицензии, токены и инфраструктура бесплатными не становятся. Но здесь важна не экономия в вакууме, а стоимость задержки бизнес-изменения. Если фича приносит заметный эффект, то выигрыш в сроках может быть важнее, чем попытка сберечь бюджет на инструментах. Есть и честная оговорка: автор не пытается приписать весь результат только ИИ. Часть эффекта могла дать параллельная перестройка процесса из проектного в более продуктовый. И это, пожалуй, главный вопрос для рынка на ближайший год: побеждать будут не те, кто первым закупил модные модели, а те, кто сумел переписать под них роли, артефакты и правила работы без лишнего театра вокруг «инноваций».