Ринок фінансових ІТ-розробок великий, і кожний продукт або його частина може розв’язувати завдання для різних категорій користувачів. Уже понад 3 роки команда Levi9 розвиває в Україні екосистему банкінгу BackBase для 80 країн світу — працює над центральною системою платформи та відповідає за те, щоб банківське середовище — будь-то застосунок чи онлайн-кабінет — були захищеними від витоку чи пошкоджень та полегшували керування коштами бізнесу та звичайним користувачам.
У цьому матеріалі Роман (BA/PO department manager у Levi9) із senior-розробником Дмитром Ковальчуком з огляду на свій досвід розповідають, що треба враховувати під час роботи з банківськими продуктами і як розвинути систему так, щоб запартнеритися з Microsoft.
Користувачам потрібні не банки, а банкінг
Завдання сучасних банківських розробок — бути зручними, функціональними та швидко працювати. І тенденція останніх років — давати більше свободи та доступу до операцій користувачам банкінгу. Самообслуговування (self-servece) дає змогу клієнтам вільно керувати грошима та самим розв’язувати проблеми. Нам не подобається годинами чекати на свою чергу та вкотре чути в слухавці, що ми важливі компанії. Зручніше зайти в застосунок і в декілька кліків здійснити операцію. Це вигідно й банкам — чим незалежніші клієнти, тим менше установи витрачають коштів і мають більше ресурсів для покращення свого продукту та сервісу.
BackBase дає змогу діджиталізувати банківські операції та зробити з класичного банку інноваційний, надавши більше можливостей користувачам. Це екосистема, яку клієнт може адаптувати під себе, як-от керувати ступенем доступу до рахунків інших осіб, встановлювати ліміти на платежі, налаштовувати щомісячні транзакції та вигляд кабінету банкіра. Продукт треба інтегрувати у вже наявну core-систему банку та доповнити цю основу рештою функцій.
Проєкт народився на початку 2000-х у Нідерландах, а українська команда долучилася до нього 2014-го. Backend-розробка побудована на Java. і це традиційно для банківської сфери — ця мова є дієвою в різних середовищах, може обробляти великі обсяги даних і має жорсткі функції безпеки. Завдяки принципу «написати раз, використовувати будь-де» Java досі в топ-3 мов програмування у фінтех, час від часу обмінюючись місцями з Python. Водночас її добре доповнюють інші інструменти. З BackBase ми пройшли багато технологічних змін. Наприклад, починали будувати мікросервіси на DropWizard і перейшли на Spring, а в роботі з даними змінили Application Servers на Kubernetes. Одночасно ми постійно оновлюємо інструменти та збільшуємо продуктивність системи, використовуючи новітні технології. А оскільки в нас багато допоміжних проєктів і у frontend, і в DevOps, то встигаємо працювати й на Scala, Groovy, TypeScript. Частину написаних рішень віддаємо в open-source.
Усередині проєкту: принципи роботи
Описуючи будову проєкту ізсередини, є 2 великі відділи — R&D, які займаються створенням продукту з нуля, його розвитком, удосконаленням і підтримкою, та Customer Success Team (CST), що відповідає за інтеграцію, підлаштування та розширення функціонала під потреби клієнта. В Україні до проєкту залучено понад 10 команд, що працюють в обох напрямах, — загалом 107 левінайнерів. Ми співпрацюємо з колегами в 6 країнах світу — такий собі Вавилон у мініатюрі. Команда Levi9 в Україні повністю залучена у wealth-менеджмент, операції з інвестиціями та позиками. Ми також розробляємо чи не всі сервіси комунікацій із клієнтами. Наприклад, якщо треба показати історію листування чи прислати push-повідомлення на телефон — це робить українська команда.
Зокрема, ми відповідаємо за доступи — хто й до чого його має, у якому обсязі, що можна з ними робити та які додаткові обмеження встановлювати. Ця функція важлива, адже користувачам потрібно:
- мати безпечне середовище, якому вони можуть довіряти;
- мати змогу запобігати помилкам і шахрайству;
- мінімізувати ризики;
- розподіляти обов'язки користувачів системи.
Уявімо, що ви — ФОП або компанія з декількома рахунками, які хочете передати для ведення бухгалтеру. Завдяки нашому сервісу ви можете надати йому/їй змогу дивитися на перший рахунок і формувати виписки для подання звітності, а з другого — здійснювати платежі в рамках певної платіжної системи, визначати, на які саме рахунки можна відправити кошти (наприклад, лише на зарплатні рахунки певних одержувачів) та встановити максимальний ліміт транзакцій за цими платежами. А приємним бонусом буде можливість призначити іншого користувача відповідальним за схвалення цих операцій — щоб він їх погоджував чи відхиляв.
Інший великий сегмент нашої роботи — це ліміти. Вони дають змогу обмежити обсяг транзакцій на день, місяць або рік, що допомагає планувати витрати та вберегтися від шахраїв. Проте BackBase має більше можливостей і дозволяє підлаштувати ліміти під різні ситуації та користувачів. Наприклад, ви замовили дитині картку й не хочете, щоб вона оплачувала комп’ютерні ігри на понад 10 тис. грн. Ви також можете встановити для певного регіону суму, понад яку списання коштів треба буде додатково підтверджувати. Крім того, є ліміти, якими можуть керувати лише працівники банків. Наприклад, обмежувати транзакції та погодження певних операцій.
Запорука успіху — чітка оцінка результату
Банківські розробки багатошарові й мають задовільняти потреби як молодої родини, так і бізнесу з командою в тисячу спеціалістів. Новий або покращений функціонал має розв'язувати реальну проблему користувача чи відкривати нові можливості для роботи — відчуття «вау, а так можна було?!» В іншому випадку впроваджувати його не матиме сенсу.
Розуміючи потреби клієнта, ми маємо враховувати й вимоги, яким має відповідати високоякісний кінцевий продукт. Це означає, наприклад, що система захищена від вразливостей, швидко реагує, має простий дизайн і доступність (accessibility) згідно з ААА, її можна змінювати та масштабувати. Більшість із таких вимог проговорюється ще перед початком роботи над розробкою, а в процесі цей список можна розширювати та переглядати.
За замочуванням система має бути безпечною. Це означає, що перед кожним релізом і оновленням її треба перевіряти на помилки, віруси, вразливості та звіряти із затвердженими чек-листами захисту даних. І тут є цікава річ із правом на забуття користувацьких даних згідно з регламентом GDPR. Так, з банкінгу не можна видалити історію транзакцій клієнта, адже дані не збігатимуться, і система зламається. І завдання розробника — знайти, як анонімізувати інформацію користувача, водночас залишивши операцію в історії.
Легке користування — складна розробка
Користуватися складним продуктом має бути легко — замість 10 дій краще зробити 3 й отримати бажаний результат. Як наслідок, клієнти зацікавлені спрощувати зовнішній і внутрішній інтерфейси. У нашій практиці із цим пов’язано 80% запитів щодо вдосконалення вже інтегрованих продуктів.
Але є зворотний бік нібито простих систем — вони складні в розробленні, що кидає додаткові професійні виклики під час їхнього вдосконалення та впровадження. Щоразу ми маємо знаходити золоту середину між можливостями, які клієнт хоче мати в продукті, та зрозумілим інтерфейсом. І коли ми додаємо функції в застосунок користувача чи кабінет банківського працівника, маємо уявляти шлях, який вони проходитимуть під час налаштування та користування. Водночас багато цікавих речей про роботу продукту ми дізнаємося від інтеграторів. Буває так, що нібито проста операція з даними виявляється складною під час перенесення в систему певного банку.
Сподобатися всім — шлях у нікуди
Створити універсальний банківський продукт неможливо — кожна установа по-своєму проводить платежі, звітує, комунікує всередині команди. Важливо враховувати й регіональні відмінності. Наприклад, в Ірландії є доволі специфічні закони, а в Африці треба більше контролювати користувачів, до того ж деякі звичні для європейського ринку функції там заборонені. Тому ми на проєкті дотримуємося принципу Lego — створюємо базову конфігурацію, яка розв’язує основні завдання сучасного банкінгу, а решту функцій нанизуємо на неї залежно від бажань, потреб і особливостей бізнесу.
Один із напрямів — модерація банківських операцій. Уявімо, ви — працівник банку і маєте перевірити та підтвердити зміни в налаштуваннях, проаналізувавши перед тим транзакції за декількома рахунками. Якщо перемикатися між 10 екранами, можна припуститися помилки, тож аби зменшити ризики, краще бачити все на одному екрані.
Користувачі полюбляють ліміти, а розробники ламають над ними голову. Передусім через роботу з великими обсягами даних і «рухомі» періоди аналізу. Припустимо, ви встановили ліміт за витратами на рік. Коли ви розраховуєтеся в інтернеті, система має щоразу проаналізувати транзакції за період, підсумувати та показати, чи ви ще в окреслених межах. Водночас треба враховувати, що більшість банків мають rolling-limit, тобто коли рік рахується від поточного моменту. І ми маємо видати результат за 5 секунд і не можемо відкласти, порахувати пізніше і через декілька годин надіслати звіт. Усе робимо швидко, безпечно, чітко.
Банківські продукти складні ще й тим, що їх не можна створювати без розуміння фінансової та суміжних сфер. Вам не потрібна сертифікація, як під час роботи з медичними ІТ-розробками, але знати базові фінансові алгоритми, регулювання цих операцій і правила опрацювання даних важливо. І виклик для розробників — це тримати баланс. Навіть якщо ви працюєте над допоміжним операційним сегментом, він має вписуватися у великий контекст усього банкінгу. Незначні зміни в одній частині системи можуть бути суттєвими для роботи інших.
Коли багатофункціональність не в плюс
Під час роботи над багатошаровими проєктами ІТ-спеціалісти мають знати про стан речей у декількох процесах одночасно. Водночас помилку можна помітити й після декількох місяців роботи над завданням.
Іноді ми стикаємося із ситуацією «гра навипередки», коли клієнти по-своєму розробляють якийсь функціонал. Це гарний спосіб пришвидшити випуск продукту та розділити сили, але трапляються непорозуміння — така функція вже є або рішення несумісне з основним продуктом, що впливає на швидкодію. Зрештою ми можемо втратити декілька місяців, щоб виявити причину.
Бувають і технічні факапи. І тут треба відмітити спокійну поведінку та культуру фідбеку в голландських компаніях. Вони проводять роботу над помилками, визначають причину та знаходять рішення, щоб цього не повторювалося. До речі, і Levi9, і BackBase народилися в Нідерландах.
Постійна реновація фінансових технологій
Банкінг — це доволі консервативна сфера. Зазвичай продукти, що стрімко масштабувалися та завоювали репутацію на ринку, зупиняються в технологічному розвитку та тримаються певного обраного напряму. Натомість ми на проєкті не стоїмо на місці, постійно пробуємо щось нове та прагнемо ділитися напрацюваннями з ринком. Ми занадто сильно любимо технології. Це запам’ятовується й клієнтам. Як наслідок, коли Microsoft шукали банківські рішення для свого хмарного середовища, вони обрали BackBase. Спершу їх зацікавила опція залучення й полегшення роботи із системою (engagement), що дає змогу в декілька дій отримати банківські послуги, як-от відкрити картку чи рахунок, брати позики. І загалом рішення видалося їм зручним, тож вони вирішили взяти його за основу і за потреби доповнювати своїми розробками. Отже, Microsoft відповідає за технічне забезпечення клієнтів засобами для cloud-банкінгу та надає інструменти для аналізу й прогнозування, а Backbase робить систему зручною, швидкою та функціональною.
Читайте також
