Что именно меняется, когда в разработке появляется ИИ? Сколько ресурса команда действительно экономит? Можно ли сравнить эффект на разных типах задач? И где проходит граница между инструментальной поддержкой разработчика, автоматизацией и передачей части интеллектуальной работы ИИ?

Ключевая тема первого «АСТРА интеллектуального семинара» — как измерять эффект ИИ в разработке. Это внутренний научно-практический формат «Группы Астра», который объединяет исследователей из разных команд вокруг общих задач.

Мы посмотрели на эту задачу с двух сторон: как оценивать изменения на уровне команды и как детально описывать сам жизненный цикл разработки ПО.

Зачем вообще измерять внедрение ИИ

Мы в «Группе Астра», как и многие команды разработки, хотим внедрять ИИ не точечно, а системно. Для этого формируем собственную методологию «Астра-ИИ» — подход к переходу к сквозной агентной разработке доверенных программных продуктов.

Но прежде чем говорить о такой трансформации, нам нужно понять, как измерять исходное состояние команды и эффект после внедрения ИИ.

Один из показателей, на который мы смотрим, — ресурс развития в человеко-месяцах. Логика простая: если после внедрения ИИ команда тратит на прежний объём работы меньше человеко-месяцев, высвободившийся ресурс можно направить на дополнительную ценность продукта.

Обратная сторона этого показателя — производительность труда.

Например, если затраты в человеко-месяцах сокращаются примерно на 30%, это соответствует росту производительности примерно на 43%. Если затраты на тот же выпуск уменьшаются вдвое, производительность растёт на 100%.

Здесь важно не путать ресурс и скорость. Речь идёт о высвободившейся ёмкости и деньгах, а не о сроках. Вдвое меньше человеко-месяцев не означает «вдвое быстрее»: человеко-месяц остаётся единицей бюджета, а не скорости.

Но одного итогового числа мало. Чтобы понять, откуда взялся эффект и почему в одной команде он выше, чем в другой, нужно описать сам процесс разработки.

Пять координат команды

В первом докладе архитектор ИИ-решений (AI Solution Architect) Артур Нагапетян предложил начинать с диагностики: прежде чем оценивать эффект ИИ, понять, где команда находится сейчас и как устроен её конвейер разработки.

Для этого команду можно представить как точку в пятимерном пространстве.

1. Автономность

Эта ось идёт от полностью ручного написания кода до полностью автоматизированного конвейера. Она показывает, какую долю операций всё ещё выполняет человек и насколько самостоятельно способны работать автоматизированные системы.

2. Контроль

Здесь мы смотрим на то, кто и как проверяет результат: ревью, тесты, гейты качества. Это не бинарная оценка «доверяем — не доверяем», а лестница зрелости.

Ступень засчитывается только тогда, когда выполнены все её условия. Например, тесты должны действительно блокировать слияние, а не просто существовать в репозитории.

Чем больше автономности мы даём ИИ, тем важнее контроль: без него появляются новые риски. Поэтому просто двигаться в сторону большей автоматизации недостаточно.

3. Масштабируемость платформы

ИИ может оставаться личным инструментом отдельного разработчика, а может стать частью общей системы с агентами и управлением доступом.

Здесь мы смотрим, способно ли решение выйти за пределы единичного использования и работать на уровне команды или всей организации.

4. Обратимость и безопасность

Если система ошиблась, насколько быстро мы можем вернуться к предыдущему состоянию? Возможность отката рассматриваем как самостоятельный параметр зрелости процесса.

Причём засчитываем только проверенный откат. Пока команда хотя бы в учебном порядке его не выполнила, время восстановления остаётся субъективной оценкой, а не измерением.

5. Широта охвата

Ещё мы смотрим на широту охвата: на скольких участках работы ИИ действительно используется, а не просто когда-то «пробовался».

Список сценариев закрытый: генерация кода, ревью, тесты, документация, рефакторинг, миграции, разбор инцидентов и так далее. Уровень зависит от того, сколько из этих сценариев реально закрыто.

Здесь работает простая аналогия: обогреватель в одной комнате не отапливает всю квартиру. Даже технологически зрелое решение не даст системного эффекта, если глубоко внедрено в одном месте и больше нигде.

В итоге мы получаем пять координат команды. Высокое значение по одной из них само по себе ничего не гарантирует. Например, высокая автономность при слабом контроле скорее создаст новые ограничения. Поэтому все пять характеристик должны развиваться согласованно.

Анкета и журнал: сказанное против сделанного

Чтобы определить положение команды в этой системе координат, мы используем два источника данных.

Первый — анкета о практиках. Но мы не просим тимлида субъективно оценить зрелость команды по шкале от одного до пяти. Вместо этого задаём вопросы о том, как команда работает на самом деле: блокируют ли тесты слияние, есть ли единая точка доступа к моделям, репетировали ли откат.

А уже на основе ответов о конкретных практиках алгоритм рассчитывает уровень по каждой оси.

Второй источник — журнал событий. В нём фиксируется, что происходило с задачей, когда началась и закончилась работа и к какому типу относится конкретная активность.

Журнал дополняет и проверяет данные анкеты: мы можем сопоставить то, как команда описывает свою работу, с тем, что фактически происходило с задачами. Так становятся видны расхождения между заявленным и происходящим.

Важное правило: отсутствие данных не считаем хорошей новостью. Если что-то нечем подтвердить, в расчёте ставим статус «неизвестно», а не «наверное, да».

На этих данных можно построить цифровой двойник команды и использовать его для экспериментов. Например, посмотреть, что произойдёт с процессом, если увеличить число ревьюеров или изменить другие параметры.

У такой модели есть и обратная сторона. Освободившуюся ёмкость быстро занимают задачи, которые раньше «не стоили того». Это похоже на расширение шоссе: добавили полосы — и на дорогу довольно быстро приехало больше машин.

То есть цифровой двойник — не только способ наблюдать за текущим состоянием, но и среда, в которой можно проверять возможные изменения до их внедрения.

Почему обещанные 35% могут превратиться в 3%

Следующий вопрос — какого эффекта от внедрения ИИ мы вообще можем ожидать.

В качестве отправной точки берём фигурирующую в профильной литературе оценку «плюс 35% к скорости разработки». Дальше модель помогает понять, какая часть этого потенциального эффекта действительно дойдёт до продукта.

Важная особенность: модель умеет только уменьшать исходную оценку. Все её сомножители не больше единицы, поэтому фактический эффект в рамках такой конструкции не может превысить исходное обещание — он может только оказаться ниже.

Сомножителей пять: широта охвата, зрелость практик работы с моделью, платформа, штрафы за обнаруженные дисфункции и ограничение, связанное с очередью на проверку.

Они перемножаются, а не складываются. То есть исходное обещание проходит через несколько последовательных фильтров, каждый из которых пропускает только свою долю. Похожим образом устроены OEE в производстве и формула DuPont в финансовом анализе.

В результате условные 35% могут превратиться, например, в 3%, которые действительно доходят до продукта.

Но для нас ценность модели не только в итоговой цифре. Параметры можно менять по одному и смотреть, что именно ограничивает результат. В одном из разобранных примеров расширение охвата увеличивает эффект с 3% до 5,6%, а устранение дисфункций — до 6,3%.

Так становится видно, за что имеет смысл браться в первую очередь.

И тогда вопрос уже звучит, так: «какие особенности нашего процесса не дают реализовать его потенциальный эффект?»

Как сравнить задачи, если они все разные

Измерение производительности разработки быстро упирается в очевидную проблему: две задачи редко бывают одинаковыми. Поэтому просто сравнить количество закрытых задач до и после внедрения ИИ нельзя — их состав и сложность могли измениться.

Чтобы сравнивать разные задачи, мы используем базовые веса. Это индексный метод с фиксированными весами, который официальная статистика применяет для измерения объёмов при несопоставимой номенклатуре (OECD, 2001; Минэкономразвития России, 2018; Росстат, 2018 и др.).

Сначала задачи из журнала классифицируем, например, на разработку, документацию, тестирование и исправление ошибок.

Для каждой группы рассчитываем базовый вес — например, медианное время выполнения задачи. В следующем периоде смотрим, сколько задач каждого типа выполнила команда, но оцениваем их по прежним, зафиксированным весам. Так появляется сопоставимый показатель выпуска.

Например, мы разобрали случай, в котором выпуск за квартал вырос с 4800 до 6000 базовых часов. Знаменатель при этом не меняется: оплаченный фонд времени берётся из кадрового учёта, а не из трекера, — те же 4800 часов.

Производительность увеличивается с 1,00 до 1,25, то есть на 25%. Это уже измерение производительности, а не подсчёт закрытых задач.

Скорость, купленная качеством, ростом не считается

Здесь у любого тимлида возникает закономерный вопрос: что мешает просто нарезать задачи помельче? Закрытых задач станет больше, веса останутся прежними — и выпуск формально вырастет без всякого ИИ.

Поэтому рядом с расчётом нужен охранный контур. Прирост засчитываем только в том случае, если по сравнению с базовым периодом не ухудшились три показателя: возвраты работ в исполнение, плотность дефектов на единицу выпуска и длительность цикла разработки.

Пороги рассчитываются по собственной волатильности команды в базовом периоде и фиксируются до того, как становится известен результат.

Есть и вторая группа сигналов. Она не блокирует прирост, а предупреждает о возможной игре с метрикой: смещении медианной трудоёмкости внутри типа, изменении распределения размеров задач, близких дубликатах формулировок, концентрации закрытий в первые дни периода или массовых правках статусов задним числом.

Такие сигналы выводятся рядом с итоговым числом и требуют разбора до того, как им начинают пользоваться.

У этой конструкции есть важный побочный эффект: неустранённые искажения скорее занижают результат, чем завышают его. Стихийное использование ИИ до официального старта повышает базу сравнения. Фонд времени из кадрового учёта включает отпуска и неполную занятость и тем самым увеличивает знаменатель. Незавершённая на конец периода работа уменьшает выпуск.

Поэтому полученное число трактуем как нижнюю границу эффекта: вопрос уже не столько в том, завышен ли результат, сколько в том, насколько реальный эффект может быть выше.

Контрольная группа для ИИ

Есть и другой способ попробовать отделить эффект ИИ от остальных изменений, которые одновременно происходят в команде.

Для этого мы рассмотрели эконометрический подход «разность разностей» (difference-in-differences, DiD) и его более позднюю версию — синтетическую разность разностей (SDID).

Логика DiD довольно простая. Есть команды, которые начали использовать ИИ, и команды, которые не начали. Эффектом считается не само улучшение первых, а то, насколько оно опережает улучшение вторых: общий тренд вычитается.

Слабое место классической конструкции — выбор контрольной команды. Одна «похожая» команда может оказаться произвольным выбором, а требуемую параллельность траекторий до внедрения по двум-трём точкам трудно проверить.

Синтетическая версия подходит к задаче иначе: контроль не выбираем вручную, а собираем как взвешенную комбинацию нескольких команд так, чтобы получившийся двойник повторял траекторию измеряемой команды до внедрения. Параллельность в этом случае не постулируется, а демонстрируется на данных.

Так мы можем попытаться отделить изменение, связанное именно с внедрением новой технологии, от изменений состава команды и других факторов.

При этом сама методология пока требует дальнейшей работы: нужно обосновать часть формул, откалибровать их на реальных данных и уточнить прикладные процедуры. Одним из вариантов такой калибровки участники семинара назвали данные GitFlic.

От команды — к атомарному действию

До этого мы смотрели на внедрение ИИ с уровня команды: сколько ресурса высвобождается, как меняется производительность и какие характеристики процесса влияют на результат. Но чтобы понять, где именно внутри разработки возникает этот эффект, нужно спуститься на уровень отдельных процессов и действий.

Во втором докладе старший системный аналитик команды GitFlic Аслан Агабубаев предложил посмотреть на задачу именно с этой стороны — через устройство жизненного цикла разработки ПО.

Идея — последовательно двигаться сверху вниз:

стадия → цепочка процессов → процесс → воспроизводимое действие.

Процесс можно представить как последовательность действий и связанных с ними артефактов — информационных объектов. Само действие, в свою очередь, описывается схемой:

артефакт → алгоритм → артефакт.

Кроме входа, алгоритма и выхода учитываются исполнитель, используемые средства и условия, необходимые для воспроизведения действия, включая требуемые компетенции и функциональные возможности.

Для моделирования атомарного действия нужен как минимум один входной артефакт. После выполнения алгоритма появляется выходной артефакт, а его внутренние характеристики позволяют описывать состояние и качество результата.

В такой модели у действия появляются как минимум два измеримых результата: время выполнения и качество результата.

Именно такая декомпозиция позволяет нам обсуждать роль ИИ не вообще, а на уровне конкретных операций.

Где заканчивается автоматизация и начинается ИИ

Чтобы анализировать изменения в SDLC, важно не складывать все технологические улучшения в одну корзину.

Мы отдельно различаем инструментальную поддержку, автоматизацию и внедрение ИИ. Ключевой вопрос здесь — в какой конкретной точке процесса или отдельного действия естественный интеллект заменяется искусственным?

Если эту границу не зафиксировать, трудно понять источник эффекта. Улучшение может быть связано с новым инструментом, перестройкой процесса или передачей конкретной интеллектуальной операции ИИ.

На уровне итоговой производительности результат может выглядеть одинаково, но сама трансформация устроена по-разному.

Артефактно-ориентированный взгляд на SDLC

В прикладных исследованиях по моделированию бизнес-процессов отдельно рассматривался артефактно-ориентированный подход: процесс описывается через объекты, действия над ними и связи между событиями.

Для описания текущих процессов применялись интервью, построенные по принципу process mining, где события связывались с соответствующими объектами. В отдельных исследованиях анализировались причинно-следственные события внутри SDLC.

Например, размечался цикл операций над merge request — дискуссии, конвейер и ревью — чтобы оценивать сложность архитектурных изменений на основе глубокого анализа кодовой базы. Классификация обращений в техническую поддержку использовалась для поиска проблемных зон жизненного цикла разработки.

Ещё один пример — оценка объёма технического долга. Для неё рассматривалась модель на основе задачи о рюкзаке, позволяющая оценивать стоимость его ликвидации.

Общий принцип у этих примеров один: жизненный цикл разработки можно разложить на наблюдаемые объекты, действия и связи, а затем анализировать их количественно и качественно.

Предприятие как граф функций

Если расширить эту идею за пределы отдельных процессов разработки, предприятие можно описывать в более формализованном виде. Такой подход рассматривался в прикладных исследованиях коллег из НИТУ МИСИС.

Исследования заведующего лабораторией кафедры АСУ Сергея Андреевича Дерябина показывают возможность унифицировать работу с разнородными функциями в архитектуре крупномасштабных предприятий и формально оценивать изменения таких архитектур в цикле цифровой трансформации.

В ходе дискуссии мы предложили связать эти направления: объединить метамодель процессов с моделями показателей.

А что будет с привычными ролями

Отдельно мы обсудили, что произойдёт с привычными ролями внутри команды, если всё больше участков жизненного цикла будут автоматизироваться и передаваться агентам.

Прозвучала мысль, что привычный сценарий, в котором разработчик заканчивает свою часть работы условным «сливом pull request», относится к уходящей модели разработки.

Роли могут постепенно схлопываться, а зона участия отдельного сотрудника — расширяться.

Тогда измерять внедрение ИИ станет ещё сложнее. Нам придётся оценивать уже не только ускорение прежних операций, но и изменение самой структуры труда.

Что дальше

Мы пока не считаем эту методологию законченной. Ещё нужно обосновать часть формул, откалибровать их на реальных данных, связать модели процессов с наборами метрик, детализировать прикладной порядок оценки и проработать вопросы патентования результатов.

Но главный принцип для нас уже понятен.

Измерять внедрение ИИ только количеством сгенерированного кода или числом используемых инструментов недостаточно.

Мы хотим понимать, какой была команда до внедрения, какой участок процесса изменился, сколько ресурса удалось высвободить, что произошло с качеством и действительно ли наблюдаемый эффект связан именно с ИИ.

И чем глубже ИИ будет встраиваться в SDLC, тем важнее будет уметь отвечать на эти вопросы.

А как вы измеряете эффект от внедрения ИИ в своих командах, и измеряете ли вообще?