Мы выдали командам ИИ-инструменты и получили нулевой эффект: почему так произошло и что пришлось изменить
Привет! Меня зовут Евгений Симонович, я работаю в Ви.Tech. В этой статье расскажу, как мы внедряли ИИ и LLM в разработку, почему первая масштабная попытка почти не принесла бизнес-результата и какие выводы помогли изменить подход.
Мы начали экспериментировать с ИИ в контуре разработки в декабре. К середине года у нас уже сложилась стратегия, но путь к ней оказался непрямым: сначала был пилот с впечатляющими результатами, затем масштабирование, после которого эффект практически исчез.
Под разработкой мы понимали не только написание кода. Для нас это весь маршрут от возникновения бизнес-идеи до появления изменения в продакшене: формирование требований, аналитика, проектирование, программирование, тестирование, согласование, релиз и последующая приемка. В электронной коммерции такой процесс почти всегда проходит через множество подразделений и специалистов. Это обстоятельство оказалось ключевым.
Пилот дал отличные результаты
На первом этапе мы выбрали несколько команд и предоставили им ИИ-ассистентов в IDE, инструменты генерации кода и средства автоматического создания тестов. Результаты выглядели очень убедительно: команды стали работать быстрее, технические метрики улучшились, участники эксперимента остались довольны.
Вывод казался очевидным: если инструмент помог пилотным группам, его нужно выдать всем.
Так мы и сделали. Но после масштабирования бизнес-эффект оказался близким к нулю. Причем речь шла не о результате, который оказался просто ниже ожидаемого. Существенного изменения для бизнеса не произошло вовсе.
Почему лицензии не превращаются в результат
После анализа стало понятно, что сотрудники разделились на несколько групп.
Первая - убежденные противники подобных инструментов. Их немного, но они есть. Такие специалисты предпочитают работать привычными способами и не считают ИИ необходимым. Одной выдачей лицензии их позицию не изменить.
Вторая группа действительно получила заметное ускорение. Однако таких команд оказалось немного - примерно 5%. Они самостоятельно разобрались в возможностях инструментов, встроили их в рабочие привычки и смогли получить около 20% прироста эффективности.
Третья категория столкнулась с неудачным первым опытом. Сотрудник попробовал использовать ИИ, получил слабый или ошибочный результат, потратил время на исправления и решил, что технология не работает. Вернуть такого человека к инструменту сложнее, чем обучить новичка.
Остальные просто перестали пользоваться доступом. Инструмент формально был доступен, но в повседневный процесс так и не вошел.
Главный вывод оказался простым: сам по себе инструмент не внедряется. Можно приобрести лицензии для всей компании и не получить ни экономии, ни ускорения, ни заметного улучшения качества.
Ускорение разработки не всегда ускоряет бизнес
Еще одна важная проблема связана с неправильным выбором метрик. Если ускорить написание кода в два раза, это вовсе не означает, что бизнес получит новую функцию в два раза быстрее.
Когда программирование не является узким местом, бутылочное горлышко просто перемещается дальше: в сбор требований, аналитику, архитектурное согласование, тестирование, приемку или релиз. В результате разработчик завершает задачу раньше, но заказчик по-прежнему ждет ее столько же.
Поэтому мы перестали считать главным показателем только cycle time разработки. Вместо этого стали отслеживать полный time-to-market - время от появления инициативы до доставки изменения пользователю.
Дополнительно мы начали искать перекладки между подразделениями. Это ситуации, когда один участник передает другому промежуточный артефакт, а тот вынужден переписывать его практически заново. Например, аналитик формирует требования, архитектор трактует их иначе, разработчик уточняет детали, а тестировщик обнаруживает, что исходная постановка была неполной.
Почему массовое обучение не сработало
Первой естественной идеей было обучить всех. Казалось, что достаточно подготовить курс, провести его для нескольких сотен сотрудников - и люди начнут применять ИИ в работе.
На практике этот план столкнулся сразу с двумя проблемами.
Первая - содержание обучения. Универсальный курс обычно рассказывает, что такое генеративные модели, как пользоваться чат-ботом и составлять запросы. Но сотруднику важно другое: как применить технологию именно в его рабочем процессе.
Аналитику нужны способы ускорить сбор и проверку требований. Тестировщику - генерация сценариев, анализ дефектов и подготовка тестовых данных. Разработчику - работа с конкретным языком, фреймворком, репозиторием и внутренними стандартами. Общий разговор об ИИ не отвечает на эти прикладные вопросы.
Вторая проблема - скорость изменений. Инструменты, модели и методы работы обновляются буквально каждый месяц. Пока компания подготовит универсальную учебную программу, отдельные ее элементы уже могут устареть. Если же поручить разработку курса внешним экспертам, они нередко просят несколько месяцев. Для быстро меняющейся области это слишком долгий срок.
Почему амбассадоры тоже не стали решением
Следующий вариант выглядел не менее разумно: выбрать энтузиастов, дать им статус ИИ-амбассадоров и попросить распространять практики внутри компании.
Однако энтузиазм не всегда означает глубокое понимание конкретного процесса. Человек может отлично разбираться в новых моделях, демонстрировать интересные сценарии и регулярно следить за обновлениями, но при этом не знать, как устроена реальная работа аналитика, тестировщика или менеджера продукта.
В итоге он показывает инструмент, но не меняет способ работы. Кроме того, у амбассадора обычно нет формальных полномочий. Он может рассказать, объяснить и продемонстрировать, но не может установить обязательное правило: "с этого момента процесс выполняется именно так".
Получалось, что мы пытались доставить технологии в команды, хотя менять нужно было не только набор инструментов, но и механизм внедрения изменений.
От инструментов - к развитию компетенций
После этого мы сменили фокус. Вместо вопроса "какой ИИ-сервис выдать сотруднику?" стали задавать другой: "какие компетенции необходимы команде, чтобы пройти рабочий процесс быстрее и качественнее?"
Это изменение оказалось принципиальным. Инструмент перестал быть самостоятельной целью. Он стал частью более широкой способности команды решать задачи.
Мы начали смотреть на процесс целиком: где возникает задержка, какие артефакты создаются, сколько раз они передаются между ролями, какие этапы требуют ручной обработки и где чаще всего появляются ошибки. Только после этого подбирался подходящий ИИ-сценарий.
Например, если проблема заключается в некачественных требованиях, бессмысленно просто выдавать разработчикам генератор кода. Сначала нужно улучшить формулирование требований, научить проверять полноту постановки и использовать ИИ для выявления противоречий еще до начала разработки.
Техническое руководство пришлось вовлечь первым
Отдельно мы поняли, что изменения должны начинаться не с рядовых исполнителей. Техническое руководство должно пройти этот путь раньше остальных и на собственном опыте понять, какие решения действительно работают.
Нельзя ограничиться декларацией: "мы внедряем ИИ, теперь используйте его". Руководители должны разобраться, как меняются контроль качества, ответственность за результат, требования к безопасности и процесс принятия решений.
Только после этого можно ожидать, что новые практики будут встроены в регулярную работу, а не останутся разовой инициативой.
Изменилась и техническая среда
Одних компетенций также оказалось недостаточно. Пришлось перестраивать среду, в которой команды работают с ИИ.
Появились требования к безопасному использованию моделей, обработке корпоративных данных, проверке сгенерированного кода, хранению запросов и оценке качества ответов. Важно было создать условия, при которых сотрудник может экспериментировать, не опасаясь случайно передать конфиденциальную информацию или внедрить непроверенное решение.
Постепенно менялся и подход к стандартам. Раньше их преимущественно формировали руководители, после чего передавали командам сверху. Но правила, созданные без учета реальной практики, часто воспринимаются как внешнее ограничение.
Мы стали привлекать к разработке стандартов людей, которые ежедневно работают в изменяемом процессе. Это вызвало сопротивление: не всем понятно, почему сотрудник без управленческой должности получает влияние на общие правила. Но именно практическое участие помогает сделать стандарты применимыми.
Как понять, что внедрение действительно работает
Оценивать успех нужно не по числу выданных лицензий и не по количеству проведенных обучающих мероприятий. Эти показатели отражают активность проекта, но не его полезность для бизнеса.
Более meaningful показатели выглядят иначе:
- сократилось ли время от идеи до релиза;
- уменьшилось ли количество возвратов задачи на доработку;
- стало ли меньше ручных перекладок между ролями;
- снизилось ли число дефектов после выпуска;
- используют ли команды новые практики регулярно;
- стало ли проще поддерживать и изменять созданные решения;
- увеличилась ли предсказуемость сроков.
Важно также учитывать качество и безопасность. Быстро сгенерированный код, который приходится долго исправлять, не создает экономии. Автоматически подготовленный документ с ошибками может увеличить нагрузку на экспертов. Поэтому скорость должна рассматриваться вместе с надежностью результата.
Что мы получили в итоге
Наш первоначальный подход был слишком прямолинейным: выдать сотрудникам современные инструменты и ожидать, что эффективность автоматически вырастет. Но цифровая трансформация так не работает.
ИИ не заменяет процесс, обучение, ответственность и управленческие решения. Он способен ускорить хорошо выстроенную операцию, но не устранит хаос между подразделениями. Если требования постоянно меняются, критерии готовности не определены, а решение проходит через множество согласований, генератор кода не устранит системную задержку.
Главный урок оказался таким: внедрять нужно не ИИ-инструменты, а новые способы работы. Для этого необходимо выявить узкие места, подготовить людей, изменить техническую среду, обеспечить поддержку руководителей и связать применение технологий с измеримым бизнес-результатом.
И только после этого лицензии, ассистенты и модели начинают приносить пользу. Иначе компания получает доступ к инструментам, но не получает изменений в реальной работе.
