Hvordan, under forholdene med trashy arkitektur og mangel på Scrum-ferdigheter, skapte vi tverrkomponentteam

Hei!

Jeg heter Alexander, og jeg leder IT-utvikling hos UBRD!

I 2017 innså vi i senteret for utvikling av informasjonsteknologitjenester ved UBRD at tiden var inne for globale endringer, eller rettere sagt, smidig transformasjon. Under forhold med intensiv forretningsutvikling og rask vekst i konkurransen i finansmarkedet er to år en imponerende periode. Derfor er det på tide å oppsummere prosjektet.

Det vanskeligste er å endre tankegangen og gradvis endre kulturen i organisasjonen, hvor det er vanlig å tenke: «Hvem blir sjefen i dette teamet?», «Sjefen vet bedre hva vi må gjøre», « Vi har jobbet her i 10 år og kjenner kundene våre bedre." , vi vet hva de trenger."

Agil transformasjon kan bare skje når menneskene selv forandrer seg.
Jeg vil fremheve følgende viktige frykter som hindrer folk i å endre seg:

  • Frykt for å miste kraft og "epauletter";
  • Frykt for å bli unødvendig for selskapet.

Etter å ha begynt på transformasjonsveien, valgte vi de første "erfarne kaninene" - ansatte i detaljhandelsavdelingen. Det første trinnet var å redesigne den ineffektive IT-strukturen. Etter å ha kommet opp med et målkonsept for strukturen, begynte vi å danne utviklingsteam.

Hvordan, under forholdene med trashy arkitektur og mangel på Scrum-ferdigheter, skapte vi tverrkomponentteam

Arkitekturen i banken vår, som i mange andre, er «søppel» for å si det mildt. Et stort antall applikasjoner og komponenter er monolittisk sammenkoblet med DB-kobling, det er en ESB-buss, men den oppfyller ikke det tiltenkte formålet. Det er også noen ABS.

Hvordan, under forholdene med trashy arkitektur og mangel på Scrum-ferdigheter, skapte vi tverrkomponentteam

Før de dannet Scrum-team, oppsto spørsmålet: "Hva skal teamet settes sammen rundt?" Konseptet om at det var et produkt i boksen, var selvfølgelig i luften, men bare utenfor rekkevidde. Etter mye omtanke bestemte vi oss for at teamet skulle samles rundt en retning eller et segment. For eksempel "Team Credits", som utvikler utlån. Etter å ha bestemt oss for dette, begynte vi å komme opp med en målsammensetning av roller og et sett med kompetanse som er nødvendig for effektiv utvikling av dette området. Som mange andre selskaper tok vi hensyn til alle rollene bortsett fra Scrum Master – på den tiden var det nesten umulig å forklare CIOen hvilken rolle denne fantastiske personen var.

Som et resultat, etter å ha forklart behovet for å lansere utviklingsteam, lanserte vi tre team:

  1. Lån
  2. Карты
  3. Passive operasjoner

Med et sett med roller:

  1. Utviklingssjef (Tech Lead)
  2. Utvikler
  3. Analytiker
  4. Tester

Det neste trinnet var å finne ut hvordan teamet skulle fungere. Vi gjennomførte smidig trening for alle teammedlemmer og satt alle i ett rom. Det var ingen PO-er i lagene. Sannsynligvis forstår alle som har gjort en smidig transformasjon hvor vanskelig det er å forklare rollen til en PO til virksomheten, og enda vanskeligere å sette ham ved siden av teamet og gi ham autoritet. Men vi "tråkket" inn i disse endringene med det vi hadde.

Med så mange søknader involvert i utlånsprosesser og resten av detaljhandelen, begynte vi å tenke, hvem kan være den rette for rollene? En utvikler av en teknologistabel, og så ser du - og du trenger en utvikler av en annen teknologistabel! Og nå har du funnet de som trengs, men ønsket til den ansatte er også en viktig ting, og det er ganske vanskelig å tvinge en person til å jobbe der han ikke liker.

Etter å ha analysert arbeidet med utlånsforretningsprosessen og lange samtaler med kolleger, fant vi endelig en mellomting! Slik oppsto tre utviklingsteam.

Hvordan, under forholdene med trashy arkitektur og mangel på Scrum-ferdigheter, skapte vi tverrkomponentteam

Hva blir det neste?

Folk begynte å dele seg i de som ønsker å endre seg og de som ikke gjør det. Alle er vant til å jobbe under forholdene «de ga meg et problem, jeg gjorde det, la meg være i fred», men teamarbeid innebærer ikke dette. Men vi løste også dette problemet. Totalt sluttet 8 av 150 personer under endringene!

Så begynte moroa. Våre tverrkomponentteam begynte å utvikle seg selv. For eksempel er det en oppgave som du må ha ferdigheter innen CRM-utvikler. Han er med på laget, men han er alene. Det er også en Oracle-utvikler. Hva gjør du hvis du trenger å løse 2 eller 3 oppgaver i CRM? Lær hverandre! Gutta begynte å overføre sin kompetanse til hverandre, og teamet utvidet sine evner, og minimerte avhengigheten av en sterk spesialist (forresten, i ethvert selskap er det supermenn som vet alt og ikke forteller noen).

I dag har vi satt sammen 13 utviklingsteam for alle områder innen forretnings- og tjenesteutvikling. Vi fortsetter vår smidige transformasjon og når et nytt nivå. Dette vil kreve nye endringer. Vi skal redesigne team og arkitektur, og utvikle kompetanse.

Vårt endelige mål: raskt svare på produktendringer, raskt bringe nye funksjoner til markedet og forbedre bankens tjenester!

Kilde: www.habr.com

Legg til en kommentar