Mai

Quando ho iniziato a lavorare scrivevo codice. Funzionava così: il cliente ti chiedeva un software ("un programma", dicevamo ai tempi). Analisi, sviluppo. Test (funziona? si\no). Consegna. Era semplice, anche perché ho sempre lavorato nel mondo dello sviluppo stand-alone e in quello che oggi chiameremmo "dipartimentale" (cioè su PC). C'erano dei tempi, si, ma se si andava lunghi (e onestamente non ricordo una sola volta in cui mi sia successo) lo si diceva al cliente e lui rispondeva 'ok'.

Adesso il software è certamente più complesso. Il progetto in cui sto lavorando ora sviluppa l'app mobile per una banca. Ci sono un sacco di variabili e di attori coinvolti. Inoltre i test sono più complessi e molto, molto, molto più importanti (non si può consegnare a centinaia di migliaia di clienti una app che non funziona).

Detto questo: le tempistiche sono definite a tavolino. Dobbiamo (DOBBIAMO) rilasciare la versione x ad agosto, la versione x+1 ad ottobre, la versione x+2 entro fine anno. Gli sviluppatori devono lavorare su più versioni del sw in contemporanea. E, a mia memoria, non c'è stata una volta in cui siamo riusciti a rispettare le tempistiche prestabilite. Che significa? Che si lavora male? Possibile. Che il gruppo è sottodimensionato? Più che possibile. Che le stime sono fatte male? Una certezza. 

Ma ciò che è peggio è che sento dire cose del tipo "non possiamo sforare, piuttosto rilasciamo l'app con tutti i bug". Consegniamo qualcosa che non funziona, certo, ma lo facciamo nei tempi previsti.

Ho ripetuto fino alla nausea quanto sia stanco di questo lavoro. Ecco, questo è uno dei motivi principali: consegnare qualcosa che non funziona, pur di rispettare le pianificazioni, non è il mio lavoro, non lo è mai stato e non lo sarà mai.