Come relazionarsi ed affrontare l’acquisto di un software
Ormai l’era della digitalizzazione comporta la necessità (ed in taluni casi l’obbligatorietà) dell’informatizzazione e della dematerializzazione di imprese e pubbliche amministrazioni quale conseguenza delle evoluzioni tecnologiche e normative. In tale contesto innovativo, diviene quindi un’esigenza (ma anche un’opportunità) ipotizzare e commissionare progetti software a fornitori esterni, con le conseguenti plausibili problematiche legate all’eventuale mancanza delle competenze interne all’organizzazione (per mission o dimensione aziendale) che permettano di seguire e chiudere con successo una tale fornitura ottenendo un prodotto funzionante ed efficiente.
La problematica maggiore risiede comunque nel fatto che non si ha la reale sensazione della complessità di un progetto software, conseguentemente è interessante analizzare velocemente uno dei tanti cartoon, circolanti in rete, legati alla gestione di un progetto a livello di relazioni tra cliente e software house, relativamente a cosa viene compreso realmente, a cosa viene chiesto, a cosa viene prodotto e a come viene passata l’informazione nel sistema aziendale. Uno dei cartoon più famosi (e “antichi”, in quanto probabilmente evolve la tecnologia, ma le problematiche restano le medesimi) a forma di albero è il “what the customer wanted” reperibile sul sito http://projectcartoon.com/, importante da analizzare in un periodo di crisi come quello che l’intera comunità mondiale sta affrontando, dove ciò che conta è massimizzare il livello di comunicazione, migliorando i rientri e i feedback con il cliente, che non ha più la possibilità di sperperare il proprio denaro per lo sviluppo di sistemi informativi inutili o inutilizzabili.
Tutto inizia da “come viene spiegato dal cliente” il progetto, il momento più importante: è necessario prestare molta attenzione a tale fase, effettuare numerosi ricicli eventualmente grafici e accompagnati da scenari di varia natura a supporto dei diagrammi di contesto.
La fase successiva è ancora più delicata espressa dalla frase “come viene compreso dal capo progetto”, in quanto legata ai rapporti intra-aziendali, motivo per il quale è necessaria sempre una comunicazione validata e non ambigua in maniera tale che tutte le funzioni aziendali coinvolte possano esattamente sapere cosa fare. Il passaggio all’analista, “come viene disegnato dall’analista” è anche fondamentale in quanto le basi dell’applicazione vengono stabilite in tale fase e i numerosi eventuali ricicli non potranno che mettere “toppe” ad un progetto mal concepito. La fase successiva, “come viene scritto dal programmatore” verte sulle capacità personali: non tanto sulla capacità di scrivere un codice quanto sulla capacità di interpretare un documento si spera “ben scritto”, quindi di interloquire con la gerarchia aziendale per poter verificare il codice e le impostazioni.
Il commerciale chiaramente lavora su un livello diverso e questo lo si evidenzia dalle sezioni “come viene descritto dal venditore” e “come è stato fatturato al cliente”, in quanto legato esclusivamente ai rientri economici e alla pubblicità, che spesso, se non rispecchia realmente il prodotto che si sta vendendo, diviene controproducente.
Problema classico di ogni progetto, legato alla velocità con cui i progetti si accumulano, cambiano e si evolvono è la documentazione (“come viene documentato il progetto”), che risulta invece il core, in quanto (parere personale) un progetto software senza documentazione a corredo vale zero perché non formalmente verificabile, non comprensibile, non manuntenibile, non scalabile, non aggiornabile, non evolvibile.
Altro problema legato alla “fretta” di consegnare un’applicazione risulta essere la reale (o meno) presenza di tutte le funzionalità dichiarate a livello di contratto (“quali sono le funzioni installate”), che, per fortuna, le moderne metodologie di sviluppo agile permettono di arginare, in quanto comportano uno stretto ciclo di sviluppo-test-messa in esercizio.
L’affiliazione al cliente è legata invece alla capacità di assistenza (“come viene supportato”), in quanto è necessario non tanto soddisfare il cliente in ogni sua richiesta, ma far sentire allo stesso la presenza di un fornitore che si interessi della fruibilità del software consegnato anche in prospettiva di future evoluzioni.
Si giunge all’ultima vignetta, nella speranza che non si presenti mai: “quello di cui ha veramente bisogno il cliente”, legata al fatto di non aver compreso cosa il cliente realmente volesse, di qui l’importanza della prima fase, ovvero comprendere esattamente (o con un minimo margine di errore) cosa il cliente realmente vuole con tutti gli strumenti possibili e disponibili.
Ciò che è importante è quindi creare un rapporto di fiducia con il cliente che permette non solo di garantire futuri progetti, ma anche di allargare il bacino degli utenti di rete. Il fornitore non dovrebbe mai manipolare e direzionare l’utente verso i propri prodotti (e interessi), ma comprendere i reali obiettivi, per poi poter sviluppare (o giustamente riciclare) al meglio il codice.
Chiaramente, quale altra faccia della medaglia, è necessario evidenziare e comprendere la necessità che un progetto ben posto e sviluppato, ovvero di qualità, possa avere costi superiori a fronte delle elevate prospettive competitive di manuntenibilità, scalabilità e modularità.
Conseguentemente, è necessario comprendere gli elementi fondamentali da attenzionare nel rapporto con il fornitore allorquando si ipotizzasse di commissionare un progetto software. I principali possono essere riassunti in:
- Attenzionare l’analisi, in quanto più si “parla”, più si riesce a migliorare la comunicazione tra committente e fornitore e a chiarire tutte le specifiche.
- Utilizzo di tecnologie open-source e sviluppo con software libero o a codice sorgente aperto, ovvero senza licenza a pagamento, evitando la sorpresa finale che comporta un “esborso” di somme non necessarie (se preventivamente valutate), in quanto esistono ormai una grande quantità di componenti free ma affidabili: dai database (ad es. MySQL), ai server (ad es. Tomcat o JBoss), ai linguaggi di programmazione (ad es. Java o Php). Inoltre, è necessario porre attenzione anche alle componenti di terze parti (librerie, plugin o utility) utilizzate nello sviluppo di un qualunque software, in quanto, anche in tal caso, è indispensabile conoscere ed essere edotti sulle relative licenze e sulle limitazioni derivanti dall’utilizzo di componenti soggette a licensing. È sufficiente che il codice software che si acquista (comprensivo delle eventuali componenti di terze parti) presenti una licenza di tipo “GNU General Public License” o similare per poter usare, modificare ed eventualmente ridistribuire il codice.
- Proprietà della soluzione sviluppata, se rientra nei costi (è obbligatorio per le pubbliche amministrazioni in ottica di riusabilità, ai sensi del CAD). Infatti, se l’obiettivo è poter subito far evolvere il codice, magari all’interno dell’organizzazione con costi nettamente inferiori, può risultare interessante avere il codice sorgente. Se invece lo scopo è mantenere per un periodo medio lungo il rapporto con il fornitore in essere, tale spesa potrebbe essere evitata.
- Approccio agile e milestone definite, ovvero è necessario interfacciarsi costantemente con il fornitore al fine di poter dare feedback costanti e continui. Questo per evitare di ricevere, alla fine dello sviluppo, un prodotto non corrispondente in alcuna maniera non tanto al contrattualizzato, quanto all’idea che si voleva fosse sviluppata. Conseguentemente, è anche necessario che vengano affiancati ai collaudi e pianificati già dall’inizio, diversi momenti di controllo con i relativi rilasci (anche piccoli), da verificare e contestualizzare con eventuali note e rettifiche su flussi e layout.
- Collaudare bene e verbalizzare sempre, in quanto, in fase di collaudo del software, è possibile accettare il prodotto se è perfettamente funzionante, ovvero se presenta fix facilmente risolvibili in tempi concordati; ma è anche possibile rifiutarlo nel caso in cui, per diverse motivazioni, non riscontra assolutamente l’idea del committente; in ultimo accettarlo con riserva. L’esito positivo del collaudo comporterà l’accettazione delle funzionalità, dando quindi luogo all’avviamento del sistema (nel caso di collaudo finale) ed alla contabilizzazione delle attività svolte.
- Attenzionare il layout, in quanto un applicativo deve essere sempre sia compatibile, ovvero visibile su differenti browser, spesso legati a differenti Sistemi Operativi (ad esempio, Internet Explorer per Windows o Safari per macOS) in maniera tale da non costringere l’utente, spesso inesperto, a dover aggiornare i suoi sistemi, sia responsivo, ovvero visualizzabile facilmente su diversi dispositivi (quali smartphone o tablet), tanto da rendere tale approccio competitivo con le app.
- Applicazione di usabilità, accessibilità e privacy sia per rendere un servizio fruibile all’utenza sia per soddisfare gli obblighi normativi, anche ai sensi dell’applicazione del nuovo codice europeo GDPR (General Data Protection Regulation).
- Applicazione di Cybersecurity in fase di autenticazione (fino all’uso di SPID), di navigazione (con uso di protocolli sicuri) e conservazione dei dati (ovvero relativamente ai server fisici).
- Presenza di Piani di Business Continuity e Disaster Recovery e backup dei dati per salvaguardare software e valore aziendale dei dati.
- Rilascio di tutta la documentazione necessaria non solo all’uso, ma principalmente alla comprensione e alla configurazione del software a fini evolutivi e manutentivi. Infatti, anche in ottica di riusabilità, risulta necessario accedere sempre e comunque alla documentazione (anche essenziale) per poter comprendere come è stato progettato, come è stato realizzato, come è stato configurato ed installato e da quali componenti è costituito (tra cui librerie, servizi esterni e file di configurazione).
- Rilascio del piano dei test completo in ottica di manutenzione correttiva.
- Formazione del personale dove necessario.
- Definizione dei livelli di manutenzione e di garanzia, al fine di poter risolvere le tipologie di bug legati al software consegnato o gestire tempestivamente problematiche di rete, hardware o sistemistiche legate all’ambiente su cui risiede l’applicativo.
Naturalmente, l’interfacciamento continuo in fase implementativa e le consegne intermedie risultano lo strumento più utile per evidenziare le eventuali problematiche, riducendo il lavoro a chiusura progetto per entrambe le parti. È necessario notare che tale approccio è proattivo sia per il cliente sia per il fornitore, in quanto se al cliente vien dato maggiore controllo sull’evoluzione del progetto, al fornitore viene fornita assistenza sull’evoluzione corretta del software: dai test che il cliente esegue, alla possibilità di evolvere ulteriormente l’applicativo.
Non esiste, a tal proposito, un prontuario, ma fondamentalmente delle linee guida di qualità del software, sia internazionali sia fornite da AgID (Agenzia per l’Italia Digitale). Come riferimenti concreti possono comunque essere usate sia le specifiche tecniche delle varie convenzioni Consip (Concessionaria Servizi Informativi Pubblici) [1], in cui, tra l’altro, sono indicati gli standard prestazionali e i livelli di manutenzione e gestione, sia i rari testi di riferimento [2], in cui sono indicati anche metodi pratici per confronto offerte. Chiaramente, se non è presente personale interno (o non è possibile acquisirlo) preposto sia a seguire i progetti nella fase di sviluppo, sia successivamente a gestirne l’ordinario e la manutenzione, è necessario essere supportati da esperti o ingegneri dell’informazione che possano sia affiancare e formare il personale interno, sia “accompagnare” lo stesso nella gestione di un progetto, dai concetti preliminari, al rapporto con il fornitore, alla definizione dei requisiti ai sensi della normativa vigente, alla valutazione della documentazione, fino all’indicazione di metodologie per l’analisi manageriale, il controllo dell’evoluzione ed il collaudo dello stesso.
Il tutto al fine di definire al meglio le richieste e ridurre al minimo la confusione delle offerte di fornitura, per ottenere un prodotto che soddisfi le esigenze dell’organizzazione e sia durevole negli anni, in quanto ogni azienda di sviluppo software ha un proprio approccio commerciale, lavora su diverse tecnologie e fornisce servizi differenti.
Note
- [1] Convenzioni Consip: http://www.consip.it/
- [2] Luciano Manelli “Scegliere e commissionare un software” – EPC Editore: https://www.epc.it/Prodotto/Editoria/Libri/Scegliere-e-commissionare-un-software/3412
A cura di: Luciano Manelli
Ingegnere dell'Informazione. Laureato in Ingegneria Elettronica al Politecnico di Bari. Ha conseguito il Dottorato di Ricerca in Informatica presso il Dipartimento di Informatica dell’Università degli Studi di Bari Aldo Moro, lavorando sul Grid Computing e sui Metodi Formali e redigendo articoli scientifici internazionali. Docente accreditato del CNI - Consiglio Nazionale degli Ingegneri, è docente a contratto presso il Politecnico di Bari per il corso di Informatica per l'Ingegneria. Professionista certificato, socio AICA - Sezione Territoriale Puglia, Segretario della Commissione ICT dell’Ordine degli Ingegneri di Taranto, socio della delegazione Federmanager Puglia e autore di testi universitari e tecnici per varie case editrici (tra cui MAGGIOLI ed EPC), dopo aver lavorato 13 anni per InfoCamere S.C.p.A., dal 2014 è impiegato presso l’Autorità di Sistema Portuale del Mar Ionio.
