Sto per parlare di contratti, lavorare con team interni ed esterni, valore consegnato, storie accettate e non so cos’altro. È un post denso, in cui temo che finirò col fare il punto di 5 anni di tentativi di applicare le metodologie agili al design.
Chi decidesse di leggerlo, avviso che servirà un quarto d’ora in buona concentrazione.
Parto da qui.
Consegnare valore di business.
Qualche giorno fa, Fabio ha chiesto: “Cosa vuol dire essere agili?”.
Gabriele Lana ha risposto così:
Consegnare valore di business a un ritmo regolare e sostenibile.
Il “valore” e la “sostenibilità” dipendono dal contesto ed è su questo che rischi di perdere molto tempo.
Anche noi designer e frontendisti, se vogliamo essere agili, siamo incaricati di progettare la ux, la ui e il visual e di realizzare il frontend di un prodotto o un servizio digitale per consegnare valore di business. In fondo, il talk che ho tenuto con Ale all’Agile UX Camp e poi i nuovo all’Agile Day nel 2012 parlava proprio di questo.
Spendo un attimo a chiarire il perimetro nel quale si muovono i progetti a cui farò riferimento:
- contratti agili
- team interni o esterni
- esplorazione, esecuzione, misurazione
1. Contratti agili
Nel 2011, Michele ha stipulato il primo contratto agile di e-xtrategy, in cui il prezzo del nostro lavoro viene misurato e pagato in iterazioni accettate, cioè al gruppo di storie concordate, pianificate, rilasciate e accettate dal cliente durante un’iterazione.
Da 3 anni ho modo di vedere e vivere come il team cambia l’approccio al progetto a seconda del contratto. In questo post mi riferirò a quei progetti in cui sono coinvolta anch’io e che sono regolati da un contratto agile.
Per non complicare troppo le riflessioni, evito di introdurre questioni legate alle stime.
2. Team interni e team esterni
Per team interni intendo team che hanno regolato il loro rapporto con il cliente in modo allineato o dipendente dal nostro e che usano il nostro stesso metodo di lavoro. Con questi team riusciamo a organizzare l’iterazione includendo sia i nostri deliverable di progettazione che quelli di sviluppo.
Per team esterni intendo team che hanno regolato il loro rapporto con il cliente in modo indipendente da noi e che possono usare metodi diversi dal nostro. Con questi team ci sentiamo regolarmente per discutere dubbi, prossimi step, ipotesi di progetto ecc. ecc., ma non sappiamo che cosa fanno, con quale criterio e quando rilasceranno i loro deliverable. Di fatto, nei progetti che seguiamo con team esterni, riusciamo a tracciare solo le nostre iterazioni, cioè quelle legate al processo di ux design.
3. Esplorazione, esecuzione, misurazione.
L’esperienza ci insegna che, in ogni progetto, le prime iterazioni sono più esplorative, mentre le successive sono più esecutive. Ma ad ogni iterazione (stando alla “dottrina” e al contratto) dobbiamo consegnare un deliverable il più possibile finito.
Quando lavoriamo con quello che ho definito “team interno”, succede che riusciamo quasi sempre a pianificare un’iterazione in modo che tutti quanti abbiamo del valore di business da consegnare.
Durante la fase esplorativa, il team fa ricerca e analisi. Per esempio i designer possono fare analisi qualitative o quantitave, definire attori e scenari, sketching e wireframing di una epic story… E gli sviluppatori possono predisporre e strutturare tutti gli ambienti di lavoro, servizi, valutazione dei sistemi esterni con cui andare a integrarsi ecc. ecc. Tutti quanti (designer e dev) ci confrontiamo continuamente con il cliente sugli obiettivi strategici del progetto.
Al termine di queste attività, il team scrive le storie che andrà a realizzare. Poi le pesa, cioè assegna un punteggio a quella storia, dove il numero più basso viene abbinato a una storia poco complessa e rischiosa e quello più alto a una molto o troppo complessa o rischiosa. Finora abbiamo sempre usato punteggi da 1 a 8, secondo la scala di Fibonacci (quindi 1, 2, 3, 5 e 8).
Iterazione dopo iterazione, storia accettata dopo storia accettata, c’è un numero che inizia ad emergere che in gergo si chiama velocity e che viene calcolato facendo la media dei punti consegnati nelle iterazioni accettate. Grazie alla velocity, riusciamo a monitorare l’andamento del progetto e a predire la consegna delle iterazioni future.
La fase di misurazione di solito è fatta più all’inizio, durante l’esplorazione, per raccogliere informazioni, prendere decisioni e stabilire quali sono le metriche che andremo a monitorare; e più verso la fine della fase esecutiva, per settare le metriche e decidere gli step successivi.
Veniamo al dunque.
Storie, epic e loro limiti.
Le storie sono uno degli strumenti fulcro della metodologia. Hanno il pregio di obbligare il team di lavoro a riferirsi alle persone alle quali è destinato il prodotto digitale che stiamo realizzando.
Per ora, il modo più efficace che abbiamo trovato scrivere le storie è questo:
- associamo a una deadline il nome di una macro-epic del progetto (per esempio: carrello);
- inseriamo le prime attività esplorative da svolgere entro quella deadline (per esempio: ricerca con gli utenti, analisi varie, schizzi e wireframe, ipotesi di dati che si vogliono raccogliere dopo il rilascio);
- quando le attività di esplorazione della macro-epic sono accettate, scriviamo le storie di esecuzione e le inseriamo prima della deadline.
Tutto questo funziona molto bene.
Quello che non va sono gli “strumenti” (storie, epic, chore, milestone, release…) che stiamo usando per inserire nell’iterazione le attività che faremo, perché:
- le storie, così per come dovrebbero essere scritte stando alla “dottrina”, sono riferibili solo al momento esecutivo di un progetto, non a quello esplorativo né a quello misurativo;
- su alcuni progetti, test con gli utenti, analisi delle metriche ecc. le inseriamo nel flusso di lavoro creando storie o chore su Pivotal, in altri progetti le abbiamo messe come milestone di progetto. Questa disomogeneità costante è sintomatica.
- come possiamo descrivere. comunicare e tracciare momenti di consegna di valore come per esempio workshop propedeutici alla condivisione della design vision?
Una storia scritta così:
Come product owner voglio vedere degli schizzi che mi spieghino il funzionamento del carrello.
secondo me semplicemente non è una storia.
In poche parole, le fasi di analisi e di esplorazione di una o più epic stories non sono descrivibili in storie, se non forzandole. In più spostano l’attenzione sul deliverable e passano per l’accettazione di uno schizzo, un wireframe o un visual. Cosa che mi ricorda troppo un “Visto si stampi”.
Cosa rimane?
Abbiamo avuto modo di verificare che le storie scritte così non funzionano confrontando due progetti simili per metodo ed effort applicati. L’unica differenza sta nel team: in un progetto il team è tutto interno, nell’altro il team interno progetta e realizza il frontend mentre lo sviluppo è assegnato un team esterno.
Nel primo progetto, nonostante la disomogeneità delle storie esplorative e misurative rispetto a quelle esecutive, le iterazioni risultano piuttosto bilanciate, perché lo sviluppo lavora quasi parallelamente al design e il valore consegnato è misurato in base alla soddisfazione del bisogno dell’utente da un lato, e dall’obiettivo di business dall’altro.
Nel secondo progetto, invece, il nostro approccio iniziale è stato quello di scrivere le storie come se il team di sviluppo fosse tutto interno, col risultato di non riuscire a capire quando le storie aperte fossero rilasciabili. Dopo le prime 8, 9 iterazioni, abbiamo visto che ne risentiva pesantemente la velocity e il tracciamento del valore consegnato, che ci avrebbe consentito di chiudere l’iterazione e quindi emettere fattura (NB: non abbiamo avuto problemi con il cliente, ma non è questo il punto).
Dopo una veloce retrospettiva, abbiamo deciso di cambiare approccio e usare le storie per descrivere le attività esplorative come dicevo prima, quindi dal punto di vista del product owner e non della persona che andrà a usare il sistema. Il risultato è che abbiamo un progetto sbilanciato verso gli obiettivi di business e che, paradossalmente, non descrive i bisogni degli utenti.
L’uovo o la gallina?
Non so capire se abbiamo un problema con i contratti agili e il vincolo dell’accettazione delle storie; oppure se sia un problema di metodo e strumenti scelti per descrivere il valore delle attività che svolgiamo.
Per me questo è un bel dilemma su come tracciare le attività di design vincolate a un contratto agile come quelli che ho descritto all’inizio del post. Un dilemma che nasconde una bella opportunità.
Come tracciare il valore di business del design?
Il manifesto agile nasce da ingegneri e informatici. Nonostante questo, tutt’ora, quando lo rileggo, mi trovo d’accordo sui 4 semplici principi su cui si basa. Ma gli strumenti e i metodi che oggi stiamo usando sono appunto da ingegneri e da informatici. La mia conclusione è che dobbiamo trovare un metodo da designer per tracciare il valore di business del design. Un metodo che sia rilasciabile per iterazioni, che possa essere descritto e tracciato con strumenti simili alle storie, ma che non possono essere storie.
E poi, ho il forte sospetto che il vincolo del pagamento per iterazione accettata non sia applicabile al design se non forzando gli strumenti che stiamo attualmente usando.
Sarà meglio che mi fermi qui.
33 Commenti
Il problema principale che vedo nell’approccio a user stories è la tendenza a verticalizzare i problemi in maniera esasperata producendo tanti piccoli monoliti che non vengono più messi in discussione (non è un problema tecnico).
E la chiave secondo me è quello di fare di meno al primo giro, meno design, meno ottimizzazione. La forma dovrebbe seguire la funzione, ma si sceglie spesso di definirla prima ancora di scoprire come verrà usata. Si investe tutto il budget nel momento di minima conoscenza del problema, poi quello che viene fatto non può essere messo in discussione semplicemente perchè non c’è più benzina.
E attenzione a tracciare una distinzione tra processo di design e quello di sviluppo. Fare un ottimo design significa conoscere bene ed esplorare gli obbiettivi degli utenti, i limiti tecnici e di business di quello che si sta facendo. Quello che ho scritto sopra per me vale allo stesso modo per chi “disegna l’interfaccia” e per chi “disegna il codice”.
Ti lascio un tweet recente di Kent Beck che riassume bene quello che voglio dire:
P.S.
Provenendo dal tuo tweet mi sono chiesto… questo post sarebbe stato più utile se lo avessi pubblicato 41 revisioni fa e avesse avuto una ventina di commenti ed una “seconda parte”? :P
Ilaria, non so dare una risposta ai tuoi quesiti (troppo avanti per me, troppo oltre la mia esperienza di piccolo “artigiano” del design e del codice). Ma da “appassionato” di metodologie e appunto di design e codice, posso dirti che ho notato uno strano effetto secondario, a mio avviso molto pericoloso e deleterio, dell’avvicinamento fra il mondo designer/visual e il mondo developer/coder.
Mondi che se prima erano completamente separati, non si parlavano e no si capivano, oggi con l’avvento del “web” come piattaforma di sviluppo, con la prevalenza sempre più importante del lato front-end rispetto al backend, e con l’accettazione ormai universale del ruolo del (buon) design e della (buona) UX nel successo di un prodotto servizio, dicevo con l’avvicinamento e la intersezione di questi due mondi, ho assistito anche a una cannibalizzazione (e in un certo senso, banalizzazione) del mondo “design” da parte del mondo developer.
Gli “ingegneri”, come li chiami tu (ok, li chiamo anche io così, ma non diciamolo troppo a voce alta, ché potrebbero non capire) hanno in qualche modo compreso il lavoro del designer – come colui che decora e abbellisce una pagina, che rende intellegibile un’interfaccia, che dà ordine alle cose visibili, ecc. – ma continuano a ignorare la complessità e il ruolo dei cento “no” che dobbiamo dire per arrivare a un “si, così funziona”. Vedono il lato semplice del nostro lavoro, e sono convinti che tutto si esaurisca lì. Per questo, hanno applicato un metodo e una forma mentis “ingegneristica” a qualcosa che è “umanistico” (?), “artistico”, condizionandoci a seguirli su questa strada senza che da parte nostra ponessimo dei dubbi, delle condizioni (io da parte mia ci avevo provato, ma con scarso successo).
Quindi la risposta alla domanda che fai in conclusione, te la sei data già tu. Ora come ora non so dare/trovare una soluzione alternativa, ma so che è una strada che sul lungo termine porterà a un impoverimento complessivo dell’apporto che un designer può dare a un progetto, se non prendiamo delle “controdifese”, se non ri-affermiamo e rivendichiamo la nostra specificità, la nostra non subalternità.
Ti faccio un esempio molto concreto, apparentemente non correlato, ma che vedo come primo sintomo tangibile di questo shift: una volta chi faceva i CSS era essenzialmente un grafico/ibrido-developer, un po’ come me o te, quello che oggi va sotto il nome di frontend developer. I CSS erano dominio dei grafici (soprattutto perché nessun altro li voleva fare, e perché eravamo noi grafici ossessionati dalla pixel perfection a voler controllare ogni minimo dettaglio, e non c’era altro modo se non attraverso i CSS), erano usati per rendere le pagine web esteticamente più belle – CSS Zen Garden, anyone? – per ottenere la miglior impaginazione possibile dei contenuti, il miglior reflow al variare della viewport, ecc. Si inventavano hack per avere ombre attorno ai box, si usavano strumenti primitivi e rudimentali come sIFR per portare un minimo di font nelle pagine web, si andava alla ricerca del sacro graal del layout a tre colonne. Oggi invece il campo dei CSS è interamente votato a discutere di BEM, OOCSS, SMACSS e compagnia cantante, approcci appunto “ingegneristici” a un problema di naming e ordine/pulizia nei CSS che noi designer non abbiamo mai avuto, francamente (parlo almeno per me). Una noia mortale, e se solo provi a alzare la mano e dire: “scusate, ma a me sembra una boiata pazzesca”, sei fuori dal coro, un eretico che non capisce l’importanza della modularità. Vabbè fine del rant.
Concludo, dicendoti che vedo con gioia da un lato che alcuni dubbi vengono sollevati da persone che stimo, come te o Luca Mascaro, rispetto a metodologie e approcci che tutti davano/davamo per scontati (il che significa non significa che siano da buttare, anzi! solo che si apre lo spazio per ricercare nuovi/migliori metodi e strumenti di design e sviluppo, nuovi/migliori modi di collaborazione fra i due mondi che, in ultimo, credo vadano comunque trattati e pensati come “diversi”, fermo restando la necessità che siano sempre uno accanto all’altro, collegati da un ponte a 24 corsie di marcia per lato). Dall’altro però ho una certa apprensione, perché mi sembra di notare – spero di sbagliarmi, ma alcuni segnali non mi piacciono – che siamo sulla china discendente del ruolo del “designer”, ora che più che mai invece dovrebbe essere al centro del prodotto. Ma credo che questo tema meriterebbe un altro post. E temo anche di essere andato fuori tema, giunto a questo punto.
Ilaria mi hai messo tante domande per la testa la prima delle quali è di quante settimane sono le tue iterazioni, una, due o tre?
A parte questa info che mi farebbe propendere in modi differenti la risposta la realtà è che i problemi che segnali sono comuni nella pratica di chiunque faccia design o anche sviluppo agile con storie ambigue che si confondono con task.
Personalmente preferisco quando una storia viene scritta dal punto di vista dell’utente finale ma il problema che poni legato al valore a mio vedere è più legata al come validarla e/o accettarla piuttosto che descriverla, mi spiego.
Il punto è però cosè il valore del design per il business e come lo descrivi?
Come Personas A voglio poter pagare dopo che ho messo nel carrello.
Come Personas A voglio poter pagare in meno di 3 click e 45 secondi
Come Personas A voglio poter pagare semplicemente ed essere soddisfatto alla fine della transazione
Come Personas A voglio che io è il 5% delle persone come me paghino
Ok le ho tirate un po’ per i capelli ma penso che parte del problema stia qui: scrivere storie e non task è la via giusta ma se le storie non descrivono come viene valutato il valore (criteri di accettazione) non è possibile valutarle.
(Pensiero che mi è venuto leggendo, spero di non essere andato fuori strada)
@Luca
Finora abbiamo fatta iterazioni da 1, max 2 settimane.
Non so se questa informazione può aiutarti ad aggiungere qualcosa alla tua risposta, per cui ti ringrazio. Ho la sensazione che tu non sia andato fuori strada, hai certamente toccato uno dei punti cruciali.
Oggi siamo appunti vincolati all’accettazione. Questo ci sta allontanando da… semplicemente dal lavoro che siamo chiamati a fare come designer.
@Cristiano e @Lele: commenti bellissimi, grazie.
Capisco e condivido l’apprensione di Cristiano, cerco di non pensarci perché so che mi farebbe fare passi indietro, invece voglio trovare lucidità e rigore per fare passi avanti.
Una persona che non si alimenta correttamente avrà più chance di ammalarsi di una che segue una dieta corretta e completa. Questo – ovviamente – ceteris paribus, cioè a parità di condizioni al contorno.
A. È molto difficile in domini complessi – e la poca società umana raccolta attorno ad un singolo progetto software ne rappresenta già uno – delineare le condizioni al contorno. Anzi no, scusa: è impossibile. Quindi già il platonico desiderio di trovare un metodo che funzioni sempre è abbastanza illusorio.
E questo ci porta a
B. Parli di dottrina abbastanza spesso nel tuo articolo e mi meraviglia: non c’è nessuna dottrina. Ci sono dei principi base che puoi accogliere (neanche “devi”, solo “puoi”) e la tua esperienza per declinarli in azioni pratiche. Non necessariamente uguali in ogni contesto. (Vedi A.)
Vuoi un esempio? Un esempio forte? Basta con le stime. Basta anche con gli story point. Non servono a nulla. Posso dimostrartelo. Lo so che ne ho parlato per anni, anche a tu per tu con te, ma non servono a nulla. A nulla. Davvero.
C. Però A. e B. non contraddicono la premessa: se mangi male, rischi di più. Cosa c’entra questo col tuo post?
Per molte persone nel mondo – la maggior parte :-( – è inevitabile una dieta non bilanciata. Scegliendo di farla lo stesso, non cambiano la realtà della nutrizione umana.
Lavorare con team esterni – come li chiami tu, benché a volte inevitabile, sembra avere dei costi – umani e, secondariamente, economici – naturalmente, fisiologicamente più alti.
Qualunque idea potremo mai estrarre dal cilindro, sempre quel gap dovremmo riempire. Possiamo accettarlo o possiamo aggirarlo. Non possiamo farlo sparire.
Se trovi un modo di misurare il valore consegnato per un progetto esclusivamente di design (e quello che descrivi accadere con i team esterni lo ricorda tanto) scrivine e faccene leggere.
Se qui l’obiettivo è stabilire che le cose che funzionano per la consegna di software funzionante non valgono sempre per i progetti (e i team) chiamati a consegnare compendi di design, beh… siamo d’accordo da molti anni.
Non solo non abbiamo trovato il martello che fa divenire tutto un chiodo, ma non abbiamo nessuna certezza che questi martelli siano del tutto possibili!
Purtroppo. O per fortuna.
@cristiano sono in disaccordo con te.
Essendo da qualche tempo “fuori” dai team di sviluppo quello che vedo è che ogni professionista punta a vendere il proprio lavoro adducendo “tanto il X non capisce la complessità di quello che faccio” e dall’altra parte altri professionisti dicono lo stesso in una spirale di incomprensioni e piccole invidie professionali.
Fare design è complesso, ma lo è anche fare architettura dell’informazione, lo sviluppo frontend e quello backend. Ma è anche complesso gestire i server, fare deploy e parlare con i clienti. Un buon designer deve tenere conto delle scelte fatte anche in base ai vincoli tecnologici, così come uno sviluppatore dovrebbe confrontarsi con un sistemista prima di adottare determinate architetture. Il TEAM si deve confrontare.
Se si lavorasse IN team (invece che con un team), condividendo il know how, il perché delle scelte fatte, senza fare progettazione upfront (sia di design, che di tecnologia, che di user stories) e lasciando le scuse agli altri i risultati sarebbero migliori. Punto.
@ilaria ti pongo un altro quesito.. cosa cambia se non “tracci” il valore di business? Il valore sono i deliverables che rilasci, rilasciali prima, ottieni prima il confronto e fatti pagare per le giornate di lavoro effettivamente svolte. Il pagamento per iterazioni ha poco senso per progetti in cui non si può avere nulla in tempi brevi (noi lo abbiamo abbandonato abbastanza in fretta), motivo per il quale siamo ormai fissi sul t&m (con gli altri problemi che comporta).
Ehm.. ma il lavoro che siete tenuti a fare come designer è quello di soddisfare questi criteri, seguendo scelte pesate su pattern di interazioni noti (o studiati ad-hoc per massimizzarne il risultato). Il designer è innanzitutto un tecnico, deve sottostare a vincoli (fisici, tecnici, di cultura) e risolvere problemi ad essi correlati… non può e non deve inventarsi soluzioni non ragionate ma solo “belle”.
O mi sono perso qualcosa per strada? Se ci sono gozziliardi di studi che dicono che il processo di acquisto deve essere rapido (sotto i 3s) ed al massimo in due step perché porsi ulteriori problemi (almeno nella prima iterazione)? Meglio concentrarsi su come rappresentare al meglio tutti gli elementi in gioco, che linguaggio usare e che tipo layout scegliere.
Poi ci sarà modo di migliorare, a latere, con i dati reali degli utenti che navigano. (se non ci sarà modo.. sfiga, prossimo cliente e via.. )
Parto anch’io dalla citazione ripresa da Fullo:
Personalmente trovo il bisogno di fare una precisazione rispetto al concetto di accettazione.
Il problema che vedo è legato soprattutto alla forma contrattuale che prevede che l’iterazione sia pagata solo se viene accettata dal cliente, il che secondo me non funziona con una parte del processo di design.
Non funziona con quella parte del processo di design che non è facilmente misurabile e accettabile, perché fatta di esplorazione (chiamiamola la fase di strategia e di visione) e approssimazioni successive (wireframe, prototipi, ecc.).
Forzare i designer a consegnare ad ogni iterazione, cioè ogni settimana, qualche forma di artefatto che possa essere accettato dal cliente per poter chiudere l’iterazione e fatturarla, secondo me, crea dei problemi.
Primo perché sposta il focus sui deliverables, che dovrebbero essere più uno strumento di comunicazione del processo di design che un artefatto su cui il cliente fa un “sign-off”. Lo stesso sign-off che ci permette di chiudere e fatturare l’iterazione dall’altro lato ci porta indietro ad un processo waterfall in cui ogni fase viene approvata e non si va avanti se non c’è la firma e ogni step firmato non può più essere ulteriormente discusso. O migliorato.
Secondo, questo approccio ci vincola a consegnare a scadenze forzate, che è un bene in certi casi (capiamoci, il mio approccio è molto vicino al pragmatico “done is better than perfect”), ma in altri ho la sensazione possa portare a compromessi o a scelte non del tutto corrette, o a prendere delle shortcut per consegnare in tempo.
Soprattutto in quelle fasi di strategia e definizione di una visione che poi impatterà su tutto il progetto, tagliare troppi angoli in nome di un constraint di tempo (auto-imposto in questo caso, non di progetto) secondo me può essere pericoloso.
Viceversa la consegna forzata ad ogni iterazione e l’accettazione trovo si applichino meglio alle parti di execution, in cui è più facile avere un criterio di accettazione (una funzionalità è presente o no, funziona o no, corrisponde a quanto definito nella user story o no). Personalmente trovo che si applichi anche alla parte di UI/visual design, che faccio rientrare nell’execution.
Per concludere, più che sul metodo, personalmente ho più dubbi che un contratto nato per regolare un processo di sviluppo possa applicarsi ad un processo di design.
Probabilmente sì, è vero.
Ma perché non dovrebbero esistere processi di solo design. Un azienda che fa solo design è subottima.
Secondo me i dubbi che manifestate sono sensatissimi: sono spia di un ‘mismatch’ a monte.
Per dire: il mondo dei silos è al tramonto.
Trovo sensatissimo il rifiuto del deliverable come misura del valore generato dall’attività di esplorazione. C’è un mondo di conoscenza implicita che viene generato col vostro lavoro! I deliverable esprimono – per definizione – solo quella esplicitabile! Ma allora quella conoscenza implicita, quando lavorate con team “esterni” che fine fa? Non fa una brutta fine cmq, in toto o in parte?
@jacopo io invece non lo trovo così ottimale il rifiuto senza pensare hai criteri di accettazione perché nel mondo della progettazione dove la parte oggettiva è relativa e può essere solo misurata con metodi empirici si rischia che il Cliente rifiuti per sempre. Per questo in diversi contratti agili per il design ho visto l’inserimento di regole di accettazione come la validazione attraverso test con utenti o (anche se un po’ è una bestemmia) la possibilità di Max 1 rigetto non giustificato o per motivi di gusto da parte del cliente.
@ilaria
Ti chiedevo le settimane perché qualche settimana ero negli US e parlavo con Chris Noessel in Practices Fusion e lui mi diceva una cosa interessante, loro non riescono a fare delivery di valore (software accettato, funzionante e testato con utenti o sottoposto al feedback pubblico) in sprint più brevi di tre settimane ma questo fa si che i designer fanno parte di sue team alla volta. Ogni singolo designer fa parte integrante del singolo team di sviluppo e ha il goal di portare avanti il valore per lo stesso, ma fanno tutti anche parte di un macro team design che itera settimanalmente e ha un backlog praticamente fatto solo di common task anche supportandosi cross team.
@jacopo: intanto, bentornato :)
Non riesco a ritrovare un tuo post di qualche anno fa in cui ti riferivi alla pratica delle arti marziali e alle varie fasi di studio e allenamento che portano a una vera conoscenza. “Dottrina” è una parolaccia che io e Ale usiamo scherzosamente per riferirci ai primi “sacri” principi e metodi che ci hai insegnato e che, con gli anni, abbiamo ridiscusso per trovare la nostra via.
Come dici anche tu, non esiste un solo tipo di martello e un solo tipo di strumento per battere un chiodo nel muro. Sapevamo fin dall’inizio che il design avrebbe dovuto trovare la sua via e i suoi metodi, fermi restando i valori di base. Ma dirlo 5 anni fa era un atto difensivo e immaturo. Non so a che punto del percorso mi trovi rispetto agli stadi che descrivevi in quel tuo bel post, ma di certo non sono più al primo. Ora riesco a capire cosa va e cosa non va, cosa dobbiamo tenere e cosa dobbiamo rivedere. Il tutto nel massimo rispetto dei ruoli di ognuno e tenendo gli occhi sulla staffetta (come dicevi sempre tu): che è consegnare valore di business.
Continuo a non trovarmi d’accordo sull’obiezione “lavorare con i team esterni non ha senso” (o derivate). Mi sembra che ci porti fuori strada. Ho inserito il discorso nel perimetro perché aiuta a far emergere il punto che dà il titolo al post: come misurare il valore del design, come comunicarlo e inserirlo costantemente nel processo.
È un problema che riguarda il team, a prescindere che sia fatto di 3 aziende o una sola.
Bel post e ottimi spunti di riflessione, peccato che la conversazione si stia dividendo tra qui e Facebook :)
Ti posso raccontare la mia esperienza all’interno di un team agile: quello dove lavoro attualmente è il 3° team dove le iterazioni sono sempre state di 2 settimane, ma i problemi sono comunque ricorrenti.
La difficoltà maggiore per me è nella suddivisione del lavoro in deliverable che abbiano un qualche valore finale.
Abbiamo scritto “finte” storie per poter continuare a produrre artefatti come eravamo sempre stati abituati a fare, e inevitabilmente ci siamo trovati a inseguire la dinamicità di progetti che stavamo cercando troppo di staticizzare. Un chiaro problema: mockup grafici realizzati in uno sprint che per questione di priorità non vengono realizzati nello sprint seguente.
Inoltre scrivere storie per gli stakeholder interni, del tipo “come marketing voglio avere un’anteprima della funzionalità x così da…” è un trucco, ma sono decisamente d’accordo con il tuo esempio: non sono storie.
Ora spesso riusciamo ad arrivare ad un buon compromesso, con storie rivolte al cliente finale per lavorare nella stessa iterazione a wireframe / prototipi e realizzare una prima versione potenzialmente pubblicabile. Molto però dipende dal lavoro da portare a termine, perchè non è sempre possibile scrivere delle storie sufficientemente piccole. Inoltre è fondamentale avere sempre presente il quadro d’insieme, che rischi di perdere se ti concentri su una piccola fetta.
La soluzione? Bella domanda.
Indispensabile collaborare e discutere con team e product owner, e sicuramente avere dei criteri di accettazione ben formulati aiuta, come sottolinea Luca. È fondamentale seguire una visione d’insieme analizzata magari durante una fase di inception, riuscendo a suddividerla sprint dopo sprint in rilasci di valore: non è sempre possibile, ma al momento è quello che stiamo cercando di fare.
Per il il 99% dei casi il mio ruolo di designer freelance mi porta a subentrare in team formati e consolidati. Per lo più si tratta di team dev.
Per il 101% dei casi propongo al cliente metodologie di lavoro e di costi simili a quelle da voi descritte. Finiscono sempre con il cadere nel vuoto e sono “costretto” a tornare al cosiddetto preventivo a corpo, con tanto di stime fuffa. Un pò di sfiga e forse anche non riesco a “vendere” bene la cosa.
Questo per dire che nel mio piccolo non sono ancora riuscito a mettere in pratica quello di cui state discutendo in modo davvero interessante.
Voglio soltanto aggiungere però che condivido appieno il pensiero di Cristiano. La figura del designer, o meglio del web designer, è stato “contaminata” dal mondo dev. Affrontiamo problematiche che fino a poco tempo fa ci sembravano lontane anni luce.
Questo in parte stimola la mia voglia di conoscenza e di approfondimento. Dall’altra alimenta dubbi, problemi e necessità di confronto costante con chi, come me, lavora in questo settore per trovare nuove soluzioni.
È quello che sta succedendo anche con il tema del design workflow. Ma forse merita una discussione a parte.
Non sono sicuro di aver colto pienamente ciò che intendi anche perché ho avuto l’impressione che in parte ti sei riferita a situazioni che conosco e questo potrebbe avermi portato fuori strada…
Mi sembra comunque che metti in campo due questioni:
1. soddisfacimento degli obiettivi di business vs. soddisfacimento dei bisogni degli utenti
2. come tracciare il valore di business del design
Sulla prima questione non si può essere talebani e non credo si possa scegliere nessuna delle due escludendo l’altra, anche in un’azienda (tipicamente non italiana) fortemente orientata al soddisfacimento del cliente tale soddisfacimento deve necessariamente essere sostenibile e compatibile con in livello di business. Il livello di business è proprio quello che, capita l’esigenza dell’utente, deve mettere in campo l’organizzazione e il minimo di struttura necessari a soddisfarla in modo profittevole. Per fare questo si fanno delle scelte e ogni scelta taglia via un ramo dell’albero delle infinite possibilità. Il difficile è rimanere a livello di salutare potatura.
In generale dunque non vedo nulla di male nel fatto che alcune storie possano avere come stakeholder primario il business, il rischio è di eccedere in questa direzione, come anche nell’altra.
Valore del design: secondo me l’equivoco nasce dal fatto che a volte si è portati a pensare che ogni storia debba avere necessariamente un valore percepibile dall’utente finale.
Non credo debba essere necessariamente così: quello che conta veramente è che in ogni storia ci sia una scheggia di valore e che questa scheggia sia compatibile con le altre schegge che alla fine andranno a comporre una vera feature.
Non sempre il valore può essere tradotto in valuta ed anzi specialmente quando si è a livello di scheggia il valore consiste nel rendere disponibili delle opzioni.
Quanto pagherebbe un utente finale per un wireframe? Forse zero, perché l’utente finale non utilizzerà mai un wireframe, tuttavia il wireframe ha valore per il business perché gli consente di acquisire conoscenza, di scegliere tra più opzioni.
Non credo ci sia reale differenza tra un prototipo, una feature realizzata solo a livello di codice per dimostrare la fattibilità o fornire un’ancora visiva ad un’idea e un wireframe.
Non mi sento di tenere la ux ed il codice su due livelli diversi, sono entrambe facce della stessa medaglia e nessuna delle due è sufficiente senza l’altra.
Semplicemente ci sono situazioni in cui è più facile/comodo/utile/profittevole dare prevalenza all’una piuttosto che all’altra, ma quello che alla fine conta è la medaglia intera.
In sintesi: spezzare il valore della medaglia nel valore delle singole facce è cosa per addetti ai lavori e credo non sia utile in tutti i contesti.
Il mio punto di vista è quello del Product Owner, che vorrebbe vedere rilasciato valore, di qualunque tipo, ogni sprint.
A me da PO sono venuti i brividi a leggere la finta storia citata prima
“Come product owner voglio vedere degli schizzi che mi spieghino il funzionamento del carrello”
Io non vorrei mai vedere degli schizzi! Per me il lavoro del designer non deve essere “mostrare a me” qualcosa, nè tantomeno “lavorare per me”.
Ho visto storie scritte “come team member voglio fare degli schizzi per…” ma nemmeno queste mi soddisfano come PO. Non è che uno dei punti focali per tutti debba essere la scrittura della storia? Che chiarisca prima dove si vuole andare, e che sia chiara per tutti quelli che lavorano ad un progetto, indipendentemente da team interni ed esterni.
cross-posto il commento qui e su fb citando e rispondendo ad altri commenti che stanno un po qui e un po la … giusto per complicare un pochino le cose :-)
Nel tuo post tocchi diversi argomenti “tosti” e metti in sacco di carne al fuoco su cui riflettere.
Provo a dire il mio pensiero attuale (da prendere con le pinze perché condizionato dai progetti su cui ho lavorato nell’ultimo periodo).
TEAM INTERNI/TEAM ESTERNI: la situazione che descrivi (e che ho vissuto anche io) mi ricorda il problema della catena del valore nella Lean Enterprise dove (stò semplificando) se un anello vuole migliorare il flusso riducendo gli sprechi lo può fare veramente solo se anche tutti gli altri lo fanno, altrimenti si rischia di fare un ottimizzazione solo locale che certe volte può essere addirittura negativa per il flusso generale.
Per questo quindi sono d’accordo con @Michele (nel suo commento su fb) che bisogna pretendere di lavorare con tutta la filiera (ma tutta tutta) allo stesso tempo però sono cosciente che in alcuni casi è impossibile. In quei casi devo essere bravo ad adattarmi alla situazione.
Se corro sempre in linea retta verso il mio traguardo arrivo prima consumando meno ma se mi trovo di fronte un muro devo valutare bene se conviene sfondarlo scavalcarlo o girarci intorno ed è diverso da muro a muro.
USER STORY: per come le uso oggi per me sono dei “pretesti”, forse non è neanche giusto chiamarle user story ma più “promemoria”. Servono da aggancio mentale da pretesto appunto per centrare tutto il team su un argomento, raccogliendo e stimolando la discussione su una determinata cosa da fare necessaria per consegnare valore (di qualsiasi tipo e genere dipende dal contesto). A seconda dei momenti del progetto possono essere Epic o Task o qualcosa nel mezzo. Oltre a questo indicano anche se quella “cosa” è fatta, è in corso o è da fare ed è il product owner a dichiarare/confermare o accettare che è fatta. Considerarla fatta però non significa che è scolpita nella pietra e non si cambierà più ma solo che adesso, in questo momento, con le informazioni che abbiamo quella particolare cosa la possiamo considerare conclusa per passare ad altro, andando avanti nel progetto poi e possibile che cambi.
Si intuisce che questo si scontra con i problemi di budget faccio una cosa adesso (momento di minor conoscenza) poi non ho più budget per modificata dopo (momento di maggior conoscenza). Ma questo non è un problema legato alle storie e all’accettazione delle storie, è un problema legato al budget. E la soluzione è diversa da progetto a progetto (problema=muro soluzione=sfondo,scavalco,aggiro). Sicuramente il suggerimento di @Emanuele (nel suo commento al tuo post) è saggio: “spendo” meno possibile all’inizio per tenermi in tasca i soldi per poi poter correggere e aggiustare.
CONTRATTO: i contratti (tutti i contratti) sono un ostacolo un inciampo uno spreco. Il contratto a iterazione (soddisfatti o rimborsati) risolve alcuni problemi che noi in e-xtrategy trovavamo nei contratti precedenti a budget fisso e allo stesso tempo risultano più digeribili per i nostri clienti rispetto ad un contratto time & material.
Sono d’accordo che anche il contratto ad iterazione ha i suoi difetti (li sperimento sulla mia pelle).
Io la vedo così: il contratto è uno strumento oggi imprescindibile, a seconda del cliente/progetto occorre cercare di trovare il contratto che permette di lavorare meglio e poi se durante il progetto il contratto si rivela essere un ostacolo (muro) occorre riflettere su quale è la soluzione migliore (sfondare, scavalcare, aggirare).
In un commento al post @Nicolò dice:
“Il problema che vedo è legato soprattutto alla forma contrattuale che prevede che l’iterazione sia pagata solo se viene accettata dal cliente, il che secondo me non funziona con una parte del processo di design”
Attenzione, nel contratto che usiamo noi in e-xtrategy (soddisfatti o rimborsati) l’accettazione dell’iterazione e l’accettazione delle storie non è la stessa cosa. Un iterazione può essere accettata anche se le storie sono rifiutate o non complete (e infatti succede spessissimo così).
L’accettazione delle storie serve per capire se possiamo chiudere quella storia e passare ad altro. L’accettazione dell’iterazione va letta in questo modo: il team mostra cosa è stato fatto in questa iterazione (sia storie finite sia in corso) il cliente che sa quanto gli costa un iterazione valuta se quello che gli viene mostrato vale (per lui) quanto lo ha pagato se è soddisfatto si va avanti se non è soddisfatto ci si ferma e tanti saluti.
La metafora del muro mi piace si è capito? :-)
Ottimo punto l’ultimo di Lorenzo che allude al fatto che – se tutti sono d’accordo – il riconoscimento del valore generale può essere esteso a zone *non* coperte da user story.
E assolutamente sì: user story che descrivono utenti interni al processo non sono user story, lo avete scritto in tanti. ;-)
@luca “io invece non lo trovo così ottimale il rifiuto senza pensare hai criteri di accettazione perché nel mondo della progettazione dove la parte oggettiva è relativa e può essere solo misurata con metodi empirici si rischia che il Cliente rifiuti per sempre.”
Ho capito solo da “mondo” in poi… :-( mi aggiungi un paio di virgole?
@jacopo magari sbaglio ma se ho capito bene Luca con
<>
intende che visto che il design produce cose che il cliente giudica “belle” o “brutte” se non poni criteri oggettivi per accettazione o rifiuto rischi che il cliente dica sempre no a quello che proponi (perché per lui è “brutto”, “fatto male”)
scusate, si è persa la citazione di Luca
“”invece non lo trovo così ottimale il rifiuto senza pensare ai criteri di accettazione perché nel mondo della progettazione dove la parte oggettiva è relativa e può essere solo misurata con metodi empirici si rischia che il Cliente rifiuti per sempre””
Design per un team interno e design per un team esterno sono due processi diversi. Ti renderebbe le cose più semplici non cercare di uniformarli? (Domanda onesta, non retorica. Non so la risposta)
In generale, la “larghezza di banda” è un constraint organizzativo non indifferente. Parlando con il team interno hai più banda e puoi stabilire una collaborazione più raffinata. Con un team esterno… non funziona altrettanto bene. Amen. È una legge di natura.
Interessante la riflessione riguardo al valore. Proverei a dimenticare le storie, come unità di valore e ragionare proprio sul valore. È un valore per il cliente vedere uno schizzo? Dipende dal cliente! Ma se è un valore (quindi il cliente È disposto a pagare per il deliverable, anche se non compila), perché gli permette di capire meglio ed a voi di raccogliere feedback utile, perché no?
Bel post e bella discussione, purtroppo non ho il tempo di scrivere tutte le cose che avrei da dire, detto questo e visto che c’è tanta gente che ha tante cose da dire sull’argomento, organizzare una bella giornata/unconference?
Cito Jacopo: “Il mondo dei silos è al tramonto” … http://ih2.redbubble.net/image.9642388.9203/flat,550×550,075,f.u1.jpg
Informazioni e licenza
Questo blog utilizza Wordpress è basato sul tema Gutenberg, modificato da me con i preziosi consigli di Nicolò e il fondamentale supporto di Luca
Eccetto dove diversamente specificato, i contenuti del mio blog sono pubblicati con Licenza Creative Commons Attribuzione Non commerciale - Condividi allo stesso modo 3.0 (Italia License).