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 | Dalle trincee | 18 Comments »

phpDay 2009: Sue me sue you blues – Contratti e preventivi nei processi agili

Con la tipica tempestività di un maschio di testuggine delle Galapagos, ecco qui le slide e il video del mio talk all’ultimo phpDay 2009.

Colgo l’occasione per ringraziare il Gr.U.S.P dell’organizzazione, perfetta, e per celebrare il pieno successo della manifestazione, a dispetto sia delle previsioni, sia della sfiducia di chi, per difendere la propria, sbeffeggiava la decisione altrui di partecipare. Quest’anno il phpDay ha sfoderato una line up da far invidia ad eventi solitamente molto più blasonati. Ed escludo assolutamente senza falsa modestia il sottoscritto.

Come sempre è stato un piacere consolidare vecchie conoscenze, creare nuovi contatti e, diciamolo, sapere che Gabriele e Federico a settembre pubblicheranno il frutto del loro durissimo lavoro permettendo a tutti noi nerd scacchisti – chi più chi meno – di giocare RESTful. ;)

Buona visione/lettura/ascolto!

May 22 2009 | Eventi | No Comments »

phpDay 2009: e tre!

È con immenso e sinceramente partecipe piacere che ti comunico la mia terza partecipazione consecutiva al phpDay, evento annuale che ha sempre rappresentato per me un momento molto significativo per la mia consapevolezza IT, sia nello sviluppo sia nella gestione dei progetti.

Devo infatti ad un lontano phpDay passato – e a Gabriele Lana, presente anche nell’edizione 2009 – il mio colpo di fulmine agile e sempre ad un phpDay – sebbene più recente – il mio primo talk pubblico su Extreme Programming.

Quest’anno peraltro il carnet di ospiti è di quelli da far impallidire… il sottoscritto! Sarà difficilissimo essere all’altezza di nomi di tale fama nazionale e internazionale. Di questo credo sia già il caso di – non :) – ringraziare il Gr.U.S.P., che saprà organizzare tutto perfettamente come sempre in passato.

Anche stavolta, tanto per non smentirmi, non toccherò mezza riga di codice PHP ma mi riproporrò con un talk ad alto livello – in senso informatico, non ho smarrito tutta la modestia! – su uno fra i temi che avverto più scottanti nella community in questi mesi: i preventivi e i contratti nei progetti agili.

Beh, non mi resta che invitarti a partecipare: Sue me, sue you blues – Preventivi e contratti nei processi agili, 15/16 maggio 2009 a Verona. Ci vediamo lì?

p.s. stavo per dimenticare: per il terzo anno di seguito sarò ad un settentrionalissimo phpDay in compagnia di Bonacivita, il lealissimo motociclo cui rendo un doveroso omaggio con questo post, tentando di stabilire una privatissima tradizione di phpDay in phpDay

Bonacivita

March 30 2009 | Eventi | No Comments »