La domanda arriva sempre nella prima call, e quasi sempre con lo stesso imbarazzo: “ma più o meno, quanto viene?”. La risposta onesta è che dipende — ma dipende da cose precise, non da una nuvola. Vale la pena spiegare quali.
Perché quasi nessuno pubblica un listino
Un preventivo per una web app non è come uno per un sito vetrina. In un sito vetrina il perimetro è quasi sempre lo stesso: alcune pagine, un form, contenuti. In una web app il perimetro è il vostro processo, e nessun processo assomiglia davvero a un altro.
Due aziende dello stesso settore, stesse dimensioni, possono avere bisogno di due software con un rapporto di costo di uno a quattro. Non perché una sia più esigente, ma perché una ha tre passaggi di approvazione e l’altra ne ha uno.
Un listino pubblicato sarebbe quindi o inutilmente vago, o falso. Quello che si può fare è spiegare quali variabili spostano davvero l’ago.
Le cinque cose che determinano il costo
1. Quanti flussi diversi deve coprire
Non conta il numero di schermate, conta il numero di percorsi. Un gestionale che serve solo a registrare ore lavorate è un flusso. Uno che gestisce preventivo, ordine, produzione, consegna e fatturazione sono cinque flussi che devono anche parlarsi fra loro. La complessità non cresce in modo lineare: cresce con le connessioni.
2. Quanti tipi di utente ci sono
Un solo tipo di utente interno è la situazione più semplice. Aggiungere il cliente esterno significa aggiungere permessi, sicurezza, interfacce diverse e casi limite. Aggiungere un terzo ruolo — l’agente, il fornitore, il consulente — moltiplica ancora.
3. Con quanti sistemi deve integrarsi
È la voce più sottovalutata. Un’integrazione con un servizio moderno e ben documentato può costare pochi giorni. Un’integrazione con un gestionale del 2009 che espone i dati solo via file esportati a mano può costare più di tutto il resto dell’applicazione. Chiedete sempre di verificare questo punto prima della firma, non dopo.
4. Quanto sono sporchi i dati esistenti
La migrazione è la sorpresa classica. Quindici anni di dati inseriti da persone diverse, con convenzioni diverse, campi usati per scopi che non erano i loro. Ripulirli è lavoro vero, e nessuno lo mette a preventivo perché nessuno lo guarda prima.
5. Chi lo manterrà
Un software che dovrà essere mantenuto da un team interno va scritto e documentato diversamente da uno che resta in carico a chi lo ha costruito. Costa qualcosa in più all’inizio e molto meno negli anni successivi.
Perché diamo il preventivo solo dopo il prototipo
Nessuno di questi cinque punti si può valutare seriamente in una prima chiamata. Per questo lavoriamo in due tempi: prima una fase breve di analisi e prototipo, poi il preventivo di sviluppo.
È un approccio che a volte fa storcere il naso — “ma io volevo solo sapere quanto costa” — ed è comprensibile. Il punto è che un numero dato al buio è utile a chi vende, non a chi compra: o è gonfiato per coprire il rischio, o è ottimista e diventerà una serie di variazioni in corso d’opera.
Un preventivo scritto su un’idea è una scommessa. Su un prototipo provato è una stima. La differenza la pagate comunque: o prima, in analisi, o dopo, in extra.
Come farsi un’idea prima di chiamare qualcuno
Se volete arrivare preparati a una conversazione con un fornitore, provate a rispondere per iscritto a queste domande. Vi servirà con noi come con chiunque altro:
- Quante persone useranno lo strumento e con quali ruoli diversi.
- Quali sistemi esistono già e devono continuare a funzionare.
- Qual è il singolo passaggio che oggi vi fa perdere più tempo. Se il progetto risolvesse solo quello, varrebbe comunque la pena?
- Chi decide: una persona sola o un comitato. Cambia i tempi più di quanto si creda.
- Cosa succede se non fate niente. Se la risposta è “niente di grave”, forse non è il momento.
L’ultima domanda è la più utile di tutte, ed è quella che quasi nessuno si pone.
