Hoe we, in de omstandigheden van trash-architectuur en een gebrek aan vaardigheden in Scrum, cross-component teams creëerden

Hey there!

Mijn naam is Alexander en ik leid IT-ontwikkeling bij UBRD!

In 2017 realiseerden wij, het centrum voor de ontwikkeling van informatietechnologiediensten bij UBRD, dat de tijd was gekomen voor mondiale veranderingen, of beter gezegd, flexibele transformatie. In omstandigheden van intensieve bedrijfsontwikkeling en snelle groei van de concurrentie op de financiële markt is twee jaar een indrukwekkende periode. Daarom is het tijd om het project samen te vatten.

Het moeilijkste is om je manier van denken te veranderen en geleidelijk de cultuur in de organisatie te veranderen, waarbij het gebruikelijk is om te denken: “Wie wordt de baas in dit team?”, “De baas weet beter wat we moeten doen”, “ Wij werken hier al 10 jaar en kennen onze klanten beter.” , wij weten wat ze nodig hebben."

Agile transformatie kan alleen plaatsvinden als de mensen zelf veranderen.
Ik zou de volgende belangrijke angsten willen benadrukken die mensen ervan weerhouden te veranderen:

  • Angst om macht te verliezen en “epauletten”;
  • Angst om onnodig te worden voor het bedrijf.

Nadat we het pad van transformatie waren ingeslagen, selecteerden we de eerste 'ervaren konijnen' - medewerkers van de detailhandelsafdeling. De eerste stap was het opnieuw ontwerpen van de inefficiënte IT-structuur. Nadat we een doelconcept voor de structuur hadden bedacht, begonnen we ontwikkelingsteams te vormen.

Hoe we, in de omstandigheden van trash-architectuur en een gebrek aan vaardigheden in Scrum, cross-component teams creëerden

De architectuur van onze bank is, net als die van vele andere, op zijn zachtst gezegd ‘rommel’. Een groot aantal applicaties en componenten zijn monolithisch met elkaar verbonden via DB-link, er is een ESB-bus, maar deze voldoet niet aan het beoogde doel. Er zijn ook enkele ABS-systemen.

Hoe we, in de omstandigheden van trash-architectuur en een gebrek aan vaardigheden in Scrum, cross-component teams creëerden

Voordat Scrum-teams werden gevormd, rees de vraag: “Waar moet het team omheen worden samengesteld?” Het concept dat er een product in het blik zat, hing natuurlijk in de lucht, maar net buiten bereik. Na lang nadenken besloten we dat het team zich rond een richting of segment moest verzamelen. Bijvoorbeeld ‘Team Credits’, dat leningen ontwikkelt. Nadat we dit hadden besloten, begonnen we met het bedenken van een beoogde samenstelling van rollen en een reeks competenties die nodig zijn voor de effectieve ontwikkeling van dit gebied. Net als veel andere bedrijven hielden we rekening met alle rollen behalve de Scrum Master - in die tijd was het bijna onmogelijk om aan de CIO uit te leggen wat de rol van deze geweldige persoon was.

Als gevolg hiervan hebben we, nadat we de noodzaak hadden uitgelegd om ontwikkelingsteams te lanceren, drie teams gelanceerd:

  1. Leningen
  2. Kaarten
  3. Passieve operaties

Met een reeks rollen:

  1. Ontwikkelingsmanager (Tech Lead)
  2. Ontwikkelaar
  3. алитик
  4. Tester

De volgende stap was om te bepalen hoe het team zou werken. We hebben agile trainingen gegeven voor alle teamleden en iedereen in één ruimte gezet. Er waren geen PO's in de teams. Waarschijnlijk begrijpt iedereen die een agile transformatie heeft doorgevoerd hoe moeilijk het is om de rol van een PO aan het bedrijf uit te leggen, en nog moeilijker om hem naast het team te zetten en hem autoriteit te geven. Maar we ‘stapten’ in deze veranderingen met wat we hadden.

Omdat er zoveel applicaties betrokken waren bij kredietverleningsprocessen en de rest van de detailhandel, begonnen we na te denken: wie zou de juiste persoon zijn voor deze rollen? Een ontwikkelaar van één technologiestapel, en dan kijk je - en je hebt een ontwikkelaar van een andere technologiestapel nodig! En nu heb je degenen gevonden die nodig zijn, maar de wens van de werknemer is ook belangrijk, en het is best moeilijk om iemand te dwingen te werken waar hij niet wil.

Na analyse van het werk van het kredietverleningsbedrijfsproces en lange gesprekken met collega's, hebben we eindelijk een middenweg gevonden! Zo verschenen er drie ontwikkelingsteams.

Hoe we, in de omstandigheden van trash-architectuur en een gebrek aan vaardigheden in Scrum, cross-component teams creëerden

Wat is het volgende?

Mensen begonnen zich te verdelen in degenen die willen veranderen en degenen die dat niet willen. Iedereen is gewend te werken onder de omstandigheden van ‘ze gaven me een probleem, ik heb het gedaan, laat me met rust’, maar teamwerk impliceert dit niet. Maar ook dit probleem hebben we opgelost. In totaal stopten 8 van de 150 mensen tijdens de veranderingen!

Toen begon het plezier. Onze cross-component teams begonnen zichzelf te ontwikkelen. Zo is er een taak waarvoor je vaardigheden moet hebben op het gebied van CRM-ontwikkelaar. Hij zit in het team, maar hij is alleen. Er is ook een Oracle-ontwikkelaar. Wat moet u doen als u 2 of 3 taken in CRM moet oplossen? Leer elkaar! De jongens begonnen hun competenties aan elkaar over te dragen en het team breidde zijn capaciteiten uit, waardoor de afhankelijkheid van één sterke specialist tot een minimum werd beperkt (trouwens, in elk bedrijf zijn er supermannen die alles weten en het aan niemand vertellen).

Vandaag hebben we 13 ontwikkelingsteams samengesteld voor alle gebieden van bedrijfs- en serviceontwikkeling. We zetten onze agile transformatie voort en bereiken een nieuw niveau. Hiervoor zijn nieuwe veranderingen nodig. We gaan teams en architectuur herontwerpen en competenties ontwikkelen.

Ons uiteindelijke doel: snel inspelen op productwijzigingen, snel nieuwe functionaliteiten op de markt brengen en de dienstverlening van de bank verbeteren!

Bron: www.habr.com

Voeg een reactie