Il compito di un preventivo non è convincere, ma dimostrare che le due parti hanno capito la stessa cosa. I preventivi che falliscono qui vincono l'incarico e perdono il progetto. I dieci punti seguenti sono lo scheletro di ogni preventivo che inviamo.
Le stesse voci Le sono utili anche quando confronta i preventivi che ha ricevuto. Se in entrambi compare "gestione clienti, reportistica e pannello di amministrazione" e i prezzi sono molto diversi, la differenza nasce di solito dal lavoro non definito dietro questi titoli.
Un preventivo che non dice cosa è fuori ambito non è un preventivo: è una lite rimandata.
01Il problema, l'ambito e ciò che ne resta fuori
Un preventivo si apre con il problema, scritto con le parole del cliente. Se lo riformuliamo con le nostre, ogni fraintendimento diventa subito visibile, ed è un bene: diventa visibile prima del contratto.
Poi l'ambito, come elenco di voci: ciascuna un deliverable, non un'intenzione. La terza voce è quella più spesso saltata: cosa resta fuori. "Nessuna app mobile in questa release", "l'inserimento contenuti è a carico del cliente", "licenze di integrazioni di terze parti escluse". Scrivere quell'elenco è scomodo, ed è esattamente per questo che vale.
02Chieda il lavoro dietro lo stesso titolo
Invece di "vogliamo un CRM", è un punto di partenza migliore dire "perdiamo traccia di quale cliente richiamare e quando nel seguire i preventivi". Quando il problema è chiaro, anche le schermate e le notifiche necessarie diventano concrete; non è necessario destinare budget a moduli che non verranno utilizzati.
La dicitura "c'è la reportistica" da sola non basta. Quali dati, in quale intervallo di date, visibili a quale utente? È richiesta l'esportazione? Se è richiesto un collegamento con il Suo sistema di contabilità, magazzino, pagamento o vendita, il preventivo deve comprendere non solo il nome dell'integrazione, ma anche la direzione del flusso dei dati, le condizioni di accesso tecnico e l'azione prevista in caso di errore.
03Tempi, milestone e responsabilità del cliente
Esprimiamo i tempi in milestone anziché in numeri di settimana: approvazione del design, release interna, test di accettazione, messa in produzione. Ogni milestone ha un artefatto e un approvatore con nome e cognome. Le date pendono dalle milestone, non il contrario.
La quinta voce sono le responsabilità del cliente, origine della maggior parte dei ritardi: file di brand, accesso al dominio, credenziali per l'integrazione contabile, testi, dati di esempio realistici per i test. Metterle nel preventivo con delle date non serve ad attribuire colpe, ma a permettere a entrambe le parti di pianificare.
04Nella consegna a fasi, chieda la prima versione funzionante
Chieda quale lavoro potrà svolgere con la prima versione funzionante. Un'azienda di servizi, ad esempio, potrebbe usare inizialmente la creazione di ordini di lavoro, l'assegnazione dei tecnici e il tracciamento dello stato; le analisi più complete possono essere affrontate in una fase successiva. Questo è un esempio rappresentativo; l'ordine corretto dipende dalle priorità della Sua azienda. Il metodo per mantenere la prima versione piccola e completa lo abbiamo spiegato nell'articolo come lanciare prima un'idea software con un MVP.
Anche la gestione delle modifiche deve comparire nel preventivo. È normale che durante lo sviluppo emergano nuove idee; tuttavia, aggiungere ogni nuova richiesta in modo invisibile all'interno della data già fissata non è affidabile. Va mostrato l'effetto della modifica su costo, tempi e altre funzionalità.
05Condizioni su dati, permessi e codice sorgente
Personale, responsabili e clienti non devono vedere le stesse informazioni. Il trasferimento e il backup dei dati, la consegna del codice sorgente e le licenze di terze parti vanno discussi in modo esplicito. È importante sapere in anticipo quali file e quali accessi verranno consegnati al termine del progetto; il nostro approccio in merito lo abbiamo descritto in dettaglio nell'articolo cosa include il pacchetto di consegna di un software chiavi in mano.
06Prezzo, piano di pagamento, garanzia e consegna
Il prezzo arriva con un piano di pagamento legato alle milestone, non al calendario. Valuta, trattamento IVA e la data a cui si fissa il cambio sono indicati esplicitamente: per i clienti UE quella sola riga elimina metà della corrispondenza successiva.
Le ultime tre voci: il periodo di garanzia e cosa copre, il contenuto del pacchetto di consegna e la data di scadenza del preventivo. La scadenza non è una leva di pressione: serve a poter rispondere onestamente se tre mesi dopo qualcuno chiede se è ancora valido.
La correzione dei bug, lo sviluppo di nuove funzionalità e la manutenzione sono attività distinte. Invece di una dicitura generica come "supporto incluso", richieda l'ambito preciso e le modalità di comunicazione. Nel nostro ambito chiavi in mano, ci basiamo sull'installare il software concordato su un server che soddisfi i requisiti tecnici, collaudarlo e consegnarlo funzionante. Offriamo una garanzia di correzione bug di 12 mesi dalla consegna; le nuove funzionalità vengono valutate separatamente. Il supporto standard viene erogato durante l'orario di lavoro; un pacchetto di supporto 24 ore separato e un accordo di manutenzione annuale separato possono essere valutati su richiesta. Offriamo il nostro servizio di sviluppo software su misura con questa definizione di ambito.
07Nel confrontare le proposte, cerchi questi sette punti
- Che il problema da risolvere sia scritto prima dell'elenco dei moduli da acquistare
- Che gli scenari utente inclusi nell'ambito siano definiti con dati, intervallo di date e permessi
- Che le integrazioni siano descritte con direzione, accesso e comportamento in caso di errore
- Che sia scritto quale lavoro sarà completato nella prima versione funzionante e con quale criterio di accettazione
- Che il trasferimento dei dati, i permessi, la consegna del codice sorgente e le licenze siano indicati chiaramente
- Come verrà mostrato l'effetto delle richieste di modifica su costo e tempi
- Che garanzia, supporto e manutenzione siano definiti separatamente
Scritto da
Il team Paradigma7
Prodotto, ingegneria e operations
Siamo un team con base a Ankara che sviluppa software per l'Europa. Qui non c'è teoria: sono i processi che usiamo davvero nei progetti dei clienti.
Chi siamo