Newsgroup: it.lavoro.informatica
Titolo: Contratti "sani"

Cari ili-isti,
 
vi propongo un interessantissimo post su una esperienza di contratto "agile"
 
http://www.sviluppoagile.it/ho-avvistato-un-contratto-agile-sano-esistono
 
 
Per i più pigri, il testo del post è in calce.
:-)
 
Ciao,
Giulio
 
_______________________
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
 
* mantengano il rischio completamente sbilanciato sul fornitore che, per 
definizione, non dovrebbe invece partecipare al rischio d’impresa 
neanche un po’
* 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:
 
mantengono il rischio completamente sbilanciato a sfavore del cliente.
non incentivano la creatività nel cercare soluzioni migliori di 
rilascio, fatturazione o pagamento, riducendo quindi il valore medio 
dell’offerta.
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
 
* del controllo del time to market, potendo rilasciare virtualmente ogni 
5 giorni in produzione
* della possibilità di scaricare il team in ogni momento, impegando al 
massimo 5 giorni per scoprire l’inadeguatezza del team selezionato
* della possibilità di allocare budget gradualmente, posticipando gli 
investimenti il più possibile
* della possibilità di definire con la massima libertà i requisiti senza 
inutili rigidità upfront
 
Fissando iterazioni brevi con questo contratto il fornitore gode
 
* della sicurezza di lavorare senza garanzia al massimo 5 giornate, 
scenario preferibile a molti scenari effettivi e tipici dei contratti a 
corpo
* di flussi di cassa stabili e ben parcellizzati
* 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.
* 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.
 

 
http://www.sviluppoagile.it/ho-avvistato-un-contratto-agile-sano-esis.
..

Sicuramente si puo' prendere ispirazione.. adeguare il lato economico
al ritmo con cui si lavora, cioe' alle iterazioni, credo che sia un '
idea sana.. direi quasi una conseguenza necessaria della metodologia
agile, ma credo sia necessario anche un "ombrello" a livello
superiore...e credo ci voglia anche il cliente "giusto" per questo
tipo di operazioni...

 Giulio
 
Ciao
 
M.
-- 
Credo che l'unica cosa da fare sia non prendersi troppo sul serio,
ridersi addosso, e sorridere spesso, così le rughe andranno nei posti 
giusti....
(A. Vincenzi)

 lavoratore, ma meno peggio di quello che si vede in giro.
 
Un  problema sorge se le interazioni cominciano ad allungarsi per la 
complessita intrinseca del lavoro da consegnare.
 
 
 

 Cari ili-isti,
 
Tutti i contratti sono SANI fino a che non sorgono problemi.
 
Nello specifico mi sembra che quello proposto (per l'azienda
informatica) pessimo, con più rischi rispetto alla consegna a corpo e
al time/material con un x giorni definito.  Una vera e propria
fregatura.
 
Ed in effetti, quando un progetto va a rotoli, quel che il cliente fa
quando è stufo di promesse su un progetto a corpo  è imporre un SAL
settimanale..... mi sfugge perché io informatico mi devo mettere in
questa condizione autonomamente.

 vi propongo un interessantissimo post su una esperienza di contratto "agile"
 
Semplicemente, un'ennesima descrizione di un'implementazione di
concetti Lean.
 
http://en.wikipedia.org/wiki/Lean_manufacturing
 
http://en.wikipedia.org/wiki/Lean_IT
 
http://en.wikipedia.org/wiki/Lean_software_development
 
 
Toyota rulez! ;)
 
--
ale
http://ale.riolo.co.uk
 


Infatti, questo discorso lo vedo bene per esigenze "spot", la roba 
voluminosa va "industrializzata" con altro approccio.
 
Ciao.


 fregatura.
 
non mi pare proprio. rispetto a time & material ovviamente si, ma con
un contratto che prevede il pagamento alla consegna finale nel caso
sorga una contestazione tu hai fatto tutto il lavoro e il cliente non
ti paga *nulla*. in quella formula invece il cliente al massimo non ti
paga l'ultima iterazione perché le altre le ha approvate.

 paga l'ultima iterazione perché le altre le ha approvate.
 
Sostanzialmetne sarebbe una sorta di pagamento a stato avanzamento lavori.


un po' diverso. pagando a stato avanzamento lavori ad ogni iterazione
il cliente dovrebbe pagare la trance, in realtà in quel caso paga
comunque alla fine solo che la formula contrattuale "blinda" i
pagamenti per le fasi già approvate. in un contratto a progetto con il
collaudo finale se il cliente respinge il prodotto blocca tutto il
pagamento, in quel caso può bloccare legittimamente solo a partire
dall'ultima iterazione che ha approvato.

 dall'ultima iterazione che ha approvato.
 
Meglio allora la formula pagamento  a stato avanzamento lavori.
 
 

 Giulio
 
 
Se lo fosse proposto alle aziende pratesi, le software house fallirebbero dopo 3 mesi.
Che poi siano fallite lo stesso (per altri motivi) è un altro discorso...

 motivi) è un altro discorso...
 
ahahah... io ho fatto anche i'cchimico di tintoria in un'altra vita (un 
quarto di secolo fa). 
comunque non sono molto d'accordo.


meglio ancora il pagamento anticipato, se proprio vogliamo dirla alla 
catalano :)

 catalano :)
Quello forse pende troppo dalla parte del fornitore :)

 comunque non sono molto d'accordo.
 
Mah...Io c'ho lavorato per un po' e tutte le scuse erano buone per non 
pagare.
I problemi delle aziende informatiche a Prato è stata l'avidità delle 
aziende che si son fatte la guerra solo sul prezzo, ammazzandosi e 
impoverendosi a vicenda
 
 
 
 
-- 
http://blog.mainardi.me
 
http://about.me/lormayna
 
python -c "print 'bG9ybWF5bmFAZ21haWwuY29t'.decode('base64')"

 giorni.
 
Ok, ma per non rimanere nell'astratto, 5 giorni per il cliente sono  euro 
pari a?
E il prezzo è fisso oppure varia in base a cosa è contenuto nella 
"transazione", a parità di tempo.
E quando tocca reiterare perché comunque "non ci si era capiti bene", che si 
fa? Sconticino o altro?
 

 impoverendosi a vicenda
 
mah dico sinceramente da quando lavoro nell'informatica ho lavorato 
pochissimo con prato, quasi per niente. 

 pochissimo con prato, quasi per niente.
 
Meglio per te, io sono scappato a gambe levate


 che si fa? Sconticino o altro?
 
no che sconticino. reiteri l'iterazione, finché non hai l'approvazione e 
passi a quella successiva.
d'altra parte preferisci scoprirlo in fondo che "non ci si era capiti 
bene"?
 


 
Il rischio di misunderstanding puo' essere mitigato con una gestione 
corretta della raccolta dei requisiti e con la modellazione.
Cosi' anticipi ancora di piu'.

 Ho diversi familiari "buzzini" e anche loro dicono la stessa cosa.
 
eh già, non s'avesse a capire da dove si proviene :)

 sorga una contestazione tu hai fatto tutto il lavoro e il cliente non
 
Beh no. Intanto non si lavora senza un aticipo, anche piccolo. Poi
comunque un progetto "classico" lo si fa sulla base di un preventivo /
analisi firmata. E se il progetto è grosso ci sono dei SAL e dei
successivi anticipi.
 
Dicevo, il vantaggio del firmare a corpo è che il cliente si impegna
per una cifra x per avere un prodotto y. Alla fine se hai fatto un
buco nell'acqua stai zitto ma se il prodotto y lo hai fatto puoi
rivolgerti ad un giudice per avere i soldi.
 
Con un progetto a corpo firmato puoi pianificare il tuo tempo,
pianificare il progetto e dimensionare team e materiali. Far partire
un progetto è anche un investimento e solitamente nelle fasi iniziali
è più il lavoro del risultato.
 
Nella proposta  "agile" invece se il cliente si stufa dopo 2 o 6
iterazioni hai chiuso. E' finita. E tutto il tuo investimento iniziale
lo puoi anche buttare, ti trovi un team scarico e non sai che fare
domani.
 
Poi comunque potrebbe non pagarti le iterazioni concluse perché se pur
corte diciamo di 10gg poi li fatturi comunque a fine mese e i soldi li
prendi dopo un bel po'.
 
Il contratto potrebbe essere carino per abituare il cliente a
spendere, ovvero a chiedere e ottenere, ma appena con le iterazioni
superi il budget che si era prefissato ed in mano non ha ancora
niente, potrebbero sorgere dei problemi. Per esperienza quando il
cliente vede il costo del "bottone aggiunto" i problemi crescono non
diminuiscono.
 
Non so, resto del parere che per lavorare Agili bisogna avere un
cliente particolare, meglio se interno. In tutti gli altri casi meno
potere/responsabilità dai al cliente e meglio è. Io sono del parere
lui mi paga, io risolvo ed i ca...i sono miei, nel bene e nel male.
 
 

 domani.
 
vabbeh che vuol dire "si stufa"? non è che nella proposta "agile" si sta 
a giocare. anche lì c'è un contratto e se il cliente cambia idea durante 
la realizzazione il problema è tecnicamente uguale. metti che anche a te 
il cliente ad un certo punto ti telefona e ti dice "no guarda, lascia 
perdere che mi sono stufato non lo voglio più" ti trovi nella stessa 
situazione eh...


io non sono un fanatico delle metodologie agili ma temo che queste 
metodologie che prevedono di lavorare a stretto giro di rilasci nascono 
proprio perché fidarsi della raccolta dei requisiti è la principale fonte 
di fraintendimenti. il cliente per astratto non ci sa ragionare e tanto 
finché non "vede" qualcosa non lo sa affatto quello che vuole. 
 
 


E' vero questo. Ma non si tratta di ragioanre in astratto se modelli.E' 
chiaro che devi essere bravo a comunicare e a capire sopratutto.
Le metodologie agili a mio avviso sono efficaci se possiedi già la 
conoscenza del dominio e il team e' piccolo e molto affiatato.Su grossi 
progetti o dove serve approfondire la conoscenza dei  domini di 
riferimento ho qualche dubbio che si adattino bene.

 riferimento ho qualche dubbio che si adattino bene.
 
Queste metodologie funzionano soprattutto - cosa veramente più
importante - se il cliente PAGA.
 
Se il cliente, quando arriva il conto, inizia col piagnucolare che vuole
lo sconticino, la dilazione, altre giornate bonus... di agile c'è il
padulo che ti si infila dietro.
 
Di clienti pronti a pagare le iterazioni finora non ne ho conosciuto
manco uno...
 
M.


mi chiedo lo stesso cliente che vede la fattura a lavoro finito e
consegnato non si mette a piagnucolare? e se si, non è un padulo
ancora più enorme visto che tu hai terminato il lavoro (quindi sei
esposto al massimo) e ciò che il cliente ti contesta è *tutto*
l'importo?
mah...
 

 a giocare. anche lì c'è un contratto e se il cliente cambia idea durante
 
No, mi manca un pezzetto. Nella proposta "agile"  puoi inserire un
impegno per il progetto nel suo complesso ?
 
Ovvero, che fai un contratto dove dici per fare l'applicazione ci dai
40.000 euro, ogni iter ci vediamo e te me lo approvi, ogni iter sarà
più o meno di 5.000 euro. Se non ti piace ce lo scarti e reiteriamo.
 
E' una cosa del genere la proposta ? Il problema è che come fai in un
progetto agile a fissare un importo per l'intero progetto... dipende
da come si evolverà.


Questo pero' e' un problema che c'e' a prescindere dalla metodologia.
Se un cliente ha gia' in testa l'obiettivo di non  pagare non c'e' 
metodologia che tenga.


 
No no per carità.
Alla fine mi sa che è in ogni caso un buon metodo perchè permette in modo 
"veloce" di capire:
- quanta disponibilità di dindi reale c'è da parte del cliente (si stufa di 
pagare dopo 1, 2, 3, n iterazioni);
- quanto costa al cliente quello che sta chiedendo/cercando di chiedere;
- quanta sintonia c'è tra il cliente e il fornitore, più che altro per la 
riuscita condivisione delle specifiche;
- che capacità reali ha il fornitore;
 

 metodologia che tenga.
 
però c'è un però.
 
Le metodologie agili prevedono il coinvolgimento del cliente, quindi
un atteggiamento da parte del fornitore molto morbido.  Se il cliente
si irrigidisce sei fatto.
 
I contratti "normali" sono più duri verso il cliente.
 
Questo non vuol dire che la metodologia agile per lo sviluppo non sia
una buona idea in alcuni contesti.
 
Tutt'altro. E' che io eviterei di portarla sul piano contrattuale. La
userei per ottenere una maggiore soddisfazione del cliente ed un
miglior prodotto, non per metter il sedere all'aria e veder che
succede.
 
 

 domani.
 
Stai confrontando due "clienti" diversi. Perchè il cliente che dopo 2 o 6 
iterazioni ti scarica, nel rapporto classico sarebbe il cliente che ti 
chiede un preventivo mastodontico che ti fa lavorare 3-4 settimane e poi 
ti dice "ah no ci ho ripensato, non mi serve".