Ottobre 2024, call di scoping con un nuovo cliente. La domanda è esattamente quella che ricevo nove volte su dieci: “quanto costa fare X?”. Apro il blocco note del Mac e scrivo sprint. Lo dico ad alta voce: “il prezzo non è un’ora-uomo, è uno sprint a prezzo fisso”. Pausa di tre secondi all’altro capo della call. Poi la domanda che separa i clienti che capiscono il framework da quelli che lo subiscono: “e se a metà sprint cambio idea?”. È in quei tre secondi che si decide se la trattativa va avanti come si deve, oppure se il framework si rompe prima ancora di partire. Questo post fa parte degli articoli di Workshop, e racconta come Romiltec vende sprint, perché lo sprint funziona solo dentro un vincolo preciso e cosa succede quando quel vincolo salta.
Perché lo sprint, e non altro
Avevo già scritto, un anno fa, di prezzo fisso al mese come modello di pricing per i contratti di delivery continua. Quel post resta valido per le partnership lunghe: un cliente compra capacità mensile rinnovabile, Romiltec consegna sprint dentro il mese. Lo sprint a prezzo fisso è la cellula minima di quel modello: l’unità che il cliente compra, anche fuori da un contratto annuale.
Le tre alternative classiche restano sempre quelle:
- Time and materials: il cliente paga ore. Ho già spiegato perché lo evito (premia il dev lento, richiede un PM rigoroso che in una società zero commerciali non c’è).
- Preventivo a corpo per progetto: prezzo fisso, perimetro definito a contratto. Buono per progetti chiusi tipo rifacimento sito istituzionale. Disastroso per software con perimetro fluido.
- Day rate o retainer aperto: il cliente compra giornate o un blocco di ore mensile spalmato. Sembra flessibile, in realtà è opaco: il cliente non capisce mai cosa riceve in cambio del bonifico.
Lo sprint a prezzo fisso è una quarta opzione. La descrivo in tre punti, perché è esattamente come la presento al cliente in call.
Punto uno: scope congelato
Lo sprint dura due settimane. Il primo giorno, in call di kick-off, il cliente e il dev senior firmano (formalmente, su un documento condiviso) la lista delle storie che entrano nello sprint. Da quel momento la lista è chiusa: non si aggiungono storie, non si tolgono storie, non si rinegoziano priorità.
Se a metà sprint il cliente ha un’idea nuova, l’idea entra in backlog per lo sprint successivo. Lo sprint corrente continua dritto, perché ha già tutto quello che serve per consegnare.
Punto due: prezzo fisso
Il prezzo dello sprint è uno solo, dichiarato nel kick-off, scritto sul documento di scoping. Non si calcola a fine sprint sulla base delle ore consumate. Non c’è una franchigia di “ore extra fatturate a parte”. Non c’è un tetto al numero di story point: c’è un capacity tarato sulla velocità nota del team, sopra al quale lo sprint successivo prende il sovrappiù.
Se Romiltec stima male, perde Romiltec. Se il dev impiega meno tempo del previsto, guadagna Romiltec. Il cliente sa esattamente quanto paga, qualunque cosa succeda dentro lo sprint.
Punto tre: deliverable testato in produzione
Lo sprint si chiude solo quando il deliverable è in produzione, testato dal cliente. Non quando il codice è in main. Non quando lo staging è verde. Quando il cliente ha cliccato sulla feature in produzione e ha detto ok, vedo che funziona.
Questa è la differenza fra uno sprint vero e una serie di pull request. Una pull request si chiude tecnicamente. Uno sprint si chiude commercialmente, e la chiusura commerciale è il deploy in produzione validato.
La matematica del prezzo (qualitativa)
Non scrivo qui il listino, perché il listino cambia in funzione della complessità del backlog e del tipo di tecnologia. Ma scrivo la struttura di calcolo, perché è la stessa che ho descritto nel post del 2023, applicata alla cellula sprint invece che al mese.
Il prezzo di uno sprint a prezzo fisso parte da:
- Costo lavoro pieno del team sullo sprint (uno o due dev senior più, in alcuni casi, una mezza giornata di sysadmin), già fully loaded su contributi, ferie ratealizzate e tredicesime.
- Coefficiente di fatturabilità effettiva del team, intorno al 75% del tempo nominale. Le call di kick-off, i passaggi di consegne, le code review interne fra i due dev senior della squadra, l’aggiornamento tecnico, sono tempo che il dev spende per tenere alta la qualità del codice consegnato, ma non sono ore fatturabili al cliente.
- Quota di infrastruttura e sysadmin, che esiste sempre anche se il cliente non la vede: il setup degli ambienti, la pipeline CI/CD, i certificati, il monitoring degli alert. Anche su uno sprint piccolo questa quota pesa.
- Riserva tecnica per gli imprevisti di produzione: il rollback urgente, l’incident notturno, l’integrazione con un SDK di terze parti che si comporta diversamente in produzione rispetto allo staging. Capita, va prezzato a monte, non ribaltato sul cliente a posteriori.
- Margine commerciale, che è il profitto vero di Romiltec, sopra a tutto il resto.
Sopra a queste cinque voci c’è un dato strutturale: lo sprint a prezzo fisso costa più di un equivalente a time and materials. È giusto così. Il cliente, in cambio del costo più alto, compra prevedibilità: sa quanto bonifica, sa cosa riceve, non ha sorprese a fine mese sulla riconciliazione delle ore. La prevedibilità è un servizio, e ha un prezzo.
Quando un cliente mi dice però così pago di più che a ore, gli rispondo che a ore paga di meno solo se il dev è bravo e veloce, e di più se il dev è lento o se il PM non controlla. Lo sprint a prezzo fisso elimina questa varianza, e il prezzo riflette l’eliminazione della varianza.
Caso uno: lo sprint andato come da framework
Nel 2024 abbiamo consegnato uno sprint a un cliente che vendeva un SaaS verticale a un mercato professionale italiano. La richiesta: aggiungere un layer di reportistica PDF generato in coda con dati di tre mesi rolling. Niente di esotico: backend Laravel esistente, queue Horizon già configurata, template PDF da disegnare con un team di design lato cliente.
Kick-off di novanta minuti. Sul documento di scoping abbiamo scritto sette storie: tre per la pipeline di generazione, due per lo storage e la firma URL temporanea, una per la UI di download dal frontend, una per la gestione degli errori in coda con re-enqueue. Capacity stimata: due settimane, un dev senior, una mezza giornata di sysadmin per il bucket dedicato.
Lo sprint è andato come da framework. Il cliente ha proposto, a metà della seconda settimana, una ottava storia (esportazione anche in Excel oltre al PDF). Il dev senior ha risposto in chat: aggiunta a backlog per lo sprint successivo, lo sprint corrente continua sulla pipeline PDF. Il cliente ha detto ok in un messaggio di tre parole. Allo standup successivo lo sprint due era già fissato.
Risultato: deploy in produzione il giovedì della seconda settimana, validazione del cliente il venerdì mattina, fattura emessa il pomeriggio. Sprint due partito il lunedì dopo, con la storia Excel più altre quattro nuove richieste.
La chiave: il cliente aveva un team di prodotto che capiva il framework. La frase aggiunta a backlog per lo sprint successivo non l’hanno percepita come un rifiuto, l’hanno percepita come una pianificazione. Quella è la postura giusta dall’altra parte del tavolo.
Caso due: lo sprint che è andato male
Nello stesso 2024 abbiamo consegnato uno sprint a un altro cliente, di settore diverso. La richiesta sembrava più semplice: una integrazione con un provider di pagamenti tramite webhook firmati, più una pagina di stato per gli amministratori interni del cliente.
Kick-off, cinque storie sul documento, capacity stimata su due settimane, prezzo concordato. Tutto in regola.
Il problema è iniziato il quarto giorno. Il cliente ha scritto in chat: piccola cosa, possiamo aggiungere anche il webhook per il provider di refund? È praticamente uguale, no?. Il dev senior, che era nuovo dell’azienda e voleva mostrare disponibilità, ha detto sì senza chiedermi conferma. Quattro giorni dopo, altra richiesta: visto che ci siete, aggiungete anche la riconciliazione automatica con il commercialista? Sono due righe in più.
Le due righe in più erano due settimane di lavoro. Il dev senior ha cercato di stringere lo scope originale per recuperare, ha tagliato i test sulla pagina di stato, è andato in produzione con il webhook refund non testato. Il quinto giorno della seconda settimana, in produzione, il refund webhook ha generato un duplicato di addebiti su un cliente test. Niente di catastrofico, nessun cliente reale impattato, ma il rollback è costato una notte intera al dev senior.
Lo sprint è finito con un giorno di ritardo, il deliverable parzialmente testato, e una conversazione lunga col cliente sulla questione ma avevamo concordato la riconciliazione, no?. La risposta onesta è: no, non l’avevamo concordata, ma non l’avevamo nemmeno rifiutata in modo esplicito. La colpa è di Romiltec, non del cliente. Il dev senior ha imparato la lezione, e io con lui: il sì gentile a metà sprint è il modo più veloce per rompere il framework.
Postmortem onesto: il cliente non aveva capito il vincolo del framework, e Romiltec non gliel’aveva ribadito quando le richieste hanno iniziato ad arrivare. Avremmo dovuto rispondere aggiunta a backlog per lo sprint successivo alla prima richiesta extra, e farlo per iscritto. Da quello sprint in poi, in Romiltec è regola interna: la frase di chiusura su una richiesta fuori scope la dico io, non il dev. Il dev passa la palla al founder, e il founder difende il framework.
Caso tre: lo sprint che è diventato lo standard del cliente
Il caso più interessante è il terzo, perché è quello in cui il framework ha cambiato la natura del rapporto col cliente.
A inizio 2024 un cliente storico, con cui avevamo lavorato un anno prima a un progetto custom a corpo (modello vecchio, pre-pivot a prodotto), è tornato con una richiesta nuova: due settimane di lavoro su una integrazione lato AI. Il cliente conosceva il modello a corpo dall’esperienza precedente, e si aspettava di ricevere un preventivo dettagliato con stima oraria, milestone, fatturazione a stato avanzamento.
Gli ho proposto invece uno sprint a prezzo fisso, in modalità prova. Una settimana di scoping leggero per chiarire le storie, due settimane di sprint, un prezzo unico, deliverable testato in produzione. Senza milestone intermedie, senza stato avanzamento, senza riconciliazione finale delle ore.
Il cliente ha accettato la prova un po’ perplesso. Ha detto qualcosa tipo vediamo come va. Ha pagato il bonifico unico in anticipo, come da kick-off.
Lo sprint è andato bene, deploy in produzione il martedì della seconda settimana, due giorni di anticipo. Il giovedì il cliente mi ha richiamato: voleva uno sprint due, e voleva sapere se potevamo fare sempre così per i progetti futuri. Da quel momento abbiamo lavorato con quel cliente solo a sprint, mai più a corpo. Sui dodici mesi successivi, lo sprint a prezzo fisso è diventato il formato standard del rapporto: niente più preventivi a corpo, niente più milestone, niente più stati avanzamento. Solo sprint, in coda, uno dopo l’altro.
La differenza per il cliente è stata operativa: il suo team interno ha smesso di dover validare timesheet, di dover discutere percentuali di completamento, di dover negoziare modifiche di scope. Comprava sprint, riceveva deliverable, pagava il bonifico. La conversazione è diventata di prodotto, non di amministrazione.
Per Romiltec la differenza è stata culturale: il cliente, con la postura giusta dall’altra parte del tavolo, ha legittimato lo sprint come formato standard. Non più prova, non più eccezione. Da quel momento, ogni nuovo cliente parte con sprint a prezzo fisso, e i pochi che chiedono il modello a corpo li orientiamo alla stessa cellula.
Cosa porto a casa
Lo sprint a prezzo fisso non è un format commerciale che ho copiato da un libro di pricing. È una formula di rispetto del lavoro tecnico, che richiede una postura precisa dal cliente per funzionare.
Il cliente ha autorità sul cosa: decide le storie che entrano in kick-off, decide la priorità del backlog, decide quando uno sprint si chiude (con la validazione in produzione). Non ha autorità sul come e non ha autorità sul in quanto tempo: il come è competenza tecnica del dev senior, il in quanto tempo è dentro il framework dei due settimane.
Quando il cliente capisce questa divisione, lo sprint a prezzo fisso è il formato più sano che ho mai visto in quindici anni nel tech. Quando il cliente non la capisce, il framework si rompe, e si rompe rapidamente, di solito al quarto giorno della seconda settimana.
Il mio compito di founder non è far funzionare il framework con tutti i clienti. È riconoscere, in call di scoping, quali clienti hanno la postura giusta e quali no. Per quelli che non ce l’hanno, è meglio rinunciare allo sprint che provarlo e farlo fallire: un fallimento di sprint, in Romiltec, è un debito tecnico e umano che paga il team, non il cliente.
Tre regole che ho condensato in un anno di sprint a prezzo fisso, valide per qualunque cliente nuovo:
Regola uno: la frase aggiunta a backlog per lo sprint successivo è il pilastro del framework. Va detta a voce in kick-off, scritta sul documento, ripetuta a ogni richiesta extra in chat. Senza quella frase, il framework non regge oltre il quarto giorno.
Regola due: la difesa del framework, quando le richieste extra arrivano, la fa il founder, non il dev. Il dev passa la palla, il founder ribadisce il vincolo. È un costo di tempo del founder, ma è la cosa più importante che può fare per il team.
Regola tre: i clienti che non capiscono il vincolo non sono clienti cattivi, sono clienti diversi. Per loro esiste il modello a corpo, esiste il time and materials con un PM forte, esistono altre soluzioni. Lo sprint a prezzo fisso non è universale, è una scelta.
Tornando al cliente di ottobre con cui ho aperto questo post: dopo i tre secondi di pausa, ha detto ho capito, ma fammi un esempio. Gli ho mandato il documento di scoping del caso uno (anonimizzato) e una sintesi in venti righe del framework. Ha richiamato il giorno dopo. Sprint uno partito il lunedì successivo. Il vincolo, quando il cliente lo sceglie consapevolmente, smette di essere un vincolo e diventa il modo in cui costruiamo qualcosa insieme.