Questo post è in risposta all'interessante (e, almeno in teoria, più che giusto) post di Andrea Boschin* su come andrebbe trattato un progetto per un software.
Nota: Se non siete del ramo (programmatori, analisti, dba, ...) è possibile (beh, diciamocelo, quasi certo) che non capiate un ciufolo ne del post di Andrea, ne della mia risposta. Ma se riuscite a leggere tra le righe, vi renderete conto che quanto dice Andrea vale anche per ambienti ben diversi dalla sola informatica.
(*): Andrea Boschin, oltre che mio conterraneo (anche lui veneto), è uno di quelli che considero GURU dell'informatica, non solo per le sue conoscenze, ma per il suo approccio sempre curioso e preciso alla materia.
Andrea ha ragionissima. Lo premetto perchè, magari, vedendo che rispondo ad un suo post con un mio post alcuni potrebbero pensare che mi sia montato la testa e che voglia confutare le sue teorie.
Niente di più falso, per due motivi.
Primo: Andrea ne sa a pacchi più di me, e se solo provassi a confutarlo farei una figura veramente magra;
Secondo: le teorie che espone non sono sue :D. Mi spiego. Quello che Andrea sostiene sono concetti che mi sono stati insegnati i primi giorni di tutti i corsi di informatica che ho seguito, a cominciare dalle lezioni del prof. Giunta, alle superiori, e che si possono riassumere nei quattro punti che presenta:
- Analizzare il problema prima di risolverlo;
- Meglio un software semplice ma robusto che un software pieno tanto di funzionalità quanto di bug;
- Iniziare il lavoro pensando nel miglior modo possibile (e, aggiungo io, escludendo momentaneamente il fattore tempo);
- Non reinventare la ruota: riutilizzare il software già scritto, o soluzioni già presenti;
Questi quattro punti dovrebbero (almeno in teoria) far parte del bagaglio culturare di chiunque lavori nell'informatica (e come ho detto, di chiunque abbia un compito da assolvere, visto che si possono portare anche in situazioni che esulano dall'informatica). E vi dirò di più: per un analista, un programmatore, un dba, questi dovrebbero essere concetti talmente radicati che non ci dovrebbe essere bisogno di sottolinearli.
Detto questo, vi sarete accorti che nel paragrafo precedente ho usato parecchi condizionali.
Questi condizionali sono dettati da quelle che sono poi le situazioni reali che si verificano a chi, in Italia, lavora nel campo dell'informatica.
Infatti, normalmente, non si riesce, a meno di sforzarsi veramente tanto, ad applicare tutti i punti sollevati da Andrea. In alcuni casi limite, non ne viene applicato nessuno.
Intanto, di norma, il cliente vuole il risultato prima di ieri. Non è disposto ad attendere che il commerciale o l'analista (con la collaborazione degli sviluppatori) mettano giù un piano di lavoro di massima e facciano una stima del tempo necessario ad implementare una certa soluzione. No, il cliente pretende di essere lui ad imporre i tempi di lavoro, e le date di consegna.
In parole povere, il cliente non si rende conto di fare parte attiva del ciclo di vita del software, ma si comporta nel classico modo: ho un problema, voglio una soluzione funzionante entro X giorni.
In questo caso, se si riesce ad applicare il punto 4, ovvero a trovare qualcosa di adatto o adattabile alle esigenze del cliente, bene. Se invece bisogna sviluppare la soluzione da zero, allora sono cavoli acidi.
In secondo luogo, anche se il cliente lascia il tempo necessario ad una corretta analisi del problema, in molte realtà italiane, anche piuttosto grosse, ci sono anelli della catena di produzione del software che sono decisamente deboli.
Qui serve un esempio. Come alcuni di voi sanno, io lavoro come consulente presso uno dei maggiori operatori di telefonia mobile italiani (l'azienda è una multinazionale). La logica vorrebbe che, in questo genere di ambiente, i processi produttivi siano il più efficienti possibile. Beata innocenza.
In primis il cliente (che per noi è un'entità interna, ma è equivalente, visto che sono quelli che definiscono i requisiti) non sempre sa chiaramente quello che vuole. Questo si traduce nel fatto che i requisiti cambiano continuamente. Se la data di scadenza si spostasse di conseguenza, poco male, ma purtroppo la data di scadenza viene decisa dal marketing, e stampata sui cartelloni che vedete per strada ben prima che i requisiti arrivino all'Analisi Funzionale.
Per fare un parallelo, è come avere un mutuo a tasso variabile con scadenza fissa il cui tasso continua a crescere. Prova te a spiegare in banca che non hai i soldi per pagare!
In secondo luogo, essendo i requisiti così fumosi, quella che chiamiamo Spefica Funzionale ritarda sempre a raggiungere gli Analisti Architetturali, che quindi ritardano il rilascio della relativa Specifica Architetturale agli Sviluppatori.
Inoltre, ma questo penso (spero) sia solo un problema specifico del nostro gruppo, gli Analisti (Funzionali e Architetturali) sono molto confusi su quella che è l'architettura dei sistemi sulla quale lavoriamo.
Ad esempio, ieri un Analista Architetturale mi è venuto a dire, candido, che lui non sapeva che tra FrontEnd e BackEnd la comunicazione avviene via WebService, ammettendo che lui di come funziona un webservice non sa nulla. Questo lo reputo gravissimo!
Come fai a far fare la Specifica Architetturale ad uno che non sa come è fatta l'architettura dei sistemi!
Non può essere che gli Analisti pensano ad illustrare il BackEnd e il FrontEnd e poi per far comunicare queste due entità qualche santo provvederà!
E infatti in specifica non c'era tutta una serie di impatti sui WebService, che portano via mezza giornata di lavoro!
Poi il riutilizzo di quanto già sviluppato viene lasciato allo sviluppatore: gli Analisti non hanno nessuna idea di quale e quanto software ci sia da riutilizzare per i vari task. Esempio: devo inserire in una maschera uno UserControl che permetta l'inserimento di un numero di telefono e un indirizzo. Lo UserControl viene validato tramite un servizio di BackEnd. Dentro questo servizio viene effettuata la validazione del numero di telefono e dell'indirizzo.
Peccato che per un altro progetto era già stato sviluppato un controllo che permetteva l'inserimento e la validazione di un indirizzo (tramite chiamata a BackEnd). Ma vuoi riutilizzare quello che è già fatto? Ma sono due chiamate a BackEnd. Vero, ma intanto la seconda la chiami solo se passa la prima, poi vuoi mettere dover riscrivere (e ritestare) tutto il codice? Per fortuna l'ho avuta vinta!
Certo, non vuol dire che bisogna arrendersi, noi sviluppatori, ed infatti il progetto attuale l'ho impostato il meglio che ho potuto (in modo che anche i collaboratori potessero essere facilitati nello sviluppo delle loro parti). Ma un aiutino anche dai processi che ci precedono non sarebbe certo male.
Insomma, quello che scrive Andrea è sacrosanto, ma non così facilmente applicabile come sembra, per un'infinità di motivi, primo tra tutti l'incompetenza di chi mettono a prendere le decisioni. In un'Italia sempre più allo sbando, la realtà dell'informatica italiana segue quello che è il trend nazionale: le decisioni le prende chi meno ne sa, senza interpellare chi magari fa il lavoro di manovalanza (o quasi) e ne sa qualcosa di più, e guardandosi bene dall'impegnarsi a capire il funzionamento effettivo delle cose.