ИИ меняет правила: как трансформируются команды, процессы и роль ИТ-лидера

Предыстория

На наших глазах происходит очередная трансформация подходов к разработке.

Когда-то мы разрабатывали по водопаду с четким, выверенным ТЗ, строго определенными ролями (аналитик, разработки, тестировщик и т.п.), длительными интеграцией и тестированием и осторожными релизами c передачей кода из отдела разработки в отдел эксплуатации. Архитектуры приложений были преимущественно монолитными или модульными, что ограничивало возможности параллельной разработки. В итоге крупные проекты могли масштабироваться через процедуры управления проектами с разбиением на подпроекты и жесткой синхронизацией промежуточных результатов (milestones).  

С точки зрения ^[1] управления ключевыми аспектами являлись декомпозиция, оценка и планирование работ, четкая постановка задач и оценка полученных на выходе артефактов, выявление рисков и их митигация. Работа с людьми и понимание бизнес-смысла решаемых задач разработчиком, тестировщиком и другими участниками имели второстепенное значение (за редким исключением). Ключевым артефактом было всеобъемлющее и понятное ТЗ, а также иные качественные артефакты (дизайн, код, тесты, документация и пр.). К сожалению, разработка по водопаду требовала очень много времени как на подготовку ТЗ, так и на саму реализацию. Это не позволяло компаниям быстро адаптироваться к динамически изменяющимся обстоятельствам и корректировать свои потребности ^[2] и задачи.

Наиболее популярным способом решения этой проблемы стало развитие концепций Agile и DevOps, где целью было сокращение Time2Market за счет сокращения каденции поставки и ускорения цикла обратной связи, как от пользователей, так и между всеми членами команды. Тут же произошел переход от функциональных команд к кросс-функциональным командам, объединяющим в себе и бизнес, и разработку, и эксплуатацию. При внедрении подходов Agile и DevOps выросли требования к коммуникабельности участников команды, пониманию бизнес-смысла и способности быстро разрабатывать инкремент/MVP, который потом нужно будет развивать, рефакторить и переделывать.

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

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

Другими словами, растущие требования к масштабу, надежности и скорости развития продуктов обусловили качественные изменения в работе ИТ, где возросшие сложность, скорость и гибкость решений потребовали от инженеров развитых софт-скиллов и продуктового мышления ^[3]. Уход от исчерпывающих артефактов и командная ориентация повысили значимость каждого инженера для успеха команды и продукта.  

С массовым развитием ИИ роль основного “трудяги” переходит от человека к ИИ. И, как указывает McKinsey ^[4], это должно полностью перестроить работу многих компаний как в части создаваемых продуктов/сервисов и даже бизнес-моделей, так и в части работы ИТ команд.  

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

Команда

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

Одна из ценностей Agile гласит “Люди и взаимодействие важнее процессов и инструментов”. Поэтому первопроходцы гибких методологий сделали ставку на командную работу и активное взаимодействие в команде как способ сократить потери времени в SDLC и быстрее реагировать ^[5] на внешние изменения. При этом появился ряд вопросов о правильном размере команды, ролях и принципах взаимодействия. Увеличение размеров команды вело к избыточным коммуникациям, а слишком маленькие команды были эффективны в своей части, но часто нуждались в подключении специалистов извне. Когда в разработке активно распространился Scrum, типичная Scrum команда обычно включала в себя около 8-10 человек в составе PO, аналитик (опционально), 2-3 backend разработчика, 2-3 frontend разработчика, 2 QA инженера. При необходимости в команду также могли добавлять DevOps инженера, дизайнера или иные роли. В последние годы в продуктовых командах появился тренд на создание Tshaped команд, где каждый специалист мог выполнять больше одной роли, что позволяло еще уменьшить размер команд (а значит и время на синхронизацию и коммуникации), не теряя гибкости и самостоятельности, и подстраховывать друг друга в случае болезни или отпуска.  

Также реализация принципа Agile “Ежедневное сотрудничество бизнеса и разработчиков” потребовала от инженеров не просто разрабатывать назначенные задачи, но работать в плотной связке с бизнесом, понимать бизнес-цели и активно участвовать в генерации бизнес-идей.  

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

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

Однако тут мы сталкиваемся с риском потери ключевых компетенций (так называемый bus factor). В целом понятно, что ИИ может помочь бороться с потерей ключевых знаний в случае ухода сотрудника благодаря сохранению разнообразных артефактов разработки задач (актуальная документация, актуальные тесты, помощь в интерпретации кода и пр), но в любом случае производительность команды сильно пострадает в моменте.  

Поэтому, на мой взгляд, большинство команд постараются выстроить следующий подход: в команде должны быть ключевые специалисты (аналитик/PO, full-stack разработчик, QA инженер – все middle+ уровня или выше) и 1-2 подмастерья, которые помогают и обучаются. Причем подмастерья могут выступать сразу в нескольких ролях, что поможет в формировании и развитии #shaped специалистов.

В целом использование ИИ агентов смещает фокус работы разработчика с написания кода в сторону детальной постановки задачи и ревью получившегося кода (подробнее тут ^[6]). В этой связи предполагаю, что будет расти спрос на фулл-стек разработчиков, кто может сформулировать продуктовую задачу целиком и провалидировать ее решение ИИ.  

Тем не менее, опытные разработчики senior и выше уровнем, вероятно, останутся востребованы для решения задач, где ИИ не справляется, или ИИ так “справился”, что теперь нужно сделать “по-нормальному”. Эти специалисты будут либо работать в продуктовой команде специального назначения, либо будут выделены как сервисная функция для продуктовых команд.

Стоит отметить, что ИИ агенты могут и должны использоваться не только для написания непосредственно кода, но также тестов и документации для задачи. Технологичные компании внедряют ИИ на всех этапах SDLC, что дает мощный буст скорости разработки (подробнее тут ^[7]). Если ускорить только разработку, то задачи будут скапливаться на других этапах SDLC, и ожидаемого ускорения Time2Market не случится.

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

Интересные изменения стоит ожидать и в роли QA. С одной стороны, ИИ может писать документацию и тесты к коду, который он разработал, и даже прогнать и проверить, что тесты работают. Поэтому такой работы у QA станет меньше. С другой стороны, повсеместное внедрение AI в процессы и продукты компании приведет к тому, что самих ИИ агентов и MCP сервера тоже надо тестировать, а это совсем другая история. Отвечать за качество недетерминированной, вероятностной системы, подверженной ошибкам и галлюцинациям, – это новый уровень вызова. Ожидаю, что в будущем QA инженеру придется работать с разметкой данных, анализом precision, recall и другими инструментами ML инженеров (например, тренировка AI модели, которая будет судьей для работы ИИ агента).

Работа DevOps инженеров, как мне кажется, не сильно изменится, только акцент будет дальше смещаться на то, что сейчас называют AgentOps. В условиях работы ИИ в продукте вопросы мониторинга, трассировок и логирования становятся еще более критичными, чем раньше. В монолите без трассировок и логов сложно, но можно воспроизвести проблему, в микросервисной архитектуре – еще сложнее, а в ИИ продукте отладить галлюцинирующего или просто глючащего ИИ агента практически невозможно.  

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

Работа архитектора станет еще сложнее в силу возрастающей сложности систем. Множество ИИ агентов, которые могут самостоятельно находить и использовать разные инструменты для решения недетерминированных задач, определяемых из контекста конкретного пользователя; невозможность построить четкие схемы взаимодействия компонентов, определить их точки взаимодействия и зафиксировать потоки данных – все это превращает работу архитектора в хаос. Поэтому архитекторам придется выработать новые подходы в работе и создать новый инструментарий, чтобы как-то управлять архитектурой будущих систем (может быть, появится ИИ агент-архитектор, который будет следить, чтобы остальные соблюдали правила ☺️). Ниже мы поговорим про возможность разделения продукта на безопасный и продуктовый контур, но это далеко не единственный вызов.

Возрастает роль ИБ архитектора и DevSecOps, поскольку ИИ агенты, включенные в продукт, могут по своему усмотрению находить и вызывать инструменты и передавать им данные для решения поставленной задачи. В этих условиях открывается множество новых векторов атаки, связанных с подменой MCP серверов, инженерией контекста и др. Решение вопроса безопасности в этих условиях будет требовать проработки комплексной системы на этапе дизайна и постоянной работы по устранению новых угроз. Хакеры также принимают ИИ на вооружение, что многократно ускоряет поиск уязвимостей и перспективных векторов атак, поэтому DevSecOps вместе c QA инженерами должны работать на опережение и внедрять в свою работу дополнительные ИИ проверки безопасности в роли “белых хакеров”.

Процессы

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

Быстрое прототипирование и острожное масштабирование

Возможность создать прототип новой фичи силами агента за несколько часов радикально меняет подход к прототипированию новых идей. Там, где раньше нужна была согласованная работа всей команды и несколько недель, теперь может хватить одного диалога PO с разработчиком, и прототип продукта для внутреннего теста готов. Это меняет привычный подход к Discovery. Раньше самой дорогой частью создания продукта была именно реализация, и поэтому на этапе Discovery старались протестировать востребованность идеи на мокапах, кликабельных прототипах и т.п, чтобы в реализацию попадало лишь то, что уже показало свою востребованность у клиентов. С приходом ИИ создание прототипа теперь стоит намного дешевле, что позволяет быстро реализовать MVP и получать полноценную обратную связь от клиентов на работающем продукте. Можно даже сделать 2-3 варианта фичи, выбрать лучший на основе пользовательских предпочтений и дальше развивать победителя. Все это можно было сделать и раньше, но теперь это требует в разы меньше времени и ресурсов.

Тем не менее, простота создания прототипа не должна нас обманывать. Она не означает быстрой выкатки в прод. Обычный код без ИИ агентов, вероятно, можно будет релизить быстро при условии отлаженных CI/CD пайплайнов и работающем SSDLC в компании, но релизы ИИ функций потребуют тщательной проверки, контроля, сравнения результативности с прошлой версией через АБ тестирование и постепенное расширение аудитории. Тут, вероятно, должна возникнуть роль специалиста по настройке ИИ функций, кто будет организовывать проведение АБ тестов, работу с обучающими выборками и обратной связью от пользователей, а также управление инженерией контекста для того, чтобы добиться от ИИ агента желаемого поведения ^[8].  

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

Фокус на ценности для пользователя

Ориентация на пользовательскую ценность и понимание бизнес-смысла задачи становится ключевым требованием ко всем участникам задачи. Исследование DORA выявило, что ИИ повышает производительность команд, сфокусированных на создании ценности для потребителей, в то время как другие команды не получают значимого результата (подробнее тут ^[7]).  

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

Масштабирование разработки

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

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

Таким образом, уменьшение размера команд и расширение скоупа задач, которые команда способна решать самостоятельно, приведут к снижению объема необходимых ритуалов для синхронизации работ и совместному планированию команд (к сожалению для тех, кто обожал двухдневные PI planning на 400+ человек), что еще больше ускорит цикл поставки инкремента для большинства задач. Возможно, появится специальный ИИ агент, который будет анализировать бэклоги команд и помогать им спланировать и синхронизировать их работу так, чтобы максимизировать поставляемую ценность.  

Отдельно хочу отметить, что для тех продуктов и фич, где будет разрабатываться и внедряться ИИ агент, обладающий способностями к самостоятельному выбору инструментов и определению логики поведения ^[9] для решения пользовательских задач, вероятно, после окончания разработки и тестирования инкремент будет проходить дополнительный этап тестирования и настройки силами отдельной команды контекст-инженеров.

Рост сложности архитектуры продукта

Начну с картинки ожидаемой работы продукта в будущем. Пользователь обращается к ИИ агенту с конкретной задачей или вообще делегирует агенту какую-то часть своей жизни. Например, пользователь определил бюджет в 10 000 рублей в месяц на все подписки на интернет-сервисы. При достижении этого лимита остальное нужно отключать в порядке наименьшего использования. В рамках этой задачи ИИ агент получает доступ к большому объему конфиденциальной информации, а также банковским данным и т.п. Агент вправе использовать функции, наподобие service discovery для обнаружения новых ИИ агентов и MCP серверов, которые помогут ему лучше решать поставленную задачу. Более того, агент вправе их вызывать по своему усмотрению и передавать им необходимые данные. Например, чтобы отключить какой-то сервис ИИ агент может вызвать MCP сервис подписки на Spotify или другого ИИ агента, который поможет проанализировать частоту и значимость двух сервисов подписки, чтобы выбрать какой отключить.  

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

Подходы к решению этой задачи могут быть разные, но точно можно говорить, что архитектура приложений столкнется с новыми вызовами и потребностью в изменениях, особенно в больших компаниях, где есть множество разных продуктов, объединенных общей серверной логикой ^[10] и данными (Яндекс, МТС и пр.).

Новые задачи и вызовы для руководителя

Отчеты McKinsey ^[4] и Google ^[7] показывают, что лоскутное внедрение ИИ не приносит значимых результатов в масштабе компании. Для достижения значимого успеха и создания конкурентных преимуществ компании нужно вовлекать людей на всех уровнях в трансформацию продуктов и процессов с поддержкой ИИ, комплексно внедрять ИИ на всех этапах SDLC создания продуктов, разработать и внедрить политику использования ИИ, существенно модернизировать внутренние платформы и данные.  

Давайте рассмотрим эти рекомендации.

Вовлечение людей

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

Поэтому важная задача руководителей заключается в том, чтобы сформировать безопасную среду, которая поощряет работу с ИИ и активное интеграцию инструментов в повседневные задачи (например, кейс Альфа-Банка ^[11]).  

В общем, управление изменениями, работа с ожиданиями и сопротивлением, мотивация ^[12] сотрудников и насаждение культуры использования ИИ – то, что требуется от руководителей, чтобы запустить процесс трансформации.  

В идеале нужно сформировать активное сообщество early adopters среди сотрудников, которые будут обмениваться идеями и лучшими практиками и вместе придумывать новые способы применения ИИ на благо организации.

Конкретно для руководителей ИТ я вижу еще актуальную задачу в развитии майндсета продуктовой разработки в командах. Бизнесу больше не нужны инженеры, которые пишут код по ТЗ. Код теперь пишут агенты, а инженеры нужны для того, чтобы придумывать, как развивать и усиливать бизнес с помощью технологий и объяснить это ИИ агенту. Именно от руководителя и его действий зависит то, насколько ИТ команды будут погружены в бизнес и ориентированы на достижение конкретного бизнес-результата. (Комплекс мероприятий по развитию майндсета продуктовой разработки – тема для отдельной статьи, которую я могу написать, если увижу запрос на это).

Внедрение ИИ на всех этапах SDLC

Как уже упоминалось ранее, лоскутное внедрение ИИ в создании продуктов создает локальные “островки производительности”, но слабо влияет на общее ускорение цикла поставки и создания потребительской ценности. Задачи просто застревают на других этапах SDLC.  

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

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

Политика использования ИИ

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

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

• к каким данным ИИ может иметь доступ, а каким категорически нет;  

• какие внутренние и внешние инструменты можно использовать и для каких задач, а какие – под запретом или требуют особого согласования;  

• общие принципы разработки ИИ агентов (например, the lethal trifecta, подробнее тут ^[13]);  

• требования по использованию инструментов для логирования, мониторинга и безопасности;  

• требования к использованию MCP серверов и service discovery;  

• общие требования к процессу разработки ИИ агентов (например, специальная защита архитектуры, валидация с DevSecOps, участие AI аудитора в приемке, наличие Prompt Engineer в команде с выделением времени на контроль работы агента и т.п.)

Этот документ не должен быть “высечен в камне”. Нужно разработать процедуру регулярного его обсуждения и актуализации со всеми заинтересованными.

Модернизация внутренних платформ и данных

Чтобы ИИ мог приносить пользу в полном объеме, он должен иметь доступ к внутренним данным компании и использовать их для решения поставленных задач. Данные в системах управления кодом, специальных базах и хранилищах, различная нормативная документация вроде регламентов, инструкций и описаний процессов должны использоваться ИИ для обучения ^[14] и использования в работе. К сожалению, во многих компаниях часть данных и документации может быть неконсистентной, неактуальной, содержать ошибки ^[15] или просто отсутствовать. В таком случае, работа ИИ будет сильно ограничена и вместо полезных ИИ сотрудников мы сможем получить только справочные чат-боты, да и то их информацию еще надо будет перепроверять.

Если не только разработка идет с помощью ИИ, но и сам продукт содержит ИИ агентов, то у руководителя появляются новые задачи по разделению контуров систем и данных на безопасный и продуктовый и выстраивание инструментов контроля доступа и валидации обмена данными между ними. Это один из возможных подходов к реализации ранее упоминавшегося принципа “the lethal trifecta”.  

Также необходимо будет обеспечить плотное вовлечение информационной безопасности в разработку на старте (включая майндсет продуктового мышления для инженеров ИБ) и налаживание процессов внутреннего тестирования и инженерии контекста ИИ агентов перед релизом в промышленную среду.  

Исследования международного опыта ^[16] подчеркивают, что ИИ не создает идеальные компании, он усиливает то, что уже есть (AI doesn’t create organizational excellence – it amplifies what already exists ^[7]). Крайне важно, чтобы все руководители компании понимали этот большой вызов и были готовы к серьезной трансформации внутренних платформ, чтобы действительно стать native AI-компанией.

Трансформация ролей и скилл-сетов в организации

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

Размытие и изменение традиционных ролей в команде, о котором говорилось ранее, потребует пересмотра привычных подходов к performance review и скилл-сетов для перехода на очередной грейд. Вероятно, в продуктовых командах должна появиться некая новая вертикаль #shape специалиста разработки, которая будет сочетать элементы разных ролей. Соответственно, изменятся подходы к наставничеству и менторингу.  

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

При этом активное проникновение ИИ создает новые роли и позиции (context инженер или AI аудитор), либо усиливает потребность в уже существующих ролях, чья зона ответственности расширяется (архитекторы систем, архитекторы данных и архитекторы ИБ, DevSecOps инженеры и пр.)  

Задача для руководителя тут – формировать свое видение дальнейших трансформаций, продумывать и запускать следующие шаги изменений, не забывая про практики управления изменениями, вовлечение агентов изменений в процессы, работу с обратной связью и сопротивлением и т.п. Не стоит забывать ^[17], что в первую очередь руководители управляют людьми, и с появлением ИИ агентов потребность людей в внимании и лидерстве никуда не пропадет.

Фокус этой статьи на трансформации работы ИТ при внедрении ИИ. Однако опыт передовых компаний показывает, что конкурентного преимущества и победы на рынке достигнут те компании, которые вовлекут весь топ-менеджмент организации и стратегически пересмотрят все свои продукты, бизнес-модель, способы взаимодействия с клиентами, внутренние процессы и т.п., опираясь на новую парадигму работы “человек + ИИ агенты”. Роль CIO/CTO в данном контексте становится стратегической. Именно от этого человека зависит вовлечение всех функций С-уровня в работу над AI стратегией, донесение масштаба вызовов и перспектив, управление ожиданиями участников и общее лидерство ^[18] программой трансформации.

Итоги и рекомендации

Топ-менеджменту:

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

2. Несмотря на кажущуюся легкость (например, история про разработку браузера за неделю инженерами Cursor ^[19]), реальный переход компании к AI-центричной модели и парадигме “человек + ИИ агент” – это большой и серьезный вызов, который требует стратегического переосмысления бизнес-модели, продуктов и сервисов компании, способов коммуникации с клиентами, внешних и внутренних процессов с точки зрения новых трендов, подходов и возможностей. Результатов этого переосмысления должна стать программа стратегической трансформации, возглавляемая CIO/CTO и поддерживаемая на уровне топ-менеджмента.  

3. “Лоскутное” или “кусочное” внедрение ИИ не приносит значимых результатов. Трансформировать процессы и системы надо комплексно, опираясь на создание дополнительной пользовательской ценности и оптимизацию затрат.  

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

ИТ-лидеру:

1. Включение ИИ агентов в продукт открывает большие перспективы для трансформации бизнес-процессов и создания конкурентных преимуществ, однако с технической точки зрения является большим и сложным шагом. Путь от стремительного и красивого MVP, где ИИ агент решает одну задачу, до полноценного промышленного решения, основанного на ИИ, который сам подбирает инструменты и пути решения, – это длинный и сложный путь, который потребует существенных изменений в процессах, архитектуре и дополнительной работы от ИТ команды. Задача ИТ-лидера – честно и наглядно показать бизнес-лидерам предстоящий путь и оценить сопутствующие затраты.

2. В международных Big Tech компаниях ИТ функция уже сейчас активно трансформируется благодаря переходу на ИИ-центричную модель. Сформулируйте свое видение и план трансформаций, донесите свое видение до заинтересованных сотрудников и сосредоточьтесь на вовлечении агентов изменений и управлении изменениями.  

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

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

5. Подойдите комплексно к внедрению ИИ в разработке на всех этапах SDLC – возьмите за фокус поставку ценности пользователям и получение обратной связи и внедряйте ИИ там, где это даст значимый результат.  
   Сфокусируйтесь на отладке конвейера синхронного изменения всех артефактов разработки, если не собираетесь выбросить продукт после MVP. ИИ агенты могут помочь не только с кодом – не упускайте эту возможность.  

6. Внедряя ИИ агентов в продукт, уделите особое внимание ^[20] тестированию, безопасности и AIOps. Вам нужны новые процессы, новые роли и даже новые инструменты, чтобы уверенно делегировать бизнес-процессы и решения ИИ агентам.

Сотрудникам ИТ:

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

2. Учитесь применять ИИ в работе – эти навыки в некоторых компаниях уже являются обязательными (например, Сбербанк ^[21]), в других компаниях – могут стать вашим конкурентным преимуществом, особенно если вы можете объяснить, как сделать ваш опыт общей практикой и принести пользу работодателю. 

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

P.S.

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