🚴🏻 💑 ➗ Du monolithe au système distribué 🤡 ♍️ ♊️

La croissance constante de la concurrence entre les Banques oblige à s'adapter aux différentes catégories de Clients. Ainsi, il est plus facile d'aller sur le site et de demander un produit bancaire en ligne, tandis que d'autres ont l'habitude de choisir directement de nouveaux produits et services lors d'une communication en direct avec un représentant de banque. En septembre 2019 Home Credit Bank a décidé de lancer un nouveau processus pour le Client, dont le principal objectif était de maintenir le contact «Client - Opérateur bancaire» et de refuser la connexion physique de l'opérateur au bureau de la Banque ou au guichet du centre commercial.

La date de lancement du projet pilote a été fixée début décembre 2019. Pour sa mise en œuvre, dès que possible, il a été nécessaire de développer un système avec des fonctionnalités d'enregistrement d'une carte de débit personnelle et non personnelle pour les clients nouveaux et existants de la Banque.

En route vers une nouvelle plateforme

Ils ont commencé à regarder vers la solution de comprimés. La mise en œuvre d'un nouveau processus sur une tablette basée sur l'architecture du système de front office actuel de la Banque pour que les opérateurs travaillent avec le client semblait irrationnelle en raison d'une pile technologique obsolète, comme Le front office actuel est une application web monolithique écrite il y a 8 ans dans Silverlight. Les tentatives de travailler avec la façade actuelle sur la tablette ont échoué en raison de la surcharge de l'interface utilisateur de l'application et du manque de disposition adaptative. De plus, le manque de prise en charge de Silverlight par Microsoft laissait subtilement entendre que le cycle de vie de notre application actuelle touchait à sa fin et qu'il y avait un moment de refonte radicale et de transition vers de nouvelles technologies. Nous sommes arrivés à la décision de mettre en œuvre une architecture de microservices. Pourquoi fallait-il abandonner le monolithe? tout d'abord,en raison de l'évolutivité de la solution, de la tolérance aux pannes globale améliorée et des mises à jour indépendantes des composants. Deuxièmement, au sein de la Banque, la tendance à répartir les fonctionnalités entre les équipes produits et l'approche microservice dans ce cas donne une plus grande flexibilité et indépendance des équipes.Lors des premières étapes, les domaines suivants (microservices) ont été attribués au projet pilote: utilisateur, client, carte de débit et incident. Pour créer la partie arrière de l'application, ils ont utilisé la plate-forme .Net Core 2.2 (récemment passée à 3.0), empruntant des éléments de la logique métier à l'héritage du système. Il a été décidé de construire la partie avant en utilisant React.

UI / UX

Parallèlement à la définition de l'architecture, l'interface d'application et la logique métier du processus ont été discutées. Il était nécessaire de déterminer comment l'Opérateur interagira avec le Client, quel ensemble de documents est nécessaire, quelles informations l'Opérateur a besoin à chaque étape de vente spécifique. L'objectif était de simplifier le processus commercial actuel, plutôt que de simplement copier des fonctionnalités sur une nouvelle plateforme. Ainsi, dans la nouvelle décision, le nombre de champs a été réduit lors de l'ouverture d'une demande de carte de débit et le questionnaire pour le client a été exclu (collecte d'informations sur la façon dont le client a découvert Home Credit Bank). Une fonction d'accès rapide à l'enregistrement des produits de débit prioritaires a été ajoutée à la page principale avec les données client. Et au stade de l'approbation, les demandes ont affiché des informations détaillées sur les tarifs et les conditions du produit, ce qui a également aidé l'opérateur.

Depuis 8 ans sur un environnement productif, la page d'accueil de la première page avec les données du client et la fonctionnalité de connexion des produits et services est devenue trop surchargée en raison des icônes et des champs sans fin.

Je voulais ajouter "air" à l'interface. Ici, je devais établir des priorités, déterminer les fonctionnalités dont les opérateurs avaient d'abord besoin pour accéder à la page principale, qui peuvent être affichées sur le panneau latéral et qui peuvent être abandonnées en raison de l'inutilité (oui, oui! De tels champs ont été trouvés). À la suite du travail fructueux de l'équipe avec le concepteur, les premières vignettes de la page avec les données du client et la page avec les étapes de la demande de carte de débit ont été conçues.

Documentation

La base de connaissances pour le front-office actuel «vit» dans Word avec la co-édition dans SharePoint. Le nouveau projet a décidé de piloter un nouveau processus de documentation dans Confluence en collaboration avec Swagger pour l'auto-documentation. Notre chemin de transition, les avantages et les inconvénients de la solution sélectionnée seront décrits dans un article séparé. Je peux seulement dire que le sujet du choix d'un outil de gestion des exigences est toujours ouvert, nous sommes à la recherche de la solution optimale pour maintenir la documentation à jour avec un investissement minimum de ressources.

Prenons la route!

En conséquence, notre feuille de route sur la façon de lancer le pilote convoité ressemblait à ceci.

Le système d'interaction d'équipe intégré a pu rattraper l'échéance du pilote. Au début du projet, l'équipe a dû abandonner la cascade et mettre le pied sur le sentier Agile. C'était un Agile adapté par notre équipe. Nous avons parallélisé: les développeurs ont commencé au stade des accords avec l'équipe sur la mise en œuvre, ce qui se reflète généralement dans les exigences avant le début du développement et convenu avec tous les participants au processus. Des questions ouvertes ont été discutées lors des réunions. Les décisions ont été prises par une équipe ensemble. À tout moment, chaque membre de l'équipe pouvait parler de l'état d'avancement du projet, tout le monde se sentait impliqué dans le processus et attendait avec impatience le pilote en fonction des résultats de notre travail.

Pilote

Le pilote a eu lieu dans l'un des plus grands centres commerciaux de Moscou à la veille du nouvel an. Pour le projet pilote, de nouveaux spécialistes des ventes ont été embauchés qui ne connaissaient pas les produits bancaires et n'avaient pas auparavant travaillé avec notre système de front-office actuel. Les résultats du pilote ont montré que les nouveaux utilisateurs trouvaient facilement la séquence d'actions nécessaire dans notre nouvelle application, ce qui signifiait qu'un tel programme pouvait être lancé sur d'autres sites, en recrutant de nouveaux spécialistes avec des exigences minimales.

Dans la nouvelle application, nous avons cherché une mise à jour constante des fonctionnalités du produit, en fonction des besoins des opérateurs et des clients. Ainsi, au cours de la première semaine de lancement, 25 petites améliorations ont été publiées sur la base des résultats du pilote. Par exemple, dans le dossier de documents lors de la conclusion du contrat, un formulaire imprimé avec les tarifs des produits a été ajouté, car La plupart des clients, après avoir consulté les tarifs sur la tablette de l'opérateur, ont exprimé le souhait de recevoir les tarifs imprimés «en main».

L'activité commerciale via la nouvelle plateforme a été suivie en ligne via un rapport sur Graphana et s'est réjouie à chaque nouvelle signature du contrat.

Erreurs

Il y a un problème dans le front-office actuel lors de l'analyse des erreurs de produit - il n'est pas toujours possible de restaurer la séquence d'actions de l'opérateur, en particulier dans les cas où il existe des transitions imprévisibles entre les écrans d'application (identifiés ex post) qui ne sont pas intégrés dans la logique métier du processus. L'appel à l'utilisateur n'est généralement pas concluant, car en raison du flux important de clients, il est impossible de restaurer la séquence d'actions effectuées dans l'application avec un client spécifique à un moment donné. Le nouveau système voulait également résoudre ces problèmes. Journalisation de bout en bout de tous les microservices dans le cadre de la Session du Client et de l'Opérateur, enregistrement supplémentaire dans le journal des SMS pour chaque action de l'Opérateur (création d'un nouveau Client, signature d'un accord,sms-informing connecté) et une capture plein écran ont aidé à restaurer rapidement l'image du processus métier, accélérant l'analyse des erreurs de produit lors de la visualisation des journaux dans GrayLog.

L'objectif du projet pilote n'était pas seulement de mettre en œuvre une solution pour tablette, mais également de jeter les bases de notre future plate-forme du système de front office Home Credit Bank. Maintenant, nous continuons de nous améliorer. Nous travaillons sur l'ajout d'un nouveau module «Crédits» pour travailler avec les produits de crédit de la Banque. Et également dans le processus de recherche sur l'utilisation des nouvelles technologies (graphql, dont le but n'est pas de générer des données supplémentaires de l'arrière vers l'avant; camunda pour une configuration flexible du processus métier; Prometheus pour la collecte de métriques commerciales pour la création de rapports).

À l'avenir, nous verrons l'avancement de la solution de tablette en ajoutant la fonctionnalité de vente de divers types de produits bancaires. Maintenant, la priorité est de créer le processus d'émission d'une carte de crédit bancaire. De plus, élargir le domaine d'application de la tablette aux magasins d'électronique et aux bureaux de représentation des fonds de pension.