20 мая 2021 г.
С ростом роли ИТ в развитии новых бизнес-моделей особое значение приобретает способность бизнеса получать в распоряжение оптимальные софтверные инструменты. Их проектирование, разработка, доработка, масштабирование — все эти задачи успешно решает кастомный подход к созданию программных продуктов. Он успешно применялся в прошлом и уверенно возвращает актуальность сегодня.
Дежа вю?
Около 30 лет назад рынок программного обеспечения отличался высокой индивидуальностью решений. Подавляющее большинство софтверных продуктов создавалось под индивидуальный заказ компаний по одной простой причине: на рынке просто не было достаточного предложения коммерческого ПО.
Бизнес делал необходимый софт под себя и своими силами, и можно сказать, с задачей справлялся: многие из кастомных ИТ-решений и систем, созданных в
Затем с расцветом ИТ-отрасли пришла эра «коробочных» программных продуктов. Компании стали использовать стандартные решения от вендоров (шаблоны сайтов, бухгалтерское ПО, САПР, системы учета и т. д.).
Сегодня в разработке корпоративного софта на первый план выходит способность интерфейса и функционала продукта идти в ногу с растущими ожиданиями клиентов. Пользователи ожидают, что ИТ-инструменты, скажем, банка, по степени удобства использования и частоте обновления будут находиться на уровне соцсетей или таких сервисов как Netflix.
Современные цифровые лидеры обеспечивают предоставление новых функций продуктов на еженедельной, ежедневной, а иногда даже ежечасной основе. Решения из сегмента коробочного софта с циклом обновлений раз в квартал — проигрывают в этой гонке.
Новые реалии бизнеса и разработки
Сегодня лидерами цифровизации и главными потребителями кастомного ПО в России становятся банки, телеком-операторы, ретейл.
В силу высокого уровня конкуренции в этих областях компании делают ставку на возможности цифровых инструментов для взаимодействия с конечными клиентами, подготовки персонального предложения продуктов или услуг, расширения воронки потенциальных клиентов (подбор клиентов из так называемой «серой зоны»), а также для оптимизации взаимодействия в рамках цепочки поставок.
При таком подходе во главе угла ставится показатель time-to-market (ТТМ), повышение которого и гарантирует бизнесу сохранение и развитие конкурентоспособности, а также обеспечивает возможности оперативного и гибкого масштабирования.
Одна из главных особенностей современных бизнес-моделей традиционных компаний — эволюция в сторону комплексных экосистем сервисов и продуктов, предоставляемых пользователям на единой платформе. В случае банков — транзакции как источник дохода уходят на второй план, на первый план выходит омниканальный маркетплейс. Такая трансформация достижима только через развитие эффективных цифровых решений.
Это одна из причин поворота в сторону кастомного подхода к разработке: обновления цифрового инструментария нужны постоянно, оперативно и с неизменно высоким уровнем качества. По большому счету, сегодня все стремятся к «цифровому конвейеру» по созданию новых ИТ-продуктов и обновлению существующих.
Современные кастомные решения разрабатываются на микросервисной архитектуре и технологиях с открытым кодом. Микросервисы дают возможность декомпозировать ИТ-реализацию бизнес-функционала на независимые друг от друга компоненты, обновление и замена которых в минимальные сроки и с минимальными затратами позволяют увеличивать ТТМ по сравнению с традиционным релизным подходом для монолитов в разы.
Софтверный DIY: успех по правилам
Основная проблема при удовлетворении данной потребности для бизнеса лежит в невозможности добиваться необходимых результатов только своими силами. Софтверный «сделай сам» силами ИТ-отдела занимает огромное время и съедает объем кадровых ресурсов, что недопустимо в современных рыночных условиях.
Что нужно, чтобы проект кастомной разработки был успешным?
1. Тщательный подход к стадии проработки архитектуры финального решения
На старте нужно заложить стандарты разработки, выбрать оптимальную комбинацию компонентов решения и технологии. Не стоит экономить на грамотных ИТ-архитекторах. Это позволит избежать проблем с производительностью, масштабируемостью, скоростью и трудоемкостью доработки будущего зрелого решения.
Так как выбор инструментов в кастомной разработке огромный, принципы и стандарты работы для всех команд должны быть едины и выполнимы, чтобы гарантировать качество продукта.
2. Правильный подбор ИТ-инфраструктуры, необходимой под задачи проекта
Нужно уметь динамически выделять аппаратные мощности, иметь надежные и эффективные средства переноса кода между средами, автоматически проводить регрессионные тесты написанного кода. Все это сегодня реализуется в рамках подхода DevOps с использованием облачных сред для разработки и тестирования программного кода. Правильная инфраструктура — один из главных факторов того, что компания сможет выпускать продуктивные релизы продукта с необходимой частотой.
Например, прогон тестов решения на виртуальных машинах в облаке позволяет сэкономить гораздо больше времени, нервов и денег, чем запуск аналогичного процесса на оборудовании, которое монтируется под каждый отдельный проект в приватном ЦОДе компании или на реальных рабочих местах сотрудников.
3. Правильное управление процессом
Для больших программ нужно грамотно «приземлить» использование SAFe для эффективной работы распределенных мультивендорных команд, чтобы использовать все преимущества гибкого подхода, избежав при этом хаоса и проваленных ожиданий инвестора.
Важно учитывать, что за контуром проекта у заказчика часто развиваются исторические (Legacy) системы, с которыми нужно интегрироваться и далее дорабатывать для синхронизации ритма работы по проекту в целом.
4. Человеческий фактор в кадровой перспективе
Рынок специалистов по кастомной разработке (Java/Front разработчики, системные аналитики, тестировщики) сегодня перегрет. Получить в свое распоряжение грамотную команду необходимых специалистов быстро и надолго — невероятно сложно.
Всегда нужно закладывать значительное время на мобилизацию команд и выстраивать эффективные процессы управления подрядчиками. Типично, над масштабным проектом работает более десятка команд, состоящих из специалистов заказчика, главного подрядчика и субподрядчиков. Численность каждой команды —
Кто-то трудится в офисе
Так удается поддержать необходимую скорость и обеспечить нужный уровень пользовательского опыта работы с продуктом с самого начала и по всей цепочке пользователей.
Коробочные решения
Чем может не подойти коробочный продукт, и в чем сложность его настройки под себя?
Во-первых, показатель ТТМ в таком сценарии целиком зависит от вендора, любая кастомизация носит строго ограниченный характер, что с учетом специфики каждого бизнеса приведет к необходимости написания огромного количества интеграционных модулей. Это долго, дорого и не всегда гарантирует нужный результат.
Во-вторых, Legacy-инфраструктура у многих банков присутствует в критически важном объеме обеспечения бизнес-операций или на критически важных участках, что делает крайне сложной интеграцию с платформами и решениями «из коробки».
Часто это вопрос не технологий, а экономики: core-система «заинвестирована» настолько серьезно, что отказ от ее использования или декомпозиция для интеграции с другим проприетарным продуктом будет означать потерю этих средств.
В то же время кастомная разработка с применением технологий с открытым кодом и микросервисных архитектур способна адаптировать Legacy к работе с учетом всех требований. Яркий пример — кредитный конвейер, решение для автоматизации процесса оценки заемщика и принятия решения о выдаче кредита.
Что дает банкам кастомное решение для этой задачи? Высокая скорость вывода и дальнейших обновлений решения, «заточенность» решения под специфику конкретного банка, гибкие возможности для интеграции с внешними и внутренними системами, надежность и горизонтальную масштабируемость на
Например, в парадигме спринтов это будет выглядеть так: сначала реализуется функционал приема заявки, сбор информации из внутренних источников, далее сбор информации из внешних источников, расчет доступных для него продуктов, затем процедура одобрения... Так шаг за шагом реализуется весь продукт. Затем происходит его запуск и поддержка под наблюдением проектной команды.
Подобные решение в последнее время были успешно запущены лидерами банковской отрасли, которые потратили на первичную разработку около шести месяцев, а затем эксплуатируют и развивают конвейеры с запуском нескольких новых релизов ежемесячно.
Источник: Алексей Минаков, директор практики управления проектами компании Accenture в России
