Malgrado le tante certificazioni che le aziende possiedono, vedo molti progetti condotti in antitesi con le metodologie previste.
Praticamente tutte le aziende che sviluppano software possiedono una o più certificazioni ISO e diversi prodotti sono classificati come dispositivi medici (per lo più in classe 1 della precedente normativa).
In teoria quindi i progetti di realizzazione o di implementazione di software dovrebbero essere gestiti partendo dall’analisi e la modellazione dei processi, la definizione puntuale delle specifiche e dei requisiti funzionali, l’individuazione dei vincoli e delle criticità da affrontare, la valutazione dei rischi e lo studio su come mitigarli.
Nella mia esperienza la pratica è invece ben lontana da tutto ciò. C’è una forte resistenza a scrivere e documentare, quasi una forma di “allergia” a tutto ciò che sembra possa allungare i tempi. Con un’ errata interpretazione del concetto di Agile, si procede spesso in fretta per tentativi, lavorando principalmente con “mockup” o prototipi, partendo da un’analisi verbale con il committente.
Mockup e prototipi vanno bene per ragionare sull’interfaccia utente e sull’aspetto esteriore (di front-end) che le funzioni determinano; sono molto meno efficaci per illustrare le logiche di business e le complessità lato backend.
Analisi che è poi viziata dall’organizzazione che oggi le aziende software si sono date e che prevede la netta separazione tra chi è sul campo e la “fabbrica” del software. I primi, che spesso non hanno forti competenze di dominio e che quasi mai conoscono le specificità e le complessità del committente, trasmettono agli sviluppatori ciò che loro hanno compreso vada fatto, generando talvolta un effetto simile al gioco del “telefono senza filo”.
La forma prevista da tutte le metodologie e le forme di certificazione esistenti non trova quindi riscontro nella sostanza delle cose. Ciò che mi stupisce è come tutto ciò sia accettato, in qualche caso incentivato, dai committenti. Si collaudano sistemi senza o con poca documentazione, basandosi su un’analisi superficiale delle funzionalità mostrate o sulla base di pochi giorni di esercizio del software.
In questa situazione le certificazioni rappresentano un “bollino” da avere e da mostrare per partecipare alle gare e stare sul mercato; la gestione dei progetti è tutt’altra cosa.
Qual è la vostra esperienza? Siete in condizione di “scagliare la prima pietra”? Pensate che il possesso di una o più certificazioni sia davvero garanzia di qualità? Dite la vostra!
Hai ragione Massimo, le certificazioni in Italia servono solo perché sono richieste ed in molti casi necessarie, ma come tutte le cose di questo nostro paese la certificazione viene presa non per innescare un reale processo di miglioramento. Un SW ben scritto, ben documentato, bene assistito costa troppo per questa nostra economia scalcinata, fintanto che in Italia non si pagherà il SW e le professionalità come in altri paesi si dovrà fare sempre tutto al minimo. Un poco come la famosa camicia di totò, quello che non si vede non serve non è camicia.