Preventivo a corpo o a tempo: quale conviene davvero
Due modi di distribuire lo stesso rischio
Davanti a un progetto software esistono due modi classici di metterlo a contratto. A corpo: una cifra fissa per un perimetro definito. A tempo: si paga il lavoro effettivamente svolto, misurato in giornate.
La discussione su quale sia "meglio" gira spesso a vuoto perché si dà per scontato che uno dei due costi meno. Non è così. In entrambi i casi si paga il lavoro che serve; quello che cambia è chi si assume il rischio che il lavoro sia più del previsto.
A corpo, il rischio è del fornitore — e siccome nessuno lavora per perderci, dentro il numero c'è un margine di sicurezza che state pagando anche se non servirà. A tempo, il rischio è vostro: se le cose vanno bene pagate meno, se vanno male pagate di più, e non lo sapete in anticipo.
Da qui deriva tutto il resto, compresa la scelta.
Quando conviene il prezzo fisso
Il prezzo fisso funziona bene quando il perimetro si può descrivere con precisione prima di cominciare, e quando è ragionevole che resti fermo.
È il caso tipico dei progetti con un contorno naturale: un'installazione per un evento con una data e una meccanica decise, il rifacimento di un flusso che già esiste e va replicato, un'integrazione fra due sistemi le cui interfacce sono documentate. In queste situazioni il fornitore può stimare con basso margine di errore, quindi il sovrapprezzo per il rischio è piccolo, e voi ottenete la cosa che vi serve davvero: un numero da mettere a budget e da difendere internamente.
C'è anche una ragione organizzativa che pesa quanto quella economica. Se dovete far approvare una spesa a un consiglio, a un socio o a una banca, un numero certo vale più di un numero probabilmente più basso.
Il rovescio va conosciuto: il prezzo fisso premia la disciplina sul perimetro. Ogni cambiamento va gestito come variazione, con un suo preventivo. Non perché il fornitore sia rigido, ma perché la matematica del contratto è quella.
Quando conviene il consuntivo
Il lavoro a tempo funziona quando quello che serve si scopre facendolo.
È la situazione naturale di un prodotto in evoluzione: c'è una direzione, non un elenco chiuso. Le priorità del mese prossimo dipendono da cosa fanno gli utenti questo mese. Se in questo contesto provate a fissare tutto in anticipo, succedono due cose, entrambe brutte: pagate un margine di rischio alto perché nessuno sa cosa c'è dentro, e vi legate le mani a un elenco che sapete già essere sbagliato in parte.
È anche il modello giusto per la fase successiva al lancio, quando il lavoro è fatto di correzioni, miglioramenti e piccole aggiunte che nascono dall'uso reale.
La condizione perché funzioni è una sola, ma non è negoziabile: visibilità. Dovete sapere ogni settimana su cosa è stato speso il tempo e cosa è uscito. Senza questo, il consuntivo è un assegno in bianco; con questo, è il modello più efficiente che esista, perché ogni giornata è spesa su ciò che in quel momento conta di più.
Le forme intermedie, che sono le più usate
Nella pratica i progetti seri raramente stanno tutti dentro una delle due formule. Le combinazioni utili sono poche e vale la pena conoscerle.
- Fase di analisi a corpo, sviluppo dopo. Un blocco breve e circoscritto per capire davvero cosa serve, che produce un documento e una stima. Poi si sceglie come contrattare il resto, avendo in mano informazioni che prima non c'erano. È il modo più onesto di uscire dal problema del "preventivare al buio".
- Prezzo fisso con tetto e restituzione del non speso. Si concorda un massimo: se il lavoro richiede meno, si paga meno. Sposta parte del rischio sul fornitore lasciandovi il beneficio dell'efficienza.
- A corpo per fasi. Il progetto è diviso in blocchi da poche settimane, ciascuno con il suo perimetro e il suo prezzo. Si ottiene la prevedibilità del fisso senza congelare per sei mesi decisioni che non sono ancora mature.
- Un canone continuativo. Per la fase in cui il prodotto vive e cresce: una capacità di sviluppo costante, con le priorità decise insieme periodo per periodo. È il modello di chi ha smesso di ragionare per progetti e ragiona per prodotto.
Cosa guardare oltre alla formula
Qualunque sia la scelta, tre punti contano più del modello stesso.
Cosa succede quando cambia un requisito. Deve essere scritto: chi valuta l'impatto, in quanto tempo, e come si decide. È la clausola che verrà usata più di ogni altra.
Come si esce. Un preavviso ragionevole da entrambe le parti, e la certezza che al termine restano in mano vostra codice, accessi e dati. Vale in tutti i modelli e vale la pena metterlo per iscritto anche quando il rapporto è ottimo.
Cosa è escluso. È qui che si annidano le differenze fra preventivi che sembrano confrontabili. Progettazione dell'interfaccia, migrazione dei dati, prove su dispositivi reali, formazione, assistenza dopo il rilascio, infrastruttura. Un fornitore che pratica prezzi trasparenti l'elenco ce l'ha già; se dovete estrarglielo a domande, avete imparato qualcosa di utile.
La formula giusta non è quella che fa uscire il numero più basso. È quella in cui il rischio se lo prende chi lo può controllare — e in cui, se qualcosa cambia, sapete già cosa succede.
