AntonioGanci

Il blog di Antonio Ganci
posts - 201, comments - 420, trackbacks - 31

Contratti Fixed Price Fixed Length Fixed Scope

Ho visto che è una tendenza diffusa da parte del cliente di preferire contratti a scadenza fissa, budget fisso e scope fisso. In pratica è come se stessi dicendo alla software house che lo svilupperà: fammi questo software con queste funzionalità entro tale data.

Il motivo credo sia soprattutto ingenuità e mancanza di fiducia con l'illusione che un contratto blindato possa garantire il risultato.

Nella pratica succede, che alla fine entrambi gli attori in gioco ci rimettono: la software house è costretta a gonfiare le stime ed essere molto pignola nelle specifiche, il cliente avrà poco controllo perchè ogni richiesta diversa da quella iniziale dovrà essere rinegoziata.

Ma perchè viene quindi preferito rispetto ad altri tipi di contratti?

Perchè ha due grossi vantaggi: è facile da capire e soprattutto è facile da confrontare.

Le aziende spesso hanno un ufficio acquisti che non ha competenze tecniche e quindi quei due vantaggi possono essere fondamentali.

Come potremmo mitigarne gli svantaggi?

Se possibile ridurre la durata del contratto e il numero di funzionalità il più possibile. In modo da ridurre i rischi.

Quali contratti alternativi posso proporre?

Il concetto di base è che una o più variabili in gioco (tempo, scope, feature) siano variabili. Qualche link per approfonfire l'argomento:

I link mi erano stati segnalati da Matteo e Piero

Vi ritrovate in questa descrizione? O riuscite a fare contratti piuttosto flessibili?

Print | posted on domenica 6 settembre 2009 13:15 |

Feedback

Gravatar

# re: Contratti Fixed Price Fixed Length Fixed Scope

Quello che io cerco di fare normalmente è conivolgere il cliente, in qualsiasi contratto. Come parte del contratto, "impongo" che ci sia un meeting almeno ogni due settimane per verificare che tutto sia secondo i piani, oppure, nel caso le priorità del cliente fossero cambiate, di adattare i piani di conseguenza. Questo ci permette di essere veramente "agili" e quindi di rispondere in modo efficace ai cambiamenti. Oltre a questo, l'incontro serve anche per verificare che non ci siano imprevisti. Al posto che fare un'analisi di dettaglio iniziale, infatti, preferiamo fare un'analisi di massima, solo per avere una stima dei tempi: questo ci permette di avere una stima del costo. In questo modo possiamo iniziare ad essere operativi nel breve ed iniziare a rilasciare in modo molto veloce. Ovviamente per supportare il cambiamento è necessario progettare l'architettura in modo che sia semplice apportare modifiche, e che sia facilamente testabile. A fronte di cambiamenti e/o imprevisti, conivogliamo il cliente per decidere insieme a lui se può permettersi di aumentare il budget oppure preferisce ridurre le funzionalità della prima release.
In pratica, cerchiamo di essere agili :-).
Tutto questo lo facciamo attualmente per progetti di BI, che - anche se molti non l'avrebbero mai detto - e' possibile affrontarli in modo Agile, esattamente come un qualsiasi altro progetto informatico.
06/09/2009 14:17 | Davide Mauri
Gravatar

# re: Contratti Fixed Price Fixed Length Fixed Scope

Personalmente mi sono fatto un bel foglio excel che - con l'esperienza acquisita nei vari anni - una volta riempito di numeri che quantificano il lavoro, riesce a darmi un'accurata stima dei tempi. L'excel tiene già conto, in una certa percentuale, di tollernze dovute ad imprevisti "gestibili", che sono accadimenti naturali in quanto non c'è un'analisi di dettaglio (che sarebbe impossibile da fare, in quanto i progetti cambiano durante la vita del progetto stesso). Per cui gran parte delle cose non previste ricade dentro questa fetta di tempo. Per ora non ha mai sbagliato una previsione :-).

Cmq, nel caso di una sottostima gli errori possono essere causati da quattro fattori:
1) Il fornitore non conosce a sufficienza la tecnologia che usa
2) Alcune informazioni - in fase di analisi - non erano disponibili od erano addirittura sconosciute al cliente.
3) Cause di forza maggiore dovute alla natura umana e del lavoro

Il primo caso non è comtemplabile IMHO, è fin che avrò fiato farò in modo che non succeda :-)

Negli altri due casi, ancora un volta, l'importante è coinvolgere in modo tempestivo il cliente. Se ci sono problemi imprevisti ed imprevedibili, credo che sia chiaro a tutte le parti che i miracoli non si possono fare, e quindi bisogna lavorare insieme per capire come affrontare la cosa. Allungare i tempi, diminuire le feature, modificare le priorità sono tutte possibilità da valutare. Dal punto di vista economico, bisogna valutare di volta in volta, non credo sia possibile avere una risposta valida per tutte le situazioni.
06/09/2009 15:42 | Davide Mauri
Gravatar

# re: Contratti Fixed Price Fixed Length Fixed Scope

Tema molto interessante, stavo preparando anche io un post a proposito.
Per quel che mi riguarda quello che mi accade è che partiamo con un contratto fixed price poi alla prima richiesta di modifica che entrambi (noi e il cliente) concordiamo essere fuori contratto ne creiamo uno nuovo solo per la modifica richiesta e cosi via.
Quindi passiamo da un grosso contratto fixed price a tanti piccoli contratti sempre fixed price ma sicuramente più stimabili. Mi sembra un buon compromesso.
07/09/2009 11:12 | Emanuele DelBono
Gravatar

# re: Contratti Fixed Price Fixed Length Fixed Scope

Con riferimento al post originale: Praticamente stai auspicando un ritorno al waterfall... e, tendenzialmente, ti do ragione: molta della attuale "agilita'" e' solo dilettantismo e mancanza di professionalita' in un settore ormai altamente inflazionato da chaos e speculazione. Il problema tuttavia non si risolve semplicemente cambiando modo di lavorare, perche' a questo punto anche le aspettative del mercato sono fortemente viziate da 10-15 anni di disinformazione e malcostume. Tocca quindi essere "agili", ma solo in superficie...

-LV
08/09/2009 17:38 | LudovicoVan
Comments have been closed on this topic.

Powered by:
Powered By Subtext Powered By ASP.NET