Cum, în condițiile unei arhitecturi neplăcute și a lipsei de competențe Scrum, am creat echipe cross-component

Hi!

Mă numesc Alexander și conduc dezvoltarea IT la UBRD!

În 2017, noi cei din centrul de dezvoltare a serviciilor de tehnologie a informației de la UBRD ne-am dat seama că a venit momentul schimbărilor globale, sau mai bine zis, transformării agile. În condiții de dezvoltare intensivă a afacerilor și creștere rapidă a concurenței pe piața financiară, doi ani este o perioadă impresionantă. Prin urmare, este timpul să facem un rezumat al proiectului.

Cel mai dificil este să-ți schimbi gândirea și să schimbi treptat cultura în organizație, unde este obișnuit să te gândești: „Cine va fi șeful în această echipă?”, „Șeful știe mai bine ce trebuie să facem”, „ Lucrăm aici de 10 ani și ne cunoaștem mai bine clienții.” , știm de ce au nevoie.”

Transformarea agilă se poate întâmpla doar atunci când oamenii înșiși se schimbă.
Aș evidenția următoarele temeri cheie care împiedică oamenii să se schimbe:

  • Frica de a pierde puterea și „epoleți”;
  • Frica de a deveni inutil pentru companie.

După ce am pornit pe calea transformării, am selectat primii „iepuri cu experiență” - angajați ai departamentului de retail. Primul pas a fost reproiectarea structurii IT ineficiente. După ce am venit cu un concept țintă pentru structură, am început să formăm echipe de dezvoltare.

Cum, în condițiile unei arhitecturi neplăcute și a lipsei de competențe Scrum, am creat echipe cross-component

Arhitectura din banca noastră, ca și în multe altele, este „gunoi”, ca să spunem ușor. Un număr mare de aplicații și componente sunt interconectate monolitic prin legătura DB, există o magistrală ESB, dar nu își îndeplinește scopul propus. Există și niște ABS.

Cum, în condițiile unei arhitecturi neplăcute și a lipsei de competențe Scrum, am creat echipe cross-component

Înainte de a forma echipele Scrum, a apărut întrebarea: „În jurul ce ar trebui să fie adunată echipa?” Conceptul că ar fi un produs în cutie, desigur, era în aer, dar tocmai la îndemână. După multă gândire, am decis ca echipa să fie adunată în jurul unei direcții sau segment. De exemplu, „Team Credits”, care dezvoltă creditarea. Decizând acest lucru, am început să venim cu o compoziție țintă a rolurilor și un set de competențe necesare dezvoltării efective a acestui domeniu. La fel ca multe alte companii, am ținut cont de toate rolurile, cu excepția celui de Scrum Master - la acea vreme era aproape imposibil să explicăm CIO care era rolul acestei persoane minunate.

Drept urmare, după ce am explicat necesitatea lansării echipelor de dezvoltare, am lansat trei echipe:

  1. Împrumuturi
  2. Carduri
  3. Operații pasive

Cu un set de roluri:

  1. Manager de dezvoltare (leader tehnologic)
  2. Dezvoltator
  3. Analist
  4. Tester

Următorul pas a fost stabilirea modului în care va lucra echipa. Am efectuat antrenament agil pentru toți membrii echipei și i-am așezat pe toți într-o singură cameră. Nu au existat OP-uri în echipe. Probabil că toți cei care au făcut o transformare agilă înțeleg cât de greu este să explici afacerii rolul unui PO și cu atât mai dificil să-l așezi lângă echipă și să-i dai autoritate. Dar am „pășit” în aceste schimbări cu ceea ce aveam.

Cu atât de multe aplicații implicate în procesele de creditare și în restul afacerii cu amănuntul, am început să ne gândim, cine ar putea fi potrivit pentru aceste roluri? Un dezvoltator al unei stive de tehnologie, apoi te uiți - și ai nevoie de un dezvoltator al unei alte stive de tehnologie! Și acum i-ați găsit pe cei de care este nevoie, dar dorința angajatului este și ea un lucru important și este destul de dificil să forțați o persoană să lucreze acolo unde nu-i place.

După ce am analizat activitatea procesului de creditare și am discutat lungi cu colegii, am găsit în sfârșit o cale de mijloc! Așa au apărut trei echipe de dezvoltare.

Cum, în condițiile unei arhitecturi neplăcute și a lipsei de competențe Scrum, am creat echipe cross-component

Ce urmeaza?

Oamenii au început să se împartă în cei care vor să se schimbe și cei care nu. Toată lumea este obișnuită să lucreze în condițiile „mi-au dat o problemă, am făcut-o, lasă-mă în pace”, dar munca în echipă nu implică acest lucru. Dar am rezolvat și această problemă. În total, 8 din 150 de persoane au renunțat în timpul schimbărilor!

Apoi a început distracția. Echipele noastre multicomponente au început să se dezvolte. De exemplu, există o sarcină pentru care trebuie să ai abilități în domeniul dezvoltatorului CRM. Este în echipă, dar este singur. Există și un dezvoltator Oracle. Ce să faci dacă trebuie să rezolvi 2 sau 3 sarcini în CRM? Învățați-vă unii pe alții! Băieții au început să-și transfere competențele unul altuia, iar echipa și-a extins capacitățile, reducând la minimum dependența de un specialist puternic (apropo, în orice companie există supraoameni care știu totul și nu spun nimănui).

Astăzi am adunat 13 echipe de dezvoltare pentru toate domeniile de dezvoltare a afacerilor și a serviciilor. Continuăm transformarea noastră agilă și atingem un nou nivel. Acest lucru va necesita noi modificări. Vom reproiecta echipele și arhitectura și vom dezvolta competențe.

Scopul nostru final: răspunde rapid la schimbările de produs, aduce rapid noi funcții pe piață și îmbunătăți serviciile băncii!

Sursa: www.habr.com

Adauga un comentariu