Come cambia, o dovrebbe cambiare, il mindset di chi lavora in un ambiente DevOps
Il management non è una scienza esatta, rigida, e ogni azienda ha la sua storia, difficilmente comparabile con le altre. Provo però a enunciare i tre temi che sono importanti rispetto a difficoltà ricorrenti, almeno nella mia esperienza:
1. Una forte eredità culturale
Il primo tema è il più difficile. È presente soprattutto nelle aziende in cui c’è tanta burocrazia. L’attività di management di un flusso produttivo (gestirlo) non porta alcun valore aggiunto nei confronti del cliente finale. Mi spiego: quando un cliente scarica una app sul suo telefono, non ha alcun interesse a sapere come internamente l’azienda si è organizzata per fare quel prodotto (eccetto rare nicchie di mercato).
Il management potrebbe anche non esistere. Pensa a un artigiano individuale che realizza un piccolo sito; è quando la dimensione produttiva diventa maggiore, o il problema più complesso da risolvere, che servono metodi più sofisticati di gestione del lavoro. Al cliente però interessa che il prodotto funzioni correttamente e alla fine, per funzionare, il codice qualcuno lo deve pur scrivere: la mano di uno o più programmatori. Il software in funzione è il risultato del processo produttivo, ed è la pasta di questa ricetta. Tutto ciò che succede in mezzo e che non concorre all’impastare, non aggiunge alcun valore diretto alla soluzione.
La differenza tra gestire risorse e servire persone
Il management è una infrastruttura che serve affinché questo processo funzioni bene e in maniera efficiente. Per cui è un costo che il cliente sostiene perché noi abbiamo deciso di produrre in quel modo, ma non aggiunge valore alla soluzione finale. Questo cambio di mentalità è importante: il management serve la produzione, non il contrario. Deve far sì che chi produce possa lavorare al massimo delle sue capacità e possa prendere decisioni quando occorre.
Nel lavoro intellettuale, chi ha la quantità di conoscenza più completa e interessante sono proprio gli operativi (mi si passi il termine), coloro che hanno le mani in pasta nelle attività di realizzazione della soluzione. In queste culture c’è molta delega e responsabilità a tutti i livelli: la vecchia economia pensa un manager gestisce 100 risorse, nel Lean si dice che un manager lavora per 100 persone. È un cambio di prospettiva notevole.
2. Non perseverare è diabolico
Il secondo tema riguarda il partire bene e poi fermarsi lì. Spesso copiando esperienze altrui (come Scrum o come il modello Spotify); non c’è niente di male a imitare all’inizio, anzi è una buona partenza, ma poi bisogna andare oltre e imparare a camminare da soli e perseverare continuamente, facendo esperimenti piccoli.
La guida di Scrum, ad esempio, è lunga una ventina di pagine. Si possono leggere velocemente 20 pagine, no? e poi si passa a fare esperimenti enormi, iniziare grandi trasformazioni miracolose. Questo invece è affrettato. Per esempio, in Italia c’è una grande quantità di aziende che viene dal mito più cose fai contemporaneamente più sei bravo, e questo, in particolare con il software, è quasi sempre antieconomico.
Se faccio lavorare le mie persone con Scrum, ma in cinque o sei team diversi nello stesso momento, torno a fare quello che facevo prima (o peggio) anche se chiamo le riunioni in un modo diverso. Non c’è nessuna magia nei metodi Agile e in DevOps. Scalfita la superficie di valori, ritmi e principî c’è da studiare: nessuna metodologia sostituisce anni di studio personale e individuale.
3. Servono i tecnici
L’ultima ha a che fare con il software, visto che parliamo di software. I metodi Agile sono nati per fare il software e questo tante volte ce lo dimentichiamo, perché nel calderone c’è un elemento che può essere trasportato un po’ ovunque: il processo. Ovvero, il come organizziamo la gestione degli gli X passi produttivi previsti. Il bello dei metodi Agile è che sono un modo ragionevole di lavorare per processi in generale, a prescindere che si faccia software o no.
Questa cosa, siccome generalmente funziona meglio di altre, contamina virtuosamente un po’ tutti gli ambiti aziendali e la voce che lavorare con certe pratiche e valori sia più conveniente si diffonde, così che tutti lo vogliono imparare. Ma quando il processo diventa accettabile emergono i problemi tecnici. A quel punto per fare DevOps servono professionisti eccellenti, che sappiano programmare bene e spacchino il bit in quattro. Non è raro infatti vedere usati i metodi Agile in gruppi a grande componente gestionale, di controllo, strategica, di marketing, ma con un numero ridotto di tecnici (programmatori, sistemisti…).
In Italia in particolare c’è una grande parte di aziende che ha prosperato in altre epoche, e che ha sempre fatto in modo di disinteressarsi e lasciar fuori dalle proprie mura aziendali coloro che scrivono codice come programmatori, sistemisti e analisti. Magari affidandosi a società di consulenza e gestendo da lontano il loro software per progetti.
Il vento sta cambiando
È il risultato di una cultura in cui il valore produttivo del software non è mai stato davvero considerato come un asset strategico in senso economico (capitale produttivo), ma solo come una mera voce di costo. Invece è un investimento eccome, dalla vita assai complessa e con la salute fragile, difficilmente rimpiazzabile quando mescolato nei processi produttivi aziendali. Se ci fai caso, nel DNA di molte dot-com (che ancora oggi dominano il mercato) c’è una gran presenza di dipendenti tecnici, mentre la consulenza ha un ruolo quasi marginale.
In Italia è il contrario da tempo. E ci siamo già un po’ scottati, gli insegnamenti dei tempi di Olivetti sono scivolati via. Però fortunatamente c’è un trend in controtendenza: anche la vecchia economia e le grosse aziende oggi, timidamente, cercano tecnici e programmatori da assumere. È positivo ma bisogna far presto, perché è un po’ come se si iniziasse a investire su quelle competenze da oggi, mentre i concorrenti hanno già percorso diversi giri di pista e i buoi hanno iniziato a scappare da un bel pezzo.
L'autore
Corsi che potrebbero interessarti
Agile, sviluppo e management: iniziare bene
Data governance: diritti, licenze e privacy
Big Data Executive: business e strategie