Salut
Je m'appelle Alexander et je dirige le développement informatique chez UBRD!
En 2017, nous, au Centre de développement des services de technologie de l'information de l'UBRD, avons réalisé que le temps était venu pour des changements globaux, ou plutôt des transformations agiles. Dans des conditions de développement intensif des affaires et de croissance rapide de la concurrence sur le marché financier, deux ans est une période impressionnante. Il est donc temps de faire le point sur le projet.
La chose la plus difficile est de changer votre façon de penser et progressivement la culture de l'organisation, où il est de coutume de raisonner: «qui sera le patron de cette équipe?», «Le patron sait mieux ce que nous devons faire», «nous travaillons ici depuis 10 ans et savons mieux que nos clients , nous savons ce dont ils ont besoin. "
La transformation agile ne peut se produire que lorsque les gens eux-mêmes y 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 avoir entamé un chemin de transformation, nous avons sélectionné les premiers «lapins expérimentés» - employés du secteur de la vente au détail. La première étape a été de repenser la structure informatique inefficace. Après avoir défini le concept cible de la structure, nous avons commencé à former des équipes de développement.
L'architecture de notre banque, comme dans beaucoup d'autres, pour le dire légèrement «thrash». Un grand nombre d'applications et de composants, liés de manière transparente par une liaison DB, ont un bus ESB, mais il ne remplit pas sa fonction. Il existe également plusieurs ABS.
Avant de former des équipes de mêlée, la question s'est posée: "Et autour de quoi l'équipe devrait-elle être constituée?". L'idée qu'il y a un produit en banque, bien sûr, était dans l'air, mais à une distance inaccessible. Après de longues délibérations, ils ont décidé que l'équipe devrait être réunie autour d'une direction ou d'un segment. Par exemple, «Team Loans», qui développe les prêts. Après avoir décidé de cela, nous avons commencé à proposer la composition cible des rôles et un ensemble de compétences nécessaires pour le développement efficace de ce domaine. Comme beaucoup d'autres sociétés, nous avons pris en compte tous les rôles à l'exception de Scrum Master - à l'époque, il était presque impossible d'expliquer au CIO quel était le rôle de cette merveilleuse personne.
En conséquence, après avoir clarifié la nécessité de lancer des équipes de développement, nous avons lancé trois équipes:
- Prêts
- Les cartes
- Opérations passives
Avec un ensemble de rôles:
- Responsable développement (Tech Lead)
- Développeur
- Analyste
- Testeur
L'étape suivante consistait à déterminer le fonctionnement de l'équipe. Nous avons organisé une formation agile pour tous les membres de l'équipe, réunissant tout le monde dans une seule pièce. PO n'était pas dans les équipes. Probablement, tous ceux qui ont fait la transformation agile comprennent à quel point il est difficile d'expliquer le rôle de l'OP aux entreprises, et il est encore plus difficile de le mettre à côté de l'équipe et de donner de l'autorité. Mais nous sommes «intervenus» dans ces changements avec ce qui était.
Étant donné qu'un grand nombre de demandes ont été impliquées dans les processus de prêt et dans d'autres domaines du commerce de détail, nous avons commencé à penser, qui peut assumer les rôles? Le développeur d'une pile technologique, et là vous regardez - et vous avez besoin d'un développeur d'une autre pile technologique! Et donc vous avez trouvé ceux qui sont nécessaires, mais le désir de l'employé est également une chose importante, et faire en sorte qu'une personne travaille là où elle n'aime pas est assez difficile.
Après avoir analysé le travail du processus de prêt aux entreprises et de longues conversations avec des collègues, nous avons encore trouvé un terrain d'entente! Il y avait donc trois équipes de développement.
Et ensuite?
Les gens ont commencé à se diviser entre ceux qui veulent changer et ceux qui ne veulent pas. Tout le monde est habitué à travailler dans des conditions de «ils m'ont donné une tâche, je l'ai fait, laissez-moi tranquille», et le travail d'équipe n'implique pas cela. Mais nous avons résolu ce problème. Au total, 8 personnes sur 150 ont démissionné lors des changements!
Puis le plaisir a commencé. Nos équipes multi-composants ont commencé à se développer. Par exemple, il existe une tâche pour laquelle vous devez avoir des compétences dans le domaine d'un développeur CRM. Il est dans 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? Enseignez-vous les uns les autres! Les gars ont commencé à transférer leurs compétences les uns aux autres, et l'équipe a élargi leurs capacités, minimisant la dépendance à l'égard d'un spécialiste solide (au fait, dans toute entreprise, il y a des surhommes qui savent tout et ne le disent à personne).
Aujourd'hui, nous avons rassemblé 13 équipes de développement pour tous les domaines du développement commercial et des services. Nous continuons la transformation agile et passons à un nouveau niveau. Cela nécessitera de nouveaux changements. Nous repenserons les équipes et l'architecture, nous développerons les compétences.
Notre objectif final: répondre rapidement aux évolutions du produit, introduire rapidement de nouvelles fonctionnalités sur le marché et améliorer les services de la banque!