Prezzo fisso o tariffa oraria nello sviluppo software: perché abbiamo scelto il prezzo fisso

Quando ingaggiate un'agenzia di sviluppo software, una delle prime cose da concordare è come pagherete. I due modelli dominanti sono la fatturazione a ore, in cui pagate il tempo impiegato, e il prezzo fisso, in cui concordate un importo totale prima che il lavoro inizi.

La maggior parte delle agenzie adotta per abitudine la fatturazione a ore. Noi abbiamo scelto il prezzo fisso. Questo articolo spiega perché, quali sono le differenze reali e cosa dovreste chiedere prima di firmare qualsiasi contratto di sviluppo software.

Il problema della fatturazione a ore

La fatturazione a ore crea un disallineamento di interessi difficile da ignorare, una volta che lo si vede con chiarezza.

Quando un'agenzia fattura a ore, guadagna di più se il lavoro dura più a lungo. Questo non significa che le agenzie siano disoneste — la maggior parte non lo è — ma la struttura crea una pressione nella direzione sbagliata. L'inefficienza non viene penalizzata. L'allargamento del perimetro diventa redditizio. Non c'è alcun incentivo a trovare la soluzione più semplice al vostro problema, perché la soluzione complessa genera più ore.

Dal punto di vista del cliente, la fatturazione a ore genera ansia. Ogni e-mail che inviate, ogni domanda che ponete, ogni revisione che chiedete è potenzialmente fatturabile. Vi ritrovate a razionare la comunicazione per contenere i costi. Smettete di fare domande perché siete preoccupati per la fattura. Il rapporto diventa conflittuale anche quando entrambe le parti agiscono in buona fede.

La fattura mensile arriva e è sempre una sorpresa, a volte gradita, spesso no. Non avete idea di quale sarà il costo finale fino alla fine del progetto.

Perché abbiamo scelto il prezzo fisso

Quando vi diamo un prezzo fisso, prendiamo un impegno: consegneremo il perimetro concordato per quell'importo, punto. La struttura degli incentivi cambia completamente.

Diventiamo motivati a trovare la soluzione più efficiente al vostro problema, perché l'efficienza è ciò che protegge il nostro margine. Siamo motivati a comunicare in modo chiaro sin dall'inizio, perché i malintesi ci costano tempo che abbiamo già impegnato. Siamo motivati a consegnare nei tempi, perché un progetto che si allunga riduce la nostra redditività senza aumentare la vostra.

Conoscete il costo totale prima che scriviamo una sola riga di codice. Potete fare un budget preciso. Potete presentare alla vostra direzione un caso concreto basato su un numero reale. Il rapporto tra noi diventa collaborativo invece che transazionale: entrambi vogliamo la stessa cosa, cioè un progetto riuscito e consegnato con efficienza.

Come quantifichiamo con precisione

L'obiezione più comune al prezzo fisso è: «Come potete impegnarvi su un prezzo prima di sapere esattamente cosa state realizzando?». È una domanda legittima, e la risposta è che una quantificazione accurata richiede lavoro reale a monte.

Ogni progetto che accettiamo inizia con un processo di analisi dettagliato. Chiediamo del vostro problema aziendale, non solo dell'elenco delle funzionalità. Mappiamo i vostri flussi di lavoro, capiamo i vostri dati, esaminiamo i sistemi esistenti e chiariamo ogni assunzione. Poniamo le domande che la maggior parte delle agenzie salta, perché fatturando a ore possono risolvere le ambiguità più tardi.

Poi quantifichiamo internamente, stimando non solo il tempo di sviluppo ma anche la complessità delle integrazioni, le esigenze di test, gli aspetti di pubblicazione e un margine per gli imprevisti che si presentano sempre. Vi diamo un solo numero. Non una forbice. Non un «a partire da». Un prezzo fisso per il perimetro definito.

Questo processo richiede tempo. Un'analisi e una quantificazione accurate possono richiedere diverse ore del nostro lavoro prima di consegnarvi una proposta. Ci assumiamo questo costo perché è la base di un prezzo fisso attendibile, e perché un progetto ben definito ha più probabilità di riuscire.

Cosa succede quando il perimetro cambia

Il prezzo fisso non significa che il perimetro sia congelato. Le imprese cambiano, i requisiti evolvono e durante lo sviluppo emergono idee migliori. Gestiamo la cosa con onestà.

Se vi serve qualcosa che non era nel perimetro originario — una nuova funzionalità, un'integrazione diversa, un flusso di lavoro modificato — la quantifichiamo separatamente. Vi diamo un prezzo per l'aggiunta prima di iniziare a lavorarci. Decidete voi se ne vale la pena. Nessuna sorpresa, nessun addebito retroattivo per decisioni prese insieme.

Quello che non facciamo è assorbire in silenzio l'allargamento del perimetro per poi presentare una fattura a sorpresa alla fine. E non usiamo «non era nel perimetro» come pretesto per far pagare qualcosa che era chiaramente implicito nella richiesta iniziale. Entrambi gli approcci distruggono la fiducia. Nessuno dei due è il nostro modo di lavorare.

La questione del rischio

Capire chi si assume il rischio in ciascun modello è il modo più chiaro per cogliere la differenza tra tariffa oraria e prezzo fisso.

Con la fatturazione a ore il rischio è vostro. Se il progetto richiede il doppio del tempo previsto, pagate il doppio. Se l'agenzia sottovaluta la complessità, quel costo lo assorbite voi.

Con il prezzo fisso il rischio è nostro. Se sottostimiamo, ne rispondiamo noi. Se qualcosa richiede più tempo del previsto, è un problema che tocca a noi risolvere. Voi pagate quanto concordato.

Non è beneficenza: è il modello che allinea i nostri interessi ai vostri. Abbiamo una forte motivazione a stimare con precisione e a consegnare con efficienza, perché è così che il prezzo fisso funziona come modello di business. Quando funziona bene, voi ottenete un costo prevedibile e un'agenzia motivata. Noi otteniamo un progetto redditizio e un cliente soddisfatto.

Cosa chiedere a qualsiasi agenzia prima di firmare

Che lavoriate con noi o con un'altra agenzia, queste sono le domande che rivelano come funzionerà davvero la fatturazione:

Chiedete cosa accade se il progetto dura più del previsto. Chiedete come vengono gestite e quotate le modifiche di perimetro. Chiedete di vedere esempi di fatture finali di progetti precedenti a confronto con il preventivo iniziale. Chiedete come gestiscono i casi in cui i requisiti erano ambigui nella richiesta iniziale. Le risposte vi diranno più del modello di fatturazione in sé.

In un progetto di sviluppo software la prevedibilità è ciò che conta di più. Dovreste sapere quanto pagherete prima di impegnarvi.