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?
Nessun commento:
Posta un commento