Когда благодаря искусственному интеллекту ИТ-разработка становится все дешевле и доступнее, ценность интегратора все меньше определяется ресурсами разработки и все больше — способностью отвечать за результат, сквозной сценарий и управление изменениями. Рассмотрим, почему сегодня бизнесу нужен не подрядчик с набором специалистов, а партнер, способный отвечать за результат.
In-house или подрядчик: как меняются модели работы
Отношение бизнеса к внешней ИТ-экспертизе меняется. После нескольких лет активного наращивания собственных ИТ-команд компании продолжают развивать in-house, но одновременно возвращаются к подрядчикам — уже не за людьми, а за результатом.
Сегодня на рынке вновь намечается тренд на создание in-house-команд. Но это уже не та практика
Хорошо это видно на примере компаний, которые пытаются полностью перевести ИТ в in-house. На практике быстро возникает вопрос: насколько эффективно внутренней командой управлять одновременно процессами Run и Change и есть ли смысл постоянно держать в штате все необходимые компетенции. Архитектор, DevOps или узкопрофильный эксперт могут быть критически важны для конкретного проекта, но не требоваться компании на постоянной основе. В результате для одних задач компания сохраняет собственную команду, а для других все равно привлекает внешнюю экспертизу.
В результате бизнес приходит к смешанной модели: ключевую экспертизу и понимание своего продукта он оставляет внутри, а отдельные компетенции и задачи привлекает извне. Но здесь возникает следующий вопрос: что именно бизнес покупает у подрядчика — отдельных специалистов, их время или все-таки конкретный результат? И именно здесь, на мой взгляд, сегодня происходит главное изменение в модели работы с внешними командами.
Покупать не людей, а результат
Долгое время у бизнеса было два основных способа привлекать внешние ИТ-команды: либо набирать специалистов под конкретные задачи, либо передавать подрядчику проект целиком за фиксированную стоимость. В первом случае компания по факту просто покупала ресурсы, и конечного результата могло не быть, поскольку оставался вопрос, кто отвечает за его достижение. Во втором ответственность за проект была более очевидной, но и здесь возникали ограничения: подрядчика приходилось глубоко погружать во внутренний контур компании, при этом у него не всегда были полномочия продвигать необходимые изменения или самостоятельно принимать решения. В итоге в обоих случаях оставался один и тот же вопрос: кто отвечает за конечный результат?
Поэтому сейчас рынок пришел к гибридным решениям. Компания по-прежнему может привлекать внешнюю команду, но отношения с ней строятся уже не вокруг количества специалистов и отработанных часов, а вокруг конкретного результата и ответственности за его достижение. Бизнес в такой модели формулирует цель и определяет, какого результата хочет добиться, а интегратор переводит эту цель в конкретную задачу, строит план реализации и отвечает за его выполнение. Это пока непростая модель, потому что нужно договориться, что именно считать результатом. Однако сам тренд уже очевиден.
Он связан еще и с тем, что сегодня бизнес предпочитает двигаться короткими итерациями: сделали что-то за два-три месяца, получили результат, посмотрели, как он влияет на метрики (а лучше — еще и на финансовые показатели), и только после этого приняли решение развивать продукт дальше. Проектов, в которых компания тратит условные 200 млн. рублей, а результат получает только через полтора года, сегодня на рынке осталось очень мало.
Если бизнес начинает покупать не ресурсы, а результат, меняется и сам подход к KPI. Раньше в фиксированных проектах большая часть требований была технической: производительность, безопасность, количество обрабатываемых SKU, RPS, допустимая нагрузка. Сейчас показатели все ощутимее уходят в сторону бизнес-метрик: продукт либо выстрелит, либо нет; он либо донесет ценность до аудитории, либо нет.
Например, если компания отказывается от внешнего SaaS для работы с подарочными сертификатами и создаёт самописное решение, недостаточно просто запустить систему в срок и обеспечить её техническую стабильность. Результат можно считать достигнутым, если собственная разработка действительно позволила сократить расходы на внешний сервис и обеспечить запланированную экономию. Конечно, технические показатели остаются необходимым условием, но главным критерием успеха становится уже бизнес-эффект.
Что бизнесу стоит оставлять у себя
При этом есть задачи, которые бизнес может отдавать подрядчику, но полностью передавать их на сторону не стоит. В первую очередь это Discovery — проработка бизнес-сценария, требований и того, каким должен быть конечный результат.
Представим, что ритейлеру нужно запустить доставку в e-commerce. На рынке много поставщиков логистики: можно подключить одного из них или построить собственную схему. И тут возникает целый набор бизнес-вопросов: как будут организованы возвраты? Сколько все это будет стоить? Можно ли будет купить товар онлайн и вернуть его офлайн? Будет ли примерка? Какие клиентские сценарии нужно реализовать?
Это уже не шаблонная техническая задача. Здесь нужно одновременно учитывать клиентский опыт, бизнес-требования, стоимость решения и то, как оно будет работать внутри компании. Эту часть очень сложно полностью вынести за пределы бизнеса. Сначала нужно хорошо прицениться, разобраться в вариантах и понять, как все будет работать. После этого можно сформировать образ конечного результата, и только после этого переходить к реализации.
Когда продуктовая команда полностью находится вовне, бизнесу сложнее сохранять контроль над приоритетами и развитием продукта. Поэтому самая рабочая модель, на мой взгляд — комбинированная: Discovery и продуктовая часть остаются на стороне клиента, а разработчики, аналитики, тестировщики и PM — на стороне подрядчика.
Главная серая зона — стык систем
Однако самая частая проблема в крупных проектах возникает не внутри отдельной системы. Она возникает на стыке систем. Интегратор отвечает за свой контур, заказчик — за остальные контуры, а их в крупном ИТ-ландшафте огромное количество. На бумаге все заняты, а в момент запуска выясняется, что никто не отвечает за сквозной сценарий — от витрины до чека.
Можно идеально сделать отдельный кусок системы, но покупателю от этого не легче. Он не видит отдельные ИТ-контуры. Он видит свой сценарий: например, оформил заказ онлайн, дождался его, получил от курьера. За этим простым пользовательским сценарием стоит огромное количество ИТ-систем, людей, процессов и вариантов развития событий.
И здесь проходит важная граница между обычным подрядчиком и правильным интегратором. Правильный интегратор берет ответственность не за разработку какой-то одной системы отдельно, а за сценарий. И буквально проводит его через весь ИТ-ландшафт, в том числе через внутренние системы заказчика.
Как управлять совместной работой и изменениями
Чтобы внутренняя команда и интегратор работали эффективно, нужен нормально выстроенный продуктовый процесс: обе стороны должны работать в единой парадигме.
Есть стандартный процесс: бизнес-анализ, системный анализ, постановка задач, передача их в спринты, определенные метрики эффективности. Все это должно быть подкреплено процессами, системами и понятными правилами. Когда работа скатывается в хаос, даже очень умные люди не будут работать эффективно.
И тут возникает вопрос, кто должен задавать эти правила. Внутри компании не всегда хватает экспертизы именно в построении таких процессов. Бизнес может отлично разбираться в своем продукте и операционной деятельности, но это не означает, что у него есть опыт разработки ИТ-продуктов. Поэтому на первый план выходит экспертиза самого интегратора или подрядчика: есть ли у него четко сформулированный фреймворк управления скоростью изменений, то есть понятный процесс, по которому инициатива бизнеса проходит путь от идеи до продакшена.
У хорошего подрядчика такой фреймворк должен быть выстроен заранее и работать вместе с его ресурсами и командами. В таком случае заказчик передает ему ответственность за скорость изменений в живой системе, которая связана с большим количеством других систем внутри ИТ-ландшафта. И правильно этим управлять — отдельная и достаточно сложная экспертиза.
И отдельная проблема — постоянно меняющееся ТЗ. Это не исключение, а нормальная часть работы над продуктом: бизнес получает новые данные, меняет приоритеты, видит реакцию пользователей и закономерно хочет корректировать решение. Задача ИТ — сделать так, чтобы бизнес понимал, где еще можно дожать, а где дополнительные изменения уже приведут к негативным последствиям. Поэтому здесь важны две вещи: прозрачный процесс и умение говорить с бизнесом на его языке. Хороший подрядчик должен уметь сказать: «Здесь можно, а здесь — нет», и грамотно подсветить риски.
Новая роль ИТ-интегратора
Понять, что перед вами действительно интегратор, а не продавец ИТ-услуг, проще всего по опыту реализации крупных проектов. Если подрядчик работает преимущественно с небольшими проектами, не стоит автоматически ожидать от него экспертизы в сложных продуктовых инициативах, где изменения проходят через десяток систем. Нужно смотреть, были ли крупные проекты, был ли опыт управления большим количеством команд, проектов и изменений в моменте. Есть ли архитекторы, бизнес-аналитики, есть ли описанный фреймворк управления. Если у компании есть опыт генподряда, это хороший сигнал: она уже умеет управлять сложной системой взаимодействий.
Все эти изменения происходят на фоне важного фактора — удешевления и ускорения самой разработки благодаря ИИ. По мере того как он меняет подходы к созданию ИТ-продуктов, ценность смещается от собственно написания кода к бизнесовой и процессной экспертизе: умению управлять разработкой, перестраивать процессы и встраивать новые инструменты в работу компании.
Если раньше интегратор приходил и говорил: «Давайте внедрим вам коробку, потому что с нуля будет дольше», то сейчас часть таких решений бизнес может собрать собственными командами с помощью ИИ-инструментов. Я уже вижу все больше историй, когда крупные и средние компании делают собственные мессенджеры, таск-трекеры, платформы для работы с LLM и другие внутренние продукты.
Поэтому одной экспертизы в поставке коробочных решений со временем будет недостаточно. А вот умение прийти к заказчику, внедрить продукт и одновременно выстроить вокруг него процессы, в том числе автоматизировать с помощью LLM изменение этого продукта, будет гораздо более ценным.
Получается интересная и в чем-то парадоксальная ситуация: чем дешевле и доступнее становится непосредственно разработка, тем важнее становится умение правильно организовать изменения. И именно поэтому будущая миссия интегратора — не в том, чтобы быть дополнительными руками для бизнеса. Его задача — помочь бизнесу пройти весь путь от идеи и Discovery до работающего сквозного сценария, взять на себя ответственность за delivery и скорость изменений, а самое главное — сделать так, чтобы в сложном ИТ-ландшафте всегда было понятно, кто отвечает за результат.
