Paano, sa mga kondisyon ng basurang arkitektura at kakulangan ng mga kasanayan sa Scrum, lumikha kami ng mga cross-component na koponan

Привет!

Ang pangalan ko ay Alexander, at ako ang namumuno sa IT development sa UBRD!

Noong 2017, kami sa sentro para sa pagpapaunlad ng mga serbisyo ng teknolohiya ng impormasyon sa UBRD ay natanto na dumating na ang oras para sa mga pandaigdigang pagbabago, o sa halip, mabilis na pagbabago. Sa mga kondisyon ng masinsinang pag-unlad ng negosyo at mabilis na paglago ng kumpetisyon sa merkado sa pananalapi, ang dalawang taon ay isang kahanga-hangang panahon. Samakatuwid, oras na upang buod ang proyekto.

Ang pinakamahirap na bagay ay baguhin ang iyong pag-iisip at unti-unting baguhin ang kultura sa organisasyon, kung saan karaniwan nang isipin: "Sino ang magiging boss sa pangkat na ito?", "Mas alam ng boss kung ano ang kailangan nating gawin," " Kami ay nagtatrabaho dito sa loob ng 10 taon at mas kilala namin ang aming mga kliyente.” , alam namin kung ano ang kailangan nila."

Ang maliksi na pagbabago ay maaaring mangyari lamang kapag ang mga tao mismo ay nagbago.
I-highlight ko ang mga sumusunod na pangunahing takot na pumipigil sa mga tao na magbago:

• Takot na mawalan ng kapangyarihan at "epaulets";
• Takot na maging hindi kailangan para sa kumpanya.

Sa pagsisimula sa landas ng pagbabago, pinili namin ang unang "nakaranas ng mga kuneho" - mga empleyado ng departamento ng tingi. Ang unang hakbang ay muling idisenyo ang hindi mahusay na istraktura ng IT. Sa pagkakaroon ng makabuo ng isang target na konsepto para sa istraktura, nagsimula kaming bumuo ng mga pangkat ng pag-unlad.

Ang arkitektura sa aming bangko, tulad ng marami pang iba, ay "basura," sa madaling sabi. Ang isang malaking bilang ng mga application at mga bahagi ay monolithically interconnected sa pamamagitan ng DB link, mayroong isang ESB bus, ngunit hindi ito matupad ang layunin nito. May ilang ABS din.

Bago bumuo ng mga koponan ng Scrum, lumitaw ang tanong: "Ano ang dapat na tipunin ng koponan?" Ang konsepto na mayroong isang produkto sa lata, siyempre, ay nasa himpapawid, ngunit hindi maabot. Pagkatapos ng maraming pag-iisip, napagpasyahan namin na ang koponan ay dapat tipunin sa isang direksyon o segment. Halimbawa, "Mga Kredito ng Koponan", na bumubuo ng pagpapautang. Nang mapagpasyahan ito, nagsimula kaming makabuo ng isang target na komposisyon ng mga tungkulin at isang hanay ng mga kakayahan na kinakailangan para sa epektibong pag-unlad ng lugar na ito. Tulad ng maraming iba pang mga kumpanya, isinasaalang-alang namin ang lahat ng mga tungkulin maliban sa Scrum Master - sa oras na iyon ay halos imposibleng ipaliwanag sa CIO kung ano ang papel ng kahanga-hangang taong ito.

Bilang resulta, pagkatapos ipaliwanag ang pangangailangang maglunsad ng mga development team, naglunsad kami ng tatlong koponan:

1. Loan
2. Mga Card
3. Mga Passive Operations

Sa isang hanay ng mga tungkulin:

1. Development Manager (Tech Lead)
2. Developer
3. Analyst
4. Tester

Ang susunod na hakbang ay upang matukoy kung paano gagana ang pangkat. Nagsagawa kami ng maliksi na pagsasanay para sa lahat ng miyembro ng koponan at pinaupo ang lahat sa isang silid. Walang mga PO sa mga koponan. Malamang na naiintindihan ng lahat na nakagawa ng maliksi na pagbabagong-anyo kung gaano kahirap ipaliwanag ang papel ng isang PO sa negosyo, at mas mahirap na maupo siya sa tabi ng team at bigyan siya ng awtoridad. Ngunit "pumunta" kami sa mga pagbabagong ito sa kung ano ang mayroon kami.

Sa napakaraming aplikasyon na kasangkot sa mga proseso ng pagpapahiram at sa iba pang retail na negosyo, nagsimula kaming mag-isip, sino ang maaaring akma para sa mga tungkulin? Isang developer ng isang stack ng teknolohiya, at pagkatapos ay tumingin ka - at kailangan mo ng developer ng isa pang stack ng teknolohiya! At ngayon natagpuan mo ang mga kinakailangan, ngunit ang pagnanais ng empleyado ay isang mahalagang bagay din, at medyo mahirap pilitin ang isang tao na magtrabaho kung saan hindi niya gusto.

Matapos suriin ang gawain ng proseso ng negosyo sa pagpapahiram at mahabang pakikipag-usap sa mga kasamahan, sa wakas ay nakahanap kami ng gitnang lupa! Ito ay kung paano lumitaw ang tatlong development team.

Ano ang susunod?

Nagsimulang hatiin ang mga tao sa mga gustong magbago at sa mga ayaw. Sanay na ang lahat na magtrabaho sa mga kondisyon na "binigyan nila ako ng problema, ginawa ko ito, pabayaan mo ako," ngunit hindi ito ipinahihiwatig ng team work. Ngunit nalutas din namin ang problemang ito. Sa kabuuan, 8 sa 150 tao ang huminto sa panahon ng mga pagbabago!

Pagkatapos ay nagsimula ang saya. Ang aming mga cross-component team ay nagsimulang bumuo ng kanilang mga sarili. Halimbawa, mayroong isang gawain kung saan kailangan mong magkaroon ng mga kasanayan sa larangan ng CRM developer. Siya ay nasa koponan, ngunit siya ay nag-iisa. Mayroon ding Oracle developer. Ano ang gagawin kung kailangan mong lutasin ang 2 o 3 gawain sa CRM? Turuan ang isa't isa! Sinimulan ng mga lalaki na ilipat ang kanilang mga kakayahan sa bawat isa, at pinalawak ng koponan ang mga kakayahan nito, pinaliit ang pag-asa sa isang malakas na espesyalista (sa pamamagitan ng paraan, sa anumang kumpanya ay may mga supermen na nakakaalam ng lahat at hindi nagsasabi sa sinuman).

Ngayon ay nagtipon kami ng 13 development team para sa lahat ng larangan ng negosyo at pagpapaunlad ng serbisyo. Ipinagpapatuloy namin ang aming maliksi na pagbabago at umabot kami sa isang bagong antas. Mangangailangan ito ng mga bagong pagbabago. Kami ay muling magdidisenyo ng mga koponan at arkitektura, at bubuo ng mga kakayahan.

Ang aming huling layunin: mabilis na tumugon sa mga pagbabago sa produkto, mabilis na magdala ng mga bagong feature sa merkado at pagbutihin ang mga serbisyo ng bangko!

Pinagmulan: www.habr.com