Ciao!
Mi chiamo Alessandro e dirigo lo sviluppo IT in UBRiR!
Nel 2017, presso il centro di sviluppo dei servizi di tecnologie dell'informazione di UBRiR, abbiamo capito che era giunto il momento di cambiamenti globali, in particolare della trasformazione agile. In un contesto di sviluppo intenso del business e di rapida crescita della concorrenza nel mercato finanziario, due anni rappresentano un periodo significativo. Pertanto, è giunto il momento di fare il punto sul progetto.
La cosa più difficile è cambiare il proprio modo di pensare e progressivamente la cultura all'interno di un'organizzazione, dove è comune pensare: «chi sarà il capo di questo team?», «il capo sa meglio cosa dobbiamo fare», «lavoriamo qui da 10 anni e conosciamo meglio i nostri clienti, sappiamo di cosa hanno bisogno».
La trasformazione agile può avvenire solo quando le persone stesse cambiano.
Evidenzierei le seguenti paure chiave che ostacolano il cambiamento delle persone:
- Paura di perdere il potere e i gradi;
- Paura di diventare superflui per l'azienda.
Intraprendendo il percorso di trasformazione, abbiamo selezionato i primi "cavie esperte" — i dipendenti del settore retail. Per iniziare, abbiamo riprogettato la struttura IT inefficace. Dopo aver ideato un concetto strutturale mirato, ci siamo messi al lavoro per formare i team di sviluppo.
L'architettura nella nostra banca, come in molte altre, è, per così dire, "trash". C'è un'enorme quantità di applicazioni e componenti, tutte rigidamente interconnesse tramite DB link; c'è anche un bus ESB, ma non svolge le sue funzioni. Inoltre, ci sono diversi APS.
Prima di formare i team scrum, sorgeva la domanda: «Attorno a cosa dovrebbe essere formato il team?». Il concetto che ci fosse un prodotto in banca, ovviamente, aleggiava nell'aria, ma a una distanza irraggiungibile. Dopo lunghe riflessioni, abbiamo deciso che il team doveva essere costruito attorno a un'area o segmento specifico. Per esempio, «Team Crediti», che sviluppa il settore dei prestiti. Una volta chiarito questo, abbiamo iniziato a concepire il mix ideale di ruoli e competenze necessari per lo sviluppo efficace di questa area. Come molte altre aziende, abbiamo considerato tutti i ruoli tranne lo Scrum Master — in quel momento, spiegare al CIO quale fosse il compito di questa figura straordinaria era praticamente impossibile.
Alla fine, dopo aver chiarito la necessità di avviare i team di sviluppo, abbiamo lanciato tre team:
- Crediti
- Carte
- Operazioni passive
Con il seguente set di ruoli:
- Manager di sviluppo (Tech Lead)
- Sviluppatore
- Analista
- Tester
Il passo successivo è stato definire come avrebbe lavorato il team. Abbiamo condotto una formazione agile per tutti i membri del team, riunendo tutti nella stessa stanza. Non c'era un PO nei team. Probabilmente, chiunque abbia effettuato una trasformazione agile capisce quanto sia difficile spiegare al business il ruolo del PO, e ancora più difficile è collocarlo accanto al team e dargli i poteri necessari. Ma abbiamo ‘fatto un passo’ in queste modifiche con ciò che avevamo.
Poiché nei processi di finanziamento e in altri settori del business al dettaglio era coinvolto un numero enorme di applicazioni, abbiamo iniziato a riflettere su chi potesse adattarsi ai ruoli. Sviluppatore di uno stack tecnologico, ma poi scopri che serve uno sviluppatore di un altro stack! E quindi hai trovato quelli che servivano, ma il desiderio del dipendente è una cosa importante e costringere una persona a lavorare dove non le piace è piuttosto difficile.
Dopo aver analizzato il processo di finanziamento e lunghe conversazioni con i colleghi, abbiamo finalmente trovato un compromesso! Così sono nate tre squadre di sviluppo.
E ora?
Le persone hanno iniziato a dividersi tra coloro che vogliono cambiare e coloro che non vogliono. Tutti erano abituati a lavorare secondo l'approccio 'mi dai un compito, lo faccio e lasciami in pace', mentre il lavoro di squadra non prevede questo. Ma anche questo problema l'abbiamo risolto. Durante il periodo di cambiamenti, abbiamo avuto 8 dimissioni su 150!
Poi è iniziato il bello. I nostri team interfunzionali hanno iniziato a svilupparsi autonomamente. Ad esempio, c'è un compito che richiede competenze nello sviluppo CRM. Nella squadra c'è un esperto, ma è l'unico. Abbiamo anche uno sviluppatore Oracle. Cosa fare se è necessario risolvere 2 o 3 compiti in CRM? Insegnarsi a vicenda! I ragazzi hanno iniziato a scambiare le proprie competenze l'uno con l'altro e il team ha ampliato le proprie capacità, riducendo la dipendenza da uno specialista forte (d'altra parte, in ogni azienda ci sono supereroi che sanno tutto e non lo dicono a nessuno).
Oggi abbiamo composti 13 team di sviluppo per tutte le aree di crescita del business e dei servizi. Continuiamo la trasformazione agile e ci stiamo spostando a un nuovo livello. Questo richiederà nuovi cambiamenti. Ridisegneremo team e architettura, svilupperemo competenze.
Il nostro obiettivo finale è: rispondere rapidamente ai cambiamenti del prodotto, lanciare nuove funzionalità sul mercato in tempi brevi e migliorare i servizi bancari!
Fonte: habr.com
