Промышленное ли решение стартап?

Денис Середенко
Директор по развитию розничного бизнеса
Compass Plus

Финтех-стартапы и смузи не сходят с уст и не выходят из умов банковского и околобанковского сообщества, несмотря на агрессивное вытеснение их в последнее время блокчейном и криптотехнологиями. Многие стартап-проекты загорались как звездочки, и многие из них так же стремительно гасли, не набирая серьезных объемов клиентской базы.

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

Но так ли это на самом деле и что отличает серьезное, промышленное решение от программного обеспечения, которое быстро создано и хорошо (на первый взгляд) работает, особенно в отношении масштабных OLTP-систем реального времени? В этом аспекте хотелось бы перечислить те вызовы, с которыми сталкиваются разработчики и владельцы программного обеспечения в ходе роста объемов их решения, приумножения числа клиентов, увеличения оборотов и клиентской активности, а также проанализировать эти вопросы на примере сервиса MobiCash (http://mobicash.ru) компании Compass Plus.

Решение представляет собой мобильный marketplace для торговых организаций, базирующийся на e-invoice-функциональности и платежах по QR- коду, с богатыми функциональными возможностями информационного обмена между физическим лицом — пользователем сервиса и предприятием, за- интересованным в получении сервиса для организации платежей за свои товары и услуги.

Внутренняя архитектура ПО, производительность и масштабируемость решения

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

Особенно часто это касается архитектуры хранения данных, когда вначале так удобно хранить однородные данные линейно, в одной табличке или одной базе, а с колоссальным ростом объемов через несколько лет СУБД уже не лезет, как говорится, ни в какие ворота…

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

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

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

Именно поэтому компания Compass Plus придает огромное значение качеству проектирования программного обеспечения. Как и во все остальные продукты компании, в решение MobiCash сразу закладывалась возможность масштабировать хостовые (серверные) компоненты системы, невзирая на однородность клиентских приложений, разделяя их по геораспределенным дата-центрам в разных странах присутствия, определяя это потребностью клиентов и партнеров проекта в разных регионах мира.

Совершенство процессов и оперативная связь с бизнес-заказчиком

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

В больших масштабах agile-подходы требуют сверхусилий по координации работы команд и важность приобретает качественное структурирование команд по продуктам или компонентам продукта.

Постоянные инновации, невзирая на сложности роста

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

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

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

Сплоченная команда и преемственность принципов разработки

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

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

Надежная инфраструктура

Все вышеупомянутые усилия могут разбиться в пух и прах о швабру уборщицы или ковш экскаватора в плохо организованном или некачественно сконструированном дата-центре. Зачастую на начальном этапе реализации проектов уделяется не большое внимание качеству инфраструктуры и площадок размещения, с мыслями усовершенствовать и модернизировать эти вещи позднее с ростом объемов бизнеса. Потом захлестывает волна инноваций и функционального развития, и инфраструктурные вопросы у кого- то постепенно отходят на второй план. Затем наступает день Ч, и простои в работе сервиса измеряются в лучшем случае десятками минут, а в худшем – часами.

Зная это, мы разместили инфраструктуру сервиса MobiCash в собственных современных, сертифицированных дата-центрах, отвечающих всем требованиям стандартов платежной индустрии. Далеко не все финтех-стартапы обязательно наступают на описанные выше «грабли», но помнить о данных вызовах важно всем создателям больших ин-формационных систем, невзирая на то, удается обойти эти проблемы легко и не задумываясь или приходится фокусироваться на них особенно внимательно. Мы своей командой, которая имеет более чем 20-летний опыт разработки сложнейших транзакционных систем, строим будущее финтех-продукта MobiCash, всесторонне создавая оптимальные условия для его дальнейшего развития, и всем желаем позитива и предотвращения ошибок, которые сложно устранять по прошествии времени!

Журнал «Банковские технологии», №9, 2017.