Posto qui le slide di Cristiano presentate all UXCamp di Firenze, al quale ho dovuto rinunciare.
Cristiano ha messo a punto il ragionamento iniziato all’Experience Camp di Lugano e ripreso anche da Luca Mascaro. Lo discuto qui perché il sito di Cristiano non è ancora un blog. :)
Il suo discorso si pone fin da subito come una provocazione e una generalizzazione. Le accetto entrambe ed ecco le mie riflessioni:
- slide 18. La qualità non è necessaria… Mi domando se sia vero che gli utenti si adattino o trovino dei workaround. Il problema è che spesso gli utenti abbandonano, magari proprio quando vogliamo il contrario. È questo che non deve succedere se vogliamo avere un minimo di qualità.
- slide 19. Sono d’accordo e sicuramente Cristiano avrà specificato che la perfezione non esiste. Davanti abbiamo persone.
- slide 25. Se un progetto fosse ad alto budget, sarebbe quasi sicuramente anche più vasto… e quindi avremo un rischio maggior di dispersione della qualità. Ecco perché non credo che sia un problema di soldi (entro un certo limite).
- slides 42 e 43: sono il cuore del discorso di Cristiano e il suo ragionamento mi porta a tornare su alcune riflessioni che abbiamo fatto grazie a Jacopo Romei. Per quello che mi riguarda più da vicino, ho cominciato a parlarne qui.
Per me il punto è capire che cosa sia la qualità per noi, per il cliente e per l’utente. E su ogni progetto, compatibilmente con il budget, decidere su quali aspetti scendere a compromessi.
10 Commenti
L’aspetto che mi ha colpito del talck di Cristiano è che è riuscito a tirarsi fuori dai metodi e da quanto leggiamo ogni giorno dicendo “ma cosa so fare io? E cosa serve di quello che so fare io al cliente?” … mi ricorda molto il grafico di Jacopo il quale molto chiaramente fece emergere che in una web agency fatta di sviluppatori la cosa che percepiva meno di tutti il cliente era proprio il codice! Tema core dell’azienda appunto. Le metodologie usate come “tool” è un’affermazione che mi è piaciuta molto specilamente in realtà in cui non si hanno solo una tipologia di lavori, ma una marea che variano da budget, a cliente, a ore… in tutto.
Io credo che sulla qualità del prodotto non si possa scendere a compromessi. Abbiamo la funzionalità (lo scopE, non lo “scopo”) come possibilità di controllare budget e tempi.
Che la metodologia vada declinata sulla realtà dei fatti – che quest’ultima sia mutevole – non ho mai avuto dubbi ed ho anzi dedicato alcuni dei miei talk (“Tutti i mie sbagli” e “Qualità totale”) a spiegare come nella mia esperienza la cieca fedeltà al metodo abbia significato danni anche grossi.
Però, come Cristiano ha mostrato di sapere, tra crearsi alibi e saper usare i propri strumenti ce ne corre.
Situazione classica: consegnamo un progetto al cliente e lui giudica la sua soddisfazione sulla base di qualche elemento (funziona, arrivo facilmente a fare la tal cosa, mi piace l’impatto) – dico a braccio. Noi però sappiamo che il nostro lavoro dietro a quel progetto è fatto di molte più componenti, che nel loro insieme portano anche a quei 3 risultati.
La mia impressione è quella che dicevo qualche settimana fa e su cui tu ci hai fatto riflettere: la qualità ha senso quando porta un valore reale al progetto, valore che verrà recepito dal cliente e dall’utente. È in questi passaggi che avviene il compromesso.
Ha senso investire tempo su una soluzione di sviluppo più raffinata, quando poi non mi resta tempo per fare una cosa che per il cliente ha un gran valore, o a cui tiene molto?
Valore consegnato e qualità sono due termini che si intrecciano molto in queste discussioni.
E aggiungo: non è detto che la qualità dei singoli componenti del progetto portino ad una qualità generale che il cliente percepirà come valore. A me sembra troppo utopistico dire che sulla qualità non si può scendere a compromessi, perché questo discorso può tenere solo guardando ai singoli pezzetti di un lavoro.
“Ha senso investire tempo su una soluzione di sviluppo più raffinata, quando poi non mi resta tempo per fare una cosa che per il cliente ha un gran valore […]?”
No, nessun senso.
“Ha senso investire tempo su una soluzione di sviluppo più raffinata, quando poi non mi resta tempo per fare una cosa […] a cui tiene molto?”
Forse. Quello a cui tiene non è detto che sia di valore. Ma è un altro tema.
“Valore consegnato e qualità sono due termini che si intrecciano molto”.
Se non è di qualità ogni valore corrisponde a… meno valore!
Credo siamo entrati in zona definizioni circolari!
Può esistere un valore di bassa qualità? Cioè: può esistere una banconota da 100 euro che valga 100 euro ma non posso usarla come tale? No, perché la stessa non varrebbe più 100 euro.
Una metodologia che ostacola la consegna di valore non ha valore.
Una metodologia che alza la qualità ha valore.
Una metodologia che aumenta il valore consegnato è di qualità.
Una persona che segue una metodologia qualunque sia il costo in valore non consegnato non è un professionista di qualità (massima).
Una persona che non segue una metodologia o ignora la qualità del proprio processo non consegna il massimo valore.
“E aggiungo: non è detto che la qualità dei singoli componenti del progetto portino ad una qualità generale che il cliente percepirà come valore. ”
Cerca di esserci o allo IAD10 o in extrategy il 22 novembre! Il Dot Game risponderà a questo tuo commento.
Sono in modalià “lame”: ascolto e rifletto su quello che state scrivendo, ci ragiono e poi scrivo…
Preciso che mi sembra proprio noi si sia tutti d’accordo. Sulla posizione di Cristiano io ho qualche ‘insight’ in più, ottenuto di fronte ad una buona birra la sera prima dell’UX Camp.
argomento che richiederebbe ben più di una lettura veloce ed un commento (meglio davanti ad una bella birra, ma avremo modo un giorno, magari).
secondo me, come ultima analisi, la qualità paga e non è un compromesso.
paga perchè è un valore (grande) e tutti i valori hanno un costo, che va pagato
non è un compromesso (nel vero senso del termine) perchè non devo trovare “uan via di mezzo”, un “prendere da una parte e lasciare dall’altra”, almeno di fronte al cliente; che poi noi lo facciamo in casa e scegliamo, in ogni progetto, per ogni cliente, dove mettere l’asticella, quello è un altro discorso.
ecco perchè mi piace molto la tua, cristiano, slide 43, dove fai capire che ci sono cose importanti (quelle che stanno a sinistra), ma che non sono argomento di discussione diretto con il cliente; questo serve, nella maggior parte dei casi, non abbassare (o fare a meno) della qualità.
i concetti, capisco, andrebbero approfonditi, ma se non chiudo questo affare, va a finire che perdo la fermata del treno (e ritrovarmi a bari non è carino).
mike.
Eccomi qua, finalmente un momento in cui posso rispondere con calma e in modo riflessivo (c’entra qualcosa il fatto di esser tornato dall’Agile Day? Boh!?).
Anche perché nel frattempo ho avuto modo di far sedimentare i pensieri sia sulla presentazione (è stata di fatto improvvisata sul treno il giorno prima, seppur sulle ceneri di un talk precedente) che sulle reazioni ad essa (mi aspettavo un “ma questo è pazzo” e invece ho ricevuto molte indicazioni di persone “sorprese”, spiazzate, quindi probabilmente ha colpito nel segno, in qualcosa di detto-nondetto che vive un po’ sottotraccia, almeno questa è la spiegazione che mi sono dato).
Ciò detto, cominciamo:
@Alessandro:
Dici bene, sono tornato a fare il mio lavoro, e sto molto meglio (nel senso che prima ero un po’ intossicato di tante “pippe mentali” che mi auto-infliggevo pensando che così il mio lavoro sarebbe stato più di qualità. Sbagliando, evidentemente…
@Ilaria:
– slide 18: uso la parola “necessario” nel senso matematico del termine, di condizione obbligatoria: la qualità non è obbligatoria (se c’è evidentemente è meglio, ma questo è il discorso che ne consegue).
– slide 25: riprendo dopo questo discorso, che ha avuto sviluppi interessanti
– slides 42+43: hai centrato in pieno, sono il cuore del mio discorso: non posso pensare di mettere (esempio) l’architettura delle informazioni (AI) di un sito nel paniere della qualità percepita da un cliente (e quindi parlarne e discuterne con lui, e quindi perderci giornate di budget) se quel cliente nemmeno sapeva cosa fosse prima di incontrarmi: per lui quel valore non sarà mai percepito. La uso, l’AI, dietro le quinte, ma lui non lo sa e non mi interessa che lo sappia. Lui vedrà il lavoro complessivo, l’insieme e su quello misurerà il risultato (la sua percezione). Sempre che non mi abbia commissionato oltre al design anche l’AI. OK? AI, UCD, UX, ecc sono il mio background di cultura e di esperienza e di know-how che infondo nel design, ma non li porto in discussione o in evidenza sul cliente, se non è lui a chiedermelo come servizio (e a quel punto vuol dire che sa di che cosa si tratta ed è quindi in grado di percepirne anche il valore e giudicarmi – nel bene e nel male – di conseguenza.
@Jacopo:
– sul tema del “valore percepito”, occhio che la metafora della banconota è pericolosa: quanto vale una banconota da 100€? oggi con 100€ ci compro un sacco di cose, ma se domani crolla l’euro da domani con quella stessa banconota non ci compro nulla, è “carta straccia” appunto, quindi il valore è quello nominale o quello percepito? fuor di metafora, l’idea di dare un valore astratto e assoluto alle cose (AI, UX, ecc.) è appunto pericoloso perché dipende dal valore che il tuo interlocutore assegna a quelle cose, e spesso non è in grado di farlo (e non è una sua colpa, intendiamoci, e nemmeno nostra ma è un dato di fatto); su questo mi sono fatto “del male” (molto) credimi
– sul tema del cercare metodi/strumenti di lavoro e principi/conoscenze che permettano di migliorare la qualità del prodotto consegnato, sfondi una porta aperta (anche se devo dire che il concetto di “kaikaku” mi ha molto sorpreso!)
@Michele:
– la qualità paga: qui torniamo al motivo per cui ho dato quel titolo al talk. quella frase di per sè non dice nulla, è data per scontata ma se ci pensi bene nella parola stessa “qualità” risiede una ambiguità e un essere relativo e soggettivo in ciò che è appunto la qualità che di fatto rende l’affermazione “buona per tutte le stagioni”. ma come ci insegna il buon Jacopo, ciò che non posso misurare scientificamente, non esiste! (sto esagerando ovviamente, eh!) in altre parole, devo stare molto attento definire io cosa è “di qualità” in un progetto, a decidere dove mettere l’asticella perché il cliente potrebbe nemmeno vederla, quell’asticella, ma guardare da un’altra parte (e con questo non intendo vendere fuffa o seguire pedissequamente quel che vuole il cliente, ma posizionare l’asticella tenendo conto di quello per cui mi ha chiesto di lavorare, di quello per cui mi ha assunto e darli qualità lì, proprio lì, soprattutto lì)
– la qualità è un compromesso: c’è qualcosa che nella vita non lo sia? è proprio questo il bello della vita! il nostro DNA stesso _è_ un compromesso fra due diversi geni… (per tornare al tema dei sistemi complessi :-)
Ultima cosa, torno al tema slide25 (qualità vs. tempo, e quindi eccellenza/perfezione): recentemente mi è capitato di parlare di questi argomenti con un grosso manager/business-owner in ambito IT; lui è appassionato di barche e mi spiegava che per un certo tipo di barche (12 piedi, mi sembra) ci sono diverse fasce di prezzo, in cui nella fascia bassa (<300.000€) ci sono molti operatori, alcuni addirittura "industriali" in un settore che invece è molto artigianale, nella fascia media (500.000-1.000.000€) ci sono quei 5-6 operatori la cui qualità e differenza rispetto ai precedenti si "percepisce" appunto e nella fascia superiore (1-2.000.000€) c'è un solo operatore, l'eccellenza. Ecco, quel che accade è che per quanto gli altri operatori facciano, non riescono mai a passare alla fascia eccellenza e muoiono, perché di fatto il mercato dell'eccellenza è troppo piccolo e non hanno abbastanza commesse.
Tornano alla slide, ho pensato che andrebbe effettivamente valutata la curva sovrapposta di numero di aziende disposte a pagare per quella qualità in funzione dela qualità (e quindi anche del budget) e andrebbe considerato che il "costo" dell'eccellenza è che poi ti devi scannare con altri pochi "eletti" e la cosa non è facile, se non ti chiami Apple o Frog Design o Clearleft… insomma, non va sottovalutato che nella parte bassa del grafico c'è lo stagno in cui nuota il maggior numero di pesci…
This is it!
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).