Hvordan vi, under betingelserne med trashy arkitektur og mangel på Scrum-færdigheder, skabte tværkomponenthold

Hi!

Mit navn er Alexander, og jeg leder IT-udvikling hos UBRD!

I 2017 indså vi i centret for udvikling af informationsteknologitjenester på UBRD, at tiden var inde til globale forandringer, eller rettere sagt, agil transformation. Under forhold med intensiv forretningsudvikling og hurtig vækst i konkurrencen på det finansielle marked er to år en imponerende periode. Derfor er det tid til at opsummere projektet.

Det sværeste er at ændre sin tankegang og gradvist ændre kulturen i organisationen, hvor det er almindeligt at tænke: "Hvem bliver chefen i dette team?", "Chefen ved bedre, hvad vi skal gøre," " Vi har arbejdet her i 10 år og kender vores kunder bedre." , vi ved, hvad de har brug for."

Agil transformation kan kun ske, når menneskerne selv ændrer sig.
Jeg vil fremhæve følgende centrale frygt, der forhindrer folk i at ændre sig:

  • Frygt for at miste magt og "epauletter";
  • Frygt for at blive unødvendig for virksomheden.

Efter at være gået ind på transformationens vej valgte vi de første "erfarne kaniner" - ansatte i detailafdelingen. Det første skridt var at redesigne den ineffektive it-struktur. Efter at have fundet frem til et målkoncept for strukturen, begyndte vi at danne udviklingsteams.

Hvordan vi, under betingelserne med trashy arkitektur og mangel på Scrum-færdigheder, skabte tværkomponenthold

Arkitekturen i vores bank er, som i mange andre, mildest talt "skrald". Et stort antal applikationer og komponenter er monolitisk forbundet med DB-link, der er en ESB-bus, men den opfylder ikke det tilsigtede formål. Der er også nogle ABS.

Hvordan vi, under betingelserne med trashy arkitektur og mangel på Scrum-færdigheder, skabte tværkomponenthold

Inden der blev dannet Scrum-teams, opstod spørgsmålet: "Hvad skal teamet samles omkring?" Konceptet om, at der var et produkt i dåsen, var selvfølgelig i luften, men lige uden for rækkevidde. Efter meget overvejelse besluttede vi, at holdet skulle samles om en retning eller et segment. For eksempel "Team Credits", som udvikler udlån. Efter at have besluttet dette, begyndte vi at komme med en målsammensætning af roller og et sæt af kompetencer, der er nødvendige for en effektiv udvikling af dette område. Ligesom mange andre virksomheder tog vi hensyn til alle rollerne undtagen Scrum Masteren – på det tidspunkt var det næsten umuligt at forklare CIO'en, hvad denne vidunderlige persons rolle var.

Som et resultat, efter at have forklaret behovet for at lancere udviklingsteams, lancerede vi tre teams:

  1. kreditter
  2. Cards
  3. Passive operationer

Med et sæt roller:

  1. Udviklingschef (Tech Lead)
  2. udvikler
  3. analytiker
  4. Tester

Næste skridt var at bestemme, hvordan teamet ville arbejde. Vi gennemførte agil træning for alle teammedlemmer og sad alle i ét rum. Der var ingen PO'er i holdene. Sandsynligvis forstår alle, der har foretaget en agil transformation, hvor svært det er at forklare en PO's rolle til virksomheden, og endnu sværere at sætte ham ved siden af ​​holdet og give ham autoritet. Men vi "trådte" ind i disse ændringer med det, vi havde.

Med så mange ansøgninger involveret i udlånsprocesser og resten af ​​detailforretningen, begyndte vi at tænke, hvem der kunne være den rigtige til rollerne? En udvikler af en teknologistack, og så ser du - og du har brug for en udvikler af en anden teknologistack! Og nu har du fundet dem, der er nødvendige, men medarbejderens ønske er også en vigtig ting, og det er ret svært at tvinge en person til at arbejde, hvor han ikke kan lide.

Efter at have analyseret arbejdet med udlånsforretningsprocessen og lange samtaler med kolleger, fandt vi endelig en mellemvej! Sådan fremstod tre udviklingsteams.

Hvordan vi, under betingelserne med trashy arkitektur og mangel på Scrum-færdigheder, skabte tværkomponenthold

Hvad er det næste?

Folk begyndte at dele sig i dem, der ønsker at ændre sig, og dem, der ikke gør. Alle er vant til at arbejde under betingelserne "de gav mig et problem, jeg gjorde det, lad mig være i fred", men teamarbejde indebærer ikke dette. Men vi løste også dette problem. I alt sagde 8 ud af 150 personer op under ændringerne!

Så begyndte det sjove. Vores tværkomponenthold begyndte at udvikle sig selv. For eksempel er der en opgave, som du skal have kompetencer inden for CRM-udvikler. Han er på holdet, men han er alene. Der er også en Oracle-udvikler. Hvad skal du gøre, hvis du skal løse 2 eller 3 opgaver i CRM? Lær hinanden! Fyrene begyndte at overføre deres kompetencer til hinanden, og holdet udvidede sine evner og minimerer afhængigheden af ​​en stærk specialist (forresten, i enhver virksomhed er der supermænd, der ved alt og ikke fortæller nogen).

I dag har vi samlet 13 udviklingsteams til alle områder af forretnings- og serviceudvikling. Vi fortsætter vores agile transformation og når et nyt niveau. Dette vil kræve nye ændringer. Vi vil redesigne teams og arkitektur og udvikle kompetencer.

Vores endelige mål: hurtigt reagere på produktændringer, hurtigt bringe nye funktioner til markedet og forbedre bankens tjenester!

Kilde: www.habr.com

Tilføj en kommentar