Купить или создать: особенности in-house разработки технологических решений в финтех-компании

Создание новых технологических решений, лежащих «под» продуктовой логикой и бизнес-процессами, — это сложная задача для компании любого масштаба. Учитывая, что сегодня у компаний есть выбор, — создать новое с нуля или приобрести готовое решение, главное — правильно этот выбор сделать. Кирилл Ермаков, Chief Information Officer QIWI Group, рассказал, как правильно расставить приоритеты и грамотно построить процессы in-house разработки.

Кирилл Ермаков

Chief Information Officer QIWI Group

Дилемма инноватора

Запуск любого IT-продукта — это долгий и трудоемкий процесс, при котором всегда что-нибудь идет не по плану. Перед деплоем всплывают серьезные баги, сроки сдвигаются, а иногда резко меняется стратегия — и продукт приходится изобретать заново. Особенно это касается масштабных запусков: по данным McKinsey, крупные IT-проекты в 45% случаев выходят за рамки бюджета, в 7% — за рамки дедлайна. От запланированных сроков исполнения вообще зависит многое — каждый дополнительный год разработки увеличивает сверхнормативные расходы на 15%. Обычно они связаны с некорректным планированием или исполнением: например, команда изначально поставила неверную цель или установила нереалистичный дедлайн.

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

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

Интересно, что три года назад аналитики IDC прогнозировали, что к 2020 компании будут тратить на покупные решения больше, чем на собственные разработки. Действительно, сегодня доступных SaaS-решений стало больше, а их средняя стоимость снизилась. Параллельно с этим развиваются open source платформы. Предполагается, что уже к 2021 две трети всего софта, используемого корпорациями, будет с открытым кодом. Многие также используют гибридный подход — например, создают собственное решение, дорабатывая open-source продукт, или комбинируют несколько готовых решений, создавая свою кастомизированную версию.

Собственные разработки: кому и зачем нужны

In-house разработка в компаниях — как технологических, так и финтех- и банках — существует на двух уровнях:

1. продуктовая разработка — технологию рассматривают как готовый продукт, являющийся драйвером для бизнеса, и в процессе участвуют продуктовые команды;
2. технологический in-house — компания изобретает технологическую платформу «под капотом», которая решает конкретную проблему, при этом продуктовая бизнес-логика на этом уровне не применяется.

Например: движок базы данных — это технология, а когда его дорабатывают, дополняют интерфейсом, бизнес-логикой и интегрируют с другими сервисами — это уже продукт

Для начала разберем плюсы и минусы in-house разработки. Можно выделить как минимум четыре недостатка технологических решений своими силами:

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

Но плюсов все же больше:

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

Возьмем, к примеру, небольшой стартап, которому нужна умная CRM-система или платформа для бухучета. В этом случае in-house разработка не имеет смысла — вы зря потратите время и деньги. Но крупная технологическая компания, которой нужны комплексные и нестандартные продукты, извлечет из in-house большую выгоду. Особенно это касается сферы финтеха. Традиционно это более гибкая и адаптивная отрасль, в которой IT-составляющая всегда играла важную роль. Классические финансовые компании обычно покупают готовые сервисы — далеко не у всех есть своя система процессинга платежей или АБС.

Мы изначально не пошли по такому  пути финансовых компаний. С момента создания QIWI работала как IT-компания и с нуля создавала процессинг терминалов. Поэтому мы сразу же делали ставку на in-house и для этого строили культуру внутренней разработки и автоматизации. Сразу стало понятно, что технологической компании нужны мощные подразделения с командой сильных программистов — скромного IT-отдела будет недостаточно. А для этого нужно наращивать экспертизу за счет разработки собственных технологий.

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

Постепенно мы пришли к гибридной модели разработки и в других подразделениях. В общей сложности сегодня QIWI использует шесть собственных процессингов и два покупных решения — это АБС и карточный процессинг. Кроме того, мы построили собственный отдел разработок в сфере информационной безопасности, а также подразделение, которое создает продукты для бэкофиса. Это помогает с легкостью кастомизировать покупные продукты и оптимизировать их под свои задачи, продолжая при этом работать над in-house разработками и выкладывали решения в открытый доступ.

Так, например, благодаря собственному отделу ИБ-разработок QIWI смогла создать платформу для обнаружения утечек исходных кодов Leak-Search — она помогает компании отслеживать утечки исходных данных и чувствительной информации. Например, если сотрудник выкладывает код в репозиторий, не осознавая, что в нем содержатся пароли от базы данных или конфигурации сетей. Мы просто не нашли в тот момент достойного и быстрого решения для автоматического мониторинга, поэтому разработали его своими силами и начали использовать в контуре компании — а затем, убедившись в эффективности платформы, предложили ее рынку.

Build vs. Buy: как определиться

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

1. Определяем цели и желаемый результат — это помогает четко сформулировать, что именно нам необходимо.
2. Проводим продуктовый анализ: изучаем, какие альтернативы уже есть на рынке и решают ли они поставленную задачу. Если находим целесообразное решение, отказываемся от in-house разработки. Если нет, переходим к третьему пункту.
3. Оцениваем не только стоимость разработки, но и косты дальнейшей поддержки с учетом количества задач и затраченных на них часов (cost of ownership). Лучше измерить потенциальные затраты помогает оценка в диапазоне 3-5 лет с учетом всех будущих апдейтов. Очевидно, что статичный продукт нам не нужен, поэтому инвестировать в него придется постоянно.
4. Заранее выясняем, есть ли продуктовый потенциал и можно ли построить отчуждаемое решение, которое сможет существовать независимо от инфраструктуры QIWI.

In-house в технологических корпорациях

Построение отдельного бизнеса на базе технологического in-house — нормальная практика в IT. Часто гиганты рынка создают профильные решения под свои нужды, а потом масштабируют и выкладывают в открытый доступ. Так делают и Google, и Яндекс. Один из самых успешных кейсов — Amazon, которая до недавнего времени получала основную долю прибыли не от своего торговой площадки, а от облачной системы AWS. Пример технологического in-house на российском рынке — Mail.ru и ее база данных Tarantool. Компания не нашла на рынке эффективной базы для хранения горячих данных и создала свою, которую вскоре выделила в отдельное продуктовое направление — и сейчас занимается ее развитием, предлагая сервисы Tarantool рынку.

Еще один похожий кейс — аналитическая система управления базами данных ClickHouse. Изначально она создавалась для Яндекс.Метрики, но в какой-то момент продукт вышел из-под контроля — в хорошем смысле, — и его стали использовать в Директе, Маркете, Почте, AdFox, Вебмастере, а также в мониторингах и бизнес-аналитике. ClickHouse работал эффективнее аналогов, а в некоторых случаях решал задачи, с которыми другие инструменты не справлялись. В результате команда Яндекса открыла доступ к ClickHouse, опубликовав исходники на GitHub.

Впрочем, часто IT-гиганты находятся в своем информационном пузыре и начинают терять связь с рынком. Они могут тратить годы на создание технологии, которая решает задачи только самой компании, но не находит отклика у рынка. Например, Google в 2011 году свернула свой проект Labs, который занимался инновационными разработками, многие из которых закончились провалом. Изначально компания делала ставку на быстрые запуски продуктов, но потом поняла, что слишком часто «промахивается» — и поменяла модель. Другой пример — хостинг Google Code, который закрылся в 2016 году — спустя 8 лет после запуска GitHub, который оказался более успешным. На финансовых показателях Google это сказалось несущественно — IT-корпорация может переносить даже миллионные потери, но для компании меньшего масштаба это был бы огромный риск.

Чтобы этого не произошло, важно на определенном этапе подключать продуктовую логику — то есть перейти от разработки технологического решения к разработке готового продукта. Поэтому для развития, а главное, продвижения внутренних инноваций на внешние рынки нужно создавать не только сильную IT-команду, но и подразделение продуктовой разработки. Иногда «продакты» помогают понять, в каком направлении двигаться — и благодаря им внутренние проекты превращаются в успешный бизнес.  Один из таких примеров — неожиданный успех игровой студии Tiny Speck, которая в начале 2010-х решила создать сервис для упрощения коммуникаций в команде. Так появился корпоративный мессенджер Linefeed, а через несколько лет он получил новое название — Slack. Первое время его использовали только четыре разработчика, но потом команда привлекла к тестированию своих друзей из других компаний — собрав фидбек, она улучшила продукт и смогла вывести его на рынок. Так появился сервис, который полностью изменил подход к корпоративным коммуникациям.

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