Si, në kushtet e arkitekturës së kotë dhe mungesës së aftësive Scrum, krijuam ekipe ndërkomponente

Привет!

Emri im është Alexander, dhe unë drejtoj zhvillimin e IT në UBRD!

Në vitin 2017, ne në qendrën e zhvillimit të shërbimeve të teknologjisë së informacionit në UBRD kuptuam se kishte ardhur koha për ndryshime globale, ose më mirë, transformim të shkathët. Në kushtet e zhvillimit intensiv të biznesit dhe rritjes së shpejtë të konkurrencës në tregun financiar, dy vitet janë një periudhë mbresëlënëse. Prandaj, është koha për të përmbledhur projektin.

Gjëja më e vështirë është të ndryshoni të menduarit tuaj dhe gradualisht të ndryshoni kulturën në organizatë, ku është e zakonshme të mendosh: "Kush do të jetë shefi në këtë ekip?", "Shefi e di më mirë se çfarë duhet të bëjmë", " Ne punojmë këtu për 10 vjet dhe i njohim më mirë klientët tanë.” , ne e dimë se çfarë kanë nevojë.”

Transformimi i shkathët mund të ndodhë vetëm kur vetë njerëzit ndryshojnë.
Do të theksoja frikërat kryesore të mëposhtme që i pengojnë njerëzit të ndryshojnë:

  • Frika nga humbja e pushtetit dhe "epoletat";
  • Frika se mos bëhet e panevojshme për kompaninë.

Duke hyrë në rrugën e transformimit, ne zgjodhëm "lepujt me përvojë" të parë - punonjësit e departamentit të shitjes me pakicë. Hapi i parë ishte ridizajnimi i strukturës joefikase të TI-së. Pasi dolëm me një koncept të synuar për strukturën, filluam të formojmë ekipe zhvillimi.

Si, në kushtet e arkitekturës së kotë dhe mungesës së aftësive Scrum, krijuam ekipe ndërkomponente

Arkitektura në bankën tonë, si në shumë të tjera, është "plehra", për ta thënë butë. Një numër i madh i aplikacioneve dhe komponentëve janë të ndërlidhur në mënyrë monolitike me lidhjen DB, ekziston një autobus ESB, por ai nuk përmbush qëllimin e tij të synuar. Ka edhe disa ABS.

Si, në kushtet e arkitekturës së kotë dhe mungesës së aftësive Scrum, krijuam ekipe ndërkomponente

Përpara formimit të ekipeve Scrum, lindi pyetja: "Për çfarë duhet të mblidhet ekipi?" Koncepti se kishte një produkt në kanaçe, natyrisht, ishte në ajër, por thjesht i paarritshëm. Pas shumë mendimeve, vendosëm që ekipi të mblidhej rreth një drejtimi apo segmenti. Për shembull, "Team Credits", i cili zhvillon kreditimin. Pasi vendosëm për këtë, ne filluam të dilnim me një përbërje të synuar të roleve dhe një grup kompetencash të nevojshme për zhvillimin efektiv të kësaj fushe. Si shumë kompani të tjera, ne morëm parasysh të gjitha rolet përveç Scrum Master - në atë kohë ishte pothuajse e pamundur t'i shpjegosh CIO-s se cili ishte roli i këtij personi të mrekullueshëm.

Si rezultat, pasi shpjeguam nevojën për të nisur ekipet e zhvillimit, ne krijuam tre ekipe:

  1. Loans
  2. kartë
  3. Operacionet pasive

Me një grup rolesh:

  1. Menaxher zhvillimi (udhëheqës teknik)
  2. Zhvilluesi
  3. Analist
  4. Testues

Hapi tjetër ishte të përcaktohej se si do të funksiononte ekipi. Ne zhvilluam stërvitje të shkathët për të gjithë anëtarët e ekipit dhe u ulëm të gjithë në një dhomë. Nuk kishte PO në ekipe. Ndoshta të gjithë ata që kanë bërë një transformim të shkathët e kuptojnë se sa e vështirë është t'i shpjegosh biznesit rolin e një PO, dhe akoma më e vështirë ta ulësh atë pranë ekipit dhe t'i japë atij autoritet. Por ne “u futëm” në këto ndryshime me atë që kishim.

Me kaq shumë aplikacione të përfshira në proceset e huadhënies dhe pjesën tjetër të biznesit të shitjes me pakicë, ne filluam të mendojmë, kush mund të jetë i përshtatshëm për rolet? Një zhvillues i një grumbulli teknologjie, dhe pastaj shikoni - dhe keni nevojë për një zhvillues të një rafte tjetër teknologjie! Dhe tani ju keni gjetur ata që duhen, por dëshira e punonjësit është gjithashtu një gjë e rëndësishme dhe është mjaft e vështirë të detyrosh një person të punojë aty ku nuk i pëlqen.

Pas analizimit të punës së procesit të biznesit të kreditimit dhe bisedave të gjata me kolegët, më në fund gjetëm një rrugë të mesme! Kështu u shfaqën tre ekipe zhvillimi.

Si, në kushtet e arkitekturës së kotë dhe mungesës së aftësive Scrum, krijuam ekipe ndërkomponente

Çka më tej?

Njerëzit filluan të ndahen në ata që duan të ndryshojnë dhe ata që nuk duan. Të gjithë janë mësuar të punojnë në kushtet e “më dhanë një problem, e bëra, më lini të qetë”, por puna në grup nuk nënkupton këtë. Por ne e zgjidhëm edhe këtë problem. Gjithsej, 8 nga 150 persona u larguan gjatë ndryshimeve!

Pastaj filloi argëtimi. Ekipet tona ndërkomponente filluan të zhvilloheshin vetë. Për shembull, ekziston një detyrë për të cilën ju duhet të keni aftësi në fushën e zhvilluesit të CRM. Ai është në ekip, por është i vetëm. Ekziston edhe një zhvillues Oracle. Çfarë duhet të bëni nëse keni nevojë të zgjidhni 2 ose 3 detyra në CRM? Mësoni njëri-tjetrin! Djemtë filluan t'i transferojnë kompetencat e tyre njëri-tjetrit, dhe ekipi zgjeroi aftësitë e tij, duke minimizuar varësinë nga një specialist i fortë (nga rruga, në çdo kompani ka supermena që dinë gjithçka dhe nuk i tregojnë askujt).

Sot ne kemi mbledhur 13 ekipe zhvillimi për të gjitha fushat e zhvillimit të biznesit dhe shërbimeve. Ne vazhdojmë transformimin tonë të shkathët dhe arrijmë një nivel të ri. Kjo do të kërkojë ndryshime të reja. Ne do të ridizajnojmë ekipet dhe arkitekturën dhe do të zhvillojmë kompetencat.

Synimi ynë përfundimtar: përgjigjja e shpejtë ndaj ndryshimeve të produktit, sjellja e shpejtë e veçorive të reja në treg dhe përmirësimi i shërbimeve të bankës!

Burimi: www.habr.com

Shto një koment