Hi!
Mi chiamo Alexander e sono a capo dello sviluppo IT presso UBRD!
Nel 2017, noi del Centro per lo sviluppo dei servizi informatici dell’UBRD ci siamo resi conto che era giunto il momento dei cambiamenti globali, o meglio della trasformazione agile. In condizioni di intenso sviluppo del business e rapida crescita della concorrenza nel mercato finanziario, due anni sono un periodo impressionante. È giunto quindi il momento di tirare le somme del progetto.
La cosa più difficile è cambiare il tuo modo di pensare e cambiare gradualmente la cultura nell’organizzazione, dove è comune pensare: “Chi sarà il capo in questa squadra?”, “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.
Vorrei evidenziare le seguenti paure principali che impediscono alle persone di cambiare:
- Paura di perdere il potere e le “spalline”;
- Paura di diventare inutili per l'azienda.
Dopo aver intrapreso il percorso di trasformazione, abbiamo selezionato i primi “conigli esperti”: dipendenti del reparto vendita al dettaglio. Il primo passo è stato riprogettare la struttura informatica inefficiente. Dopo aver elaborato un concetto target per la struttura, abbiamo iniziato a formare team di sviluppo.
L’architettura della nostra banca, come di molte altre, è “spazzatura”, per usare un eufemismo. Un numero enorme di applicazioni e componenti sono interconnessi monoliticamente tramite collegamento DB, esiste un bus ESB, ma non soddisfa lo scopo previsto. Ci sono anche alcuni ABS.
Prima di formare i team Scrum, è sorta la domanda: “Su cosa dovrebbe essere riunito il team?” Il concetto che ci fosse un prodotto nella lattina, ovviamente, era nell'aria, ma era appena fuori portata. Dopo aver riflettuto a lungo, abbiamo deciso che la squadra dovesse essere raccolta attorno a una direzione o segmento. Ad esempio, “Team Credits”, che sviluppa i prestiti. Dopo aver deciso questo, abbiamo iniziato a elaborare una composizione target di ruoli e un insieme di competenze necessarie per lo sviluppo efficace di quest'area. Come molte altre aziende, abbiamo preso in considerazione tutti i ruoli tranne lo Scrum Master: a quel tempo era quasi impossibile spiegare al CIO quale fosse il ruolo di questa persona meravigliosa.
Di conseguenza, dopo aver spiegato la necessità di lanciare team di sviluppo, abbiamo lanciato tre team:
- Prestiti
- Cards
- Operazioni passive
Con una serie di ruoli:
- Responsabile dello sviluppo (responsabile tecnico)
- Sviluppatore
- Analista
- Tester
Il passo successivo è stato determinare come avrebbe funzionato la squadra. Abbiamo condotto una formazione agile per tutti i membri del team e abbiamo fatto sedere tutti in una stanza. Non c'erano PO nelle squadre. Probabilmente chiunque abbia effettuato una trasformazione agile capisce quanto sia difficile spiegare il ruolo di un PO all'azienda, e ancora più difficile farlo sedere accanto al team e dargli autorità. Ma siamo “entrati” in questi cambiamenti con ciò che avevamo.
Con così tante applicazioni coinvolte nei processi di prestito e nel resto dell'attività di vendita al dettaglio, abbiamo iniziato a pensare: chi potrebbe essere la soluzione giusta per i ruoli? Uno sviluppatore di uno stack tecnologico, e poi guardi: e hai bisogno di uno sviluppatore di un altro stack tecnologico! E ora hai trovato chi è necessario, ma anche il desiderio del dipendente è una cosa importante, ed è abbastanza difficile costringere una persona a lavorare dove non gli piace.
Dopo aver analizzato il lavoro del processo aziendale di prestito e lunghe conversazioni con i colleghi, abbiamo finalmente trovato una via di mezzo! Ecco come sono comparsi tre team di sviluppo.
Quali sono le prospettive?
Le persone hanno cominciato a dividersi tra chi vuole cambiare e chi no. Tutti sono abituati a lavorare nella condizione del “mi hanno dato un problema, l’ho fatto, lasciatemi in pace”, ma il lavoro di squadra non implica questo. Ma abbiamo risolto anche questo problema. In totale, 8 persone su 150 hanno smesso durante i cambiamenti!
Poi è iniziato il divertimento. I nostri team intercomponenti hanno iniziato a svilupparsi. Ad esempio, c'è un compito per il quale è necessario possedere competenze nel campo dello sviluppatore CRM. Fa parte della squadra, ma è solo. C'è anche uno sviluppatore Oracle. Cosa fare se devi risolvere 2 o 3 attività nel CRM? Insegnatevi a vicenda! I ragazzi hanno iniziato a trasferirsi reciprocamente le proprie competenze e il team ha ampliato le proprie capacità, riducendo al minimo la dipendenza da un forte specialista (a proposito, in ogni azienda ci sono superuomini che sanno tutto e non lo dicono a nessuno).
Oggi abbiamo riunito 13 team di sviluppo per tutte le aree dello sviluppo aziendale e dei servizi. Continuiamo la nostra trasformazione agile e raggiungiamo un nuovo livello. Ciò richiederà nuove modifiche. Ridisegneremo i team e l'architettura e svilupperemo le competenze.
Il nostro obiettivo finale: rispondere rapidamente ai cambiamenti dei prodotti, introdurre rapidamente nuove funzionalità sul mercato e migliorare i servizi della banca!
Fonte: habr.com