Quanto costa un software su misura: cosa fa salire davvero il preventivo

Due persone possono chiedere entrambe «un piccolo gestionale» e avere in mente lavori molto diversi. Una deve salvare clienti e note. L'altra deve gestire sedi, contratti, permessi, dati da importare e un collegamento con il programma di fatturazione.

Per capire quanto costa un software personalizzato, bisogna quindi vedere come lavoreranno le persone che lo useranno, quali regole dovrà seguire e cosa dovrà succedere quando qualcosa va storto. Contare le schermate non basta.

Un pulsante può nascondere molte regole

Prendiamo un pulsante con scritto «Approva». Disegnarlo è semplice. Per farlo funzionare bisogna però decidere chi può usarlo, in quale momento, cosa cambia dopo il clic, chi riceve una notifica e come si può correggere un'approvazione fatta per errore.

Ognuna di queste regole va sviluppata e provata. Un software con un solo tipo di utente è più semplice di uno con ruoli e permessi diversi. Anche conservare la cronologia o gestire due persone che cambiano lo stesso dato richiede altro lavoro.

Vale lo stesso per le integrazioni. «Collegare il programma di fatturazione» sembra una funzione sola, ma bisogna decidere quali dati inviare, quali ricevere, cosa fare se il servizio non risponde e come evitare di creare due volte la stessa fattura.

Ecco perché due software con cinque schermate possono avere costi molto diversi: le schermate possono sembrare simili, ma dietro seguono regole diverse.

Se il progetto non è ancora chiaro, la stima sarà meno precisa

Quando non è ancora chiaro cosa deve fare il software, chi prepara il preventivo deve fare molte ipotesi. Può includere un margine per coprire il lavoro che potrebbe emergere oppure può stimare una versione minima e aggiungere il resto in seguito. In entrambi i casi è difficile ottenere subito una cifra precisa.

L'analisi iniziale serve a ridurre queste ipotesi chiarendo chi userà lo strumento, quali attività dovrà completare, quali casi particolari capitano spesso e quali dati sono già disponibili. Per farlo non serve un documento enorme.

«Abbiamo tutto in Excel», per esempio, può indicare un file ordinato con colonne coerenti. Può anche significare sette file compilati in modi diversi, con clienti duplicati e date scritte in tre formati. Prima di importare questi dati bisogna pulirli, scegliere quali sono corretti e decidere dove salvarli nel nuovo software.

Prima di iniziare, vale anche la pena capire se Excel debba davvero essere sostituito. In alcuni casi organizzare meglio il foglio può essere sufficiente e costare molto meno. Se costruisci un software senza prima sistemare i dati, porterai gli stessi problemi nel nuovo strumento.

La prima versione deve permettere di finire un lavoro

Per contenere il costo si parte spesso da una prima versione, chiamata anche MVP. Se però inserisci un pezzo di ogni funzione, rischi di avere molte schermate senza riuscire a completare un'attività dall'inizio alla fine.

Se il problema riguarda le richieste in arrivo, una prima versione utile potrebbe raccoglierle, assegnarle a una persona, aggiornarne lo stato e mantenere la cronologia. I report avanzati possono aspettare. Se manca l'assegnazione, invece, il team dovrà continuare a usare anche il vecchio sistema per completare il lavoro.

È più utile completare un processo piccolo e farlo usare davvero al team. Dopo le prime settimane sarà più semplice decidere cosa aggiungere e cosa può aspettare.

Con un CRM il ragionamento è identico. Prima di costruirne uno, controllo se un prodotto esistente regge già le attività principali. Nell'articolo su CRM standard e CRM su misura spiego anche una soluzione intermedia: mantenere il prodotto esistente e sviluppare soltanto la funzione specifica che manca.

Quando ha senso un preventivo a prezzo fisso

Un prezzo fisso funziona quando è abbastanza chiaro cosa verrà realizzato, da quali altri servizi dipende il progetto e come verrà verificata la consegna. Se durante il lavoro aggiungi funzioni o cambi quelle concordate, aumenta anche il lavoro necessario e il preventivo va aggiornato.

Se ci sono ancora molti dubbi, puoi dividere il progetto in fasi. Prima chiarisci il processo, poi provi un prototipo e infine sviluppi la prima versione. Alla fine di ogni fase avrai più informazioni per stimare quella successiva.

Pagare in base al tempo può essere adatto quando le priorità cambiano spesso. Servono però un limite di spesa e aggiornamenti regolari sul lavoro completato, altrimenti diventa difficile controllare il budget.

Per confrontare due preventivi, oltre al totale controllerei:

• quali casi sono compresi e quali no;
• chi prepara e pulisce i dati;
• quali servizi esterni sono necessari;
• come vengono gestite modifiche e verifiche;
• chi possiede codice, account e dati;
• cosa è previsto dopo la pubblicazione.

Se le risposte sono diverse, i due preventivi non stanno descrivendo lo stesso lavoro.

Il costo continua dopo la pubblicazione

Un software usa quasi sempre servizi esterni, come hosting, database, email, mappe, pagamenti o API. Alcuni hanno un costo fisso, altri aumentano con l'utilizzo. Chiedi di indicarli prima, anche se li pagherai direttamente a un altro fornitore.

Va considerata anche la manutenzione. I browser e i servizi esterni cambiano, possono emergere errori e il lavoro dell'azienda può evolvere. Non serve per forza un contratto costoso, ma deve essere chiaro chi interverrà, in quali tempi e per quali attività.

Controlla anche a chi appartengono account, codice e dati. Se sono intestati all'azienda, in futuro sarà più semplice cambiare fornitore o continuare lo sviluppo con un'altra persona.

Per ricevere una stima utile, porterei il materiale che usi oggi, un esempio di attività normale e due casi che creano spesso problemi. Con queste informazioni si può capire se serve davvero un prodotto dedicato, quale parte sviluppare per prima e cosa rimandare.

È lo stesso punto di partenza che uso per i software e gestionali su misura: ricostruisco il processo e preparo un prototipo prima di scrivere il codice. Il preventivo dovrebbe poi spiegare cosa verrà costruito, cosa resta fuori e quali costi continueranno dopo la pubblicazione.