È notizia recente degli smartphone Samsung che esplodono. Informandomi un po’ in giro, ho letto che sarebbe -riassumo- “un problema di batteria che viene caricata oltre il necessario”. In pratica un problema a metà tra hardware e software, dove il software non è in grado di dire “ok, basta caricare la batteria, è carica abbastanza”.

Che c’entra con la programmazione questa vicenda?

Devo dire che sento questa notizia da giorni. Tutti a parlare delle conseguenze dal punto di vista del marketing e delle vendite. Certo, sono le stesse considerazioni che abbiamo fatto tutti, ma prova a seguirmi e scoprirai un altro scenario dietro tutto questo.

Stamattina, mentre mi preparavo per andare in ufficio (ho l’abitudine di ascoltare video o podcast durante la preparazione) ho sentito per l’ennesima volta questa notizia. Ero in piedi, semi distratto dai bottoni della camicia che non si infilano mai al primo colpo, quando improvvisamente sono stato folgorato da un’immagine.

Il programmatore che ha fatto la cazzata lato software, riguardo il problema della batteria. Teste che salteranno -o sono già saltate- nel team sviluppo di Samsung e gente che gioca allo scarica barile.

Ho immaginato la scena, con una nitidezza quasi inquietante. Come quando Harry Potter si immerge nel pensatoio di Silente e riesce a vedere i ricordi di altre persone con una chiarezza incredibile, quasi come se fosse li.

Ecco, mi è successa la stessa cosa. Ma il mio non era proprio un ricordo e -ahimè- non ho il pensatoio di Silente. Però ho qualche annetto di esperienza alla spalle e la mia mente ha ricostruito le scene degli accadimenti in Samsung, come fossero pezzi di un film visto e rivisto.

Da una parte abbiamo il programmatore come noi. Seduto alla sua scrivania, redbull e fettazza di pizza a lato, mani un po’ unte (si, nella mia mente questo è lo stereotipo del programmatore medio) che chiede di parlare con il suo superiore. La scena la immagino così:

DEV: “Hey, abbiamo un problema. Ho ripensato all’algoritmo che gestisce la carica della batteria. Esiste la possibilità che questa roba, in determinate condizioni, mandi questa procedura in pappa e sovraccarichi le batterie, con potenziali rischi”.

CTO: “Ok fixiamolo subito!”

DEV: “Va bene, ma ci vorrà almeno un mese di sviluppo. Bisogna coinvolgere l’altro team che si è occupato della cosa, questa funzionalità interferisce con altre e bisogna rifare tutti i test”

CTO: “Non ci voleva, cazzo.. il boss non sarà contento di questa cosa. Ne parlo con lui, ma dobbiamo assolutamente trovare un modo, perché non possiamo ritardare l’uscita, altrimenti l’iPhone e Pixel di Google ci faranno il culo!”

La scena si sposta al colloquio tra il CTO e il CEO.

CTO: “Abbiamo un problema. Il team di sviluppo ha trovato un falla nella gestione della batteria. Ma ci vogliono due mesi per fixare questo problema. Che facciamo?”

CEO: “Impossibile. Tra un mese c’è l’uscita del nuovo iPhone e noi non possiamo ritardare. Sarebbero milioni, se non miliardi di dollari di danni! Dovete fixare subito e andare avanti. Non c’è altra soluzione. Intesi?”

Il CTO a quel punto china il capo, sconfortato e da la notizia ai programmatori, che in qualche modo mettono una pezza al problema, ma non sono sicuri non si ripresenterà.

Questo dialogo ti suona familiare?

Ok, lo so anche io che non è andata proprio così in Samsung. Ma questa scena è abbastanza plausibile e, sai una cosa? Succede continuamente nelle aziende Italiane.

Purtroppo questi problemi esistono e, come te, ho sempre pensato che se le cose non cambiano dall’alto è IMPOSSIBILE far cambiare questo modo di lavorare.

Ma da cosa derivano questi problemi? Derivano, secondo l’analisi della mia esperienza, dalla mancata percezione del danno che fa una cosa sul lungo periodo. Modificando leggermente una delle frasi più famose di uno dei miei mentori:

“Le aziende sottostimano cosa può causare un problema al metodo di lavoro in cinque anni, e sovrastimano cosa può causare un problema operativo in un anno”.

Detto in altre parole, si interessano al problema immediato (lo smartphone deve uscire tra un mese perché se no l’iPhone esce e ci batte sul tempo!) e sottostimano che cosa potrebbe invece causare un problema strutturale sul lungo periodo (come quello delle batteria che si sovraccaricano -e poi esplodono- sul lungo periodo, se non risolto in tempo).

Questo è il motivo per cui le aziende iniziano bene e iniziano ad “ingolfarsi” sul medio e lungo periodo. E, indovina chi ne paga le conseguenze? Il team di sviluppo, ovviamente, in un’azienda di tecnologia.

È sempre colpa del team tecnico.

Ma davvero è cosi? Forse c’è bisogno di cambiare paradigma. La velocità è importante in azienda, ma non è tutto. Anche avere il controllo del volante lo è. Se vai ai duecento all’ora ma stai andando nella direzione di un muro, non guardare dove stai andando non ti salverà di certo.

Dovrai quindi fare tu il lavoro sporco e noioso di dimostrare che esiste un metodo di lavoro più sano. Si, hai capito bene. Non ci sono soluzioni. Se il tuo capo non vede la soluzione, difficilmente la vedrà in seguito. Probabilmente non la vede perché è oberato di altre cose da fare, tipicamente di operatività.

Non ha la possibilità di fermarsi, salire di qualche gradino su una scala e guardare la situazione più dall’alto. È preso da mille cose e questo è un circolo vizioso che si auto alimenta.

Il ciclo del sovraccarico da operatività

  • Troppo preso dall’operatività
  • Non ho il tempo di guardare dall’alto le cose
  • Non riesco a scoprire ed anticipare i problemi
  • Si creano altri problemi
  • Che tento di risolvere lavorando di più (operatività)
  • Produco altri errori e il ciclo si ripete all’infinito

Capisci bene che se non arriva da te l’input giusto, che ti sei accorto dei possibili problemi, non arriverà mai dal tuo capo.

La prima cosa da fare, se il management è ottuso in questo senso è: cercare le altre aziende simili alle tue che non hanno i tuoi problemi e cercare invece le aziende simili a quella in cui lavori per vedere invece che fine hanno fatto queste aziende.

Così avrai due set di case history:

  1. quelle che avevano i tuoi problemi e hanno fatto una brutta fine (perché nessuno è intervenuto a risolvere i problemi)
  2. quelle che non li hanno (e qui devi scoprire il loro metodo di lavoro)

Questo è il primo passo di tanti altri. Ma come dico sempre: le opinioni non contano, contano i fatti. Solo con i numeri e i fatti reali potrai convincere il management ad intervenire nelle aree che ritieni siano fondamentali.