Kuidas me prügiarhitektuuri ja Scrumi oskuste puudumise tingimustes lõime komponentidevahelised meeskonnad

Tere!

Minu nimi on Alexander ja ma juhin UBRD-s IT-arendust!

2017. aastal saime UBRD infotehnoloogiateenuste arenduskeskuses aru, et on saabunud aeg globaalseteks muutusteks või õigemini agiilseks transformatsiooniks. Intensiivse äriarengu ja finantsturu konkurentsi kiire kasvu tingimustes on kaks aastat muljetavaldav periood. Seetõttu on aeg teha projektist kokkuvõte.

Kõige keerulisem on muuta oma mõtlemist ja järk-järgult muuta organisatsioonis kultuuri, kus on tavaline mõelda: "Kes saab selles meeskonnas bossiks?", "Ülemus teab paremini, mida me tegema peame," " Oleme siin töötanud 10 aastat ja tunneme oma kliente paremini." , teame, mida nad vajavad."

Agiilne transformatsioon saab toimuda ainult siis, kui muutuvad inimesed ise.
Tooksin esile järgmised peamised hirmud, mis takistavad inimestel muutumast:

  • Hirm võimu kaotamise ja "epaulettide" ees;
  • Hirm muutuda ettevõtte jaoks ebavajalikuks.

Olles asunud ümberkujundamise teele, valisime välja esimesed "kogenud küülikud" - jaemüügiosakonna töötajad. Esimene samm oli ebaefektiivse IT-struktuuri ümberkujundamine. Olles välja mõelnud struktuuri sihtkontseptsiooni, hakkasime moodustama arendusmeeskondi.

Kuidas me prügiarhitektuuri ja Scrumi oskuste puudumise tingimustes lõime komponentidevahelised meeskonnad

Meie panga arhitektuur, nagu paljudes teistes, on pehmelt öeldes prügikast. Tohutu hulk rakendusi ja komponente on monoliitselt omavahel ühendatud DB lingiga, olemas on ESB siin, kuid see ei täida oma eesmärki. On ka mõned ABS-id.

Kuidas me prügiarhitektuuri ja Scrumi oskuste puudumise tingimustes lõime komponentidevahelised meeskonnad

Enne Scrumi meeskondade moodustamist tekkis küsimus: "Mille ümber tuleks meeskond kokku panna?" Arusaam, et purgis on toode, oli muidugi õhus, aga lihtsalt kättesaamatus kohas. Pärast pikka mõtlemist otsustasime, et meeskond tuleks koondada mingi suuna või segmendi ümber. Näiteks laenuandmist arendav “Team Credits”. Olles selle otsustanud, hakkasime välja mõtlema selle valdkonna tõhusaks arendamiseks vajalike rollide ja kompetentside komplekti. Nagu paljud teisedki ettevõtted, võtsime arvesse kõiki rolle peale Scrum Masteri – tol ajal oli CIO-le peaaegu võimatu selgitada, mis roll sellel imelisel inimesel on.

Selle tulemusel käivitasime pärast arendusmeeskondade käivitamise vajaduse selgitamist kolm meeskonda:

  1. Laenud
  2. Kaardid
  3. Passiivsed operatsioonid

Rollide komplektiga:

  1. Arendusjuht (tehniline juht)
  2. Разработчик
  3. Analüütik
  4. Tester

Järgmine samm oli kindlaks teha, kuidas meeskond töötab. Viisime läbi agiilse treeningu kõigile meeskonnaliikmetele ja istusime kõik ühte ruumi. Võistkondades PO-sid ei olnud. Tõenäoliselt saavad kõik agiilse transformatsiooni teinud inimesed aru, kui raske on PO rolli ärile selgitada ja veel keerulisem on teda meeskonna kõrvale istutada ja autoriteeti anda. Kuid me "astusime" nendesse muutustesse sellega, mis meil oli.

Kuna laenuprotsessidesse ja muusse jaeärisse on kaasatud nii palju rakendusi, hakkasime mõtlema, kes võiks nendesse rollidesse sobida? Ühe tehnoloogiavirna arendaja ja siis vaatad – ja sul on vaja teise tehnoloogiavirna arendajat! Ja nüüd olete leidnud need, keda vaja on, aga oluline on ka töötaja soov ja üsna raske on sundida inimest tööle sinna, kus talle ei meeldi.

Pärast laenude äriprotsessi töö analüüsimist ja pikki vestlusi kolleegidega leidsime lõpuks kuldse kesktee! Nii tekkis kolm arendusmeeskonda.

Kuidas me prügiarhitektuuri ja Scrumi oskuste puudumise tingimustes lõime komponentidevahelised meeskonnad

Mis edasi?

Inimesed hakkasid jagunema nendeks, kes tahavad muutuda, ja nendeks, kes ei soovi. Kõik on harjunud töötama tingimustes "nad andsid mulle probleemi, ma tegin seda, jätke mind rahule", kuid meeskonnatöö seda ei tähenda. Kuid me lahendasime ka selle probleemi. Kokku lahkus muudatuste käigus 8 inimest 150-st!

Siis algas lõbus. Meie komponentidevahelised meeskonnad hakkasid end arendama. Näiteks on tööülesanne, mille jaoks peate omama CRM-i arendaja valdkonna oskusi. Ta on meeskonnas, kuid ta on üksi. Samuti on olemas Oracle'i arendaja. Mida teha, kui CRM-is on vaja lahendada 2 või 3 ülesannet? Õpetage üksteist! Poisid hakkasid oma pädevusi üksteisele üle andma ja meeskond laiendas oma võimalusi, minimeerides sõltuvust ühest tugevast spetsialistist (muide, igas ettevõttes on supermehi, kes teavad kõike ega räägi kellelegi).

Tänaseks oleme koondanud 13 arendusmeeskonda kõigi äri- ja teenustearenduse valdkondade jaoks. Jätkame oma agiilset ümberkujundamist ja jõuame uuele tasemele. See nõuab uusi muudatusi. Kujundame ümber meeskonnad ja arhitektuuri ning arendame kompetentse.

Meie lõppeesmärk: kiiresti reageerida tootemuudatustele, tuua kiiresti turule uusi funktsioone ja täiustada panga teenuseid!

Allikas: www.habr.com

Lisa kommentaar