Salut!
Je m'appelle Alexander et je dirige le développement informatique à l'UBRD !
En 2017, nous, au centre de développement des services informatiques de l'UBRD, avons réalisé que le temps était venu de changements globaux, ou plutôt de transformation agile. Dans des conditions de développement intensif des affaires et de croissance rapide de la concurrence sur le marché financier, deux ans constituent une période impressionnante. Il est donc temps de résumer le projet.
Le plus difficile est de changer de façon de penser et de changer progressivement la culture de l'organisation, où il est courant de penser : « Qui sera le patron dans cette équipe ? », « Le patron sait mieux ce que nous devons faire », « Nous travaillons ici depuis 10 ans et connaissons mieux nos clients. " , nous savons ce dont ils ont besoin. "
La transformation agile ne peut se produire que lorsque les personnes elles-mêmes changent.
Je voudrais souligner les principales craintes suivantes qui empêchent les gens de changer :
- Peur de perdre le pouvoir et les « épaulettes » ;
- Peur de devenir inutile pour l’entreprise.
Après nous être engagés sur la voie de la transformation, nous avons sélectionné les premiers « lapins expérimentés » - les employés du rayon vente au détail. La première étape consistait à repenser la structure informatique inefficace. Après avoir défini un concept cible pour la structure, nous avons commencé à constituer des équipes de développement.
L’architecture de notre banque, comme celle de beaucoup d’autres, est « poubelle », c’est le moins qu’on puisse dire. Un grand nombre d'applications et de composants sont interconnectés de manière monolithique par liaison DB, il existe un bus ESB, mais il ne remplit pas son objectif. Il y a aussi des ABS.
Avant de constituer les équipes Scrum, la question s’est posée : « Autour de quoi l’équipe doit-elle être constituée ? » L’idée selon laquelle il y avait un produit dans la canette était bien sûr dans l’air, mais tout simplement hors de portée. Après mûre réflexion, nous avons décidé que l'équipe devait être rassemblée autour d'une direction ou d'un segment. Par exemple, « Team Credits », qui développe des prêts. Après avoir décidé de cela, nous avons commencé à proposer une composition cible de rôles et un ensemble de compétences nécessaires au développement efficace de ce domaine. Comme beaucoup d'autres entreprises, nous avons pris en compte tous les rôles à l'exception du Scrum Master - à cette époque, il était presque impossible d'expliquer au CIO quel était le rôle de cette merveilleuse personne.
De ce fait, après avoir expliqué la nécessité de lancer des équipes de développement, nous avons lancé trois équipes :
- Prêts
- Cartes
- Opérations passives
Avec un ensemble de rôles :
- Responsable du développement (Tech Lead)
- Promoteur
- Analyste
- Testeur
L’étape suivante consistait à déterminer comment l’équipe fonctionnerait. Nous avons organisé une formation agile pour tous les membres de l'équipe et avons assis tout le monde dans une seule pièce. Il n'y avait aucun PO dans les équipes. Tous ceux qui ont réalisé une transformation agile comprennent probablement à quel point il est difficile d'expliquer le rôle d'un PO à l'entreprise, et encore plus difficile de le faire asseoir à côté de l'équipe et de lui donner de l'autorité. Mais nous nous sommes « lancés » dans ces changements avec ce dont nous disposions.
Avec autant d’applications impliquées dans les processus de prêt et dans le reste du commerce de détail, nous avons commencé à réfléchir : qui pourrait être la bonne personne pour ces postes ? Un développeur d'une pile technologique, et puis vous regardez - et vous avez besoin d'un développeur d'une autre pile technologique ! Et maintenant, vous avez trouvé ceux dont vous avez besoin, mais le désir de l'employé est aussi une chose importante, et il est assez difficile de forcer une personne à travailler là où elle n'aime pas.
Après avoir analysé le fonctionnement du processus commercial de prêt et de longues conversations avec des collègues, nous avons finalement trouvé un terrain d'entente ! C'est ainsi qu'apparaissent trois équipes de développement.
Quelle est la prochaine?
Les gens ont commencé à se diviser entre ceux qui veulent changer et ceux qui ne le veulent pas. Tout le monde est habitué à travailler dans des conditions de « ils m'ont posé un problème, je l'ai fait, laissez-moi tranquille », mais le travail en équipe n'implique pas cela. Mais nous avons également résolu ce problème. Au total, 8 personnes sur 150 ont démissionné lors des changements !
Puis la fête a commencé. Nos équipes inter-composantes ont commencé à se développer. Par exemple, il existe une tâche pour laquelle vous devez avoir des compétences dans le domaine du développeur CRM. Il fait partie de l'équipe, mais il est seul. Il existe également un développeur Oracle. Que faire si vous devez résoudre 2 ou 3 tâches dans CRM ? Apprenez-vous les uns les autres ! Les gars ont commencé à se transférer leurs compétences et l'équipe a élargi ses capacités, minimisant la dépendance à l'égard d'un spécialiste fort (en passant, dans toute entreprise, il y a des surhommes qui savent tout et ne le disent à personne).
Aujourd'hui, nous avons réuni 13 équipes de développement pour tous les domaines du développement commercial et des services. Nous poursuivons notre transformation agile et atteignons un nouveau niveau. Cela nécessitera de nouveaux changements. Nous allons repenser les équipes et l'architecture, et développer les compétences.
Notre objectif final : répondre rapidement aux évolutions des produits, mettre rapidement de nouvelles fonctionnalités sur le marché et améliorer les services de la banque !
Source: habr.com