Kako smo v razmerah trashy arhitekture in pomanjkanja Scrum veščin ustvarili večkomponentne ekipe

Lep pozdrav!

Moje ime je Alexander in vodim IT razvoj pri UBRD!

Leta 2017 smo v Centru za razvoj storitev informacijske tehnologije UBRD ugotovili, da je prišel čas za globalne spremembe oziroma agilno transformacijo. V razmerah intenzivnega razvoja poslovanja in hitre rasti konkurence na finančnem trgu sta dve leti impresivno obdobje. Zato je čas, da povzamemo projekt.

Najtežje je spremeniti svoje razmišljanje in postopoma spremeniti kulturo v organizaciji, kjer je običajno razmišljanje: “Kdo bo šef v tej ekipi?”, “Šef bolje ve, kaj moramo narediti,” “ Tukaj delamo že 10 let in bolje poznamo svoje stranke.” , vemo, kaj potrebujejo.”

Agilna transformacija se lahko zgodi le, ko se spremenijo ljudje sami.
Izpostavil bi naslednje ključne strahove, ki ljudem preprečujejo, da bi se spremenili:

  • Strah pred izgubo moči in "epolet";
  • Strah, da bi postali podjetju nepotrebni.

Ko smo stopili na pot preobrazbe, smo izbrali prve »izkušene zajce« - zaposlene v maloprodajnem oddelku. Prvi korak je bilo preoblikovanje neučinkovite informacijske strukture. Ko smo oblikovali ciljni koncept strukture, smo začeli oblikovati razvojne ekipe.

Kako smo v razmerah trashy arhitekture in pomanjkanja Scrum veščin ustvarili večkomponentne ekipe

Arhitektura v naši banki je, tako kot v mnogih drugih, milo rečeno »trash«. Ogromno aplikacij in komponent je monolitno povezanih z DB linkom, obstaja ESB vodilo, ki pa ne izpolnjuje svojega namena. Nekaj ​​je tudi ABS.

Kako smo v razmerah trashy arhitekture in pomanjkanja Scrum veščin ustvarili večkomponentne ekipe

Pred oblikovanjem Scrum ekip se je pojavilo vprašanje: “Okrog česa naj se sestavi ekipa?” Koncept, da je v pločevinki izdelek, je seveda lebdel v zraku, a le izven dosega. Po dolgem premisleku smo se odločili, da se ekipa zbere okoli smeri ali segmenta. Na primer »Team Credits«, ki razvija posojila. Ko smo se za to odločili, smo začeli snovati ciljno sestavo vlog in nabora kompetenc, potrebnih za učinkovit razvoj tega področja. Kot številna druga podjetja smo tudi mi upoštevali vse vloge razen Scrum Masterja – takrat je bilo CIO-ju skoraj nemogoče pojasniti, kakšna je vloga te čudovite osebe.

Posledično smo po razlagi potrebe po zagonu razvojnih skupin ustanovili tri ekipe:

  1. Posojila
  2. Kartice
  3. Pasivne operacije

Z nizom vlog:

  1. Vodja razvoja (tehnični vodja)
  2. Developer
  3. analitik
  4. Tester

Naslednji korak je bil določiti, kako bo ekipa delovala. Izvedli smo agilen trening za vse člane ekipe in vse posedli v eno sobo. V ekipah ni bilo PO. Verjetno vsi, ki so opravili agilno preobrazbo, razumejo, kako težko je razložiti vlogo PO podjetju, še težje pa ga posaditi ob ekipo in mu dati avtoriteto. A v te spremembe smo »zakorakali« s tem, kar smo imeli.

S toliko aplikacijami, vključenimi v postopke posojanja in ostalo maloprodajno poslovanje, smo začeli razmišljati, kdo bi lahko bil pravi za te vloge? Razvijalec enega tehnološkega sklopa, potem pa pogledate - in potrebujete razvijalca drugega tehnološkega sklopa! In zdaj ste našli tiste, ki so potrebni, vendar je pomembna tudi želja zaposlenega in človeka je precej težko prisiliti, da dela tam, kjer mu ni všeč.

Po analizi dela poslovnega procesa kreditiranja in dolgih pogovorih s sodelavci smo končno našli srednjo pot! Tako so se pojavile tri razvojne ekipe.

Kako smo v razmerah trashy arhitekture in pomanjkanja Scrum veščin ustvarili večkomponentne ekipe

Kaj sledi?

Ljudje so se začeli deliti na tiste, ki se želijo spremeniti, in tiste, ki se ne želijo. Vsi so navajeni delati v pogojih »dali so mi problem, jaz sem ga naredil, pusti me pri miru«, timsko delo pa tega ne pomeni. A tudi ta problem smo rešili. Skupno je med spremembami odstopilo 8 od 150 ljudi!

Potem se je začela zabava. Naše medkomponentne ekipe so se začele razvijati. Na primer, obstaja naloga, za katero morate imeti veščine na področju razvijalca CRM. Je v ekipi, a je sam. Obstaja tudi razvijalec Oracle. Kaj storiti, če morate v CRM rešiti 2 ali 3 naloge? Učite drug drugega! Fantje so začeli prenašati svoje kompetence drug na drugega, ekipa pa je razširila svoje zmogljivosti in zmanjšala odvisnost od enega močnega strokovnjaka (mimogrede, v vsakem podjetju so supermani, ki vse vedo in nikomur ne povedo).

Danes smo sestavili 13 razvojnih ekip za vsa področja razvoja poslovanja in storitev. Nadaljujemo z našo agilno transformacijo in dosegamo novo raven. To bo zahtevalo nove spremembe. Prenovili bomo ekipe in arhitekturo ter razvijali kompetence.

Naš končni cilj: hitro odzivanje na spremembe produktov, hitro uvajanje novosti na trg in izboljšanje storitev banke!

Vir: www.habr.com

Dodaj komentar