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

Согласно критериям, приведённым в отчёте «Состояние DevOps в 2025 году» (отчёт DORA), опубликованном Google Cloud, у высокоэффективных команд показатель MTTR обычно составляет менее 1 часа, тогда как у малоэффективных команд на это может уйти неделя или даже месяц (на основании обоснованных предположений, сделанных на основе отчётов DORA за предыдущие годы). Такая разница в порядках величины напрямую определяет способность предприятия выжить в кризисной ситуации и уровень доверия со стороны клиентов.

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

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

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

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

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

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

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

Этап

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

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

Обнаружение сбоев

Пассивные оповещения (на основе фиксированных пороговых значений)

Активное обнаружение аномалий (на основе моделей ИИ)

Реакция на уведомления

Ручное уведомление, возможны задержки

Автоматический запуск рабочего процесса, немедленное реагирование

Анализ первопричин

Ручная диагностика, занимающая несколько часов

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

Выполнение исправлений

Ручное создание и развертывание исправлений

Автоматическое выполнение сценария или автоматический откат

Проверка восстановления

Ручное подтверждение

Автоматический мониторинг показателей восстановления

MTTR

От нескольких часов до нескольких дней

От нескольких минут до часа

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

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

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

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

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

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

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

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

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

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

Более короткие циклы означают, что организация может запускать «эксперименты» с большей частотой и быстрее получать обратную связь от рынка, что ускоряет цикл обучения и итераций (цикл OODA: Observe, Orient, Decide, Act).

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

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

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

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

Продолжительность цикла: «световое» путешествие от кода к ценности

Представьте себе одну из ведущих команд Формулы-1: если их болид задержится в боксах всего на одну секунду, это может стоить им чемпионского титула. В мире, где ИИ является неотъемлемой частью, скорость разработки программного обеспечения — это наша скорость «заезда в боксы». А ключевым показателем, позволяющим измерить эту скорость, является «время цикла» (Cycle Time). Это понятие заимствовано из концепции бережливого производства и обозначает время, проходящее от «начала обработки» задачи до «завершения доставки». В сфере разработки программного обеспечения мы обычно определяем его как общее время, затрачиваемое от первой фиксации кода (First Commit) до официального запуска кода в производственной среде (Production Release). Это как высокоточный хронометр, фиксирующий весь процесс: от идеи, функции или исправления, зародившихся в мыслях инженера, через многочисленные этапы разработки, тестирования и развертывания, до момента, когда они попадают в руки пользователя и создают реальную ценность.

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

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

1. Время программирования (Coding Time): от момента первой значимой фиксации разработчика до создания «запроса на слияние» (Pull Request, PR). Этот период отражает непосредственную эффективность разработчика в преобразовании требований в код. Если время написания кода слишком велико, это может означать нечеткость требований, сложность технического решения или частые отвлекающие факторы, мешающие разработчику сосредоточиться. Исходя из имеющихся данных, можно сделать обоснованный вывод, что ведущие инженерные команды сокращают время написания кода за счет четкой документации, модульной архитектуры и сокращения количества совещаний.

2. Время ожидания PR (PR Pickup Time): время от создания PR до момента, когда первый рецензент (Reviewer) приступает к проверке кода. Это часто упускаемый из виду вид «потерь времени на ожидание». Слишком длительное время ожидания свидетельствует о «заторах» в процессе рецензирования кода, что может быть связано с перегрузкой рецензентов или отсутствием эффективного механизма распределения PR.

3. Время рецензирования PR (PR Review Time): время от начала рецензирования первым рецензентом до окончательного утверждения (Approve) PR.Это не только проверяет эффективность рецензентов, но и отражает качество кода и уровень командной работы. Частые и длительные циклы исправлений обычно указывают на низкое качество кода или отсутствие консенсуса между членами команды. Внутреннее исследование Google показало, что размер PR прямо пропорционален времени рецензирования, поэтому в компании активно продвигают практику небольших и частых сдач (Gergely, 2021).

4. Время слияния (Merge Time): время от утверждения PR на странице до успешного слияния (Merge) кода в основную ветку. Задержки на этом этапе часто связаны с эффективностью и стабильностью конвейера непрерывной интеграции/непрерывного развертывания (CI/CD). Частые конфликты при слиянии также могут свидетельствовать о хаосе в стратегии управления ветками команды.

5. Время развертывания (Deployment Time): время от слияния кода в основную ветку до окончательного запуска в производственной среде. В современной системе НИОКР этот процесс должен быть высокоавтоматизированным. Если по-прежнему требуется значительное ручное вмешательство, время развертывания будет бесконечно затягиваться, а риски — резко возрастать.

Благодаря точному измерению этих микроэтапов мы можем составить «карту потока создания ценности» (Value Stream Map) организации, чтобы четко увидеть, куда уходит время и в каком звене происходит «затор» в создании ценности.

Название показателя (англ.)

Название показателя (китайский)

Начальное событие

Конечное событие

Выявленная проблема

Время кодирования

Время кодирования

Первая значимая фиксация кода

Создание запроса на слияние (PR)

Неясные требования, техническая сложность, отвлечение внимания разработчиков

Время обработки PR

Время ожидания PR

Создание запроса на слияние (PR)

Первый рецензент приступает к проверке

Нехватка ресурсов для рецензирования, неэффективный механизм распределения PR

Время рассмотрения PR

Время рассмотрения PR

Первый рецензент приступает к проверке

PR окончательно одобрен

Низкое качество кода, отсутствие консенсуса в команде, чрезмерный объем PR

Время слияния

Время слияния

PR окончательно одобрен

Код успешно слит в основную ветку

Низкая эффективность конвейера CI/CD, хаотичное управление ветвями

Время развертывания

Время развертывания

Код успешно слит в основную ветку

Успешный запуск в производственной среде

Низкая степень автоматизации процесса развертывания, высокий риск выпуска

Эта таблица представляет собой «отчет о компьютерной томографии» для самодиагностики организаций, ориентированных на ИИ.Только благодаря постоянному отслеживанию этих показателей и непрерывному поиску возможностей для улучшения — например, сокращению времени ожидания за счёт внедрения интеллектуальных агентов (Agent) для автоматического распределения PR, снижению нагрузки на рецензентов за счёт использования ИИ для первичного рецензирования кода или оптимизации конвейера CI/CD для ускорения слияния и развёртывания — организация сможет постоянно повышать скорость своего «метаболизма» и сохранять лидерство в условиях жесткой рыночной конкуренции.

Коэффициент переделок: «невидимый гигант», пожирающий инновационный потенциал

В сфере разработки программного обеспечения также скрывается «невидимый гигант», пожирающий эффективность и прибыль, — это «переделка» (Rework). Под переделкой понимается работа, которая уже была «завершена», но из-за дефектов, недопонимания или изменения требований приходится начинать с нуля, вкладывая время и усилия в исправления. Это может быть исправление ошибки в рабочей версии, рефакторинг сложного для обслуживания кода или цепная реакция, вызванная «небольшой корректировкой» со стороны менеджера по продукту. Согласно отчету исследовательской компании Citrix, разработчики в среднем тратят около 30 % рабочего времени на доработку (Citrix, 2022). Это означает, что в команде из 10 человек фактически только 7 создают новую ценность, а остальные 3 занимаются «заделыванием ям», оставленных в прошлом. Этот гигант не только поглощает ценные ресурсы на исследования и разработку, но и подрывает боевой дух команды, задерживает вывод продукта на рынок и является главным врагом инновационной способности.

Отслеживание и измерение показателя доработок — это создание точного «портрета» этого чудовища. Основная формула расчета показателя доработок несложна:

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

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

1. Отслеживание на основе коммитов кода: это самый прямой и объективный способ. Анализируя историю коммитов в репозитории (например, Git), мы можем определить, какие коммиты были сделаны для исправления дефектов или рефакторинга существующего кода. Например, мы можем отслеживать те изменения, которые были внесены в один и тот же функциональный модуль после слияния кода в основную ветку. Некоторые передовые платформы для анализа эффективности НИОКР, такие как Harness и Minware, способны автоматически анализировать изменения в коде, выявлять «переработанный код» (Churn) — то есть строки кода, которые неоднократно изменялись в течение короткого периода времени, — и количественно оценивать его в качестве показателя переделки. Преимуществом этого метода является объективность данных и высокая степень автоматизации; недостатком — сложность полного разграничения между нормальной оптимизацией путем итераций и настоящей «переделкой».

2. Отслеживание с помощью инструментов управления проектами: это наиболее распространённый способ, в значительной степени зависящий от стандартов процессов. Команда может помечать задачи, связанные с переработкой, в инструментах управления проектами, таких как Jira или Zenhub, с помощью определённых меток или типов задач. Например, можно создать метку с названием «Переделка» или ввести отдельный тип задачи «Технический долг». Когда обнаруживается баг или требуется доработка уже завершённой функции, создаётся соответствующая задача по переделке. Преимущество этого метода заключается в возможности более точного определения переделки с учётом бизнес-контекста; недостаток — зависимость от ручной маркировки членами команды, что при недостаточной дисциплине может легко привести к упущениям и отклонениям. Многие специалисты из сообщества Atlassian рекомендуют использовать плагины Jira, такие как «Time in Status», для отслеживания количества переходов задачи между различными статусами (например, «В ожидании», «В разработке», «Тестирование», «Завершено») и использовать эти данные в качестве прокси-показателя доработок (Atlassian Community, 2022).