Компания, в которой работает ИИ. Агенты, автоматизация и новые правила управления

Глава 4.

Показатели организаций, построенных на ИИ: хватит ориентироваться только на человеческий фактор

В одну из сред ноября 2025 года Карл Эрикссон (Karl Eriksson), главный директор по продуктам (CPO) известной скандинавской игровой компании, оказался втянут в бесконечную дискуссию. В конференц-зале проектный менеджер, руководитель отдела разработки и директор по маркетингу сидели кругом и горячо спорили о дате выпуска следующего крупного дополнения. Гантова диаграмма проектного менеджера занимала весь экран; на ней были плотно разбросаны сотни узлов задач и зависимостей. Он указал на критический путь на диаграмме и с беспомощной улыбкой сказал: «При текущих кадровых ресурсах и темпах разработки мы сможем завершить разработку и тестирование всех функций не раньше второго квартала следующего года. И это при условии, что не произойдет никаких серьезных непредвиденных обстоятельств».

Директор по маркетингу тут же возразил: «Во втором квартале? Новая игра конкурентов выйдет уже в январе следующего года, а к тому времени мы уже будем в пролете! Мы должны выпустить игру до конца февраля — это вопрос жизни и смерти!»

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

Карл потеребил виски, почувствовав приступ знакомой усталости. Он уже участвовал в таких совещаниях много раз. Руководство компании одержимо показателем «производительности труда» — сколько строк кода пишет каждый инженер в день, сколько эскизов создает каждый художник в неделю, сколько тестовых случаев выполняет каждый тестировщик в день. Чтобы повысить эти цифры, компания постоянно нанимала новых сотрудников, и за три года численность команды удвоилась, но скорость выпуска продукта, казалось, только замедлялась. Каждый отдел утверждал, что его эффективность уже достигла предела, но общий цикл проекта продолжал удлиняться.

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

1. Время цикла: насколько сократилось время от идеи до реализации

В традиционных организациях ключевым показателем эффективности часто является «коэффициент использования ресурсов» или «личная производительность», то есть «производительность труда». Руководители одержимы идеей обеспечить, чтобы каждый был «занят», полагая, что при максимальной индивидуальной эффективности общая производительность автоматически повысится. Однако, как показал опыт Карла Эриксона, у такого подхода есть фатальный недостаток: он игнорирует огромные временные затраты, связанные с перемещением работы между различными этапами. На разработку одной задачи может уйти всего три дня, но она может пролежать три недели в очереди «запросы, ожидающие обработки» и ещё две недели — в очереди «ожидание тестирования». С точки зрения отдельного сотрудника эффективность разработчика очень высока, но с точки зрения общей картины создания ценности для клиента эффективность оказывается поразительно низкой.

AI-ориентированные организации полностью перевернули эту логику измерения. Они больше не задают вопрос «насколько занят каждый человек», а спрашивают: «Сколько времени требуется, чтобы идея, от момента её зарождения до создания ценности для клиента?» Это и есть время цикла (Cycle Time) — главный ключевой показатель эффективности AI-ориентированных организаций. Время цикла измеряет скорость потока ценности, а не скорость потребления ресурсов.

Формула расчёта цикла очень проста:

Время цикла = момент завершения задачи – момент начала задачи

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

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

Продукт-менеджер описывает требование с помощью намерения (Intent) и отправляет его в систему рабочих процессов.

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

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

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

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

В процессе роль человека меняется с исполнителя на проектировщика и арбитра. Люди проектируют рабочие потоки, определяют границы поведения интеллектуальных систем и обрабатывают исключительные ситуации, которые интеллектуальные системы не могут решить самостоятельно. Передача работы больше не происходит посредством электронной почты или совещаний между людьми, а представляет собой переход состояний внутри системы, который происходит практически мгновенно. Это приводит к увеличению скорости потока ценности на несколько порядков.

Таблица 4-1: Сравнение структуры цикла: традиционная организация vs. организация, построенная на ИИ

Этап

Традиционная организация (пример: 30 дней)

Организация, построенная на ИИ (пример: 2 дня)

Уточнение и оценка требований

5 дней (несколько совещаний, переписка по электронной почте)

0,2 дня (структурирование намерений, автоматическая проверка ИИ-системой)

Распределение задач и планирование

3 дня (ручное распределение проектным менеджером)

0,01 дня (автоматический запуск системой)

Разработка и выполнение

10 дней (один разработчик или небольшая команда)

0,5 дня (параллельная разработка несколькими «умными сущностями»)

Рецензирование кода

2 дня (ожидание в очереди на проверку старшим инженером)

0,1 дня (статический анализ «умного агента» + выборочная проверка человеком)

Проведение тестирования

5 дней (планирование и выполнение тестирования командой тестировщиков)

0,5 дня (автоматизированная конвейерная линия тестирования)

Развертывание и запуск

2 дня (ручное развертывание командой эксплуатации и обслуживания)

0,1 дня (автоматизированная конвейерная линия развертывания)

Общее время ожидания и передачи

составляет примерно 60–80 % от общего времени

Примерно 10–20 % от общего времени

Общая продолжительность цикла

30 дней

2 дня

Согласно данным Codeintelig.ai по эталонным показателям продолжительности цикла на 2025 год, медиана продолжительности цикла у элитных SaaS-команд составляет от 0,5 до 2 дней, тогда как у команд с низкой производительностью — от 5 до 7 дней и более (Codeintelig.ai, 2025). Создание «AI-ориентированной» организации направлено именно на то, чтобы организация в целом приблизилась к уровню элитных команд или даже превзошла его. Использование продолжительности цикла в качестве основного показателя означает, что фокус руководства смещается с «контроля затрат» на «ускорение создания ценности», что представляет собой коренной сдвиг в мышлении.

2. Коэффициент переделок: реальная стоимость ошибок и изменений

Если время цикла измеряет «скорость» потока ценности, то коэффициент переделок (Rework Rate) измеряет «качество» этого потока. Под переделками понимается любая ситуация, когда требуется вернуться назад и исправить или доработать уже «завершённую» работу. Это может быть исправление ошибки в рабочей версии, доработка модуля, не соответствующего требованиям, или полная переделка проекта из-за изменения требований. В традиционной разработке программного обеспечения переделка рассматривается как «необходимое зло» — неизбежная часть процесса разработки. Однако организации, ориентированные на ИИ, считают, что высокий показатель переделок является явным сигналом о нездоровом состоянии организации и ещё одним ключевым негативным показателем, характеризующим её эффективность.

Почему цена переделки так высока? Дело в том, что это не просто «сделать заново». Согласно исследованиям в области системных наук, устранение дефекта, обнаруженного на поздних этапах разработки программного обеспечения (например, на этапе тестирования или в производственной среде), обходится в 10–100 раз дороже, чем его обнаружение и устранение на этапе проектирования (обоснованное предположение на основе имеющихся данных). За этим стоят огромные скрытые затраты:

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

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

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

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

Формула расчета коэффициента переделок:

Коэффициент переделок = (время или объем работы, затраченное на переделки / общее затраченное время или объем работы) × 100%

Согласно статистике платформы анализа программной инженерии Velocity, медиана показателя переделок в отрасли составляет около 7%, а в организациях с низкой эффективностью этот показатель может превышать 10% (CodeClimate, 2024). Это означает, что почти одна десятая часть ценных инженерных ресурсов этих организаций тратится не на создание новой ценности, а на исправление прошлых ошибок.

Организации, ориентированные на ИИ, систематически снижают коэффициент переделок с помощью трёх основных механизмов:

Встроенное качество на ранних этапах (Shift-Left Quality): с помощью интеллектуальных модулей на самых ранних этапах рабочего процесса (таких как определение требований и написание кода) проводится большое количество автоматизированных проверок, что позволяет «встроить» качество в процесс, а не оставлять его на конец для «проверки». Например, «интеллектуальный агент кодирования» при сдаче кода должен пройти сканирование «интеллектуальным агентом статического анализа», чтобы гарантировать отсутствие явных логических ошибок или рисков безопасности; «интеллектуальный агент анализа требований», получив задание от менеджера по продукту, автоматически проверяет его на наличие конфликтов с логикой существующей системы.

Полная автоматизация тестирования: организации, ориентированные на ИИ, стремятся к максимальной автоматизации тестирования. Каждый раз, когда разрабатывается новая функция, специальный «интеллектуальный модуль генерации тестовых случаев» создает для неё исчерпывающий тестовый скрипт. Это сводит затраты на регрессионное тестирование практически к нулю, а любые непреднамеренные сбои, вызванные изменениями, обнаруживаются немедленно.

Не ная инфраструктура и декларативная конфигурация: благодаря инфраструктуре как коду (IaC) и декларативной конфигурации обеспечивается согласованность среды, что устраняет классические проблемы типа «на моем компьютере всё работает». Все изменения вносятся через код, что обеспечивает отслеживаемость, возможность аудита и откат одним нажатием, что значительно сокращает объем доработок, вызванных несогласованностью среды.

Таблица 4-2: Экспоненциальный рост затрат на переделку

Этап обнаружения дефектов

Затраты на исправление (относительные единицы)

Типичные места обнаружения в традиционных организациях

Типичные места обнаружения в организациях, ориентированных на ИИ

Требования/проектирование

1x

Иногда

Основное (через интеллектуальный модуль проверки намерений)

Разработка/программирование

5x–10x

Часто

Основной (с помощью кодирования и статического анализа)

Модульное/интеграционное тестирование

15x

Основные

Регулярно (с помощью автоматизированной тестовой конвейерной линии)

Системное/приемочное тестирование

30x

Основные

Иногда

После запуска в производство/в эксплуатацию

60x–100x

Часто

Очень редко

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

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

Представьте себе оживлённый перекрёсток без светофора, где все автомобили полагаются на взаимные сигналы и жесты водителей, чтобы определить, кто проедет первым. Результатом неизбежно станут бесконечное ожидание, пробки и хаос. В традиционных организациях барьеры между отделами и ролями похожи на этот хаотичный перекресток: каждое взаимодействие между командами и ролями сопровождается огромным количеством «циклов взаимодействия» (Collaboration Round-trips).

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

продукт-менеджеру нужны данные от отдела маркетинга; он отправляет электронное письмо (первая передача); сотрудник отдела маркетинга отвечает, что данные должны обработать аналитики (вторая передача); аналитик отвечает, что необходимо уточнить критерии данных (третья передача)… Даже простой запрос данных может потребовать 5–6 циклов взаимодействия.

Дизайнер завершил работу над макетом интерфейса и передал его фронтенд-разработчику. Фронтенд-разработчик обнаружил, что какой-то элемент дизайна невозможно реализовать, и отправил сообщение дизайнеру (первый обмен). Дизайнер внес изменения и снова отправил макет фронтенд-разработчику (второй обмен). После реализации фронтенд-разработчик передал код бэкенд-разработчику для совместной отладки, но тот обнаружил, что параметры интерфейса неверны, и снова обратился к фронтенд-разработчику и дизайнеру (третий обмен)…

Каждый такой обмен сопровождается огромными скрытыми издержками. Исследования показывают, что частая смена контекста значительно снижает производительность, а потери могут достигать 40% и даже 80% (Psychology Today, 2021; Trunk.io, 2025). Когда разработчик вынужден выйти из состояния глубокого погружения в программирование, чтобы ответить на письмо или принять участие в внеплановом совещании, он теряет не только время на само выполнение этой задачи, но и значительное время, необходимое для возвращения в состояние «потока» — обычно требуется 15–20 минут, чтобы восстановить прежнюю эффективность работы (обоснованное предположение на основе имеющихся данных).

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

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

Как организации, ориентированные на ИИ, сокращают количество циклов взаимодействия?

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

«Рабочий процесс как услуга» (Workflow-as-a-Service): правила совместной работы заранее заложены в рабочие процессы. Кто, при каких условиях и что должен делать, а также как происходит передача информации — всё это закреплено в системной логике. Например, рабочий процесс «Публикация статьи» может быть настроен следующим образом: после завершения работы автором автоматически отправляется уведомление «интеллектуальному агенту-рецензенту» для проверки грамматики и фактов, затем уведомляется «интеллектуальный агент по соблюдению нормативных требований» для проверки конфиденциальных терминов, и только после этого задача попадает в список дел главного редактора-человека. Весь процесс не требует никаких ручных напоминаний или координации.

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

Таблица 4-3: Сравнение моделей сотрудничества: традиционная организация vs. организация, ориентированная на ИИ

Аспект

Традиционная организация

Организация, ориентированная на ИИ

Носители информации

Электронная почта, чаты, совещания, документы

Единая система рабочих процессов, структурированные данные

Инициирование совместной работы

Инициирование вручную, «точка-точка»

Системное запускание, на основе событий

Синхронизация статуса

ручной запрос, регулярные совещания

Отображение в системе в режиме реального времени, автоматические уведомления

Источники знаний

Зависит от личного опыта, «поиска нужного человека»

Сосредоточено в «интеллектуальных системах» и правилах рабочих процессов

Способы принятия решений

Многораундовое обсуждение, поиск консенсуса

Автоматическое принятие решений на основе заранее заданных правил, сообщение об аномалиях

Среднее количество циклов взаимодействия

Высокое (5–10 раз на задачу)

Очень низкое (0–2 раза на задачу)

Измерение и стремление к сокращению количества циклов взаимодействия по сути означают снижение «внутренних потерь» организации, что позволяет направлять больше энергии на создание внешней ценности. Организация с низкими затратами на взаимодействие будет значительно превосходить своих конкурентов, тратящих огромное количество времени на внутреннюю коммуникацию, по скорости реагирования и способности к итеративной работе.

4. Восстановление после сбоев: как быстро можно вернуться в нормальный режим работы

В любой сложной системе ошибки и непредвиденные ситуации неизбежны. Будь то программные ошибки, сбои оборудования или неверные бизнес-решения, главное не в том, чтобы не допускать ошибок, а в том, как быстро можно восстановить работу после их возникновения. Время восстановления после сбоя (Mean Time to Recovery, MTTR) является золотым стандартом оценки устойчивости (Resilience) организации и стабильности системы, а также четвертым ключевым показателем, на который обращают внимание организации, ориентированные на ИИ.

Формула расчёта MTTR:

MTTR = (общее время от возникновения сбоя до полного восстановления) / количество сбоев

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

время, необходимое для восстановления нормальной работы онлайн-сервиса после его сбоя;

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

Время, необходимое для восстановления нормального уровня ключевого бизнес-показателя (например, коэффициента успешных заказов) после его внезапного падения.