Hur vi, under förhållanden med trashig arkitektur och brist på Scrum-kunskaper, skapade team med flera komponenter

Hälsningar!

Jag heter Alexander och jag leder IT-utveckling på UBRD!

Under 2017 insåg vi på centrum för utveckling av IT-tjänster på UBRD att det var dags för globala förändringar, eller snarare, agil transformation. Under förhållanden med intensiv affärsutveckling och snabb tillväxt av konkurrensen på finansmarknaden är två år en imponerande period. Därför är det dags att summera projektet.

Det svåraste är att ändra sitt tänkande och gradvis förändra kulturen i organisationen, där det är vanligt att man tänker: ”Vem blir chef i det här laget?”, ”Chefen vet bättre vad vi behöver göra”, ” Vi har arbetat här i 10 år och känner våra kunder bättre.” , vi vet vad de behöver."

Agil transformation kan bara ske när människorna själva förändras.
Jag vill lyfta fram följande viktiga farhågor som hindrar människor från att förändras:

  • Rädsla för att förlora makt och "epauletter";
  • Rädsla för att bli onödig för företaget.

Efter att ha inlett omvandlingens väg valde vi de första "erfarna kaninerna" - anställda på detaljhandelsavdelningen. Det första steget var att göra om den ineffektiva IT-strukturen. Efter att ha kommit fram till ett målkoncept för strukturen började vi bilda utvecklingsteam.

Hur vi, under förhållanden med trashig arkitektur och brist på Scrum-kunskaper, skapade team med flera komponenter

Arkitekturen i vår bank, liksom i många andra, är "skräp", för att uttrycka det milt. Ett stort antal applikationer och komponenter är monolitiskt sammankopplade med DB-länk, det finns en ESB-buss, men den uppfyller inte sitt avsedda syfte. Det finns även en del ABS.

Hur vi, under förhållanden med trashig arkitektur och brist på Scrum-kunskaper, skapade team med flera komponenter

Innan man bildade Scrum-team dök frågan upp: "Vad ska teamet samlas kring?" Konceptet att det fanns en produkt i burken låg förstås i luften, men bara utom räckhåll. Efter mycket funderande bestämde vi oss för att laget skulle samlas kring en riktning eller ett segment. Till exempel "Team Credits", som utvecklar utlåning. Efter att ha bestämt oss för detta började vi ta fram en målsammansättning av roller och en uppsättning kompetenser som är nödvändiga för en effektiv utveckling av detta område. Liksom många andra företag tog vi hänsyn till alla roller utom Scrum Mastern – på den tiden var det nästan omöjligt att förklara för CIO:n vilken roll denna underbara person hade.

Som ett resultat, efter att ha förklarat behovet av att lansera utvecklingsteam, lanserade vi tre team:

  1. Lån
  2. Kort
  3. Passiv verksamhet

Med en uppsättning roller:

  1. Utvecklingschef (Tech Lead)
  2. Utvecklare
  3. Analytiker
  4. Testare

Nästa steg var att bestämma hur teamet skulle fungera. Vi genomförde agil träning för alla lagmedlemmar och satt alla i ett rum. Det fanns inga POs i lagen. Förmodligen förstår alla som har gjort en agil transformation hur svårt det är att förklara rollen som en PO för verksamheten, och ännu svårare att sätta honom bredvid teamet och ge honom auktoritet. Men vi "klev" in i dessa förändringar med vad vi hade.

Med så många ansökningar involverade i utlåningsprocesser och resten av detaljhandeln började vi fundera på vem som kan passa rätt för rollerna? En utvecklare av en teknikstack, och sedan tittar du - och du behöver en utvecklare av en annan teknikstack! Och nu har du hittat de som behövs, men den anställdes önskan är också en viktig sak, och det är ganska svårt att tvinga en person att arbeta där han inte gillar.

Efter att ha analyserat arbetet med utlåningsprocessen och långa samtal med kollegor hittade vi äntligen en mellanväg! Så här uppstod tre utvecklingsteam.

Hur vi, under förhållanden med trashig arkitektur och brist på Scrum-kunskaper, skapade team med flera komponenter

Vad händer nu?

Folk började delas upp i de som vill förändras och de som inte vill. Alla är vana vid att arbeta under villkoren "de gav mig ett problem, jag gjorde det, lämna mig ifred", men lagarbete innebär inte detta. Men vi löste även detta problem. Totalt slutade 8 av 150 personer under förändringarna!

Sedan började det roliga. Våra tvärkomponentteam började utveckla sig själva. Till exempel finns det en uppgift för vilken du behöver ha kompetens inom området CRM-utvecklare. Han är med i laget, men han är ensam. Det finns också en Oracle-utvecklare. Vad ska man göra om man behöver lösa 2 eller 3 uppgifter i CRM? Lär varandra! Killarna började överföra sina kompetenser till varandra, och teamet utökade sina kapaciteter och minimerade beroendet av en stark specialist (förresten, i vilket företag som helst finns supermän som vet allt och inte berättar för någon).

Idag har vi samlat 13 utvecklingsteam för alla områden inom affärs- och tjänsteutveckling. Vi fortsätter vår agila transformation och når en ny nivå. Detta kommer att kräva nya ändringar. Vi kommer att designa om team och arkitektur och utveckla kompetens.

Vårt slutmål: snabbt svara på produktförändringar, snabbt få ut nya funktioner på marknaden och förbättra bankens tjänster!

Källa: will.com

Lägg en kommentar