In breve: per scegliere una software house non basta confrontare tecnologia e prezzo. Bisogna verificare come analizza i processi, definisce il perimetro, gestisce dati e codice, progetta le integrazioni, collauda il software e assicura continuità dopo il rilascio. La proposta migliore è quella che rende comprensibili responsabilità, vincoli, costi e criteri di accettazione prima di iniziare.

Prima domanda: serve davvero un software su misura?

La selezione del fornitore viene dopo una decisione più importante: capire se il problema richiede un prodotto standard, una configurazione, un’integrazione oppure uno sviluppo personalizzato.

Un software su misura ha senso quando il processo distingue l’azienda, coinvolge più sistemi, contiene regole non coperte dagli strumenti esistenti o produce abbastanza valore da giustificare sviluppo e manutenzione. Se il bisogno è comune e già risolto bene dal mercato, configurare un prodotto affidabile può essere più rapido ed economico.

Per questa prima scelta è utile partire dal confronto tra gestionale standard e gestionale su misura. Solo dopo aver chiarito il tipo di soluzione conviene valutare chi dovrà realizzarla.

1. Parte dai processi o da un elenco di funzionalità?

Un elenco di schermate non descrive ancora un sistema. La software house dovrebbe ricostruire:

  • chi svolge ogni attività;
  • quali dati entrano ed escono;
  • quali eccezioni si verificano;
  • quali strumenti sono già utilizzati;
  • dove nascono errori, attese o duplicazioni;
  • quali risultati devono migliorare.

Questa analisi impedisce di digitalizzare un processo inefficiente senza correggerlo. Il primo documento utile non è quindi una lista di tecnologie, ma una mappa condivisa del lavoro attuale e del flusso desiderato.

Prima del confronto conviene preparare alcuni esempi reali: un ordine completo, un documento usato ogni giorno, una situazione che genera eccezioni e l’elenco degli strumenti coinvolti. Non serve scrivere da soli un capitolato tecnico. Serve mostrare come il lavoro avviene davvero, comprese attività manuali, passaggi informali e controlli che oggi dipendono dall’esperienza delle persone. La guida su come progettare un gestionale partendo dai processi aiuta a organizzare queste informazioni senza trasformarle prematuramente in funzioni o schermate.

2. Distingue requisiti indispensabili, utili e rinviabili?

Quando tutto è prioritario, budget e calendario diventano poco controllabili. Una proposta valutabile separa almeno:

  1. funzioni necessarie per rendere operativo il primo rilascio;
  2. miglioramenti importanti ma non bloccanti;
  3. idee da verificare con l’uso reale;
  4. elementi esplicitamente esclusi.

Il perimetro deve chiarire anche utenti, ruoli, volumi, dispositivi, lingue, integrazioni e dati da migrare. Le esclusioni riducono le incomprensioni quanto l’elenco delle funzioni incluse.

È utile chiedere che assunzioni e dipendenze siano visibili accanto alla stima. Se, per esempio, il cliente deve fornire un’API, ripulire un archivio o approvare i prototipi entro una data, quel contributo incide sul calendario. Rendere esplicite queste condizioni consente di confrontare proposte costruite sullo stesso perimetro.

3. Propone una fase di analisi o un progetto pilota?

Per un sistema complesso è prudente ridurre l’incertezza prima di costruire tutto. Una fase iniziale può produrre:

  • mappa dei processi;
  • requisiti e priorità;
  • prototipo delle interfacce critiche;
  • verifica delle API disponibili;
  • modello dei dati;
  • rischi tecnici;
  • stima aggiornata per fasi.

Un progetto pilota deve avere un obiettivo misurabile e un confine preciso. Non è una versione incompleta del prodotto finale: serve a verificare l’ipotesi più rischiosa con un investimento controllato.

4. Spiega come il software dialogherà con gli altri sistemi?

Gestionali e web app raramente lavorano da soli. Possono dover scambiare dati con e-commerce, CRM, ERP, macchine, sistemi documentali, corrieri, pagamenti o servizi pubblici.

Prima di approvare il progetto bisogna conoscere:

  • sistemi responsabili di ciascun dato;
  • API, file o protocolli disponibili;
  • frequenza dello scambio;
  • gestione di duplicati ed errori;
  • log e possibilità di ripetere un’operazione;
  • versioni delle interfacce;
  • funzionamento previsto quando un servizio esterno non risponde.

Il progetto Alfonso Forni mostra perché lo sviluppo non coincide con una singola interfaccia: e-commerce, gestionale, flussi interni e macchine utensili devono condividere informazioni controllate.

5. Chiarisce proprietà, accesso e portabilità dei dati?

Il contratto e il progetto tecnico dovrebbero specificare:

  • chi è titolare dei dati;
  • dove vengono conservati;
  • chi può accedere agli ambienti;
  • quali esportazioni sono disponibili;
  • in quale formato vengono consegnati i dati;
  • tempi e modalità di restituzione alla fine del rapporto;
  • procedure di cancellazione e conservazione dei backup.

L’esportazione non dovrebbe essere discussa soltanto quando si decide di cambiare fornitore. Va progettata dall’inizio, insieme a ruoli, permessi e tracciamento delle operazioni.

6. Definisce licenza, codice sorgente e piano di uscita?

“Software su misura” non significa automaticamente che ogni componente diventi proprietà esclusiva del cliente. Possono coesistere:

  • codice sviluppato specificamente per il progetto;
  • librerie open source;
  • componenti riutilizzabili del fornitore;
  • servizi cloud e API di terze parti;
  • licenze commerciali.

La proposta deve distinguere questi elementi e indicare cosa accade alla fine del rapporto: disponibilità del repository, documentazione, credenziali, procedura di consegna, dipendenze esterne e attività necessarie per un eventuale passaggio.

7. Integra la sicurezza nel ciclo di sviluppo?

La sicurezza non è un controllo da aggiungere alla fine. Requisiti, ambienti, accessi, dipendenze, log, backup, aggiornamenti e gestione delle vulnerabilità devono essere previsti durante tutto il ciclo.

Domande concrete:

  • sviluppo, test e produzione sono separati?
  • gli accessi seguono il principio del privilegio minimo?
  • segreti e credenziali sono esclusi dal codice?
  • dipendenze e aggiornamenti vengono controllati?
  • esistono test per autorizzazioni e dati sensibili?
  • come vengono gestiti incidenti e vulnerabilità dopo il rilascio?

Il Secure Software Development Framework del NIST organizza le pratiche tra preparazione, protezione del software, produzione sicura e risposta alle vulnerabilità. L’OWASP ASVS può essere usato per rendere verificabili i requisiti di sicurezza delle applicazioni web.

8. Considera accessibilità e usabilità come requisiti?

Un software può essere tecnicamente corretto e comunque rallentare chi lo utilizza. La valutazione dovrebbe includere:

  • attività frequenti completabili con pochi passaggi;
  • messaggi di errore comprensibili;
  • interfaccia utilizzabile da tastiera;
  • contrasto e focus visibili;
  • campi e controlli correttamente etichettati;
  • adattamento ai dispositivi previsti;
  • test con persone che conoscono davvero il processo.

Le WCAG 2.2 del W3C offrono criteri verificabili per l’accessibilità dei contenuti e delle interfacce web. Il livello da raggiungere e il perimetro devono comparire nei requisiti, non essere lasciati impliciti.

9. Descrive come verrà collaudato il progetto?

“Il software funziona” non è un criterio di accettazione. Per ogni funzione importante servono condizioni osservabili:

  • dato di partenza;
  • azione eseguita;
  • risultato atteso;
  • permessi necessari;
  • comportamento in caso di errore;
  • evidenza del test.

Il collaudo dovrebbe coprire anche migrazione, integrazioni, ruoli, notifiche, backup e ripristino. Va chiarito chi prepara i dati, chi esegue le prove e come vengono classificati gli eventuali difetti.

10. Rende visibile l’avanzamento?

Un progetto controllabile dispone di un ritmo di confronto e di artefatti condivisi. A seconda della dimensione possono bastare:

  • backlog con priorità;
  • dimostrazioni periodiche;
  • ambiente di staging;
  • registro delle decisioni;
  • elenco di rischi e blocchi;
  • note di rilascio;
  • responsabilità per le approvazioni.

Non serve imporre una metodologia per nome. Serve sapere come il cliente vedrà ciò che è stato completato, cosa sta cambiando e quali decisioni richiedono il suo intervento.

11. Separa sviluppo, manutenzione e assistenza?

Il preventivo iniziale non esaurisce il costo del sistema. Prima della firma bisogna distinguere:

  • correzioni incluse nel periodo di garanzia;
  • manutenzione evolutiva;
  • aggiornamenti di sicurezza e dipendenze;
  • hosting e monitoraggio;
  • backup e ripristino;
  • assistenza agli utenti;
  • tempi di presa in carico;
  • interventi fuori orario;
  • costi delle piattaforme esterne.

Un accordo chiaro non promette disponibilità illimitata: definisce servizi, orari, priorità e responsabilità in modo coerente con il rischio operativo.

12. Mostra prove pertinenti e un team coerente?

Un caso utile non deve essere identico al nuovo progetto, ma deve dimostrare capacità rilevanti: processi complessi, integrazioni, gestione dei dati, accessibilità, settore regolato o continuità operativa.

Per valutare l’esperienza:

  • chiedere quale problema è stato risolto;
  • distinguere lavoro del fornitore e tecnologie di terzi;
  • verificare se il caso è ancora rappresentativo;
  • comprendere chi lavorerà concretamente al progetto;
  • controllare come vengono coperte analisi, sviluppo, design, test e gestione.

È utile consultare i casi DLM Design e il team separatamente: i casi mostrano il lavoro, il team chiarisce le competenze coinvolte.

Matrice per confrontare più proposte

Area Cosa dovrebbe essere verificabile Segnale da approfondire
Problema processo, utenti, obiettivi e vincoli proposta basata soltanto sulle schermate richieste
Perimetro incluso, escluso, priorità e dipendenze preventivo sintetico senza assunzioni
Integrazioni sistemi, dati, errori e log “si integra” senza aver verificato API o formati
Dati accessi, esportazione, backup e cancellazione portabilità non descritta
Codice e licenze componenti, repository e piano di uscita proprietà indicata in modo generico
Sicurezza requisiti, test, aggiornamenti e incidenti sicurezza rinviata al rilascio
Collaudo casi di prova e criteri di accettazione approvazione basata solo su una demo
Continuità manutenzione, SLA, documentazione e backup costi successivi non distinti

Dieci domande da fare durante il primo confronto

  1. Quale parte del nostro processo volete analizzare prima di proporre la soluzione?
  2. Quali assunzioni state usando per preparare la stima?
  3. Cosa escludete dal primo rilascio?
  4. Quali integrazioni devono essere verificate prima di confermare tempi e costi?
  5. Come potremo esportare dati e documenti?
  6. Quali componenti saranno nostri, concessi in licenza o forniti da terzi?
  7. Come definite e dimostrate il completamento di una funzione?
  8. Quali controlli di sicurezza e accessibilità includete?
  9. Cosa accade dopo il rilascio e quali costi sono ricorrenti?
  10. Come avverrebbe il passaggio a un altro fornitore?

Segnali che richiedono un approfondimento

Non sono automaticamente motivi per scartare una proposta, ma meritano una risposta scritta:

  • prezzo definitivo prima di aver verificato integrazioni e dati;
  • tempi senza dipendenze o responsabilità del cliente;
  • nessuna distinzione tra prototipo e prodotto operativo;
  • ambienti, backup o manutenzione non citati;
  • esportazione dei dati rimandata a fine progetto;
  • collaudo descritto soltanto come “verifica del cliente”;
  • scelta tecnologica presentata come obiettivo invece che come conseguenza dei requisiti.

Cosa deve contenere un preventivo confrontabile

Un preventivo utile dovrebbe permettere di ricostruire:

  1. obiettivo e contesto;
  2. perimetro funzionale;
  3. utenti e ruoli;
  4. dati e integrazioni;
  5. deliverable;
  6. fasi e dipendenze;
  7. criteri di accettazione;
  8. costo iniziale e costi ricorrenti;
  9. manutenzione e assistenza;
  10. proprietà, licenze e uscita.

Il prezzo resta importante, ma diventa confrontabile soltanto quando le proposte coprono responsabilità e risultati simili.

Il metodo DLM per avviare un progetto software

Il metodo DLM parte dal problema operativo, costruisce un perimetro verificabile e procede per rilasci controllati. Per un gestionale su misura o una web app il primo passo può essere un’analisi dei processi, non necessariamente lo sviluppo immediato.

Se devi valutare un progetto, porta al primo confronto un processo concreto, gli strumenti già usati, le persone coinvolte e il risultato che vuoi migliorare. Da questi elementi è possibile capire se serve configurare, integrare o sviluppare.

Parliamo del progetto

Fonti tecniche