Sette domande da fare prima di firmare un preventivo

Hai un preventivo sul tavolo. Una pagina, forse due. In alto «sviluppo gestionale personalizzato», sotto tre righe di descrizione, in fondo una cifra tonda e la frase «offerta valida 30 giorni».

Il problema non è la cifra. Il problema è che quel foglio non risponde a nessuna delle domande che ti faranno male fra otto mesi, quando il software è a metà, il fornitore dice che quella cosa lì non era compresa e tu scopri che il codice non è tuo.

Queste sette domande si fanno prima. Costano venti minuti di riunione. Ognuna ha un motivo per cui la fai e un modo per capire, in tempo reale, se la risposta che ti stanno dando regge.

Un preventivo di una pagina con una cifra tonda non è semplicità: è un conto che nessuno ha fatto

Un numero tondo — 15.000, 20.000, 30.000 — quasi mai nasce da una somma. Nasce da una sensazione: «questo cliente ci sta, questo lavoro assomiglia a quello dell’anno scorso».

Fai la prova al contrario. Prendi la cifra e dividila per una tariffa giornaliera di mercato, diciamo 400-500 € al giorno per uno sviluppatore in Italia. Ventimila euro sono più o meno quaranta giornate di lavoro. Chiedi come sono spese: quante per l’anagrafica clienti, quante per i documenti, quante per i permessi utente, quante per le prove e le correzioni.

Se te lo sanno dire, il numero viene da un ragionamento. Se ti rispondono che «non si può spacchettare», il numero viene da un’intuizione, e le intuizioni sbagliano in una direzione sola: verso l’alto per te, verso le varianti a pagamento.

Un preventivo che sta in piedi ha quattro cose: l’elenco di cosa è compreso, l’elenco di cosa resta fuori, il numero di giornate e la tariffa. Non serve che sia lungo trenta pagine: serve che sia derivato da qualcosa.

«Quando abbiamo finito, il codice di chi è?»

Perché la fai. Perché è la differenza fra comprare una cosa e affittare il diritto di usarla. Se il codice non è tuo e fra tre anni vuoi cambiare fornitore, non stai cambiando fornitore: stai ricominciando da capo, e paghi due volte lo stesso software.

Come si riconosce una risposta che non va bene. «Il codice è nostro ma tu puoi usarlo per sempre» è una licenza d’uso, non una proprietà: sembrano la stessa cosa e non lo sono. Anche «lo vediamo alla fine» è un no travestito, perché alla fine il potere contrattuale ce l’hanno loro.

Una risposta che tiene suona così: il codice è tuo alla consegna, sta scritto nel contratto, e sta su uno spazio intestato a te dove noi siamo collaboratori. Se usano parti di loro proprietà — capita, ed è legittimo — devono dirti quali e cosa succede a quelle se ve ne andate ognuno per la sua strada.

«Cosa succede se sparite, o se litighiamo?»

Perché la fai. Perché nessuno pianifica la rottura, e la rottura è la situazione in cui perdi di più. Non stai facendo un’offesa: stai chiedendo dove sono le chiavi di casa tua.

Tre cose concrete: dove sta il codice oggi e chi ha le credenziali; a nome di chi sono intestati il dominio e l’hosting; dove sono i dati e chi fa i backup. Se le risposte sono tutte «nostro», non hai un fornitore, hai un padrone di casa.

Come si riconosce una risposta che non va bene. Se si offendono, hai già la risposta. Se dicono «non succederà mai», stanno rispondendo a un’altra domanda. Se dicono «te lo diamo tutto quando serve», chiedi cosa succede se «quando serve» coincide con «non ci parliamo più».

Come finisce quando questa domanda non la fai nessuno lo racconta volentieri. L’abbiamo scritto qui: cosa fare quando il fornitore sparisce a metà progetto.

«Cosa c’è dentro questo prezzo e cosa diventerà una variante a pagamento?»

Perché la fai. Perché è il punto dove nasce la quasi totalità delle liti. Non perché qualcuno sia in malafede, ma perché tu e lui avete in testa due software diversi e ve ne accorgete al terzo mese.

Chiedi la lista dei fuori. Un preventivo senza una sezione «cosa non è compreso» non è finito: è un preventivo a cui manca metà. Le voci che spariscono più spesso sono la stampa dei documenti in PDF, l’invio delle email, i permessi per ruolo, l’importazione dei dati vecchi, la formazione delle persone e le correzioni dopo il collaudo.

Come si riconosce una risposta che non va bene. «Tutto quello che serve» e «siamo flessibili» sono la stessa frase, e vuol dire che la decisione su cosa è compreso verrà presa dopo, quando avrai già pagato l’acconto. Chiedi anche il meccanismo: una variante si valuta a quale tariffa, la stimate prima o dopo averla fatta, chi la approva per iscritto.

«I dati che ho già, chi li porta dentro?»

Perché la fai. Perché dodici anni di storico non entrano nel software nuovo da soli, e la migrazione è il lavoro che tutti sottovalutano: pesa spesso il 10-20% del progetto e nel preventivo non compare quasi mai.

I dati vecchi sono sporchi. Ci sono tre volte lo stesso cliente scritto in tre modi, campi vuoti, note importanti dentro una colonna «osservazioni». Qualcuno deve decidere cosa si tiene, cosa si butta e chi lo pulisce. È un lavoro noioso e va assegnato con un nome e cognome.

Come si riconosce una risposta che non va bene. «Ce li importi tu da un file Excel» può anche andare bene, ma allora deve essere scritto e tu devi sapere quante ore della tua gente costa. La risposta peggiore è nessuna risposta: se la migrazione non compare da nessuna parte, comparirà come variante.

Se i dati da portare dentro stanno in un foglio condiviso, prima leggi quando l’Excel va sostituito e quando no: a volte la risposta giusta è tenerselo.

«Quanto mi costa tenerlo acceso ogni anno?»

Perché la fai. Perché il prezzo di acquisto è la parte che vedi, non è la parte che paghi più a lungo. Un software vive cinque, otto, dieci anni. Ogni anno ha un costo che esiste anche se non tocchi niente.

Le voci sono sempre queste: server e spazio, dominio e certificati, backup, i servizi esterni a consumo (invio email, messaggi, mappe, firma digitale, pagamenti) e gli aggiornamenti di sicurezza delle librerie usate.

Un conto per capirci. Su un progetto da 30.000 €, fra infrastruttura e manutenzione ordinaria una cifra realistica sono 200-300 € al mese. Fanno 2.400-3.600 € l’anno. In cinque anni sono 12.000-18.000 €: metà del progetto, sotto forma di bollette. Va saputo prima, non è una brutta notizia in sé.

Come si riconosce una risposta che non va bene. «Pochi euro al mese» e «dipende» non sono numeri. Chiedi una cifra annua a spanne con le voci sotto, e chiedi se la manutenzione è un contratto separato o si paga a chiamata.

«Fra due anni, chi mette mano a questo software?»

Perché la fai. Perché il software è la persona che lo sa mantenere. Se quella persona se ne va, cambia lavoro o si ammala, tu resti con un file di testo che nessuno legge.

Chiedi quante persone dentro quello studio conoscono il progetto, con quali tecnologie è scritto e quanto sono diffuse. Poi fai la domanda vera: «se domani porto questo progetto a un altro studio, quanto ci mette a capirlo?». E chiedi la documentazione come consegna scritta nel contratto, non come cortesia.

Come si riconosce una risposta che non va bene. «Abbiamo un nostro sistema interno» è la bandiera rossa più grande di tutte: significa che nessuno fuori da lì può metterci mano, e il prezzo per uscirne lo decidono loro. Anche «lo sa solo Marco» è un problema, per quanto Marco sia bravo.

«Su cosa vi state basando per darmi questo prezzo?»

Perché la fai. Perché è la domanda che riassume le altre sei. Chi ha capito il tuo problema sa spiegarti da dove viene il numero. Chi non l’ha capito ti dà una cifra e spera.

La risposta che vuoi sentire è un elenco: queste funzioni, tante giornate ciascuna, questi rischi che potrebbero allungare i tempi. Se ti dicono «esperienza» o «abbiamo fatto un progetto simile», chiedi quale parte era simile e quale no.

Come si riconosce una risposta che non va bene. Chi ha capito il lavoro a metà, di solito, è quello che ti fa il prezzo più basso: ha visto meno lavoro di quello che c’è.

Se nessuno dei preventivi che hai in mano regge questa domanda, molto probabilmente il problema non sono i fornitori: è che non esiste ancora un documento scritto che dica cosa deve fare il software. Finché non c’è, ognuno ti quota una cosa diversa e tu confronti mele con pere. È esattamente il buco che riempie il blueprint da 500 €: dieci pagine da dare a tutti e tre i fornitori, così i preventivi tornano confrontabili.

Le sette risposte, in una riga ciascuna

Domanda	Risposta che tiene	Risposta che ti fa rimandare la firma
Di chi è il codice?	«Tuo alla consegna, sta nel contratto»	«Licenza d’uso perpetua»
Se litighiamo?	«Gli account sono già intestati a te»	«Non succederà»
Cosa resta fuori?	Un elenco scritto	«Tutto quello che serve»
Chi migra i dati?	Un nome e delle giornate	Silenzio
Quanto costa l’anno?	Una cifra con le voci	«Pochi euro al mese»
Chi lo mantiene fra due anni?	«Tre persone, tecnologie diffuse»	«Il nostro sistema interno»
Da dove viene il prezzo?	Funzioni per giornate	«Esperienza»

Cosa fai con il foglio delle risposte

Scrivile a mano durante la riunione, in colonna, di fianco alla domanda. Serve dopo, ma serve anche durante: uno che ti vede annotare risponde in modo più preciso.

Poi tre cose. Chiedi che le risposte alle domande 1, 3 e 5 finiscano dentro il contratto, con quelle parole. Fai le stesse sette domande a tutti i fornitori che stai valutando, altrimenti stai confrontando due cifre tonde e non è un confronto — su come si legge davvero un prezzo c’è quanto costa un software su misura in Italia. E prendi nota di chi si irrita: è un’informazione sul rapporto che avrete quando qualcosa andrà storto, e qualcosa andrà storto.

Nessuna di queste sette domande è tecnica. Non serve sapere cos’è un database per farle, e nessuna richiede che tu capisca la risposta a livello di codice: richiede che la risposta esista, sia specifica e si possa scrivere in un contratto.

La firma non è la fine della trattativa. È l’ultimo momento in cui hai ancora potere contrattuale.