Contratti

Il mio primo progetto fu un programma per la gestione della biblioteca di un paesino vicino al mio. Scritto nel 1985 prima con il mitico Dbase III e poi con l’ancor più mitico Clipper 86/87 è ancora in uso dopo la bellezza di 24 anni. L’applicativo gestiva, anzi gestisce ancora!, libri, periodici, soci e prestiti. A suo modo, fin da allora faceva già il mail-merge, visto che la bibliotecaria scriveva in un form “Caro @NOME, ci deve restituire i @LIBRI il cui prestito è scaduto…” e a quel punto il programma stampava le lettere, con tanto di etichette per le buste, per tutti i soci ritardatari. Allora chiesi un compenso di ben 2.800.000 lire (la solita stima fatta prima e la solita fattura unica fatta alla fine).

Posso dire con orgoglio che, oltre che il mio primo lavoro informatico, fu anche il mio primo bagno di sangue! 🙂

Bagno di sangue

Le “stime”

Da allora ho sicuramente imparato un po’ meglio a fare le stime (appena un po’, ma non potrebbe essere diversamente, altrimenti non sarei ancora qui a fare lo stesso lavoro). Ciò nonostante, quella non è stata l’unica debacle extimatoria che ho avuto, soprattutto da quando ho dovuto fare previsioni sul tempo in cui, non io ma altri, avrebbero dovuto realizzare il progetto.

Quante volte vi sarete trovati in una situazione simile? Il vostro cliente vi chiede “Ma quanto mi costerà?” e voi, che nel vostro intimo più profondo conoscete già la risposta giusta “Te lo potrò dire solo alla fine!”, vi sentite pronunciare, con voce dall’oltretomba, una cifra nella vana speranza di non sbagliare di troppo in difetto.

Stranamente non esiste la situazione in cui si sbaglia di troppo in eccesso, infatti ci sono un sacco di aneddoti su come si devono fare le stime e tutti usano addizioni e/o moltiplicazioni. Poco tempo fa un amico mi ha raccontato che il suo professore di informatica gli diceva di moltiplicare per due e aumentare di un ordine di grandezza la stima (“dici 1 ora? Saranno 2 giorni; prevedi 2 giorni? Ci vorranno 4 settimane; stimi 4 settimane? Calcola pure 8 mesi”).

Ah, quante volte, in tanti anni di stime, offerte, progetti, contratti ho visto la battaglia tra queste due forze opposte che si sostengono a vicenda, non possono fare a meno l’una dell’altra, ma sempre su fronti opposti del campo di battaglia: il cliente e il fornitore!

Cane e gatto

Agile?

Certo esistono i grossi soliti nomi, che possono permettersi progetti dove l’unità di misura sono MdAD (migliaia di anni “dummy”), dove i programmatori si affittano a tonnellate un tot al chilo. È facile in questo modo chiudere un progetto in verde. Si affitta forza lavoro, spesso “mediamente incompetente”, per cui il pericolo di sbagliare è prossimo allo zero, fintanto che si munge il cliente fino al punto di fallimento ma non oltre.

Per i pesci piccoli, come me e, credo, la maggior parte di coloro che mi stanno leggendo, soprattutto in tempi grami come questi, il momento dell’offerta è sempre delicato e pericoloso, un momento in cui il futuro del progetto corre sul filo del rifiuto da parte del cliente da una parte e il “bagno di sangue” dall’altra.

Da sempre ho affrontato questo momento seguendo l’istinto, che altro non è che una inconscia raccolta di case-history, fino a quando, se non ricordo male era il 2007, andai all’Agile Day a Bologna. Tra i molti e interessanti talk ne seguii uno che parlava di contratti agili.

Bagno di sangue

L’ottimo speaker, Alex Ruggeri, descrisse le varie modalità di contratto tradizionale e come il movimento agile cercasse di andare oltre.

Il vecchio

Da un lato ci sono i time & material, il rischio è tutto del cliente, il fornitore è in una botte di ferro, non perde e non vince mai. Dal lato opposto ci sono i contratti all-inclusive, dove invece il rischio è tutto del fornitore, mentre il cliente, all’apparenza, non corre pericoli. Perché scrivo all’apparenza? Perchè in realtà, nei bagni di sangue chi ci rimette è senza dubbio il fornitore ma, subito dopo, viene il suo cliente che crede, magari, di aver fatto un affare, ma in realtà si trova un applicativo raffazzonato, portato a termine alla bell’e meglio, pieno di bachi, quando addirittura non funzionante.

Lo speaker cominciò a questo punto a parlare di contratti agili in cui si prospettava una situazione ideale di completa fiducia tra cliente e fornitore. Infatti, se non ricordo male, diceva che gli unici clienti con cui era riuscito a stipulare questi contratti agili erano di vecchia data.

Al mio ritorno ho indagato un po’ a proposito di questi contratti agili e ho provato a formularne una versione personale. Non pretendo di avere inventato nulla, anzi, ho senz’altro fatto un patchwork di tante soluzioni, però nel mio caso questa formula ha già funzionato più volte nel mondo reale, non quello dei libri (pun not intended 🙂 ).

Ora, nella speranza di fare cosa gradita, proverò a descrivere con un esempio pratico cosa cerco di proporre da allora ai miei clienti, anche quelli nuovi!

Il cliente vi chiama, vuole rifare la sua intranet e comincia a parlarvi di questo mega-progetto in cui tutto è integrato: i dati dal gestionale, il CRM, la bacheca, le best-practices e via dicendo. Voi ponete tutte le domande del caso, fate un po’ di calcoli e alla fine ritenete che 200 giornate potrebbe essere una stima più o meno sensata. Calcolando una tariffa da “pesci molto piccoli” di 300 € al giorno fanno 60.000 €. A questo punto andate dal cliente e gli proponete un contratto agile.

Contratto agile

Il nuovo

Invece di chiedere un fisso per tutto il progetto o di chiedere un tot al giorno, la tariffa è divisa in due: 30.000 € rappresentano la quota fissa, fatturata in diversi momenti del progetto, per esempio un terzo all’ordine, un terzo dopo 3 mesi e l’ultimo terzo a collaudo effettuato, il resto viene fatturato a 150 € al giorno per ogni giorno effettivamente fornito. Vediamo ora alcuni possibili scenari.

Fortuna. Siete stati degli ottimi chiromanti e il progetto viene completato in 200 giorni esatti, il cliente paga i 30.000 € delle tre tranche fisse, più i 150 € a giornata per 200 che fanno altri 30.000 €. Esattamente la cifra totale prevista ad un rate giornaliero di 300 €.

Fantascienza. Il progetto viene completato in 150 giorni, il cliente paga la quota fissa di 30.000 € più 150 * 150 € = 22.500 €. Totale 52.500 €. Il cliente risparmia e voi avete guadagnato 350 € al giorno.

Realtà. Il progetto, a causa di difficoltà impreviste (che per definizione non potevano essere previste altrimenti non sarebbero state impreviste) viene completato in 300 giorni, il cliente paga la quota fissa di 30.000 € più 150 * 300 € = 45.000 €. Totale 75.000 €. Il cliente, a fronte di un aumento del 50% dei tempi previsti, affronta un aumento dei costi di solo il 25% e voi avete comunque guadagnato 250 € al giorno.

Qual è lo scenario migliore? Il secondo, quello in cui il cliente paga meno e voi guadagnate di più per ogni giorno di lavoro. Qual è quello peggiore? Senza dubbio l’ultimo, dove il cliente paga di più, il progetto finisce in ritardo e voi guadagnate di meno per ogni giorno di lavoro.

Bingo! Un contratto dove sia voi che il vostro cliente siete contenti nello stesso ipotetico scenario! Vorrà dire che entrambi remerete in quella stessa direzione.

Il cliente vi chiederà a questo punto “Ma chi mi garantisce che non andremo avanti all’infinito o che non mi chiederai un numero di giornate eccessivo?”. È una domanda lecita che, per ottenere la fiducia necessaria a chiudere il contratto agile, richiede una risposta forte: ad ogni fine mese voi consegnerete tutti i sorgenti al cliente insieme alla fattura periodica. Se il cliente riterrà di non ricevere del valore adeguato a fronte della relativa fattura, avrà il diritto di rescindere il contratto, tenendosi i sorgenti e tutti amici come prima. Non serviranno altre motivazioni che il giudizio del cliente.

Il cliente a questo punto potrà chiedervi “Ma come faccio a valutare questo cosiddetto valore e cosa me ne faccio dei sorgenti?”. Voi potrete rispondergli che non solo a fine mese, ma di settimana in settimana, lui potrà verificare lo stato di avanzamento del progetto, collegandosi e testando la versione in sviluppo, accessibile via web. I sorgenti gli garantiranno di essere di fatto indipendente da voi e di poter interrompere il progetto per riprenderlo o con altri fornitori o, per assurdo, in un secondo momento di nuovo con voi, quando si saranno ripresentate le condizioni economiche per poterlo fare.

E tutto questo voi lo scriverete nel contratto!

La morale

A questo punto la vostra domanda a me sarà “Ma come? Chi mi garantisce che il cliente a metà non mi pianti in asso?”. E io vi rispondo “Ma ovviamente la qualità del vostro lavoro!”.

Se ritenete non soddisfacente questa risposta, allora questa modalità di contratto non fa per voi.

Dove osano le aquile
About Marco Beri

Marco Beri si laurea in Scienze dell’Informazione nel 1990, periodo oramai definibile come la preistoria del settore. Il computer è prima di tutto un suo hobby e anche per questo si innamora di Python a prima vista nel lontano 1999, dopo aver sperimentato una ventina di altri linguaggi. Fa di tutto, riuscendoci, per portarlo nella sua azienda, la Link I.T. spa, dove dal 1997 occupa il ruolo di amministratore e responsabile dello sviluppo software. Riesce perfino a intrufolarsi come amministratore nella fondazione dell’associazione Python Italia. Incredibilmente pubblica anche diversi libri per Apogeo/Feltrinelli.

Comments

  1. Giovanni Porcari says:

    Mi sembra un’ottima soluzione. Io ho sempre puntato più sugli accordi di assistenza e manutenzione che sulla fornitura iniziale perchè questo consente al cliente di diluire nel tempo la spesa e di mantenere un ottimo livello di aggiornamento delle procedure. Insomma invece che la gallina oggi meglio una rendita fissa in uova ;).

  2. Complimenti per il post.
    Il tema dei contratti è uno dei punti deboli del ‘movimento agile’; riflettere su diverse possibili soluzioni è doveroso.

    La soluzione proposta va nella direzione del win-win. L’hai già sperimentata?

  3. @Tommaso: grazie! Riguardo al successo della formula, mi autocito dal post “nel mio caso questa formula ha già funzionato più volte nel mondo reale” 🙂

    Quel più volte equivale a 3. E non si trattava di progetti così piccoli.

  4. @Giovanni: sì, è vero che è auspicabile un contratto di manutenzione, ma se questo si riesce a strappare abbastanza facilmente con i gestionali, è spesso un’impresa riuscirci con i progetti meno tradizionali. Comunque mi dai uno spunto per migliorare in futuro 🙂

  5. Paolo "Nusco" Perrotta says:

    Per un piccolo progetto di qualche anno fa, feci esattamente come hai suggerito tu. Ha funzionato molto bene. Dopo un paio di iterazioni, il cliente si è reso conto di avere già le funzionalità che gli servivano, e ci siamo salutati con reciproca soddisfazione.

  6. Andrea Spadaccini says:

    Complimenti, ottimo post!

  7. Splendida idea !
    (di solito mi frego da sola con il tutto compreso 🙂 )
    maturo l’idea e alla prossima occasione lo propongo sicuramente.
    Grazie, Grazia

  8. Ottimo post ed ottimo spunto per i prossimi “contratti” 😉

  9. @Paolo “Nusco” Perrotta: e dopo quella volta del piccolo progetto, non hai più ottenuto le stesse condizioni? Come mai?

  10. claudio.cicali says:

    Un po’ l’uovo di Colombo dei contratti 🙂 Grazie, bel post.

  11. Articolo illuminante 😉

    Anche io applico qualcosa di simile e credo che integrerò i tuoi spunti. In genere, quando possibile, cerco di dividere il lavoro in *tappe*. Ad esempio nel caso di un e-commerce potrebbe essere: 1) preparo il cms per gestire il sito 2) aggiungo la gestione per il commercio 3) aggiungo il pagamento con uno o più sistemi di pagamento con carta di credito.
    Rateizzando il progetto, le scadenze hanno una prevedibilità migliore (il range di tempo è minore), il cliente ha modo di diluire la spesa e valutare il lavoro un passo alla volta (chiedendo modifiche o mettendo in stand-by il lavoro senza rimanere con qualcosa di incompiuto), io posso *switchare* meglio tra i clienti 😛

    un saluto,
    Andrea

  12. molto interessante ed è un approcio simile a quello utilizzato per il followup dei progetti (dove followup è un termine riduttivo) o per clienti già in essere dove riusciamo addirittura a lavorare su iterazioni di 5 giornate (e sono progetti grossi).

    Il problema grosso è che molti clienti di nuova acquisizione entrano in casa ed affermano io ho X mila euro e voglio questo (valutabile in X*n mila euro). Fregandosene delle metodologie, dei reciproci vantaggi dei contratti incrementali e (spesso) del buon senso…

    In questo caso di volta in volta si valuta il “rischio cliente” e si decide se lavorarci insieme o meno… e purtroppo, da quel che ho visto, non esiste una ricetta “certa” per salvaguardarsi e l’unica cosa da fare è affidarsi al proprio intuito… 🙁

  13. mi sembra un ottimo approccio per i contratti da far seguire a sviluppo con metodologia agile.

    bisogna lavorarci molto, sui clienti intendo; perche’ spesso quello che fanno e’ confrontare la tua offerta con altre e nella maggior parte dei casi (la totalita’, per quanto mi riguarda) questo metodo di approccio (anche quello “agile puro”) sembra fuori dal mondo.
    forse lo e’, visto che siamo (sono) abituati a ragionare in termini diversi.

    ma fare un esempio numerico, come hai fatto tu, aiuta senza dubbio.

    lo sperimentero’ e ti faro’ sapere 🙂

    mike.

  14. @fullo: condivido con te, l’intuito, checché se ne pensi, ha ancora tanta parte nel nostro lavoro. Per il resto non posso certo vantare il 100% di successi nell’ottenere questo contratto, ma ultimamente siamo al 50%. E spesso i clienti che non accettano sono quelli che fanno parte di quelli con cui non conviene lavorare.

    @mike: in bocca al lupo, sono sicuro che alla fine troverai un cliente che accetterà convinto questo approccio.

  15. Complimenti per il post, sia per il contenuto che per la forma!

  16. Bell’articolo. Illuminante. Non mi era mai venuto in mente di dividere in questo modo il totale del progetto. La seconda soluzione ti spinge a lavorare molto più in fretta. Devo provarla con qualche prossimo cliente (se mai arriveranno).

  17. Per quanto riguarda le stime io mi sono sempre trovato bene con la regola del 4x. Se penso che per un lavoro ci voglia un’ora dico 4. Se sembrano necessarie 2 ore dico una giornata. Un giornata piena diventa una settimana. Di fatto il tempo reale di lavoro e’ piu’ o meno quello. Di solito sbaglio di poco, ma non ho provato mai a stimare cose piu’ grosse di tre settimane,

  18. @Michele: per curiosità sono stime che hai fatto su codice che dovevi scrivere tu o che doveva scrivere qualcun’altro?

  19. Bell’articolo Marco!

    Per dare al cliente il polso della situazione del progetto noi forniamo anche:
    A) Invio automatico di email giornaliere con i diff del lavoro fatto nelle precedenti ore di lavoro.
    B) Report online di quale programmatore ha lavorato quante ore, quale giorno e su quale fase del progetto.

    Il cliente potrà poi valutare se il lavoro A vale il costo B.

  20. Non mi e’ mai capitato di dovere stimare il tempo di lavoro di altre persone.

  21. @Michele: se ti dovesse capitare, non posso che consigliarti di moltiplicare almeno x40, per raggiungere il livello di un Essere Umano Normale™ 😉

  22. @Michele: per me è stata una bella scottatura iniziare a fare le stime sulla pelle degli altri.

  23. Interesting post and my friend in Italy pointed it to me after i wrote this.
    http://lotustech.blogspot.com/2009/12/do-you-use-this-line-in-your-contracts.html

    The agile way implies to me a better offering for a repeat customer. Most 1st time clients will not go for this because it implies you will never finish the project.

    If you find you are way off in estimates or even if the extension of time is because they have no solution ready to be used yet, than you are still not being fair to the client.

    I prefer total project pricing which allows for leveraging deadlines and other opportunities but also keeps scope creep minimal and then provides new projects.

  24. @Keith: Why do you state “Most 1st time clients will not go for this because it implies you will never finish the project?”
    I do not agree 🙂

  25. massimo says:

    Clipper vive ancora ..
    Un potente linguaggio compatibile con clipper è disponibile su
    http://www.harbour-project.org/

Policy per i commenti: Apprezzo moltissimo i vostri commenti, critiche incluse. Per evitare spam e troll, e far rimanere il discorso civile, i commenti sono moderati e prontamente approvati poco dopo il loro invio.


Speak Your Mind

*

Time limit is exhausted. Please reload CAPTCHA.