Una parte preponderante delle attività del Project Manager, delle sue energie lavorative e personali sono assorbite dalla gestione del contratto col cliente. La cultura di progetto in cui sono cresciuto professionalmente è contratto-centrica. "Andate dal cliente col coltello tra i denti" diceva un mio vecchio dirigente.
Il profilo stesso del bravo PM è, per fortuna, decaduto.
Il bravo PM era colui che schivava tutti i tentativi di scope-creep del cliente ovvero di richiedere alcune funzionalità (feature) non esplicitamente previste contrattualmente senza pagarle, giocando sull'ambiguità. Faceva valere i contratti col cliente (carta canta), contabilizzava l'avanzamento del lavoro del team.
Tutelava la sua azienda e redigeva meravigliosi e inattaccabili verbali mentre spronava il team a sforzi perennemente eccezionali, ovviamente grazie ad innate doti di leadership.
Possibilmente bloccava il cliente sulla soluzione prodotta rendendo sconveniente l'assecondamento del fornitore.
Si attaccava al cliente come una cozza allo scoglio.
Il segreto del suo successo non risiedeva tanto nelle capacità innovative, ma la capacità di incassare le lamentele e l'arte di rigirare la frittata.
Tale PM tradizionale degenerava spesso a un anemico ibrido tra un contabile e un avvocato, un servo che negozia tra due entità superiori: la sua azienda (padre) e il cliente (padrone) .
Per questo il valore più sovversivo dell'Agile Manifesto è:
"Customer collaboration over Contract Negotiation".
In definitiva i prodotti di successo non nascono dai contratti. Piuttosto, un buon contratto favorisce un clima di fiducia reciproca cliente-fornitore, rilassa le relazioni, rende inutili le trincee.
Un Project Management orientato alla contrapposizione cliente-fornitore ingessa il progetto, soffoca l'innovazione.
Il risultato è un pessimo software, utenti nauseati, programmatori maltrattati con conseguenti litigi al lavoro e in famiglia, divorzi, licenziamenti, impotenza, diffusione della droga, autolesionismo e suicidi. Invasioni di cavallette.
Ma com'è possibile coniugare il diritto contrattuale con la mentalità agile, i progetti di natura adattiva, non predittiva, con i contratti?
I legali, come sostengono Tom Arbogast (avvocato), Craig Larman (guru Agile) e Bas Vodde (guru Agile) in Agile Contract Primer sono creature abitudinarie. I singoli casi peculiari, portati davanti ai tribunali, sono analizzati alla luce dei principi di diritto prevalenti.
Il lavoro di avvocato comporta il continuo richiamo ai precedenti, a modelli del passato che sono provati e veri. Se impropriamente svolto può avere lo stesso effetto di un genitore iperprotettivo che soffoca ogni iniziativa del figlio a causa di paure ataviche e spesso immotivate: il figlio eternamente ipertutelato non crescerà, il progetto condurrà a un lose-lose inappellabile nelle sedi giudiziarie, a un contratto apparentemente efficace ma che causa un fallimento del rapporto cliente-fornitore e del progetto.
Parola d'ordine: ambito flessibile
I modelli contrattuali dovranno prevedere flessibilità dell'ambito. L'ambito, le feature da consegnare, il "cosa" dovrà essere accettato come variabile, mentre costi (persone) e tempistiche (timebox) saranno prefissate. I requisiti e gli altri oggetti costituenti l'ambito saranno poi continuamente rielaborati e prioritizzati in modo da svilupparli in un ordine coerente col loro valore.
I contratti "chiavi in mano", ovvero i contratti tradizionali a prezzo fisso/scopo fisso, irrigidiscono progressivamente la capacità del progetto di recepire cambiamenti. Il contratto diviene in tal caso un cappotto di cemento. Perciò il progetto consegnerà quanto era stato previsto dettagliatamente all'origine basandosi su improbabili assunti e requisiti iniziali.
Per contro un progetto agile tenderà a massimizzare il flusso di valore sulla base di quanto scoperto all'avanzare del progetto e all'arricchirsi della relazione cliente-fornitore: vi sarà un adattamento progressivo al contesto e la capacità di recepire il cambiamento anche negli stadi più avanzati di sviluppo.
Condividere, non incentivare o punire
Dovremo prediligere modelli collaborativi di tipo "pain/gain" ovvero di condivisione di gioie e dolori, dove un costo inferiore a quello preventivato permetterà in parte un maggior profitto del fornitore e in parte un minor esborso del cliente. Cliente e fornitore sono sulla stessa barca come passeggero e skipper: se la barca affonda annegano entrambi, se arriva al porto di destinazione entrambi si meritano una sbronza.
Dovremo per contro stralciare incentivi e penalità: entrambi conducono a minor trasparenza e qualità (Scaling Lean & Agile Development, Craig Larman, Bas Vodde).
Time and Materials
Il Time and Materials è una tipologia contrattuale non sempre compresa, talvolta confusa con l'odioso body rental. Comporta una quotazione prefissata del prezzo per il cliente delle unità di lavoro e materiali ed è anche detto "a unità fisse". Viene stabilito, ad esempio, un accordo sul prezzo di una giornata di un programmatore senior, ma senza specificare quante giornate di programmatore senior saranno necessarie. La sua natura adattiva lo rende idoneo ai progetti agile. La tipologia contrattuale è spesso abbandonata a causa del timore tipico del cliente di un ciclo infinito e inarrestabile di pagamenti. D'altra parte l'uso dell'agile mitigherà tale timore grazie a due caratteristiche chiave dell'agile: lo stato di avanzamento verrà misurato in termini di funzionalità completate e la chiusura del progetto potrà avvenire alla conclusione di ogni iterazione (Sprint) di durata prefissata.
Vincolo del contratto a prezzo fisso, che fare?
Ma cosa fare se il cliente impone (ad esempio per policy aziendale) il "contratto a prezzo fisso"?
"Money for Nothing and Your Change for Free" è un trucco ideato da Jeff Sutherland per questo (guarda quì). Prevede un prerequisito fondamentale: il cliente partecipa attivamente allo Scrum Team. Se tale condizione dovesse decadere si passa a un contratto Time and Materials.
Le clausule sono:
In conclusione...
La mancata applicazione del valore "Customer collaboration over Contract Negotiation" può avvelenare la nostra vita privata e professionale, specialmente in un contesto culturale in cui il potere del cliente è enfatizzato con retorica crescente e stonata esaltazione:
“Esiste solo un capo supremo: il cliente. Il cliente può licenziare tutti nell'azienda, dal presidente in giù, semplicemente spendendo i suoi soldi da un'altra parte.” Sam Walton
L'unico modo di ribilanciare questo potere asimmentrico, enorme e incondizionato è far sì che il cliente viva il nostro stesso viaggio e avventura, partecipi quotidianamente alle decisioni, abbia come noi facoltà di sbagliare, ripensarci e rimediare. Facciamo sì che il cliente partecipi all'atto creativo del software anzichè perderci in estenuanti e svilenti negoziazioni. Probabilmente, a progetto compiuto, sarà soddisfatto del valore ricevuto, cui il progetto convergerà dopo un cammino tortuoso ma sostenibile o, nella peggiore delle ipotesi, non disconoscerà i frutti della relazione.
Il profilo stesso del bravo PM è, per fortuna, decaduto.
Il bravo PM era colui che schivava tutti i tentativi di scope-creep del cliente ovvero di richiedere alcune funzionalità (feature) non esplicitamente previste contrattualmente senza pagarle, giocando sull'ambiguità. Faceva valere i contratti col cliente (carta canta), contabilizzava l'avanzamento del lavoro del team.
Tutelava la sua azienda e redigeva meravigliosi e inattaccabili verbali mentre spronava il team a sforzi perennemente eccezionali, ovviamente grazie ad innate doti di leadership.
Possibilmente bloccava il cliente sulla soluzione prodotta rendendo sconveniente l'assecondamento del fornitore.
Si attaccava al cliente come una cozza allo scoglio.
Il segreto del suo successo non risiedeva tanto nelle capacità innovative, ma la capacità di incassare le lamentele e l'arte di rigirare la frittata.
Tale PM tradizionale degenerava spesso a un anemico ibrido tra un contabile e un avvocato, un servo che negozia tra due entità superiori: la sua azienda (padre) e il cliente (padrone) .
Per questo il valore più sovversivo dell'Agile Manifesto è:
"Customer collaboration over Contract Negotiation".
In definitiva i prodotti di successo non nascono dai contratti. Piuttosto, un buon contratto favorisce un clima di fiducia reciproca cliente-fornitore, rilassa le relazioni, rende inutili le trincee.
Un Project Management orientato alla contrapposizione cliente-fornitore ingessa il progetto, soffoca l'innovazione.
Il risultato è un pessimo software, utenti nauseati, programmatori maltrattati con conseguenti litigi al lavoro e in famiglia, divorzi, licenziamenti, impotenza, diffusione della droga, autolesionismo e suicidi. Invasioni di cavallette.Ma com'è possibile coniugare il diritto contrattuale con la mentalità agile, i progetti di natura adattiva, non predittiva, con i contratti?
I legali, come sostengono Tom Arbogast (avvocato), Craig Larman (guru Agile) e Bas Vodde (guru Agile) in Agile Contract Primer sono creature abitudinarie. I singoli casi peculiari, portati davanti ai tribunali, sono analizzati alla luce dei principi di diritto prevalenti.
Il lavoro di avvocato comporta il continuo richiamo ai precedenti, a modelli del passato che sono provati e veri. Se impropriamente svolto può avere lo stesso effetto di un genitore iperprotettivo che soffoca ogni iniziativa del figlio a causa di paure ataviche e spesso immotivate: il figlio eternamente ipertutelato non crescerà, il progetto condurrà a un lose-lose inappellabile nelle sedi giudiziarie, a un contratto apparentemente efficace ma che causa un fallimento del rapporto cliente-fornitore e del progetto.
Parola d'ordine: ambito flessibile
I modelli contrattuali dovranno prevedere flessibilità dell'ambito. L'ambito, le feature da consegnare, il "cosa" dovrà essere accettato come variabile, mentre costi (persone) e tempistiche (timebox) saranno prefissate. I requisiti e gli altri oggetti costituenti l'ambito saranno poi continuamente rielaborati e prioritizzati in modo da svilupparli in un ordine coerente col loro valore.
I contratti "chiavi in mano", ovvero i contratti tradizionali a prezzo fisso/scopo fisso, irrigidiscono progressivamente la capacità del progetto di recepire cambiamenti. Il contratto diviene in tal caso un cappotto di cemento. Perciò il progetto consegnerà quanto era stato previsto dettagliatamente all'origine basandosi su improbabili assunti e requisiti iniziali.
Per contro un progetto agile tenderà a massimizzare il flusso di valore sulla base di quanto scoperto all'avanzare del progetto e all'arricchirsi della relazione cliente-fornitore: vi sarà un adattamento progressivo al contesto e la capacità di recepire il cambiamento anche negli stadi più avanzati di sviluppo.
Condividere, non incentivare o punire
Dovremo prediligere modelli collaborativi di tipo "pain/gain" ovvero di condivisione di gioie e dolori, dove un costo inferiore a quello preventivato permetterà in parte un maggior profitto del fornitore e in parte un minor esborso del cliente. Cliente e fornitore sono sulla stessa barca come passeggero e skipper: se la barca affonda annegano entrambi, se arriva al porto di destinazione entrambi si meritano una sbronza.
Dovremo per contro stralciare incentivi e penalità: entrambi conducono a minor trasparenza e qualità (Scaling Lean & Agile Development, Craig Larman, Bas Vodde).
Time and Materials
Il Time and Materials è una tipologia contrattuale non sempre compresa, talvolta confusa con l'odioso body rental. Comporta una quotazione prefissata del prezzo per il cliente delle unità di lavoro e materiali ed è anche detto "a unità fisse". Viene stabilito, ad esempio, un accordo sul prezzo di una giornata di un programmatore senior, ma senza specificare quante giornate di programmatore senior saranno necessarie. La sua natura adattiva lo rende idoneo ai progetti agile. La tipologia contrattuale è spesso abbandonata a causa del timore tipico del cliente di un ciclo infinito e inarrestabile di pagamenti. D'altra parte l'uso dell'agile mitigherà tale timore grazie a due caratteristiche chiave dell'agile: lo stato di avanzamento verrà misurato in termini di funzionalità completate e la chiusura del progetto potrà avvenire alla conclusione di ogni iterazione (Sprint) di durata prefissata.
Vincolo del contratto a prezzo fisso, che fare?
Ma cosa fare se il cliente impone (ad esempio per policy aziendale) il "contratto a prezzo fisso"?
"Money for Nothing and Your Change for Free" è un trucco ideato da Jeff Sutherland per questo (guarda quì). Prevede un prerequisito fondamentale: il cliente partecipa attivamente allo Scrum Team. Se tale condizione dovesse decadere si passa a un contratto Time and Materials.
Le clausule sono:
- Risoluzione anticipata (Money for Nothing): può avvenire al termine di qualsiasi iterazione (Sprint) quando i costi residuali di progetto sono più alti del valore addizionale che il cliente riceverebbe proseguendo. Il cliente per esercitare la risoluzione anticipata paga il 20% del valore residuale del contratto
- Clausula "Change for free": i change sono gratuiti in quanto finanziati con la rimozione dall'ambito ("de-scope") di voci equivalenti in termini di effort stimato ma, ovviamente, a minor priorità. In tal modo l'effort complessivo non varia al variare dei requisiti inclusi nell'ambito. Le stime dell'effort necessario per evadere le varie voci sono concordate tra cliente e fornitore
In conclusione...
La mancata applicazione del valore "Customer collaboration over Contract Negotiation" può avvelenare la nostra vita privata e professionale, specialmente in un contesto culturale in cui il potere del cliente è enfatizzato con retorica crescente e stonata esaltazione:
“Esiste solo un capo supremo: il cliente. Il cliente può licenziare tutti nell'azienda, dal presidente in giù, semplicemente spendendo i suoi soldi da un'altra parte.” Sam Walton
L'unico modo di ribilanciare questo potere asimmentrico, enorme e incondizionato è far sì che il cliente viva il nostro stesso viaggio e avventura, partecipi quotidianamente alle decisioni, abbia come noi facoltà di sbagliare, ripensarci e rimediare. Facciamo sì che il cliente partecipi all'atto creativo del software anzichè perderci in estenuanti e svilenti negoziazioni. Probabilmente, a progetto compiuto, sarà soddisfatto del valore ricevuto, cui il progetto convergerà dopo un cammino tortuoso ma sostenibile o, nella peggiore delle ipotesi, non disconoscerà i frutti della relazione.
