Ho avvistato un contratto sano: esistono!

C’è voluto un intero anno di sperimentazione e raffinamento, per essere certi di non doverci smentire troppo facilmente, o che le correzioni apportate fossero più rilevanti dell’idea di partenza, ma oggi ho un racconto croccantissimo su un nuovo modello di pricing adottato da e-xtrategy, una internet company marchigiana per cui svolgo attività di coaching da qualche anno. Cercherò di essere breve per trasmetterti in poco tempo lo spirito di questo post.

Il problema da risolvere

I contratti che tipicamente regolano i rapporti nello sviluppo di software sono il vero dramma del nostro mercato. Ereditati da mercati con caratteristiche finanziarie, tecniche e sociali completamente diverse, i classici contratti a corpo ad oggi, secondo me, sono il principale motivo di fallimento dei progetti software. Senza dilungarmi troppo, mi basterà farti notare come

  1. mantengano il rischio completamente sbilanciato sul fornitore che, per definizione, non dovrebbe invece partecipare al rischio d’impresa neanche un po’
  2. richiedano di prendere le decisioni più cruciali – visto che si tratta di denaro – in modo definitivo nel momento di minima conoscenza riguardo al progetto stesso: l’inizio.

Purtroppo il contratto a corpo, sovrano indiscusso delle gare d’appalto, rimane lo standard di riferimento per i progetti software. Questo problema può essere mitigato dall’impiego di altre forme contrattuali tradizionali: il contratto tempo e materiali con tetto dei costi, per esempio, oggi è la vera spina dorsale di aziende come ideato, che si permettono di chiedere al cliente appena acquisito un briciolo di fiducia in più sulla base della grande fiducia accordata dai clienti già acquisiti.

Il problema dei contratti tempo e materiali è che scalano male. Cosa intendo?

Intendo dire che i contratti che definiscono un prezzo in modo accoppiato al tempo speso per fornire valore ad un cliente hanno alcuni grossi difetti:

  1. mantengono il rischio completamente sbilanciato a sfavore del cliente.
  2. non incentivano la creatività nel cercare soluzioni migliori di rilascio, fatturazione o pagamento, riducendo quindi il valore medio dell’offerta.
  3. non incentivano l’azienda fornitrice allo sviluppo tecnologico, anzi, disincentivando l’innovazione! Un’azienda che fattura il tempo speso a lavorare non ha molti incentivi finanziari a ridurre il tempo impiegato a risolvere un dato problema(*).

Questa insofferenza per i contratti tradizionali – perché di insofferenza nel mio caso si tratta – potrebbe sembrare un dettaglio, un vezzo pignolo da fanatico agilista, ma vorrei invece ti fosse chiaro come un contratto sbagliato possa distruggere ogni sforzo di adozione di un approccio iterativo e incrementale. Lo preciso perché fra questi approcci figura anche quello detto lean start-up – scrivo strizzando l’occhio ad un tema molto in voga in questi mesi.

Nel gennaio 2011, chiamati a sviluppare un’applicazione mobile per la domotica, i ragazzi di e-xtrategy hanno dovuto gestire da subito una grande incertezza: requisiti descritti poco e male, un cliente abituato alla programmazione di dispositivi automatici senza esperienza di design di interfacce utente e tecnologie relativamente nuove rispetto all’esperienza del team. Necessariamente si imponeva su entrambi i versanti cliente-fornitore una forma contrattuale più intelligente, che portasse l’esposizione al rischio di entrambe le parti a convergere.

La soluzione

Cosa abbiamo pensato con e-xtrategy un anno fa per contribuire alla sovversione di preconcetti causa di sprechi tipici? L’idea fondante il nuovo contratto è nota da sempre in altri mercati: soddisfatti o rimborsati. Vediamo un po’ di dettagli.

Il team vende il suo tempo a prescindere dalle specifiche di progetto come nel caso del contratto time & material, ma sulla base dell’intera iterazione, come una tariffa flat per intenderci. “Per un’iterazione di sviluppo del tuo team io ti pago tot” ed il team incassa la cifra pattuita per ogni iterazione lavorata alla consegna del deliverable più opportuno (tipicamente il codice, ma anche template grafici, wireframe, prototipi etc etc). Il fornitore può rifiutare arbitrariamente il prodotto dell’ultima iterazione, rinunciando ad ogni diritto su esso, senza pagare il conmpenso stabilito.

“Eh ma così rischio di lavorare gratis!” ti sento già argomentare. Vero, rischio di lavorare gratis per la durata di un’iterazione. Ma nel caso di team sufficientemente maturi un’iterazione dura 5 giorni, quindi il rischio con un contratto di questo tipo è di lavorare gratis 5 giorni. Davvero non conosci alcun team sopravvissuto a 5 giorni di lavoro oltre una deadline stabilita da un contratto a corpo classico? Permettimi di dubitarne.

Fissando iterazioni brevi con questo contratto il cliente gode

  1. del controllo del time to market, potendo rilasciare virtualmente ogni 5 giorni in produzione
  2. della possibilità di scaricare il team in ogni momento, impegando al massimo 5 giorni per scoprire l’inadeguatezza del team selezionato
  3. della possibilità di allocare budget gradualmente, posticipando gli investimenti il più possibile
  4. della possibilità di definire con la massima libertà i requisiti senza inutili rigidità upfront

Fissando iterazioni brevi con questo contratto il fornitore gode

  1. della sicurezza di lavorare senza garanzia al massimo 5 giornate, scenario preferibile a molti scenari effettivi e tipici dei contratti a corpo
  2. di flussi di cassa stabili e ben parcellizzati
  3. dell’incentivo interno a migliorare la rapidità di sviluppo senza andare a discapito della qualità: se impiego meno tempo a parità di funzionalità consegnata evidentemente avrò margini più ampi, ma se la qualità degrada il cliente finirà per non pagarmi l’iterazione.
  4. della possibilità di servire il miglior ritorno di investimento, recependo i requisiti all’ultimo momento utile e responsabile

La vera morale

Ovviamente questa è una forma contrattuale che si fonda sulla (quasi) certezza del fornitore di apportare fin dalla prima iterazione valore concreto e apprezzabile al business del cliente. Non è quindi un contratto adatto a tutti, bisogna saperlo sostenere fin dalle più remote retrovie, coinvolgendo management, commerciali, programmatori, designer, grafici. Ma e-xtrategy dopo un anno si ritrova con un cliente soddisfatto, iterazioni acquistate e pagate ben oltre l’accordo iniziale e un prodotto completo, di alta qualità e in grado di abilitare il cliente a recuperare l’investimento fin dalle prime battute.

Insomma il vero obiettivo del mio lavoro: sviluppo sostenibile di software. Eh… quante soddisfazioni! :-)

Soprattuto – sono serio – la chance per me di raccontarvi che un altro mercato dell’information technology è possibile e non in un fantomatico paese paradisiaco d’oltralpe. È possibile qui e ora e dipende da noi, tutti noi. Tu allora lo vuoi?

(*) ovviamente rimangono intatti gli incentivi strategici: impiegare poco tempo per servire un cliente mi permette di servirne di più, anche quando la somma delle ore spese – e il fatturato – non cambiano. Rimane quindi comunque valido il principio di un servizio tempestivo e più rapido possibile.

February 08 2012 11:14 am | Dalle trincee

18 Responses to “Ho avvistato un contratto sano: esistono!”

  1. Giorgio Cefaro on 08 Feb 2012 at 11:46 #

    Quello che non ho ben chiaro è se il contratto che si sottoscrive copre un arco di tempo predeterminato che include più iterazioni ed ha delle clausole chiare rispetto ai diritti e doveri relativi alla singola iterazione, o si fa un contratto per iterazione (???) o cos’altro?

  2. Daniel Londero on 08 Feb 2012 at 11:49 #

    Tutto bello, ma mi sfugge una cosa: abbiamo il tempo (iterazione), abbiamo il costo (il TOT relativo all’iterazione), manca però il cosa si farà nell’iterazione (in termini di quantità che siano pomodori, story points o qualsiasi altra misura).

    Un’iterazione a TOT soldi per aggiungere un link o per creare FB (estremizzo per rendere chiaro il concetto) sono cose fondamentalmente diverse.

    Ci si basa sempre sulla velocity delle iterazioni precenti o della storia del team per stimare “dovremmo riuscire a fare queste cose” o la fiducia del cliente è tale da poter sopportare un “facciamo tutto quello che riusciamo”?

  3. Roberto Balducci on 08 Feb 2012 at 11:50 #

    Si in effetti è la logica evoluzione del lato prettamente economico della metodologia scrum.
    Se alla fine di un’iterazione produco qualcosa di deliverable e il cliente la accetta allora mi sembra molto ragionevole che paghi quello che è stato rilasciato.

    Un po’ come i lpagamento a stadi d’avanzamento nell’edilizia ma in questo caso il pagamento è posticipato e condizionato al fatto che il cliente ritenga soddisfacente il lavoro svolto.

    +1

  4. Federico Galassi on 08 Feb 2012 at 13:04 #

    Daniel, il cliente accetta “facciamo tutto quello che riusciamo” perchè ad ogni iterazione può dire “non mi soddisfa, ciao”. In pratica il soddisfatti o rimborsati riequilibra la percezione sfavorevole che il cliente associa al time & material. Il trucco sta nel fatto che per il fornitore la clausola appare iniqua, ma è ininfluente se questo sa fare bene il suo mestiere. Anche Clean Code adotta questa strategia, grande Jacopo!

  5. Daniel Londero on 08 Feb 2012 at 15:40 #

    Federico, grazie per aver condiviso la tua esperienza.

    Una curiosità: le “piccole modifiche” che arrivano di solito dal cliente (in molti casi per prendere tempo sul pagamento) le fate rientrare nell’iterazione successiva o sfruttando continuo feedback anche durante l’iterazione fate in modo di arrivare in fondo con tutte cose “pre approvate”?

  6. Massimiliano Atzori on 08 Feb 2012 at 16:17 #

    Ciao Jacopo, ottimo post, mi ha dato un sacco di spunti su cui riflettere! Però mi viene in mente una cosa: l’approccio mi torna per progetti in cui le iterazioni possono essere abbastanza brevi e il cui risultato finale sia ben comprensibile al cliente. Ma che succede se per mettere su qualcosa sono necessarie diverse iterazioni, ciascuna delle quali è importante per quella successiva?

  7. Cesare D'Amico on 08 Feb 2012 at 16:43 #

    +1 per il punto sollevato da Massimiliano Atzori, te lo volevo chiedere pure io :)
    Anche perché questa è una cosa che succede all’inizio di ogni progetto, di deliverable non è che ci sia molto dopo la prima settimana…

  8. Jacopo Romei on 08 Feb 2012 at 16:46 #

    “Ovviamente questa è una forma contrattuale che si fonda sulla (quasi) certezza del fornitore di apportare fin dalla prima iterazione valore concreto e apprezzabile al business del cliente. Non è quindi un contratto adatto a tutti, bisogna saperlo sostenere fin dalle più remote retrovie, coinvolgendo management, commerciali, programmatori, designer, grafici.”

  9. Cesare D'Amico on 08 Feb 2012 at 16:48 #

    Touché :-P

  10. Federico Galassi on 08 Feb 2012 at 17:14 #

    Daniel, nell’iterazione successiva.
    Cesare, se un problema non permette un deliverable in una settimana forse stai risolvendo il problema sbagliato ;) http://www.azarask.in/blog/post/the-wrong-problem/

  11. Cesare D'Amico on 08 Feb 2012 at 17:44 #

    Giusto, in effetti però parlo da una prospettiva specifica, one-man-show che non segue un progetto alla volta…

  12. Massimiliano Atzori on 08 Feb 2012 at 17:54 #

    Jacopo, aspetta, non te la cavi così facilmente :) Io non ho scritto che la prima iterazione e le successive non portano “valore concreto e apprezzabile al business del cliente”: ho scritto semplicemente che questo valore non è visibile sotto forma di deliverable o simili, e che per produrre i primi risultati apprezzabili ci vuole più tempo e più iterazioni. Pensa a questi progetti come a degli iceberg, in cui la parte visibile (la superficie) è una frazione molto piccola rispetto al lavoro totale.

    Daniel, non sono daccordo che se un progetto non riesce a produrre un deliverable in una settimana si sta automaticamente usando un approccio sbagliato. Paradossalmente, in molti progetti il problema è appunto dover produrre un deliverable la settimana. Ci ricaschiamo?

  13. Massimiliano Atzori on 08 Feb 2012 at 17:55 #

    Ehm, il secondo in realtà era per Federico :)

  14. Federico Galassi on 08 Feb 2012 at 18:30 #

    Massimiliano, eh si, è uno di quei temi universali su cui ognuno ha la sua opinione. Io mi limito ad ascoltare le foto dei defunti dell’attimo fuggente, e già da qualche tempo mi sussurrano: “faiiillll faaaaasssst”

  15. Stefano Leli on 13 Feb 2012 at 20:17 #

    Ottimo post.
    Anche io mi sto orientando sull’utilizzo/suggerire questa tipologia di contratti, a volte con qualche variante. In particolare in alcuni contesti dove l’iterazione è più lunga (tipicamente 2 settimane) mi è stato fatto notare come perdere uno Sprint di lavoro di un team da 6/8 persone possa essere oneroso. Le varianti che ho visto adottare sono state:

    1. L’iterazione mancata si perde al 50%, quindi il team verrebbe pagato per la metà del lavoro.

    2. Come sopra ma a partire dalla terza iterazione. Questa variante è stata applicata perché non si voleva vincolare il cliente nella fase iniziale del progetto (cliente nuovo)

    3. Altre che spero di approfondire in un nostro prossimo incontro…marzo? :-)

    Personalmente sono convinto che questo approccio (con varianti o meno) sia la soluzione migliore per team ben rodati, che lavorano con iterazioni di 1/2 settimane e dove la qualità del deliverable è alta (punto fondamentale). Va da se che deve esserci un forte commitment in tutta l’azienda su tale modo di lavorare.

    PS: Ad un incontro di qualche anno fa dell’xpug Marche abbiamo trattato proprio di contratti agili. Discussione molto interessante, trovi le slide all’indirizzo http://goo.gl/5Qidt

  16. Jacopo Romei on 13 Feb 2012 at 21:03 #

    Stefano, scherzi? Le slide di Roberto sono un asset fondamentale del mio quotidiano! :-)
    Domanda: all’iterazione mancata pagata al 50% si consegna il codice o no? Siccome immagino di sì, realisticamente, mi chiedo come questo accordo non incentivi il cliente a pagare solo metà dell’ultima iterazione senza contropartita, apprestandosi a scaricare il team.

  17. Stefano Leli on 13 Feb 2012 at 23:48 #

    mmm…ottima osservazione, effettivamente in questo modo esiste la possibilità di non avere pagata l’ultima settimana di lavoro.
    In realtà questo era vero per la prima variante, nella seconda (cliente nuovo) se si abbandonava il progetto in una delle ultime iterazioni (mi sembra 2) non si otteneva il codice di quella iterazione. Il ciente aveva accettato questo tipo di contratto perché da una parte aveva una libertà iniziale di abbandonare il progetto quando voleva senza spendere un euro, dall’altra capiva che probabilmente abbandonare a 1/2 iterazioni dalla fine non avrebbe avuto molto senso.

    In realtà quello che penso (essendo a volte stato cliente) è che se trovo un team (ma soprattutto un’azienda) che rispetti i requisiti di cui prima, difficilemnte rischierei di mettere in discussione un rapporto futuro per una settimana di lavoro.

  18. Alessio on 24 Aug 2012 at 08:21 #

    Ottimo! Parto dalle stesse premesse in http://alessiosaltarin.blogspot.com/2012/07/non-molto-agili-fin-qui.html, anche se sono un po’ più pessimista sulle possibilità di superare gli ostacoli…

Trackback URI | Comments RSS

Leave a Reply