Questa è una storia di data-driven incompreso, ed è abbastanza esemplare. Esemplare perché tutte le aziende vogliono la qualità, l’efficienza, la riduzione dei tempi, l’eliminazione degli sprechi. Ma quando le ottengono, spesso, non sanno cosa farsene e finiscono per trarre le conclusioni sbagliate.
Prima i fatti (questa la fonte e leggere vale la pena):
- un programmatore viene assunto per eseguire dei test di qualità sul software
- nei primi otto mesi il programmatore scrive delle routine che automatizzano i suoi compiti
- l’automazione funziona, il programmatore va in ufficio a non fare assolutamente nulla per sei anni
- dopo sei anni l’azienda se ne accorge e lo licenzia
- nei sei anni trascorsi a perdere tempo in ufficio il programmatore ha scordato come si programma e deve tornare sui libri, fortunatamente sostenuto dai soldi che comunque ha messo da parte (si parla di uno stipendio di 95mila dollari l’anno).
Ora, se la vostra reazione è del tipo “era ora” o “se l’è meritato” o “dovrebbe restituire sei anni di stipendio”, quell’azienda potrebbe essere la vostra.
Diciamo prima di tutto che, trattandosi di un racconto di un programmatore, e per di più non verificabile (l’account di reddit è stato cancellato), occorre fare una grossa tara, diciamo come su un racconto di pesca.
Ma anche fatta la tara (non saranno stati sei anni, qualcosa avrà pur fatto in ufficio, eccetera), rimane il fatto che la storia è del tutto realistica e plausibile.
Quindi qual è il punto di vista del dataKnightmare? Semplice: l’azienda ha licenziato la persona sbagliata, nei tempi sbagliati, per i motivi sbagliati.
Andiamo con ordine. I test software sono un compito assolutamente (e doverosamente) automatizzabile, ma non sono certo il solo. E in un’azienda qualsiasi compito automatizzabile dovrebbe venire automatizzato: l’alternativa si chiama spreco, inefficienza, perdita di competitività. Quindi il nostro bravo programmatore (chiamiamolo Joe per praticità) ha inizialmente fatto solo quel che andava fatto.
Come ha reagito l’azienda? Non accorgendosene.
Nessuno, per anni, ha scoperto che Joe aveva completamente automatizzato il proprio lavoro.
Nessuno, per anni, ha capito che i compiti che venivano chiamati “lavoro” erano in realtà un insieme di script in attesa di qualcuno che li scrivesse.
Nessuno ha pensato, per anni, di fronte a un processo formalizzato (al punto di poter essere automatizzato!), di definire dei KPI per valutare se il processo poteva essere reso più efficiente.
O, peggio, i KPI c’erano ma nessuno ha pensato a migliorare il processo, alla faccia del kaizen che piace tanto a parole.
Quindi delle due l’una:
- nessun manager ha controllato (del tutto realistico)
- il manager vedeva e non capiva (purtroppo altrettanto realistico).
Quando alla fine qualcuno si è accorto dell’andazzo, chi è stato silurato? Il manager? Il manager del manager? Il CEO? No: il programmatore, colpevole di avere fatto il suo lavoro e di avere un manager con la consapevolezza di una macchinetta del caffè.
Quindi Joe non meritava di essere licenziato? Certo. Ma solo perché si era dimenticato come fare il proprio lavoro, non per averlo fatto troppo bene.
Oh, ma forse Joe avrebbe dovuto andare dal proprio manager a dire “capo, non ho niente da fare”, no? Sicuro, ma forse come tanti anche Joe aveva imparato che il manager è migliore quando non lo si disturba: in fin dei conti è compito suo controllare, no? E quindi aspettiamo che controlli.
Cosa avrebbe dovuto succedere, invece? Che il manager di Joe (e probabilmente quello sopra di lui) dovevano essere buttati fuori per non essersi accorti, per anni, di cosa succedeva. In un ambiente dove si parla continuamente di automazione, di efficienza, di risparmi, questo equivale a non essere presenti sul lavoro.
Dopodiché le competenze di Joe avrebbero dovuto essere applicate ad altri ambiti. Certo, molti altri posti di lavoro sarebbero stati ridimensionati, o sarebbero spariti. Peccato, ma è a questo che serve l’informatica, non a mandarsi avanti e indietro via mail presentazioni in PowerPoint e documenti Word. (Ops! Ho messo a rischio intere carriere!)
Se un processo automatizzabile non viene automatizzato, significa che stiamo pagando una persona per fare il lavoro di una macchina. E questo non è esattamente un certificato di qualità, no? Lasciamo stare per un attimo la perdita di efficienza, che l’efficienza serve quando sappiamo di stare facendo la cosa giusta. Pensiamo alla persona che fa quel lavoro che sarebbe di una macchina. Crediamo che si senta realizzata? Soddisfatta? Considerata?
Basta guardare negli occhi le cassiere del supermercato per avere la risposta.
Che cosa dice di un’azienda, e della competenza di chi la guida, il fatto di usare persone quando dovrebbe usare macchine, e di impiegare anni ad accorgersene?
Si fa presto a dire data-driven, ma data-driven è prima di tutto sapere cosa sta succedendo nella propria azienda. Processi formali, indicatori di processo, revisioni di processo, miglioramento continuo. Per avere più efficienza, certo, ma prima ancora per avere più efficacia: l’efficienza è per quando siamo certi di stare facendo la cosa giusta.
Un’azienda data-driven non è solo più efficiente: è anche più efficace perché non chiede alle persone di svolgere che possono fare le macchine. E quindi impiega sì meno persone, ma quelle poche le impiega in compiti non automatizabili, ad altissimo valore aggiunto, e le paga di conseguenza.
Ops, l’ho detto.
E voi, quanti Joe potreste trovare in questo momento in azienda, se guardaste?
Facebook Comments