Меня зовут Евгений Симонович, я работаю в Ви.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, инфраструктура под длинные запуски.
И самое короткое, если вы сейчас в такой же точке:
Выбирайте лидов компетенции, давайте им права, давайте им эту задачу, обучайте их.
Дальше они перестроят процесс лучше, чем это сделает любой документ сверху.
Автор: delonet
