Привет, Хабр! Меня зовут Евгений Симонович, я работаю в Ви.Tech.
Расскажу одну историю, как мы набивали шишки. Мы начали внедрять ИИ и LLM в контур разработки в декабре, к середине года собрали из этого стратегию, и по дороге успели получить около нулевой эффект, разобраться, почему так, и переделать подход. Мне кажется, это применимо к кому угодно в екоме, у кого цель звучит примерно так же: быстрее доставлять бизнесу ценность.
Перед началом рамка: будет нечисто про чисто SDLC.
Разработка − это весь путь от бизнес‑требования до выкатки в прод: идея, требования, аналитика, архитектура, код, тестирование, релиз. В екоме почти всегда есть стандартный путь заказа изменений, и он сквозной − через много команд и много людей. Дальше это будет важно.
Начинали мы, как, наверное, и все
Взяли пилот: несколько команд, ассистент в IDE, генерация кода, автотесты. Результаты были потрясающие. Команды бустанулись, метрики поехали в правильную сторону, всем понравилось. Вывод сделали логичный: надо раскатывать на всех.
Раскатали. И получили около нулевой эффект.
Не «поменьше, чем в пилоте», а именно нулевой бизнес‑результат.
Когда стали разбираться, картинка получилась примерно такая.
Есть луддиты. Их немного, но они есть: «мы как писали на перфокартах и в блокноте, так и будем писать». Раздачей лицензий это не лечится.
Есть те, кто реально бустанулся. Условно 20% буста в тех 5% команд, которые сами разобрались и сами дотащили.
Есть негативный опыт. Человек попробовал, у него не получилось, он сделал вывод «эта штука не работает» и вернулся к прежнему способу. Переубеждать потом сложнее, чем учить с нуля.
А остальные просто бросили. Инструмент есть, доступ есть, а в ежедневной работе его нет.
Инструмент сам себя не внедряет. Можно купить лицензии всем и не получить ничего.
Бутылочное горлышко просто смещается
Важно, что ускорив разработку, ты не ускоряешь весь процесс для бизнеса.
Если разработка не была бутылочным горлышком, то, ускорив ее в два раза, ты просто перенес горлышко дальше − в аналитику, в тестирование, в приемку, в релиз. Бизнес по‑прежнему ждет свою фичу столько же.
Поэтому мы перестали смотреть на cycle time разработки как на главную метрику. Смотрим на другое:
на time‑to‑market каждой фичи;
на то, есть ли там перекладки − когда артефакт передается из рук в руки и по дороге переписывается заново.
«Давайте мы всех научим»
Первая идея, которая приходит в голову: давайте мы всех научим. Соберем обучение, прогоним через него несколько сотен человек, и все начнут пользоваться.
Не пошло, по двум причинам.
Первая − содержание. Обучение, которое сделано «вообще про ИИ», выглядит так: «вот, смотрите, чат GPT-3.5». Мы такие: окей, классно, понятно. А делать‑то что в моем процессе? Общий курс не отвечает на вопрос, как это применить в аналитике, в тестировании, в моем стеке, в моих артефактах.
Вторая − скорость. Все устаревает буквально каждый месяц. Пока собираешь программу, она уже неактуальна. А если приходишь к тем, кто сделает хорошо, тебе говорят: «дайте нам полгодика». Полгодика в этой теме − это вечность.
«Давайте выберем амбассадоров, людей, которые горят»
Вторая идея звучит так же логично и тоже не сработала.
Люди с горящими глазами не всегда самые экспертные люди в процессе. Человек искренне кайфует от новых моделей, приносит идеи, что‑то показывает, но: ты, конечно, классный, молодец, но не в нашем процессе. Он не знает, как устроена работа аналитика или тестировщика в реальном потоке, и энтузиазм не превращается в изменение процесса.
И главное − у них не было полномочий. Амбассадор может рассказать и показать, но не может сказать «теперь мы работаем так».
Пришлось менять стратегию доставки ценностей
Раз инструмент сам не внедряется, а обучение всех и энтузиазм не тянут, надо было менять сам способ, которым изменение доезжает до процесса. Мы перестали внедрять инструменты и начали заниматься компетенциями.
Вопрос не «какой ассистент выдать», а «кто в каждом домене отвечает за то, как этот домен работает с ИИ».
Лиды компетенции
Так появились лиды компетенции − доменные эксперты, каждый по своему направлению: аналитика, архитектура, бэкенд, фронтенд, тестирование и так далее. Таких людей нужно немного: на старте хватает чуть больше десятка на весь контур, дальше их становится больше, по мере того как появляются новые домены.
Что делает лид компетенции:
изучает, что вообще есть по его теме;
проверяет на своих задачах;
измеряет эффект;
формализует то, что сработало;
передает в свой домен;
и дальше улучшает.
Это не разовое поручение, а цикл, который повторяется.
Тут же закрылась еще одна старая проблема
Сеньору некуда развиваться: он уже сильный инженер, и дальше по треку у него только менеджмент. А в менеджмент мы их брать не всегда хотим − теряем ценного эксперта и не всегда получаем хорошего менеджера. Лид компетенции − это как раз горизонтальный рост: остаешься инженером, но влияешь на то, как работает весь домен.
И важное: у лида компетенции должны быть права. Не «расскажи коллегам», а «определи, как мы теперь работаем».
Но сначала этот путь прошло техническое руководство
Поручить это снизу не получается, потому что снизу нет мандата. Мы попробовали иначе: техническое руководство прошло этот путь само. Не «поставили задачу», а сели и сделали руками.
И оказалось, что одного технического эксперта оказалось достаточно, чтобы завести всех остальных. Когда руководитель приходит и говорит: смотри, я могу сделать скилл, вот так, смотри, как бустится моя производительность − это работает совсем не так, как презентация про тренды. Дальше люди сами хотят попробовать.
«Пуля с моей стороны вылетела, ловите»
Следующее, во что мы уперлись, − артефакты. Классическая история: пуля с моей стороны вылетела, ловите. Аналитик написал, отдал, дальше не его забота. DoR и DoD живут в конфлюенсах, какие‑то ТЗшки написаны в доках, что‑то в тикетах, и каждый следующий в цепочке переписывает это под себя. Вот это и есть перекладки, из которых собирается time‑to‑market.
Когда в процессе появляется LLM, вопрос про формат артефакта становится острым. Тому же Клоду не нужны формальные документы на много страниц − ему нужен JSON и юзкейсы. Человеку нужно другое.
Мы сформулировали для себя просто:
Формат артефакта задает тот, кто принимает эстафету. Не тот, кто пишет, а тот, кто дальше с этим работает, − человек или агент.
Если следующий шаг делает агент, значит артефакт должен быть машиночитаемым, и это нормально.
Техническую среду тоже пришлось сильно менять
Когда инженеры начинают работать с внешними моделями сами, быстро выясняется:
во‑первых, неэффективно;
во‑вторых, неуправляемо;
в‑третьих, небезопасно.
Каждый выбирает модель сам, платит сам и сам решает, что можно отправить наружу. Первое время это делается немножко с трясущимися руками.
Поэтому появился внутренний контур: доступ к моделям через прослойку, внутренние LLM для того, что нельзя отдавать наружу, точки контроля на входе и на выходе. Отдельный разговор был про код: очищенный код без уязвимостей вполне достоин того, чтобы с ним работали внешние агенты. То есть не «наружу нельзя ничего», а «понятно, что можно и в каком виде».
Второй слой − какие скиллы и MCP лучше давать. Это тоже часть среды: одна и та же модель с нормальным набором инструментов и без него дает совершенно разный результат.
Третий − инфраструктура под длинные запуски. Хочется оставить агента работать 20 часов подряд, закрыть свой ноутбук и уйти. На ноутбуке это не живет, поэтому перебираемся в Kubernetes.
Стандарт теперь пишут не руководители
Раньше стандарт писал менеджмент: собрались, договорились, выпустили документ, дальше живем по нему год. С ИИ так не получается. Изменения приходят чуть ли не раз в неделю, и корректировать приходится раз в месяц.
Поэтому стандарт собирают лиды компетенции, каждый по своему домену, а из их частей складывается общий документ. И это скорее PDLC, а не SDLC, потому что речь про весь продуктовый путь, а не только про написание кода.
Есть мысль выложить это в open source, но не сейчас, а когда точно поймем, что все закончено.
«Ты кто такой, мы тебя не звали»
Отдельная история − доверие. Когда приходишь в команду с новым способом работы, первая реакция часто такая: ты кто такой, мы тебя не звали. И она честная, потому что до этого им уже приносили инициативы, которые ничего не улучшили.
Работает только одно: сначала сделать на себе, потом принести результат. Не «внедряем сверху», а «я тут попробовал одну классную штуку, вот вам даю ее всем». Разница в формулировке маленькая, а в реакции огромная.
Часть профессии
Сейчас это уже не выглядит как инициатива. Примерно как IDE: никто не спрашивает, зачем инженеру IDE, это стало базой. Умение работать с ИИ так же становится частью профессии, а не отдельным навыком, за который дают бонус.
Как мы поняли, помогло нам это или нет
Теперь цифры, потому что без них разговор бессмысленный.
Time‑to‑market изменился около двух раз.
Минимальный срок доставки изменения − с месяца минимального до двух недель минимальных.
В среднем тоже около 50%.
Затраты выросли, это правда. Лицензии, токены, инфраструктура − это все деньги. Но считать надо не изолированно. Если проектное изменение идет полгода, а вы сделаете его за три месяца, и эффект от самого изменения измеряется миллиардами, то скорость выгоднее экономии. Нам так и говорили: лучше работайте быстрее, чем экономичнее.
Численность не изменилась. Немножко меняются роли: больше времени уходит на постановку, проверку и приемку, меньше − на ручное написание однотипного кода.
И честно про то, чего нет: нормальных инструментов измерения нет. Мы не можем аккуратно разделить, сколько принес ИИ, а сколько − то, что мы попутно поменяли проектный подход больше на продуктовый. Эти два изменения шли вместе, и это надо держать в голове, когда смотришь на любые красивые проценты, включая наши.
Если подытоживать
Инструменты не работают без компетенций. Раскатать лицензии на всех − это не внедрение.
Ускорив разработку, ты не ускоряешь весь процесс для бизнеса. Смотреть надо на time‑to‑market и на перекладки, а не на cycle time одной команды.
Обучение всех и амбассадоры на энтузиазме не тянут. Нужны доменные эксперты с правами.
Формат артефакта задает тот, кто принимает эстафету.
Среду надо готовить отдельно: доступ к моделям, безопасность, скиллы и MCP, инфраструктура под длинные запуски.
И самое короткое, если вы сейчас в такой же точке:
Выбирайте лидов компетенции, давайте им права, давайте им эту задачу, обучайте их.
Дальше они перестроят процесс лучше, чем это сделает любой документ сверху.
