Банковское обозрение

Финансовая сфера

  • Инхаус vs аутсорсинг: как финтех развивает ДБО
23.07.2019 Best-practice
Инхаус vs аутсорсинг: как финтех развивает ДБО

Банковская сфера движется к цифровизации, повышению качества и ускорению обслуживания с помощью IT-решений. При этом классические банки рискуют уступить позиции более гибким финансово-технологическим — финтех-компаниям. В перспективе, согласно прогнозу Bain&Company, к 2020 году до 30% прибыли перетечет от традиционных банков в финтех-сектор. Как не допустить устаревания банковских продуктов и чем может помочь аутсорсер?


Алексей Флоринский
Генеральный директор SimbirSoft

Инхаус или аутсорсинг — какой путь лучше?

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

Ведущие банки предпочитают самостоятельно разрабатывать программное обеспечение, практически создавая IT-компанию внутри своей структуры — так называемую инхаус-команду. Лидеры отрасли, такие как Сбербанк, «Тинькофф», Альфа-Банк и другие, развивают свои финтех-проекты, дистанционное банковское обслуживание (ДБО), мобильные приложения. В банковских инхаус-командах работают тысячи разработчиков. Гиганты обращаются к аутсорсингу с частными задачами: например, при необходимости ускорить релиз — когда продукт оказывает непосредственное влияние на продажи, на этапе активного маркетинга или при продвижении на высококонкурентном рынке.

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

• Заказчик, как правило, ожидает, что инхаус-разработка обойдется дешевле, а специалисты с учетом привычных, устоявшихся условий будут готовы работать за меньшие деньги. В идеальных условиях экономия на инхаус-разработке возможна, но если на проекте возникли ошибки, то их исправление собственными силами обходится дороже, чем аутсорсинг. При оценке стоимости аутсорсинга и инхаус-разработки следует учитывать некоторые дополнительные расходы: на создание команды, обучение (если проект сложный), на оплату труда во время «простоя» — если проект закончен и по большей части требует только поддержки, а разработчики сидят без дела.

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

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

• Хорошо выстроены личные связи внутри команды и с другими подразделениями компании. Это помогает оперативно разрешить возникшие вопросы, найти наиболее правильное решение в той или иной запутанной ситуации.

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

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

Сложность управления

Масштабировать отдел IT-разработки сложно, поскольку его главным ресурсом являются люди. Если в некоторых других видах производства вы можете, к примеру, увеличить количество станков, то для создания качественного и конкурентоспособного IT-продукта этого недостаточно. При увеличении команды возможны разногласия между разработчиками, и руководителю нужно справиться с этим, выстроить управление процессами.

Развитие без конкуренции

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

Управление мотивацией

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

Управление качеством

Во внутренней команде управление качеством продукта может сводиться к поиску багов. Кроме того, когда внутренние отделы компании оплачивают работу IT-отдела из своего бюджета, это создает дополнительные ограничения. Например, один из отделов просит инхаус-команду протестировать ПО — через неделю релиз. Внутренний заказчик начинает думать, как ему сэкономить, и заказывает неполный объем тестирования: только критически важные функции или тестирование отдельного нового сервиса (а может быть, решает и вовсе обойтись без тестирования). Все это приводит к падению качества. Аутсорсер же постоянно развивается и уделяет много внимания обмену опытом.

Что дороже: аутсорсинг или инхаус?

Считается, что аутсорсинг IT-услуг — это дорого. Но если бизнес решает, что инхаус-команда должна расти и обеспечивать высокий уровень качества, то ему приходится создать «IT-компанию внутри компании» и вложить в это много денег и времени. На практике инхаус-команда может оказаться дороже аутсорсинга, поскольку затрачиваются ресурсы на ее создание, а не только на поддержание. За счет обширной экспертизы в создании IT-решений для разных ниш бизнеса аутсорсер приходит на помощь, когда компания не успевает выпустить продукт в срок, ей не хватает рабочих рук или знаний в отдельных областях — например, в мобильной разработке.

Инхаус и аутсорсинг: как организовать взаимодействие?

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

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

Функции инхаус — сохранение у себя экспертизы, ведение базы знаний и инфраструктуры, с которой будут работать приглашенные специалисты (Docker, GitLab, Jira, Confluence). Удобнее всего, когда аутсорсер приходит в инфраструктуру банковской инхаус-команды и программирует или тестирует ее в рамках своей задачи. Например, разработка банковского программного обеспечения обычно отдается на аутсорсинг без доступа к реальным данным. Заказчик контролирует все процессы и сохраняет исходные данные даже в том случае, если рано или поздно перестанет сотрудничать с подрядчиком.

Задачи инхаус-специалистов — это автоматизация операций, метрики и отчетность по разработке, развитие методики разработки (команды, спринты, планирование, регламенты), сохранение экспертизы (обучение, митапы, хакатоны, грейды). Быстрый ввод новых специалистов на проект невозможен без подробных инструкций-тьюториалов в документации.

Начало сотрудничества

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

Инхаус+аутсорсинг: мобильный «ДелоБанк» для СКБ

С помощью аутсорсинга банк может усовершенствовать финтех-решения быстрее, чем собственными силами. Так было и в нашей практике, когда инхаус-подразделение банка СКБ — SKB_Lab — пригласило нас разработать мобильный «ДелоБанк», впоследствии вошедший в топ-5 рейтинга Markswebb. Перед нами была поставлена цель — сформировать комфортную среду для развития проектов малого бизнеса без отвлечения предпринимателей на рутину. Нужно было предоставить банковским клиентам все виды ДБО и дать возможность быстрого оформления кредитов. Мы доработали функции приложения и выпустили релиз за три месяца, чтобы успеть войти в отраслевой рейтинг. «ДелоБанк» занял четвертое место среди интернет-банков для индивидуальных предпринимателей (2017 год), а в 2018 году с онлайн-банком мы достигли второго места в рейтинге.

Как «спасти» банковский продукт от устаревания

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

• разработка не успевает за вновь приходящими бизнес-функциями;

• невозможность часто выпускать релизы;

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

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

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

Для ускорения релиза разработку можно разделить на несколько уровней:

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

2) уровень управления вертикальными командами, которые работают параллельно;

3) инфраструктурный уровень — здесь сосредоточены Git, сервера, тестовые площадки, инструменты.

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

Разделение ролей архитектора и тимлида

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

Алгоритм спасения продукта

Что делать, если вы исправили описанные выше распространенные ошибки, но продукт все равно нужно «спасать»? Предлагаем четыре шага:

1) погружение в бизнес-цель;

2) анализ текущего состояния;

3) построение Roadmap-изменений;

4) подключение команды для реализации изменений.

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

Когда нужно «спасать» банковский продукт

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

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

2. Сокращение time to market. Ведущие банки нацелены на выпуск как минимум двух-трех релизов в месяц, задавая высокую планку другим участникам рынка: необходимо создавать актуальные продукты и оперативно доводить их до клиентов. Трендом становится сокращение time to market, то есть времени вывода продукта на рынок. Это особенно важно в следующих случаях:

• продукт продвигается на конкурентном рынке;

• множество пользователей ежедневно обращаются к вашему продукту;

• вы намерены увеличить долю на рынке;

• стратегия компании включает в себя работу на опережение конкурентов.

Если говорить об организационных изменениях, то очевидное ускорение — параллельные команды, когда мы перекрываем процессы производства и аналитики, и они работают практически одновременно.

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