Ловушка вендора: почему банки и корпорации переходят на свою разработку и как сделать это правильно

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

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

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

Чем плохи вендорские решения?

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

Первое. Развитие решения отстает от развития фронтира отрасли, новые продукты появляются с опозданием. А из‑за эффекта масштаба бизнеса крупный банк, когда он вкладывается в новые продукт, не может долгое время работать на Excel и другими подручными средствами, как делают средние. И это является ограничениям для банка по развитию новых продуктов.

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

Второе. Типовое решение реализует основные сценарии, а обработку исключений оставляет оператором. Здесь для крупного банка тоже возникает проблема масштаба: если особые случаи, порождающие инциденты, возникают лишь в 1% операций конкретного типа, то при 1000 операций в день у вас — лишь 10 инцидентов, разобрать которые вручную не составляет проблемы, а вот при 10000 операций инцидентов уже их уже 100, и это требует поддержки — выявления среди них типовых ситуаций и включения их в основные сценарии. При этом во многих случаях речь идет не об автоматизированной обработке инцидента: необходимо добавить какой‑то дополнительный контроль или альтернативную ветку бизнес‑процесса. Вендор вряд ли будет это делать, так как у основной массы его заказчиков все хорошо, а у крупных способы работы в особых ситуациях сильно различаются и с трудом обобщаются.

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

Я наблюдал последствия этого во многих проектах, прорабатывая интеграцию новых решений с существующими системами. Оказывалось, что необходимые доработки сложны или вообще невозможны. Например, в одной из банковских систем заказчика мультивалютные проводки реализованы с помощью полупроводок и сложной системы отчетов, которые объединяли их в полные проводки по требованиям ЦБ. И это было в начале 2010‑х, когда требованиям ЦБ по полным проводкам было уже более 10 лет. Естественно, в нашей системе мы использовали полные проводки, и заказчик нам обещал, что команда поддержки старой системы при интеграции свернет полупроводки в полные проводки. Но у нее не получилось, пришлось решать задачу на нашей стороне. В другом случае внедрение нашей системы было форсировано, потому что выяснилось, что существующая система не может поддержать сложные изменения нормативных требований по кредитным линиям, поэтому на первом этапе мы внедряли систему для очень ограниченного функционала в одном сегменте бизнеса, а далее были вынуждены вести развитие уже эксплуатируемой системы. И все это — типичные ситуация.

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

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

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

Соответствие между процессами компании и моделями, заложенными в систему — принципиальный фактор для успеха внедрения новой системы. Когда‑то я писал статью с разбором этого вопроса «Путь к результативной автоматизации», в ней есть конкретные кейсы и способы оценки соответствия. А здесь я подчеркну, что проблемы конструирования процессов на основе того, что предоставляет платформа, с разумными доработками и без потери важных собственных процессов я наблюдаю во многих проектах. При этом даже там, где бизнес искренне готов меняться, ИТ не может им объяснить, как именно надо перестроить процессы. Специалисты 1С часто знают лишь типовые процессы, а процесс адаптации и выработки решений по новым процессам необходимо проходить совместно. Ведь именно бизнесу, а не подрядчику предстоит перестроиться и работать иначе, и только он знает границы возможных изменений, в то время как подрядчик может лишь оптимизировать стоимость доработок.

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

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

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

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

Надо ли выделять ядро или платформу?

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

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

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

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

Во‑вторых, типичной проблемой интеграции является идентификация объектов. Ключи в разных системах различаются. Сделать основной ключ в формате GUID — типичная ошибка, которая приводит к нечитаемым ключам и очень сильно усложняет работу службы поддержки. В некоторых проектах пытаются на систему интеграции возложить перекодировку ключей, чтобы она держала таблицы соответствий. По факту это приводит к тому, что система интеграции перестает быть stateless, она начинает включать существенную часть MDM — информацию о соответствии объектов в разных системах. Это делает обработку сообщения тяжелой, порождает еще одну точку потенциальных ошибок. А если по соображениям безопасности требуют еще и подписывать сообщения отправителем, то перекодировка внутри сообщения становится невозможной, так как подпись теряет актуальность, и возникает специальная часть сообщени с таблице соответствия. И вместо упрощения интеграции за счет перекодировки ключей она оказывается чрезмерно усложненной.

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

Последний вопрос логично подводит нас к следующему уровню, который тоже часто выносят в ядро или платформы — состояние документов и сделок. Некоторые банки радикально решают этот вопрос, используя для оркестрации BPMN‑движок Camunda или аналогичные средства. У такого решения есть свои плюсы и минусы. Плюсом является однородность решения на все ИТ‑ландшафте. Она же является очевидным минусом, потому что для многих сегментов бизнеса мощность BPMN является излишней, там есть 2‑3 документа с простым графом состояний. Именно поэтому другие банки, проведя анализ и выяснив, мощность Camunda реально востребована для 3‑5 продуктов из многих десятков, образующих ИТ‑ландшафт, решают отказаться от такой стандартизации. И в результате оказывается, что разные команды выбирают разные решения, и построить сквозной мониторинг сделок очень затруднительно.

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

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

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

Я был архитектором и одним из основных разработчиков такого движка в нашей компании — CUSTIS Accounting Engine. И наш опыт разработки позволяет сделать парадоксальный вывод: реальная ценность ядра — не в конкретном коде, а в методологии проектирования приложений и наборе архитектурных принципов и шаблонов, которые обеспечивают типовые решения для большинства бизнес‑задач.

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

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

Именно наличие методологии позволило нашему ядру пережить несколько изменений технологического стека реализации с переписыванием кода: мы переносили его с двухзвенной архитектуры на Oracle в трехзвенную архитектуру для проектов на.Net и Java по мере того, как менялись используемые технологические стеки. И в моем рассказе на CNews 2024 «Учетно‑ориентированная архитектура — основа построения учета в распределенном ИТ‑ландшафте» именно архитектурный шаблон был основным фокусом, потому что он сохранился неизменным.

Конечно, код ядра тоже важен: именно он обеспечивает масштабируемость решений, эффективную работу под нагрузкой. И тут необходимо обеспечить, чтобы ядро давало достаточную гибкость, а также имело возможность быстрого развертывания для реализации новых проектов. В том числе таких, где функциональность может быть востребована в ограниченном объеме, чтобы избежать излишней сложности решений. Если говорить про enterprise‑системы, то там есть несколько классов решений: сложные справочники, которые не всегда выносят в единый MDM, документооборот без учета, или, наоборот, учет без документооборота, с получением учетных событий от внешних систем.

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

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

Мой опыт говорит, что некоторые системы могут не обновлять ядро годами, если развитие бизнес‑логики не требует нового функционала ядра. Очень важно, чтобы переход на новые версии ядра каждая система могла планировать, исходя из собственной логики развития и ее потребностях в новом функционале ядра. Заказчику не объяснишь необходимость изменений с комплексным тестированием, если продукт стабилен. Чтобы такая модель работала, у команды разработки платформенного ядра возникает жесткое обязательство — обеспечивать обратную совместимость версий, иначе мозаичный ИТ‑ландшафт превратится в хаос. А при создании нового функционала надо дополнительно думать о том, как его смогут использовать старые проекты. Например, очень часто заманчиво доработать структуру базу данных, и для новых проектов это сделать легко, а вот когда в исторических таблицах лежат сотни миллионов записей, то изменение структуры без остановки системы становится сложной задачей. И тут стоит думать про альтернативные решения, которые могут обеспечить обратную совместимость и доступность нового функционала в старых проектах без подобных изменений.

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

Подрядчики или собственная разработка?

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

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

В свое время проблему культурного разрыва начали решать, создавая отдельные дочерние компании. Но из‑за инерции большой структуры это помогало слабо, я помню, как в начале 2010‑х на одной из конференций руководитель проекта такой структуры жаловался, что не может найти квалифицированных Java‑разработчиков на интересный высокотехнологичный проект на зарплату +30% к рынку: как только они слышали, что в офис надо жестко приезжать к 10 утра, они говорили, что последний раз так рано вставали на экзамены в институте, и то не на каждый. Сейчас таких жестких условий нет, но корпоративная культура большой корпорации дает о себе знать. И за согласие на работу в таких условиях корпорациям приходится переплачивать вдвое. Впрочем, ситуация постепенно изменяется и в большинстве дочек и собственных ИТ‑отделах корпораций условия труда вполне приемлемы, а в ряде мест — и хорошие, сопоставимые с ИТ‑компаниями.

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

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

Схема с ТЗ приемлемо работала, пока интеграторы внедряли вендорские решения: в этом случае ты ограничен теми возможностями, которые это решение предоставляет, и интегратору надо лишь определить необходимые настройки с делать небольшие доработки в предусмотренных точках расширения. Это все можно описать в ТЗ, которое по сути представляет некоторую анкету. А вот заказчику надо перестроить свою работу в соответствии с best practice этого решения.

Для создания оригинальных решений схема не работает. Первыми это поняли ИТ‑компании и у некоторых из них лет пятнадцать назад возникла бизнес‑модель: делаем формально по ТЗ минимальными усилиями, выигрывая конкурс за счет демпинга, а потом — много и дорого дорабатываем, доводя решение до приемлемого уровня. Через некоторое время заказчики разобрались, как это работает, и научились создавать такие ТЗ, которые можно практически произвольно трактовать, требуя дополнительных доработок без увеличения стоимости проекта. Результат мы видим сейчас в виде достаточно многочисленных конфликтов между корпорациями и крупными ИТ‑подрядчиками, в которых нередки судебные разбирательства.

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

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

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

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

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