Un prezzo fisso rende prevedibile il costo di un periodo di lavoro soltanto se è chiaro che cosa viene acquistato. Può essere un risultato definito, una capacità di team oppure una fase di esplorazione con un esito da valutare. Chiamare tutto “sprint” non elimina queste differenze.
Nel modello Team IT in abbonamento di Romiltec, la collaborazione continuativa permette di ordinare e sviluppare il lavoro con il cliente. Per una singola iterazione considero essenziali obiettivo, disponibilità del team, dipendenze e modo di gestire nuove informazioni.
Definire un risultato osservabile
“Aggiungere reportistica” è una direzione. “Un amministratore può generare il report del periodo, vedere gli errori e scaricare il file autorizzato” descrive un percorso che si può discutere e provare.
Nell’esempio, chiarirei anche dati inclusi, formato, permessi e comportamento quando il lavoro richiede tempo. Le condizioni di errore fanno parte del risultato: un pulsante che funziona soltanto nel caso ideale non completa il flusso.
Le attività tecniche possono cambiare mentre si impara. Il cliente deve però sapere quale capacità è disponibile e quale risultato stiamo perseguendo, senza confondere una previsione con la promessa di qualunque funzionalità emerga.
Un cambiamento richiede una scelta esplicita
Se a metà lavoro arriva la richiesta di esportare anche in un altro formato, valuterei impatto e urgenza. Possiamo inserirla nel periodo successivo, sostituire un’attività meno importante o rivedere l’accordo. La scelta deve essere comprensibile alle persone coinvolte.
La Scrum Guide prevede che lo scope possa essere chiarito e rinegoziato con il Product Owner man mano che si impara, senza mettere a rischio lo Sprint Goal. Non descrive lo sprint come una lista di task congelata per contratto.
Un accordo commerciale può prevedere vincoli diversi, ma deve dichiararli. Non presenterei una specifica regola di vendita come una proprietà universale del metodo di sviluppo.
Rendere visibili le dipendenze dal cliente
Accessi, contenuti, risposta di un fornitore e decisioni di prodotto possono determinare il calendario. Prima di partire indicherei ciò che deve essere disponibile e chi lo fornisce.
Se una dipendenza si ferma, il team deve poter segnalare l’effetto sull’obiettivo e proporre un lavoro alternativo utile. Aspettare l’ultimo giorno per spiegare perché manca un pezzo rende più difficile prendere una buona decisione.
La prevedibilità nasce da questi accordi e dagli aggiornamenti durante il lavoro. Non deriva dalla sola assenza di un consuntivo orario.
Concordare cosa significa accettare la consegna
Definirei criteri verificabili, ambiente di collaudo e responsabilità della verifica. Un incremento può essere pronto per il rilascio e richiedere una finestra di pubblicazione concordata: la chiusura dell’iterazione non impone sempre di modificare la produzione in quel momento.
La demo deve mostrare il percorso atteso e i limiti ancora aperti. Se la consegna comprende una migrazione o un deploy, includerei anche controlli successivi e procedura di recupero appropriata.
Un requisito non completato non deve essere nascosto dentro una presentazione riuscita. Va descritto con l’impatto sull’obiettivo e una proposta per gestirlo.
Scegliere un modello adatto all’incertezza
Un lavoro ben delimitato può prestarsi a un prezzo a corpo. Un prodotto in evoluzione può beneficiare di capacità continuativa e priorità aggiornabili. Un’integrazione sconosciuta può richiedere prima un’indagine circoscritta.
Non considero il pagamento a ore un incentivo inevitabile alla lentezza, né il prezzo fisso una garanzia contro gli sprechi. Trasparenza, competenze e gestione delle decisioni contano in entrambi i casi.
Quando presento una proposta voglio che il cliente possa spiegare, con parole proprie, quale risultato o capacità sta acquistando e cosa accade se cambia la richiesta. Quella comprensione condivisa è la base su cui il lavoro tecnico può procedere con meno ambiguità.