Indice
Introduzione
Alcuni clienti preferiscono ricevere offerte a corpo dai loro fornitori, nella convinzione di poter rimuovere l’incertezza in termini di costo, tempistiche e funzionalità dei progetti.
I clienti sono soddisfatti nel pensare di poter mantenere il controllo su questi aspetti, senza tuttavia rendersi conto che così facendo in realtà il controllo sulla qualità lo perdono.
Cosa ci vuole per realizzare un prodotto digitale di alta qualità? Innanzitutto, i prodotti migliori sono il risultato di uno sforzo collaborativo tra cliente e fornitore, poiché è necessaria l’esperienza di entrambi: tecnologica del fornitore e di business del cliente.
Inoltre, è indispensabile poter adattare un progetto agli inevitabili cambiamenti che ci saranno in corso d’opera, come avviene e come in realtà deve essere in un prodotto digitale.
Non è necessario che tutte le funzionalità siano completamente definite all’inizio del progetto, che è il momento in cui quest’ultimo è meno conosciuto ed è anche il momento peggiore per prendere alcune scelte: sia il cliente che il fornitore sono nella posizione di poterle dettagliare meglio solo man mano che passa il tempo.
Un contratto a corpo è in contrasto rispetto a questi principi della qualità.
Non si adatta facilmente ai cambiamenti in quanto definisce in dettaglio l’ambito delle funzionalità e discostarsene significa dover ogni volta dedicare tempo e risorse nel rinegoziarlo, tipicamente a discapito della relazione tra cliente e fornitore, della qualità e del rispetto delle scadenze.
Inoltre, un contratto di questo tipo non allinea gli incentivi delle due parti: l’obiettivo non è quello di realizzare un prodotto di alta qualità, ma quello di soddisfare gli obblighi degli accordi contrattuali.
La domanda che guida gli sviluppi non è più “cosa è meglio”ma “cosa stabilisce il contratto”; quest’ultimo diventa un muro che ostacola la comunicazione tra le parti.
Nel lungo termine, il software prodotto su queste basi è più costoso, e non solo in termini di costi di manutenzione.
Anche i prodotti che funzionano correttamente e che rispondono ai requisiti contrattuali possono avere costi di opportunità aggiuntivi: un prodotto può non soddisfare il suo mercato di destinazione, o un sistema ad uso interno può non avere successo nel rimuovere le inefficienze dell’azienda.
Come lavoriamo nella mia azienda
Nei team di sviluppo della mia azienda lavoriamo su progetti a “budget fisso” e a “funzionalità variabili”, con fatturazione a intervalli regolari (mensili) basata sulla quantità di lavoro consegnato piuttosto che sul completamento delle caratteristiche.
“Budget fisso” significa che centriamo in modo affidabile un costo prefissato e che lavoriamo in modo collaborativo con i clienti per realizzare il miglior software possibile per quel budget.
“Funzionalità variabili” significa che il prodotto che sarà consegnato non è definito in dettaglio nel contratto ma è controllato dal cliente durante lo sviluppo.
Aiutiamo il cliente a farci lavorare sulle giuste funzionalità, e a costruirle con il giusto livello di complessità e dettaglio, per ottenere il maggior valore possibile dal budget prefissato.
Con questo metodo il cliente sa sempre a quanto ammonta il budget residuo e quali funzionalità rimangono da realizzare.
Le seguenti tecniche lavorano congiuntamente per garantire la piena trasparenza tra il cliente e gli sviluppatori:
- Ordinare le funzionalità per priorità
- Tracciare la velocità
- Lavorare per iterazioni periodiche
Ordinare le funzionalità per priorità
Durante la fase di pianificazione, aiutiamo il cliente a produrre un elenco delle funzionalità desiderate, ordinandole per importanza. Gli sviluppatori usano poi questa lista per strutturare la programmazione.
I clienti possono cambiare la priorità durante gli incontri che precedono le iterazioni di lavoro.
Una volta definita, la lista può essere usata per stimare quanto ci vorrà per realizzare il progetto.
Piuttosto che assegnare una quantità arbitraria di tempo alle funzionalità, misuriamo le attività sulla base della loro complessità relativa.
Se l’aggiunta di una funzionalità ha un livello di complessità di un punto, un’altra che è il doppio più complessa verrà stimata in due punti.
Tracciare la velocità
Una volta che ogni caratteristica è stata stimata su una scala relativa, possiamo definire un budget di iterazione (es. dieci punti per l’iterazione attuale), e poi misurare il nostro progresso.
Se ci vuole una settimana per produrre dieci punti, possiamo stimare che per realizzare un progetto di cento punti ci vorranno circa dieci settimane.
Tracciando la nostra velocità, siamo in grado di produrre una stima sempre più accurata dei tempi di consegna del progetto.
I clienti sono parte attiva di questo processo: sanno esattamente qual è la nostra velocità, come si posiziona rispetto allo storico, e come influenzerà il futuro del progetto.
Lavorare per iterazioni periodiche
Rilasciamo software funzionante e testato in iterazioni periodiche (es. ogni due settimane o una volta al mese), offrendo ai clienti una buona percezione del punto in cui si trova il team e assicurandoli che le funzionalità consegnate corrispondano alle loro aspettative.
Le iterazioni periodiche forniscono ai clienti il modo di cambiare idea senza dover rinegoziare il contratto.
Piuttosto che accordare un contratto e rivedersi a distanza di qualche mese per la consegna del prodotto finito, i clienti possono toccare con mano il progresso del progetto, mitigando il rischio che il prodotto non sia quello che hanno in mente.
Inoltre, questi punti di controllo continui garantiscono ai clienti che gli sviluppatori stanno usando il loro tempo nel modo più efficiente possibile. Poiché il cliente collabora con gli sviluppatori su base continua, il progresso è completamente trasparente.
Tracciare la nostra velocità e spezzare il progetto in parti più piccole incentiva gli sviluppatori a produrre di più e in modo efficiente.
Conclusione
Il vantaggio di realizzare progetti a budget fisso e funzionalità variabili rispetto a quelli a corpo è che viene rimosso il muro creato dai contratti, promuovendo la comunicazione e la collaborazione tra il cliente e gli sviluppatori.
Tutti condividono le responsabilità per il successo del progetto quando la comunicazione è aperta e trasparente, e questo significa software di maggiore qualità.
