Hogyan hoztunk létre többkomponensű csapatokat a trash-architektúra és a Scrum-ban való jártasság hiányában

Hi!

A nevem Alexander, informatikai fejlesztést vezetek az UBRD-nél!

2017-ben mi, az UBRD informatikai szolgáltatások fejlesztésének központjaként felismertük, hogy eljött a globális változások, pontosabban az agilis átalakulás ideje. Az intenzív üzletfejlesztés és a pénzügyi piaci verseny gyors növekedése mellett két év lenyűgöző időszak. Ezért itt az ideje, hogy összefoglaljuk a projektet.

A legnehezebb a gondolkodásmód megváltoztatása és a szervezeti kultúra fokozatos megváltoztatása, ahol általában a következő gondolatok fordulnak elő: „Ki lesz a főnök ebben a csapatban?”, „A főnök jobban tudja, mit kell tennünk”, „ 10 éve dolgozunk itt, és jobban ismerjük ügyfeleinket." , tudjuk, mire van szükségük."

Agilis átalakulás csak akkor történhet meg, ha maguk az emberek is megváltoznak.
A következő fő félelmeket emelném ki, amelyek megakadályozzák az embereket abban, hogy megváltozzanak:

  • Félelem a hatalom elvesztésétől és az „epaulets”-től;
  • Félelem, hogy szükségtelenné válik a cég számára.

Miután elindultunk az átalakulás útján, kiválasztottuk az első „tapasztalt nyulakat” - a kiskereskedelmi osztály munkatársait. Az első lépés a nem hatékony informatikai struktúra újratervezése volt. Miután kidolgoztuk a struktúra célkoncepcióját, elkezdtük a fejlesztőcsapatok kialakítását.

Hogyan hoztunk létre többkomponensű csapatokat a trash-architektúra és a Scrum-ban való jártasság hiányában

A mi bankunk architektúrája – sok máshoz hasonlóan – finoman szólva is „szemét”. Hatalmas számú alkalmazás és komponens monolitikusan össze van kötve DB linkkel, van ESB busz, de az nem teljesíti a rendeltetését. Van néhány ABS is.

Hogyan hoztunk létre többkomponensű csapatokat a trash-architektúra és a Scrum-ban való jártasság hiányában

A Scrum-csapatok megalakítása előtt felmerült a kérdés: „Mi köré épüljön a csapat?” Az elképzelés, hogy a dobozban van egy termék, természetesen ott volt a levegőben, de nem volt elérhető. Hosszas gondolkodás után úgy döntöttünk, hogy a csapatot egy irány vagy szegmens köré kell összegyűjteni. Például a „Team Credits”, amely a hitelezést fejleszti. Miután ezt eldöntöttük, elkezdtük kidolgozni a szerepek célösszetételét és a terület hatékony fejlesztéséhez szükséges kompetenciák körét. Sok más céghez hasonlóan mi is figyelembe vettük az összes szerepet, kivéve a Scrum Mastert – akkoriban szinte lehetetlen volt elmagyarázni a CIO-nak, hogy mi a szerepe ennek a csodálatos embernek.

Ennek eredményeként, miután elmagyaráztuk a fejlesztőcsapatok indításának szükségességét, három csapatot indítottunk:

  1. Kölcsönök
  2. kártya
  3. Passzív műveletek

Egy sor szerepkörrel:

  1. Fejlesztési vezető (technikai vezető)
  2. Fejlesztő
  3. Elemző
  4. Vizsgáló

A következő lépés az volt, hogy meghatározzuk, hogyan fog működni a csapat. Agilis edzést tartottunk minden csapattagnak, és mindenkit egy terembe ültettünk. A csapatokban nem volt PO. Valószínűleg mindenki, aki agilis átalakulást végzett, megérti, milyen nehéz elmagyarázni a PO szerepét a vállalkozásnak, és még nehezebb őt a csapat mellé ültetni és tekintélyt adni neki. De mi „beléptünk” ezekbe a változásokba azzal, amink volt.

Mivel a hitelezési folyamatokban és a lakossági üzletág többi részében rengeteg alkalmazás érintett, elkezdtünk gondolkodni, vajon ki lehet a megfelelő szerepkör? Egy technológiai verem fejlesztője, majd megnézi – és szüksége van egy másik technológiai verem fejlesztőjére! És most megtalálta azokat, akikre szükség van, de az alkalmazott vágya is fontos dolog, és elég nehéz rákényszeríteni az embert arra, hogy olyan helyen dolgozzon, ahol nem szeret.

A hitelezési üzleti folyamat munkájának elemzése és a kollégákkal folytatott hosszas beszélgetések után végre megtaláltuk a középutat! Így jelent meg három fejlesztőcsapat.

Hogyan hoztunk létre többkomponensű csapatokat a trash-architektúra és a Scrum-ban való jártasság hiányában

Mi a következő lépés?

Az emberek elkezdtek szétválni azokra, akik változtatni akarnak, és azokra, akik nem. Mindenki megszokta, hogy „problémát adtak, megcsináltam, hagyj békén” körülmények között dolgozni, de a csapatmunka nem jelenti ezt. De ezt a problémát is megoldottuk. Összességében 8 emberből 150 felmondott a változások során!

Aztán elkezdődött a mulatság. A többkomponensű csapataink fejlődésnek indultak. Például van egy feladat, amelyhez CRM fejlesztői készségekkel kell rendelkeznie. A csapat tagja, de egyedül van. Van egy Oracle fejlesztő is. Mi a teendő, ha 2 vagy 3 feladatot kell megoldania a CRM-ben? Tanítsátok egymást! A srácok elkezdték átadni kompetenciáikat egymásnak, a csapat pedig kibővítette képességeit, minimálisra csökkentve az egy erős szakembertől való függőséget (mellesleg, minden társaságban vannak szupermenek, akik mindent tudnak, és nem mondanak el senkinek).

Mára 13 fejlesztőcsapatot állítottunk össze az üzlet- és szolgáltatásfejlesztés minden területén. Folytatjuk agilis átalakulásunkat, és új szintre lépünk. Ehhez új változtatásokra lesz szükség. Újratervezzük a csapatokat és az építészetet, valamint fejlesztjük a kompetenciákat.

Végső célunk: gyorsan reagálni a termékváltozásokra, gyorsan új funkciókat hozni a piacra és javítani a bank szolgáltatásait!

Forrás: will.com

Hozzászólás