Kuinka roskaisen arkkitehtuurin ja Scrum-taitojen puutteen olosuhteissa loimme komponenttien välisiä tiimejä

Hi!

Nimeni on Alexander, ja johdan IT-kehitystä UBRD:ssä!

Vuonna 2017 me UBRD:n tietotekniikan palveluiden kehittämiskeskuksessa ymmärsimme, että on tullut aika globaaleille muutoksille tai pikemminkin ketterille muutoksille. Intensiivisen liiketoiminnan kehittämisen ja rahoitusmarkkinoiden kilpailun nopean kasvun olosuhteissa kaksi vuotta on vaikuttava aika. Siksi on aika tehdä yhteenveto projektista.

Vaikeinta on muuttaa ajatteluaan ja muuttaa vähitellen organisaation kulttuuria, jossa on tavallista ajatella: "Kuka on pomo tässä tiimissä?", "Pomo tietää paremmin, mitä meidän tulee tehdä", " Olemme työskennelleet täällä 10 vuotta ja tunnemme asiakkaamme paremmin." , tiedämme mitä he tarvitsevat."

Ketterä muutos voi tapahtua vain, kun ihmiset itse muuttuvat.
Haluaisin korostaa seuraavia keskeisiä pelkoja, jotka estävät ihmisiä muuttumasta:

  • Pelko vallan menettämisestä ja "epauleteista";
  • Pelko tulla tarpeettomaksi yritykselle.

Lähdettyään muutoksen tielle valitsimme ensimmäiset "kokeneet kanit" - vähittäiskaupan työntekijät. Ensimmäinen askel oli tehottoman IT-rakenteen uudelleensuunnittelu. Rakennuksen tavoitekonseptin päätyttyä aloimme muodostaa kehitystiimejä.

Kuinka roskaisen arkkitehtuurin ja Scrum-taitojen puutteen olosuhteissa loimme komponenttien välisiä tiimejä

Pankkimme arkkitehtuuri, kuten monissa muissakin, on lievästi sanottuna "roskaa". Valtava määrä sovelluksia ja komponentteja on yhdistetty monoliittisesti toisiinsa DB-linkillä, ESB-väylä on olemassa, mutta se ei täytä tarkoitustaan. Myös ABS:iä löytyy.

Kuinka roskaisen arkkitehtuurin ja Scrum-taitojen puutteen olosuhteissa loimme komponenttien välisiä tiimejä

Ennen Scrum-tiimien muodostamista heräsi kysymys: ”Mille tiimin pitäisi koota?” Ajatus siitä, että tölkissä oli tuote, oli tietysti ilmassa, mutta vain ulottumattomissa. Pitkän harkinnan jälkeen päätimme, että tiimi tulisi koota jonkin suunnan tai segmentin ympärille. Esimerkiksi "Team Credits", joka kehittää luotonantoa. Päätettyään tästä, aloimme laatia tavoitekokoonpanoa roolista ja osaamisesta, jota tarvitaan tämän alueen tehokkaaseen kehittämiseen. Kuten monet muutkin yritykset, otimme huomioon kaikki roolit paitsi Scrum Master - tuolloin oli lähes mahdotonta selittää tietohallintojohtajalle mikä tämän ihanan henkilön rooli oli.

Selvitettyämme kehitystiimien käynnistämisen tarpeen, käynnistimme kolme tiimiä:

  1. ov
  2. Kortit
  3. Passiiviset toiminnot

Rooleilla:

  1. Kehityspäällikkö (tekninen johtaja)
  2. Kehittäjä
  3. Analyytikko
  4. Testaaja

Seuraava askel oli selvittää, miten tiimi toimii. Teimme ketteriä harjoituksia kaikille tiimin jäsenille ja istuimme kaikki samassa huoneessa. Joukkueissa ei ollut PO:ita. Todennäköisesti jokainen ketterän muutoksen tehnyt ymmärtää, kuinka vaikeaa on selittää PO:n roolia yritykselle, ja vielä vaikeampaa on istuttaa hänet tiimin viereen ja antaa hänelle auktoriteettia. Mutta "astuimme" näihin muutoksiin sillä, mitä meillä oli.

Kun lainausprosesseihin ja muuhun vähittäiskauppaan liittyy niin monia sovelluksia, aloimme miettiä, kuka voisi olla oikea soveltuva rooliin? Yhden teknologiapinon kehittäjä, ja sitten katsot - ja tarvitset kehittäjän toiselle teknologiapinolle! Ja nyt olet löytänyt tarvittavat, mutta työntekijän halu on myös tärkeä asia, ja on melko vaikeaa pakottaa ihmistä työskentelemään siellä, missä hän ei pidä.

Luotonannon liiketoimintaprosessin työn analysoinnin ja kollegoiden kanssa käytyjen pitkien keskustelujen jälkeen löysimme vihdoin keskitien! Näin ilmestyi kolme kehitystiimiä.

Kuinka roskaisen arkkitehtuurin ja Scrum-taitojen puutteen olosuhteissa loimme komponenttien välisiä tiimejä

Mitä seuraavaksi?

Ihmiset alkoivat jakautua niihin, jotka haluavat muuttua, ja niihin, jotka eivät halua. Kaikki ovat tottuneet työskentelemään olosuhteissa "he antoivat minulle ongelman, tein sen, jätä minut rauhaan", mutta ryhmätyö ei tarkoita tätä. Mutta ratkaisimme myös tämän ongelman. Yhteensä 8 henkilöä 150:stä erosi muutosten aikana!

Sitten alkoi hauskuus. Monikomponenttitiimimme alkoivat kehittyä. Esimerkiksi on tehtävä, johon tarvitset CRM-kehittäjän taitoja. Hän on joukkueessa, mutta hän on yksin. Siellä on myös Oracle-kehittäjä. Mitä tehdä, jos sinun on ratkaistava 2 tai 3 tehtävää CRM:ssä? Opettakaa toisianne! Kaverit alkoivat siirtää osaamistaan ​​toisilleen, ja joukkue laajensi kykyjään minimoimalla riippuvuuden yhdestä vahvasta asiantuntijasta (muuten, missä tahansa yrityksessä on supermiehiä, jotka tietävät kaiken eivätkä kerro kenellekään).

Tänään olemme koonneet 13 kehitystiimiä kaikille liiketoiminnan ja palvelukehityksen osa-alueille. Jatkamme ketterää muutosta ja saavutamme uuden tason. Tämä vaatii uusia muutoksia. Suunnittelemme tiimejä ja arkkitehtuuria uudelleen sekä kehitämme osaamista.

Lopullinen tavoitteemme: reagoida nopeasti tuotemuutoksiin, tuoda nopeasti uusia ominaisuuksia markkinoille ja parantaa pankin palveluita!

Lähde: will.com

Lisää kommentti