Il costo dell’interesse per il cliente in un progetto agile

A commento dell’ultimo post di Luca, leggo:

Pero Luca, il cliente che ti “paga per fare un lavoro” non vuole (in alcuni casi certo) fare il cliente Agile perchè potrebbe obbiettare: perchè dovrei fare io il uto lavoro ?
Perche dovrei essere presente nella fase di analisi/refactoring del progetto ?
Potrebbe obbiettare che è un costo che devi gestire tu esecutore …

Ho pensato di rispondere così:

Beh, dipende dall’approccio.

Quando chiedo ad uno studio di architettura di progettarmi una casa è uso per lo studio affiancarsi a me e assorbire le mie esigenze, proprio per evitare di farmi un lavoro sbagliato e io sono ben contento di farmi fare la casa dei miei sogni e non quella dei sogni di qualcun altro. :)
Per non parlare del rapporto tipico fra proprietario della casa e la ditta di lavori edili incaricata di tirarla su! Sapete quanto spesso accade che i muratori tirino su un pezzo di casa diverso da come lo intendeva il proprietario? Molto, molto spesso… Per questo chi paga ha interesse a essere sempre presente (nei limiti dell’utile, è più che ovvio) sul cantiere.

Oppure c’è la figura del consulente personale, come il medico, l’avvocato. Conoscete un avvocato difensore che possa lavorare bene senza avere il proprio cliente al proprio fianco? O un medico che non concordi, fra tutte le alternative possibili, la cura migliore per il particolare paziente con il paziente stesso?

Oppure c’è il supermercato.
Vado allo scaffale, mi fido, accetto la produzione studiata peraltro comunque sull’utenza – ma su base statistica e non personale, e torno a casa con un prodotto molto economico ma identico a quelli di centinaia di migliaia di altri clienti.

Un sito web può mai permettersi di essere uguale ad altri?
Il lavoro del medico è quello operativo di farti prendere la medicina tutte le sere o quello consultivo di fare la giusta analisi in tua presenza della tua specifica patologia?
Se investo denaro – quello serio – lo sparo su un missile fire & forget o la villetta in cui vorrò passare il resto della mia vita me la curo e coccolo dal primo mattone in su?

Un’azienda di sviluppo software non è un’azienda di esecutori. Gli esecutori sono le CPU. Chi fa sviluppo vende analisi e progettazione, da fare al fianco del committente nel suo stesso interesse. [...]

Tu che dici? Sei d’accordo?

July 09 2009 | Dalle trincee | 3 Comments »

Lo user centered design ed il valore per il cliente nello sviluppo agile

Tempo fa promisi una risposta ad un post di Alberto in cui lui esponeva parte di alcune nostre elucubrazioni sulla differenza fra ciò che vale per l’utente e ciò che vale per il cliente. Finalmente ho avuto il tempo di… disegnare i diagrammi! :)

In buona sostanza il diagramma che preferisco contrapporre a quello da lui pubblicato è questo

La peiorità delle user story in base al valore per il cliente e al rischio

Peraltro lo stesso Alberto in un altro suo post discute anche questo approccio.

Nelle metodologie agili, ed in particolare in Extreme Programming, si prende come obiettivo il valore realizzato per il cliente – inteso come colui che possiede il sistema finale e ne finanzia lo sviluppo, mentre nella disciplina dello user centred design i bisogni, le volontà e le limitazioni dell’utente finale sono poste al centro dell’intero processo di progettazione.

Mentre si potrebbe pensare in un primo momento che gli interessi dell’utente siano sempre coincidenti con gli interessi del cliente, che immaginiamo tutti puntare ad ottenere un pubblico soddisfatto, un’analisi più approfondita mostra immediatamente che le cose non sono così semplici. Esistono cioè casi in cui il cliente ha degli obiettivi diametralmente contrapposti alle esigenze dell’utenza del sistema. I sistemi di e-commerce sono spesso contraddistinti da questa contrapposizione, mentre le community online vedono un maggiore allineamento fra interessi del cliente e dell’utente.

Nel diagramma sopra quindi, benché il valore per l’utente di una feature non sia mai trascurabile per calcolarne il valore per il cliente, abbiamo una rappresentazione troppo semplicistica della realtà che, effettivamente, viene a galla in fase di assegnazione delle priorità delle user story.

Direi quindi che questo diagramma possa essere considerato più fedele al vero

Le priorità delle user story in base al valore per l'utente e al rischio su un piano ortogonale al precedente comunque indicato

Come si vede il valore utente, se considerato, deve esserlo in maniera in linea di principio indipendente dal valore per il cliente o cmq in correlazione controllata ovvero consapevole.

I due piani ortogonali e il diedro da essi individuato

Quanto le due metriche di valore siano correlate tra loro è quindi dato, in questa rappresentazione, dall’angolo formato dai due piani individuati: il primo che pone in relazione le priorità delle user story con il valore per il cliente, il secondo che pone in relazione le priorità delle user story con il valore per l’utente. Minore l’angolo formato dai due piani, maggiore la concordanza tra le due assegnazioni di valore e la conseguente corrispondenza di assegnazione di priorità.

Quindi, in relazione ulteriore, possiamo porre la coincidenza di interessi tra clienti e utenti

La intersezione utente-cliente delle features va massimizzata

e arrivare ad una morale conclusiva: se il design delle applicazioni ancora soffre troppo spesso di rigidità di processo, mentre le metodologie agili non forniscono veri e propri strumenti per la progettazione macroscopica delle stesse applicazioni, il vero sforzo da compiere nei prossimi anni è quello di far convergere i due mondi, individuando metodologie che sappiano da una parte accogliere il cambiamento senza waterfalliane eredità, dall’altra produrre e sostenere la vision di ogni progetto.

Come a dire: ok, con le user story sappiamo cosa farci, ma una metodologia di spessore per scriverle non sarebbe bello averla? Con Luca lo scambio a tal proposito è nel vivo…

November 14 2008 | Esperti | 3 Comments »

User story: mai senza il cliente!

Più che un post uno sfogo. Voglio promettermi che non lascerò mai più scrivere user story in assenza del cliente o di un suo adeguato rappresentante! Non senza aver almeno protestato!

Si finisce sempre per buttare la prima stesura e rifare tutto da capo. Lavorare due volte per fare una cosa sola è uno spreco e, soprattutto, abbassa il morale del team.

Non devo farlo accadere più. Oh.

October 29 2008 | Tutti i miei sbagli | 2 Comments »