La mia usabilità

In seguito a qualche fugace battuta scambiata oggi nei corridoi della facolta mi e’ sorta spontanea una domanda.
Pretendiamo che il mondo sia usabile con noi, che gli oggetti siano al nostro servizio per poter adempiere ai nostri scopi, che i programmi che usiamo si aprano e, come per magia, gia’ ci diano tutto quello che vogliamo, eccetera…
Ma, volendo rivoltare la medaglia…quanto siamo usabili invece noi?

Quanto la nostra interfaccia risulta usabile all’esterno? (ebbene sì…me lo sto proprio chiedendo!)

Inutile dirvi che credo fermamente che noi non siamo usabili per niente!!

E’ una stronzata? forse si’… ma scrivere un post sull’argomento mi sembra il giusto modo per poter esternare le mie pazzie senza coinvolgere nessuna povera creatura vivente….

Iniziamo indicando alcuni dei principi base dell’usabilita’ quali efficacia, efficienza e soddisfazione dell’utente, seguite da adeguatezza e facilità di apprendimento.

Per essere usabile dovrei quindi essere:

• facile da “imparare”, o meglio facile da capire anche per chi mi vede per la prima volta;
• veloce da usare, per chi già mi conosce;
• efficace nel raggiungere gli obiettivi che mi propongo di fare (inutile dire quindi che dovrei anche, ovviamente, portarli a termine!);
• e soprattutto sempre piacevole da “utilizzare”

(semplifico l’elenco per motivi pratici…non vorrei vi fermaste a leggere a metà per noia )

E io già rido….

Facile da imparare….proprio no… ma credo non sia un “problema” esclusivamente mio. Le persone sono piene di mille sfaccetature diverse, di caratteristiche, di emozioni contrastanti, di esperienze alle spalle eccetera. Ovvio che tutto questo non si può “capire” ad una prima occhiata. Si può tentare certo, si può iniziare ad intravedere qualcosa soprattutto in quelle persone che si definiscono “trasparenti” (eviterò di aprire un dibattito anche su questo…facciamo che l’ho scritto giusto perchè ci stava bene…), si può iniziare quantomeno a prendere una direzione, ma non capirai mai nessuno a prima vista.

Credere di poterlo fare è da ipocriti e forse anche un po’ diminutivo e sminuente della persona con cui si sta parlando. Se qualcuno mi venisse a dire (…) che mi ha capito dopo poche ore di chiacchierata, mi sentirei davvero alquanto avvilita personalmente. Ho davvero così poco da dire e mostrare che tutto questo può essere fatto in poche ore?

Iniziamo quindi a porre i primi paletti. Non siamo “facili da imparare” per chi ci vede per la prima volta.

Proseguiamo con la velocità nell’uso di chi già ci conosce. Questo assolutamente sì. E’ il motivo per il quale con un’amico ti capisci attraverso un’occhiata (adoro questa ottimizzazione dei tempi!! ), motivo per il quale con un’amico spesso non c’è bisogno di un immenso giro di parole. Lui ti conosce e sa cosa vuoi dire e cosa vuoi, come ti senti e cosa pensi. E tutto questo il più delle volte avviene nell’arco di un saluto.

Il secondo paletto quindi pone un punto a favore della nostra usabilità. Siamo veloci da usare per chi ci conosce.

Efficaci nel raggiungere gli obiettivi. Su questo potrei mettere con un bel “dipende”. Personalmente tento di esserlo (efficace) ma non sempre ci riesco. Non solo poi non sempre è facile raggiungere i propri obiettivi nel minor tempo e col minor sforzo possibile, ma il più delle volte addirittura non si riesce nemmeno a raggiungerli! Obiettivi troppo irraggiungibili e visionari forse? Sopravvalutazione delle nostre capacità?  Assolutamente sì, ma allora la colpa è assolutamente solo nostra (se non siamo abbastanza ragionevoli da porci giusti obiettivi e se non riusciamo a capire nemmeno le nostre capacità realli) ed è inutile prendercela con chiunque altro.

Per interagire con un sistema cerchiamo di capirne i limiti per poter usare poi tutto quello che questi limiti comprendono nel migliore dei modi e a nostro favore… ma allora perchè sempre più spesso non facciamo lo stesso con noi stessi? Non staremmo tutti meglio e saremmo più felici se accettassimo il nostro “sistema” così com’è? Non saremmo in quel momento più consapevoli dei nostri obiettivi ed efficaci nel raggiungerli?

Ne deriva che no, non siamo efficaci nel raggiungere gli obiettivi.

Arriviamo ora al bello: piacevole da utilizzare. E su questo argomento ci sarebbero una marea di cose da dire ma forse l’argomento è un po’ troppo psicologico per le mie capacità. Possiamo giusto parlare di compatibilità “a pelle” e compatibilità caratteriali ad esempio. Credo fermamente infatti che, nel caso di cui si sta parlando, non ci si possa definire “piacevoli” verso chiunque. Non ci sono linee guida per questo (e forse è anche un bene), non potremmo mai piacere a tutti. Provarci certo è consentito, ma ciò significa immedesimarsi in quello che il nostro interlocutore vuole e darglielo, distruggendo quindi in parte il nostro essere reale. Adattarsi è certo una delle migliori caratteristiche che noi umani abbiamo e che non riusciremo mai a trasmettere del tutto al nostro software, ma adattarsi sempre agli altri toglie a poco a poco quello che fa appunto dell’uomo una cosa totalmente diversa da un software… il proprio carattere…

Mettiamo quindi anche l’ultimo “no” nella nostra lista.

Se la matematica non mi inganna quindi, ne risulta che possiamo anche costruire le migliori interfacce del mondo, progettare sistemi utilizzabili persino da un gatto, applicare ai nostri lavori tutte le linee guida del mondo affinchè tutti siano tutti felici e desiderosi di utilizzarli, ma quello che non riusciremo mai a fare è essere prima di tutto noi stessi usabili verso il mondo esterno…

E tu, quanti pomodori fai in un giorno?

Giorno dopo giorno scopro che c’è sempre meno gente che è a conoscenza di una fantastica tecnica di studio/lavoro… la cosiddetta “Tecnica del Pomodoro”!

Prendo in mano questo argomento ora, approfittando del fatto che proprio ieri ho parlato dell’agile programming. La tencica del pomodoro infatti è “sponsorizzata” dall’ xPlabs .

Cercherò ora di riassumere tutta la suddetta pratica, invitandovi però a leggere tutto il paper su tecnicadelpomodoro.it, vi assicuro che la lettura è molto interessante nonchè a tratti ironica (sfido chiunque a non ridere almeno un po’ leggendola, con la ovvia conseguenza di ritrovarsi poi ad annuire ad ogni frase)

Iniziamo.

Innanzitutto è bene dire che questa tecnica è stata inventata da Francesco Cirillo nel 1996 e successivamente perfezionata da lui ed il suo team.

Si basa su alcuni semplici concetti, semplici ma troppo spesso sottovalutati e poco considerati, come ad esempio “il tempo”.

Per molte persone infatti il tempo rappresenta un nemico. L’ansia relativa al “tempo che passa”, soprattutto in presenza di scadenze, genera comportamenti non efficaci nel lavoro e nello studio e, per questa via, sviluppa la tendenza a procrastinare.

La Tecnica del Pomodoro nasce con l’obiettivo di utilizzare il tempo come un utile alleato per realizzare le proprie attività nel modo desiderato e consentire un continuo miglioramento nel proprio processo di lavoro o studio.

Tre sono le ipotesi di lavoro alla base della Tecnica del Pomodoro:

• Un diverso modo di “vedere” il tempo, non più centrato sul concetto di divenire, riduce l’ansia e, per questa via, porta ad aumentare l’efficacia personale;
• Un migliore impiego della propria mente consente di ottenere maggiore lucidità,consapevolezza, focalizzazione, e facilita l’apprendimento;
• L’impiego di strumenti semplici da usare e poco intrusivi riduce la complessità diapplicazione della Tecnica, favorendone la continuità, e consente di concentrare gli sforzi sulle attività da realizzare. Molte tecniche di gestione del tempo falliscono perché impongono, a chi le utilizza, un alto livello di complessità aggiuntivo rispetto alla complessità intrinseca dell’attività da realizzare.

Per realizzare la Tecnica del Pomodoro è sufficiente dotarsi di:

• Un Pomodoro: un timer da cucina
• Un foglio delle “Attività da Realizzare Oggi” , redatto quotidianamente a inizio giornata e composto da: Una intestazione con luogo, data e autore; Una serie di righe con la lista delle cose da fare nella giornata in ordine di priorità; Una sezione intitolata “Urgenti Non Previste” nelle cui righe inserire le attività non previste che devono essere realizzate entro la fine della giornata. Attività quindi potenzialmente in grado di alterare la programmazione del giorno.
• Un foglio del “Magazzino di Attività” , composto da: Una intestazione con il nome dell’autore; Una serie di righe sulle quali si annotano le varie attività da svolgere mano a mano che si presentano e dal quale, a fine giornata, si depennano le attività realizzate.
• Un foglio delle “Registrazioni”: che rappresenta l’insieme di dati grezzi necessari per produrre i report e i grafici di interesse. A seconda degli obiettivi posti sotto osservazione contiene un diverso insieme di campi. In genere contiene la data, la descrizione e il numero di Pomodori di sforzo necessari per realizzare l’attività. L’aggiornamento di questo foglio avviene almeno una volta al giorno, tipicamente a fine giornata.

La tecnica del pomodoro si pone alcuni obiettivi fondamentali, quali:

1. Rilevare lo sforzo per ogni attività:

• Il Pomodoro non è interrompibile. I 25 minuti sono quindi 25 minuti di puro lavoro.
• Il Pomodoro non è divisibile. Non esistono i mezzi Pomodori o i quarti di Pomodoro.
• L’unità atomica di tempo è un Pomodoro.
• Se il Pomodoro viene definitivamente interrotto da qualcuno o qualcosa, quel Pomodoro è da considerarsi nullo, mai caricato, e si proseguirà dando la carica ad un nuovo Pomodoro.
• Lo squillo del Pomodoro sancisce la fine perentoria, anche se temporanea, dell’attività. Non è quindi ammesso continuare l’attività per “altri due minuti”, anche se ci si sente convinti che in quei “due minuti” la si potrebbe completare.
• Nella pausa non si deve assolutamente continuare a pensare a quanto realizzato negli ultimi Pomodori.

2. Ridure le interruzioni

Il periodo di 25 minuti del Pomodoro sembra sufficientemente breve da consentire di resistere alle diverse forme di interruzione. Nell’esperienza però, quando si inizia a praticare la Tecnica del Pomodoro, le interruzioni possono essere problematiche da gestire. Di qui la necessità di una strategia per ridurre le interruzioni “non gestite” ed arrivare progressivamente ad aumentare il numero costante di Pomodori realizzati senza interruzioni.

Esistono vari metodi per la gestione sia delle interruzioni interne (ovvero dentro di noi) che per quelle esterne. Rimando a questo punto alla lettura del paper, che consiglio vivamente.

3. Stimare lo sforzo delle attività

4. Rendere più efficace il Pomodoro

5. Definire un orario

Sono diversi i motivi per cui non bisogna sottovalutare l’importanza di definire e rispettare un orario:

• Un orario definisce un limit. I limiti, quando sono realmente eprcepiti come non violabili, aiutano ad essere “concreti”.
• Un orario definisce la separazione tra il tempo in cui lavorare ed il tempo libero, dove per tempo libero si intende lo svolgere attività non finalizzate o non programmate. Questo tempo è la benzina per la propria mente. Senza tale benzina si perde creatività, interessem curiosità, ci si stanca fino ad esaurire le energie.
• Un orario misura i risultati della giornata. Se arriva il termine dell’orario e non si sono completate tutte le attività pianificate per la giornata, si cerca di capire cosa non ha funzionato

Nella tecnica del pomodoro non è importante rilevare il tempo perso, quanto il numero di Pomodori realizzati. L’indomani si considererà quel numero per definire i Pomodori disponibili e si assegneranno attività solo fino al raggiungimento di quel numero di Pomodori. Il rischio principale degli orari è che è facile sottovlutarne l’importanza e cadere nell’errore di non rispettarli.

In conclusione.

La sensazione di avere avuto più tempo per fare cose e non averlo usato proficuamente è spesso paralizzante. La nostra mente inizia a vagare tra passato e futuro stimolando sensi di colpa e creando situaizoni di ansia per cose che si sarebbero potute fare ma che non si è fatto.

La Tecnica del Pomodoro consente sempre di focalizzarsi sul Pomodoro corrente, o una volta terminato, sul prossimo Pomodoro. L’attenzione è rivolta “qui e ora”.

Quando ci si sente perduti è possibile destinare un Pomodoro ad attività esplorative per riordinare le priorità e organizzare unnuovo piano. Se si hanno invece già le idee chiare e manca “qualcosa”, forse la volontà, forse un po’ di coraggio, si carica il Pomodoro e si comincia a lavorarci su, senza aspettare il tempo!

…

Allora cosa ne dite?

Vediamo chi fa più Pomodori?

L’insostenibile leggerezza del progettare

Una  metodologia che ho sempre trovato molto affascinante è l’Agile Programming.

Per chi non lo conoscesse (male!!) ne farò ora una breve descrizione perchè credo che sia un’ottimo modo di procedere per garantire dei buoni prodotti finali.

Innanzitutto le metodologie di sviluppo agili si contrappongono con le classiche metodologie di sviluppo quale ad esempio lo sviluppo a cascata. Tali metodologie hanno l’obiettivo di organizzare il processo di produzione del software per renderlo prevedibile, affidabile, efficiente e ripetitivo ma per ottenere questi risultati richiedono anche di applicare in modo rigoroso una serie di linee guida, di controlli, di adempimenti  “burocratici”, tra cui molta molta documentazione.

In contrapposizione a tutta questa pesantezza sono nate le metodologie “agili”.

Tra i vantaggi di questa tecnica vediamo innanzitutto la necessità di produrre poca documentazione (cosa fantastica a mio parere. Ho sempre creduto poco nelle aziende e nei team di sviluppo che meticolosamente compilano rapporti ogni giorno e soprattutto sono convinti che questo serva!), successivamente c’è il fatto che si adatta anche a piccoli team di sviluppo, anzi, questi sono nettamente preferibili, che ha come obiettivo principale una buona usabilità e quindi semplicità del software da produrre e che lo sviluppo avviene in maniera incrementale, ovvero a piccoli rilasci successivi.

Caratteristiche a mio parere assolutamente affascinanti per una metolodologia di programmazione.

Le metodologie di sviluppo agili partono dalla considerazione che i requisiti utente cambiano in continuazione durante il progetto, per cui non ha molto senso svolgere una pesante attività di analisi, di progettazione e di documentazione prima di iniziare la codifica, in quanto molto di questo lavoro potrebbe essere sprecato (questa frase mi fa letteralmente venire voglia di gridare a sguarciagola “Evviva Evviva!!!”).

Si può inoltre mantenere la documentazione essenziale all’interno del codice sorgente stesso: così quando si modifica il codice a seguito delle variazioni di specifiche richieste dal cliente, si modifica anche la documentazione.

A questo punto è mio assoluto dovere citare una delle più note e diffuse metodologie agili: l’ eXtreme Programming (XP).

Alcune pratiche dell’eXtreme Programming sono:

• La ricerca della soluzione più semplice;
• L’estrema semplicità del codice;
• Standard di codifica rispettato da tutti, nel senso che chiunque deve poter comprendere il codice scritto da un altro membro del gruppo;
• La progettazione dei test prima della codifica;
• La programmazione in coppia (pair programming), ovvero un tipo di programmazione che vede solo due persone coinvolte, una scrive e l’altra supervisiona con la possibilità/necessità di interscambiarsi i ruoli (chi scrive il codice è focalizzato sul modo migliore per realizzare un metodo, una classe, un algoritmo, mentre il collega che gli sta dietro mentre lui scrive è focalizzato sui controlli da effettuare, su cosa potrebbe non funzionare, su possibili strade alternative);
• Interazioni brevi e frequenti;
• Integrazione continua, ovvero si basa sul fatto che il testing intensivo e soprattutto continuo garantisce che ad ogni rilascio successivo il sistema rimanga comunque stabile;
• Refactoring del codice, cioè sua ristrutturazione per contrastare il possibile degrado dovuto alle continue implementazioni;
• Cliente sempre disponibile: un suo rappresentante deve sempre essere a disposizione del team di lavoto per rispondere alle domande;
• Riunioni in piedi;
• Proprietà collettiva del codice: chiunque all’interno del team di lavoro può modificare qualunque parte del codice in qualsiasi momento.

Cosa dire di più? descritta così verrebbe voglia di applicarla subito sempre e comunque!

Purtroppo (in Italia soprattutto) questa metodologia è ben poco applicata.

Infatti, nonostante spiegata così possa sembrare assolutamente perfetta (oggi mi sento evidentemente molto positiva!), essa riserva anche qualche difettucio che si potrebbe dire causa della scarsa applicazione nel nostro Paese.

Uno dei principali “pregi” di questa metodologia è il fatto che coinvolge molte figure di alto livello che collaborano tra loro in periodi continuati di forte concentrazione. Bello sì, ma ovviamente anche molto costoso!

Inoltre il voler ottenere in tempi brevi prototipi o prime versioni funzionali del prodotto dalla qualità eccelsa e perfettamente in tempo per il mercato, significa anche bloccare completamente interi team di progettazione e sviluppo per tempi medio-lunghi. Team di lavoro che oltretutto richiedono una particolare attenzione e abilità nell’essere formati. Lavorare in modalità agile è una tecnica soprattutto psicologica, prima ancora che tecnica. Nel senso che dovendo lavorare a così stretto contatto con altre persone e con il proprio lavoro costantemente messo sotto pressione e sotto il giudizio dagli altri membri, non è cosa così facile spicologicamente sostenibile. Richiede molta apertura mentale e stima reciproca tra tutti i membri del gruppo, senza che ci sia nessuno che voglia sopraffare gli altri. Caratteristiche credo non molto facili da trovare…

Insomma, in parole povere è una metodologia potenzialmente costosa (uso questa parola perchè in fondo essa avrebbe anche come obiettivo la riduzione di tempi e costi tramite eliminazione del lavoro inutile e dei tempi morti, ma questo non è sempre visibile da subito).

Quando il budget totale è relativamente basso, è praticamente insostenibile mantenere un processo di creazione agile ed il team tende quasi sempre a passare ad una metodologia di sviluppo a cascata: “si fa quello che si può… come viene viene” si preferisce dire, e purtroppo questa è una realtà molto comune.

Non è da nascondere che nel nostro mercato non sempre si punta alla qualità e che i clienti chiedono spesso, a prescindere da tutto e soprattutto da tutte le belle parole dei progettisti sulla potenziale usabilità/qualità del prodotto, una chiusura del progetto in tempi brevi e con costi contenuti.

Succede così che chi fa “agile” si trova, in breve tempo a dover affrontare più progetti “mediocramente” perchè non ha i fondi per affrontarne uno “seriamente”.

Alla fine dunque il risultato è sempre lo stesso: prodotto incompleto e di scarsa qualità.

La domanda che a questo punto viene spontaneo porsi dunque è: ma bisogna cambiare la mentalità della clientela/mercato portandola a comprendere i vantaggi di questi processi oppure identificare nuove strade che intermedino il tutto?

Il tempo ci darà una risposta… speriamo!

(parte di questo post è stata presa da un articolo di qualche mese fa di Luca Mascaro “Sostenibilità dell’Agile design”… la citazione è d’obbligo, trovandomi in assoluto accordo con lui, o meglio, questo è uno di quei milioni di casi in cui io penso una cosa e poi scopro che qualcun altro ha già scritto a riguardo e non ho quindi potuto far a meno di usare alcune sue parole per un esplicita citazione!)

Utente o non Utente

Questo è un quesito che mi iniziai a porre già qualche tempo fa, quando mi ritrovai a dover scrivere sullo usage centered design.

Come arrovellai le mie rotelle allora, tento di fare lo stesso con voi in questo momento e chissà che non trovi una risposta alle mie domande…

Vi chiedo quindi adesso: ma, secondo voi, è giusto includere l’utente nella progettazione di un prodotto a lui dedicato?

La risposta non mi sembra così scontata.

Ho letto tantissimi trattati in merito e sono arrivata alla conclusione che, molto semplicemente… dipende! (tanto per citare colui che ha la colpa del 90% dei miei deliri mentali)

Scontata anche questa risposta forse, ma il mio “dipende” continua con “dipende a chi lo chiedi…”

Leggendo ho notato, e col tempo imparato, che importante quasi quanto il contenuto di uno scritto è sapere chi lo ha concepito, conoscere il suo background (ovviamente sempre in riferimento all’area tematica in questione), che lavoro fa, se lavora nel campo, se ci ha lavorato ed è stato mandato via, se la sua unica risorsa e ragione di vita è quello che ci stiamo approcciando a leggere eccetera…

A mio parere tutte queste cose influenzano molto i contenuti ma soprattutto il punto di vista attraverso il quale siamo portati a vedere una certa cosa (e quando si parla di processo di sviluppo questo è molto importante in quanto le fasi sono molteplici e di conseguenza i punti di vista).

Potrà quindi capitare che un designer ad esempio, risponderebbe alla nostra domanda dicendoci che il dialogo e l’interazione con l’utente sono assolutamente necessari se non sacri per ottenere un buon prodotto ed un ingegniere invece che preferisce lavorare da solo senza avere persone “non competenti nel campo” che disorientano il lavoro.

Ma come fare a capire qual è l’approccio giusto da utilizzare?
E’ giusto includere l’utente nella progettazione essendo lui il destinatario dell’oggetto, o meglio escluderlo per permettere ai progettisti di poter applicare tutte le loro conoscenze nel campo?
Bisogna focalizzarsi sui bisogni dell’utente, sui compiti che vuole svolgere o sugli obiettivi che vuole raggiungere?

Volendosi focalizzare sull’utente si potrebbe citare come in fondo “Non si può vendere caffè senza parlare coi bevitori di caffè” (sacrosante parole) ma se al contrario ci si volesse focalizzare sui compiti è anche vero che, come afferma un vecchio detto del design, “Se si chiederà a qualcuno di disegnare un vaso e non qualcosa per contenere dei fiori non si avrà mai un giardino pensile”…

Verrebbe qui molto spontaneo chiedersi: ma, in fondo è per l’utente che si sta progettando. Perché non
bisognerebbe includerlo nella progettazione?

Il problema è che spesso è difficile definire bene l’utente ed i suoi obiettivi, soprattutto se a lungo termine, oppure essi sono talmente vaghi che risulta davvero difficile pensare ad un design concreto per loro.

Immaginiamo un designer che stia creando un’applicazione per aiutare gli studenti universitari a
gestire i loro impegni.
Qual è l’obiettivo? Aiutare gli studenti ad andare meglio a scuola? Ma perché? Perché possano
laurearsi? E qual è l’obiettivo lì? Che siano istruiti? Che trovino un buon lavoro?

Sono convinta che le persone non sempre sanno cosa vogliono, e allora, è giusto ascoltarle? è giusto basarsi su dichiarazioni che magari non sono corrette? Sempre tenendo presente che l’utente può nn farlo apposta ma che semplicemente, in quanto umano, può avere un subconscio che dice una cosa e il corpo che ne fa capire un’altra…e allora noi, cosa facciamo??

Ci impuntiamo sugli obiettivi?

Bene.

Iniziamo dunque a chiederci “perchè”. Perchè l’utente dovrebbe voler usare il nostro prodotto? Perchè c’è bisogno di quella funzione? Cosa sta tentando di fare? Cosa vuole ottenere?

Ovvio che questo è importante. Se il nostro utente non trova quello che sta cercando, ovviamente non lo comprerà. Se le informazioni chiave non sono visibili, il processo decisionale sarà compromesso.

Quello che gli utenti vogliono è uno strumento che li accontenti? Perfetto. Eccolo.

Partire quindi subito con l’obiettivo “dell’utilizzo”, identificando subito gli usi fondamentali, aiuta
ad ottimizzare i tempi di sviluppo ed a rendere il nostro prodotto decisamente più usabile e quindi quale approccio migliore di questo per il nostro successo…

Ma un problema c’è, ovviamente. Fissandosi sui compiti, i designer non cercheranno soluzioni per il problema nella sua globalità. Non vedranno la “foresta” perché troppo occupati a guardare gli alberi.

E quindi? ….siamo sempre al punto di partenza…

A volte ho avuto come l’impressione che in fondo nessuno avesse davvero in mano la risposta a tutto questo…nemmeno chi scriveva in merito. Mi è sembrato tutto un bisogno assoluto di prendere posizione e basta senza preoccuparsi davvero di cosa si stava dicendo.

“Si fa così”, dice qualcuno,”No, è sbagliato, bisogna fare in quest’altro modo”, dice un’altra voce, “I bisogni!!”, “No le attività!!!”, “No gli obiettivi!!”, “e l’emozione?!”, “le funzioni!!” Gridano e litigano altri…

E a questo punto mi viene spontaneo chiedermi…ma siamo sicuri che esista una risposta a tutto questo che sia diversa da un “dipende”?

Lui sa…

Come è risaputo, nutro profondi dubbi sulle convinzioni che inducono a prendere la parola dell’utente come sacro santa…

Tendo ad essere più convinta del fatto che lui non sappia sempre esattamene cosa vuole ma che questo sia vero solo “dentro di lui”. All’esterno tende sempre ad esagerare, a proporre cose assurde ed a porsi come unico obiettivo quello di non voler sembrare studipo (come il caro Norman insegna….).

Tante volte mi è capitato di assistere a scene al limite dell’assurdo.

Prendiamo nuovamente ad esempio i cari frequentatori di pub e dintorni. Tali persone sono sempre lì a dirti “mettine di più”, “oh mi raccomando fallo così e così” eccetera…e lì sta al bravo barista decidere se ascoltare il cliente o far finta di niente pur di mantenere la qualità del suo lavoro.

Eh sì, perchè se si fa come ti dice il presuntuoso personaggio, il cocktail non verrà certo buono come potrebbe venire se solo si lasciasse lavorare in pace il nostro caro barman!

A volte mi è persino capitato di vedere gente che, datale una bottiglia in mano per somministrarsi quindi autonomamente la quantità desiderata, qui esagerava, riempiva a sproposito il bicchiere, con il risultato poi di lasciarne metà a causa della scarsa “grazia” del sapore.

Alla luce di tutte queste esperienze io personalmente ho trovato la mia via di mezzo. I clienti/utenti vanno sì considerati e ascoltati, non li si può certo trascurare, ma con un occhio aperto l’altro chiuso…nel senso che non bisogna fargli capire che in realtà non lo stai ascoltando, che stai fingendo di fare esattamente come lui ti dice quando invece stai lavorando per lui in un modo migliore, ovvero dandogli non quello che vuole ma quello che gli piace e lo farà felice…

Perchè non è vero che lui sa davvero cosa vuole…o meglio, spesso semplicemente non è in grado di dircelo, anche perchè se fossimo tutti esperti baristi non ci sarebbe poi bisogno di tutti i mille locali presenti ad ogni angolo delle città!…

Lui, per l’appunto, non è un “barista”!! Cosa vuole e cosa gli piace davvero lo si imparerà solo osservandolo dall’esterno mentre sorseggia il suo cocktail, con che velocità lo finisce e che espressione ha sul volto mentre beve.

Persino io nelle mie mille serate a bancone mi limitavo a comunicare al barista i miei gusti generici aggiungendo poi un bel “fai tu!”…

Chi, quindi, meglio di un barista, esperto conoscitore della propria arte ed al quale si provvede a comunicare i propri gusti, saprà mai renderci più felici e soddisfatti?

L’arte di fare un mojito

ebbene sì…questo post si chiama esattamente così e il tema è esattamente quello.

Ultimamente mi è capitato più e più volte di soffermarmi a pensare alla differenza tra prodotto e processo, nel senso di “cosa sia più importante” a livello di usabilità e di tutto quello che questa parola vuole dire…

Cioè, è meglio valutare il processo o soffermarsi sulle caratteristiche del prodotto finito?

Ovvero…basta spiegare ad una persona come si fa un mojito perchè questo venga buono?

In linea di massima la risposta sarebbe sì….ma allora… perchè sempre più spesso di finisce col bere mojito terribili??

Questa è una riflessione sulla quale sono da un bel po’ di tempo e sulla quale credo resterò ancora a lungo se non altro per la differenza che c’è tra quello che si crede che sia e quello che poi è!

Nella teoria funziona! Funziona perfettamente!

Impara il processo e fai in modo che esso sia ripetibile! Questa è la regola fondamentale per rendere il proprio prodotto “di qualità”. Questa è la regola che tutti i vari enti di certificazione, le varie norme ISO e linee guida in genere ci insegnano. Ma allora perchè quando poi ti viene dato in mano un prodotto sviluppato con le dovute regole, questo non è proprio per niente “di qualità”? Dov’è lo sbaglio? Dov’è il punto in cui le convinzioni teoriche smettono di aderire con quelle reali?

Che forse la strada giusta non sia solo spiegare al barista come si fa un mojito ma fargliene assaggiare un sacco finchè non impara a valutare da sè se il prodotto è buono oppure no in modo che poi sappia “dove andare a parare”?

O che forse il problema sia che non basta che il “capo” ti spieghi come fare una cosa, ma che l’importante sia soffermarsi a fare due chiacchiere con chi i tuoi mojito li beve e sentire loro cosa ne pensano?…. mmh… forse questa è decisamente la cosa migliore…

Certo, in fondo è il capo che ti paga e se dice che nel suo locale i mojito si fanno così tu li fai così. In fondo se chi ti paga lo stipendio ti chiede di fare una cosa in un determinato modo ovviamente la cosa migliore per la propria carriera è farla esattamente così. Ma cosa succede se poi la gente inizia a non venire più nel tuo locale? Forse succede che abbiamo sbagliato qualcosa ed è ora di chiedersi se non fosse stato allora meglio alzare un po’ la voce col capo facendogli capire che quei minuti spesi a parlare con chi ci sta di fronte e capire cosa essi vogliano, siano di vitale importanza per la salute poi di tutto il locale! Se non fosse stato meglio pensare al piccolo per salvare il grande…

Sì…credo sia così…

Pochi giorni fa qualcuno mi ha ricordato che le cose bisogna farle un passo alla volta. Che non si rivoluziona il mondo in una notte (tanto per restare in tema) e che è da minuscoli dettagli che si capisce la differenza tra due prodotti.

Certo, il mojito si fa sempre nello stesso modo (frase di non particolare verità, lo so, ma lasciatemi qui una piccola “licenza poetica”): metti il lime, lo zucchero, pesti il tutto, aggiungi la menta, aggiungi il ghiaccio, aggiungi rum e soda. Facile. Sì. Ma è il modo in cui si pesta il lime, la quantità di menta aggiunta in base anche alla qualità della materia prima, la qualità del ghiaccio eccetera che fanno la differenza…Insomma, tante piccole cose. Tante piccole che non basta insegnare, ma alle quali bisogna credere.

Credere nella propria professione, credere nel lavoro che si sta svolgendo, nel potere del cliente ma anche in quello dell’utente, credere che le piccole cose possano fare la differenza e soprattutto credere che queste cose siano così tanto importanti da poter decretare la vittoria o il fallimento della nostra attività.

Rimango infine sempre convinta del fatto che la gente, nella maggior parte dei casi, non sa assolutamente cosa vuole, quindi non sempre chiedendo a loro si ha la “ricetta perfetta”, ma sta appunto nella professionalità e astuzia di un barista il segreto! Nell’interpretare le parole del cliente e trasformarle in quella sublime miscela di sapori capace di rendere il nostro mojito efficace a risollevare i sensi, efficiente in relazione al nostro ritorno nel suddetto locale e soprattutto che porterà la nostra soddisfazione di popolo della notte ad un livello piuttosto elevato.

Cosa dire…

Fare un mojito è un’arte…

Ma essere un bravo barista è un’arte decisamente più sottile e profonda