Documenti inutili

Talvolta sento persone che si preoccupano dell'utilizzo della carta.
Beh, in caso di progetti della pubblica amministrazione, la carta non è un problema.

Ogni progetto software prodotto deve essere accompagnato durante tutto il periodo del ciclo di sviluppo da una serie di documenti: l'analisi, il disegno, i requisiti funzionali, il piano di test, il documento di integrazione, il documento di adeguamento esercizio...

Di per se tutti questi documenti hanno un senso: servono a chi coordina, a chi progetta, a chi sviluppa, a chi deve testare il funzionamento, a chi dovrà un giorno prende in mano il software per correggerlo o evolverlo.
Purtroppo però non è questo che si fa!

Tutto si riduce a riunioni con 37 persone in cui solo 2 persone si parlano (perchè sono le due persone che realmente faranno il lavoro); riunioni interminabili in cui non esce assolutamente nulla se non la data di quando rivedersi; riunioni che sono battaglie politiche fra diversi schieramenti (ne parlerò in un altro post). Da queste riunioni esce una serie di appunti, che poi si tramandano a voce e che il gruppo che sviluppa il software invece non recepisce quasi mai.

A chi produce software si racconta la cosa a voce, magari con schizzi su fogli di carta che vengono poi serbati come gioielli in scrigni (essendo l'unica cosa che spieghi in un qualche modo abbozzato cosa il software debba fare). Le idee cambiano spesso, ma i documenti no, quelli si fa la corsa a scriverli solo quando li si deve consegnare e il software è già bello che fatto da tempo.

I documenti che si producono sono quindi assolutamente inutili.
Il documento dei requisiti è sempre obsoleto e sono chiacchiere (in quanto abbozzato e lasciato così, tanto chi lo deve leggere?).
I piani di test non li vede nessuno, sono uno strumento politico; se un giorno quancosa non funziona, la pubblica amministrazione deve trovare il modo di dimostrare che così non doveva essere quindi, solo allora prenderà il documento e cercherà in tutti i modi di sfruguliare l'applicativo per farlo esplodere.
Il documento di analisi è una chimera; viene scritto alla fine chiedendo proprio a chi ha sviluppato il software come questo funziona (ma allora "l'analista funzionale" che ci sta a fare? ma questo è oggetto di un altro post).
"Scusa ma dopo aver inserito i dati anagrafici, non facevamo firmare qualcosa?", "No, a giugno ci avete detto che bastava cliccare su ok"...
"Va bene allora aggiorno il documento".

Ma del resto come biasimare il dirigente della pubblica amministrazione?
Voi vi leggereste un documento di 200 pagine con un titolo una descrizione, precondizioni e postcondizioni (che il più delle volte fanno ridere)?

titolo: login
precondizione: l'utente va alla pagina login.html
azione 1: l'utente mette username nella casella username
azione 2: l'utente mette la password nella casella password
postcondizione: username e password sono corretti
risultato: l'utente entra nella pagina privata del sito
Maddai!!!!

Immaginatevi di dover leggere e mettere il bollino su 200 pagine così....
Lo fareste?

Il modo in cui viene scritto il software non lo decide il gruppo di Sviluppo, ma il Cliente

La mia società ha sviluppato software per centinaia di migliai di euro per la pubblica amministrazione ma chi ha deciso come dovesse funzionare (non solo le funzionalità che doveva avere), soprattutto quelle più inconsistenti, assurde e balzane è stato il Cliente.

Vi lascio intendere le cose con una scenetta:
Cliente: "Bisogna costruire un razzo"
Analista: "Benissimo, dove lo dobbiamo mandare? Luna? Marte?"
Cliente: "Non saprei, basta che voli, poi vediamo"
Analista: "Abbiamo già una rotta? un centro di controllo? C'è un posto dove possiamo lanciarlo?"
Cliente: "Purtroppo non ho informazioni al momento, ditemi che vi serve e vedo se riesco a procurarlo".
A questo punto l'Analista si sente come un pusher a cui è stata chiesta una qualche non meglio identificata droga all'ultimo grido, di cui non sa nulla e va dallo Sviluppatore che dovrebbe fabbricargliela.
Analista: "Bisogna costruire un razzo che voli"
Sviluppatore: "Usiamo metallo o acciaio? Quanto deve reggere di carico? Dobbiamo trasportare uomini o macchine pesanti?..."
Analista: "Non so dirtelo in questo momento: tu inizia a costruire qualcosa, e non discutiamo troppo: l'ha chiesto il cliente"

La frase "l'ha chiesto il cliente" ha lo stesso tono e valore di quello che in ambito militare significa "è un ordine": si sta zitti e si obbedisce.

Non hai capito?... non importa
Non sai a che serve?... non importa
Non hai gli strumenti giusti?... non importa

La soluzione va accroccata perchè anche la tua società non vuole deludere il cliente e tanto, basta che passi il collaudo, che gli frega se poi gente reale dovrà usare il software...

 Questo è solo uno dei tanti esempi che aiutano a produrre la monnezza che rende inusabile il software, quindi impossibile la vita agli impiegati (che si stressano), quindi impossibile la vita al contribuente (che vorrebbe un servizio semplice, semplice)...

Vi dico solo che quando creammo un software che doveva prendere dei dati, mettemmo dei limiti: per esempio se mi registri una fattura di 100 euro non puoi effettuare pagamenti per 120 euro (su quella fattura).
Il Cliente trovò questo limite insopportabile...
Cliente: "Però se poi uno si è sbagliato a mettere la fattura da 100 ed era invece da 120?"
Sviluppatore: "Gli dite che i dati non erano corretti e vanno reinseriti"
Cliente: "Nooooo, troppo difficile, facciamo che glieli facciamo inserire lo stesso e mettiamo degli avvisi tipo rosso fuoco per far capire che ha messo troppo... ma non lo possiamo bloccare".
Sviluppatore: "Ma così poi sarà impossibile fare i conti bene, far funzionare tutto il resto..."
Cliente: "Capisco ma voglio sia fatto così, grazie!"

Morale

Per risolvere un problema che ha già una soluzione evidente, semplice, sicura, abbordabile e poco costosa viene IMPOSTA dal gradimento del dirigente del Cliente la soluzione stupida, costosa, e che genera altri problemi.

Consegne a Natale e Ferragosto (i premi produzione)

Alcune volte il progetto subisce brusche accelerate: si grida all'urgenza, si proclama che il software va consegnato per quella data, che magari è a Natale, a Ferragosto o durante qualche vacanza...
E tu che sei solo uno sviluppatore software ti chiedi: perchè?
Perchè c'è tutta questa urgenza di uscire con un software rappezzato a Natale? Sono tanti quelli che a Natale lo useranno? In fondo poi la scadenza per utilizzare questa funzione sarà a Giugno... perchè tutta questa fretta? perchè costringere gli sviluppatori a produrre pezze a colori sul software per farlo funzionicchiare?

Non si può aspettare di farlo con calma e bene? Farlo funzionante?
Eh no, si bisbiglia: ci sono i premi produzione...

Un dirigente della pubblica amministrazione prende dei premi se conclude nei termini gli obiettivi; terminare un obiettivo significa molto spesso terminare lo sviluppo di un software, non conta quando questo software viene usato, il premio va consegnato...

Facciamo solo un esempio: immaginate un nuovo software per il pagamento dell'IMU che ha il suo massimo utilizzo a Giugno; immaginate che il dirigente che se ne occupa ha un premio produzione a fine gennaio. Farà fare le notti agli sviluppatori a Natale e capodanno per consegnare un'accrocco che non funziona (e che non si sa ancora bene che deve fare) entro metà gennaio. Il prodotto esce in sordina, lui prende il premio e tutti se ne scordano. Poi 10 giorni prima della scadenza la gente comincia a usare il software, il sistema esplode e in fretta scattano le punizioni corporali per gli sviluppatori, che intanto erano su altri progetti e non sanno manco mettere le mani sull'accrocco che sono stati costretti a produrre; il fuggi fuggi alla ricerca del colpevole; ricerche di email e documenti in cui si spiegava cosa doveva fare il software (nessuno lo sa più) o email in cui si spiegava che certe cose (a causa di scelte del cliente) non avrebbero mai funzionato.

Ma in fondo poi che problema c'è: il dirigente cazzia il fornitore ma ottiene il premio, il fornitore cazzia lo sviluppatore ma guadagna delle MAC (correttive al software che vengono pagate a parte).

In pratica gli sventurati sono solo lo sviluppatore (che avrebbe voluto fare il suo lavoro e produrre software professionale e di qualità) e chi deve pagare l'IMU, che si deve smazzare l'onere di sbattere contro il computer (o al CAF) per la pratica, magari arrivare tardi, poi andare da Equitalia...

Il cerchio della vita!