Quando sarebbe meglio che i programmatori andassero “in pausa”

Questo post era in serbo da tanto…l’ho coltivato e fatto crescere per settimane insieme al mio disagio…e finalmente ho trovato due minuti per farlo venire fuori unendomi alla gran quantità di post su blog di tutto il mondo trattanti questo argomento……

…..

Ho ascoltato molti pareri negli ultimi giorni, ho discusso con amici, ho origliato durante le conversazioni di estranei e tutto questo mi ha portato all’inevitabile conclusione che: “alcuni programmatori qualche volta sarebbe meglio andassero altrove!!!…in pausa pranzo ad esempio, oppure potrebbero andare a comprare un nuovo componente per il loro pc, o a scoprire bug sulla nuova release di office, o a spolverare l’interno del loro computer…insomma, sarebbe meglio facessero qualunque altra cosa sia differente dall’occuparsi di interfacce!!!

Perchè in verità questa è l’unica risposta che mi sono data alla domanda: “Ma chi può aver così deliberatamente rovinato l’interfaccia più famosa (e, se permettete un parere personale, avente un elevato livello di usabilità) al mondo!?!?” risposta: “Forse solo un programmatore annoiato…”.

Questa teoria mi è inoltre stata confermata da un piccolo sondaggio effettuato tra qualche amico…..ovvero che le uniche persone (ovvio specificare il “con cui io abbia parlato”) a cui questa interfaccia piace, sono informatici.

Minuto di riflessione.

Inutile adesso inserire il nome del sito avente l’interfaccia in questione….tanto ci siamo passati tutti…una mattina di fine marzo ci siamo tutti svegliati, abbiamo tutti acceso il computer e con nostra grande sorpresa esclamato “Ma che c… è questo?!?!” passando poi le settimane successive a scusarci per non aver visto il promemoria del compleanno, a cercare l’icona degli eventi, a cercare di capire quale fosse il proprio status e quale una semplice scritta su bacheca eccetera eccetera eccetera……

L’unico pensiero che non sono proprio riuscita a togliermi dalla mente è stato che probabilmente nella testa di qualche sviluppatore in quel momento ci fossero mille pensieri e problemi personali che gli hanno impedito di pensare ad una stupidaggine chiamata: studio di usabilità….

Inutile però infierire ancora sul suddetto argomento…navigando anche solo per la rete si possono scoprire valanghe di articoli e commenti (tutti purtroppo strettamente negativi) sull’interfaccia in questione…

Personalmente ho letto molti libri sul design e devo ammettere che la maggior parte delle volte che si cambia l’aspetto a qualcosa di già così intrinseco nella vita quotidiana della popolazione, è facile essere subito oggetto di critiche…ma questa volta il polverone alzato è davvero enorme!! Non credo di aver mai assistito ad un cambio di design così pessimo e soprattutto che riesca a non soddisfare in maniera così piena il paradigma relativo alla “piacevolezza d’uso”!

Sul suo blog, tale Mark, ha persino affermato “Calma, respirate, vi stiamo ascoltando”…. …..gran bella presa di posizione…DOPO!!!!

Nel cercare quindi di seguire il suo consiglio e respirare mi imbatto però subito dopo in una mail che sempre tale Mark ha inviato ai suoi dipendenti affermando l’inaffermabile … (neanche voglio esplicitare tale mail per evitare di innervosirmi ulteriormente…..)

Concludo questo post adducendo un piccolo lutto personale per aver perso una meravigliosa interfaccia che ci ha fatto conoscere un genio del mondo virtuale forse però ancora troppo piccolo per il mondo reale…

Con la speranza che il tempo mi smentisca, vi saluto……………

Le percezioni

No, non sono sparita, e nemmeno ho abbandonato le mie pratiche e riflessioni in campo “usabilità”.

Sono solo impegnata in una piccolissima cosuccia: la tesi!

Tesi sudata dal punto di vista dell’argomento. Iniziata in azienda sull’usabilità dei processi produttivi, continuata con deliri mentali a tema geolocalizzazione e varie e terminata ora con le percezioni di sicurezza dei servizi per il cellulare.

Questo argomento mi piace ogni giorno di più. Milioni di studi sono stati condotti su quanto siano sicuri o meno i cellulari e i loro servizi, su quanto la gente non si senta sicura nell’utilizzo di questo o quel servizio… ma qualcuno che pensa a come risolvere questo problema mai!!

Tutti che si fermano ad analizzare il problema ma nessuno che ci chiede “E adesso cosa facciamo?”. Tutti che investono milioni e milioni di euro per piattaforme iper-sicure, anti-intrusione, anti-bomba e tutto quanto di simile esista ma se poi l’interfaccia è implementata male e i nostri cari utenti utilizzatori non si rendono conto di tali sforzi tecnici, “Cosa li si è fatti a fare???”.

Servizi che prevedono l’utilizzo di questo e quel codice, di questa e quella procedura, di questa e quella tecnologia…Ma se tutto ciò è buono solo ad infastidire i nostri utenti al punto di “abbandonarci”, sono davvero serviti tutti gli sforzi fatti per garantirgli un servizio sicuro?!

In tutto questo contesto manca dunque evidentemente una cosa, uno studio che evidenzi come quanto e quando la gente si sente  sicura. Non quindi E’  sicura,  ma quando si SENTE tale.

Ecco, questo studio sto cercando di portarlo a termine io.

Tramite attente analisi del campo mobile, degli studi fatti e delle statistiche stilate da istituti internazionali, tramite l’utilizzo dell’analisi dei rischi per individuare gli attacchi ai dispositivi cellulari potenzialmente più pericolosi, l’analisi di come attualmente si cerca di proteggere gli utenti da questi rischi e di un test, cercherò di scoprire quale approccio/tecnica gli utenti preferiscono.

Le domande da porsi sono tantissime e certo con un singolo test non posso essere in grado di raccoglierle tutte. Non ho certo la presunzione con questo studio di risolvere completamente il problema, ma cercherò di andarci molto molto vicino.

Stilerò i miei personali paradigmi appoggiandomi ovviamente ai sempre verdi paradigmi di usabilità di Nielsen e concluderò con un “Decalogo del mobile”, ovvero cosa un progettista deve considerare quando progetta servizi per i cellulari per fare in modo che questi siano percepiti come i più sicuri possibile.

Mancano ormai poche settimane alla consegna quindi…bando alle ciance ora…

Tornerò a scrivere non appena la cosa sarà conclusa….

Auguratemi in bocca al lupo!

Il design viscerale del Natale

Ed ecco arrivato il Natale…fiera del consumismo è vero…ma come resistere a spendere spendere e ancora spendere!?!?

Ma ve lo dico io il perchè di questa convulsione che prende tutti in questo periodo: è tutta colpa del design emozionale!! e più nello specifico del design viscerale (ovvero quel design legato all’apparenza esterna delle cose) che si fonde poi irrimediabilmente con il design riflessivo (ovvero quel design più legato alla soddisfazione personale, quel design che ci porta a saccheggiare negozi e bancarelle pensando che prima o poi l’oggetto ci servirà o che in qualche modo in casa nostra starebbe benissimo…).

E’ il Natale!

e in fondo, come resistere a quelle belle tazzine della Villeroy & Roche create dal super designer del momento, con quel bel cucchiaino coordianto e il piattino in perfetta sintonia …e anche se costano 50 euro l’una, chi se ne frega…staranno sicuramente benissimo sul mio ….ehm…. per festeggiare…. ehm…. boh… prima o poi mi saranno assolutamente necessarie…

e come non parlare poi della Alessi che ha fatto del design viscerale uno standard per i suoi prodotti! L’altro giorno sono capitata in un luogo pieno degli ultimi ritrovati di questa azienda… e non solo vi ho trovato tutti i suoi meravigliosi oggetti dal design esclusivo tutti belli lucidamente esposti che sembravano avere al loro interno una calamita verso la mia carta di credito e che hanno scatenato in me un sacco di reazioni del tipo “oooooh….che carino!!!”, ma i brutti bastardi responsabili markenting ne hanno inventata un’altra!! Ad un certo punto mi sono ritrovata di fronte ad una teca per la quale l’esclamazione è stata “Devo assolutamente averlo!!”….ovvero: stavo per spendere 25 euro per la MINIATURA del famoso spremiagrumi Juicy Salif… ebbene sì…perchè adesso non solo vendono i loro prodotti consapevoli di scatenare determinate reazioni in noi, ma vendono anche le miniature di tali prodotti… miniature che rendono il prodotto poi inutilizzabile per lo scopo per il quale sono stati creati (un apribottiglie di 3 centimentri certo non aprirà il mio vino..) ma sicuramente placano gli istinti di chi come me non vuole rinunciare al suo Juicy (della serie: chi se ne importa se non riuscirò a spremerci delle arance…è così carino!!) …. ottime strategie di sfruttamento del design viscerale misto a design riflessivo che in questo periodo prendono possesso di ogni oggetto presente nei negozi portandoci all’inevitabile rovina!

A questo punto la mia domanda è: ma siamo davvero sicuri che la colpa del consumismo estremo legato al Natale (ovvero della mania compulsiva di tutti di spendere soldi per ogni più piccola cavolata) sia nostra e non sia degli abili responsabili marketing che ci stregano con le loro magie subliminali!?!?

Ovviamente io quoto la seconda…siamo solo piccoli, poveri e indifesi utenti inconsciamente pilotati da chi si occupa di marketing, packaging, design e ogni altra forma di preparazione del prodotto alla vendita…

Non è colpa mia insomma se la mia camera è piena di cianfrusaglie e il mio conto in rosso … il discorso fila alla perfezione non credete?

E se volete saperne di più, eccovi alcuni interessanti articoli relativi ai vari tipi di design concepiti da Norman:
- Il design e le emozioni
- Emotional Design
- Design emozionale minimalista
- I tre aspetti del design e le icone dello sport
- Gli oggetti del desiderio

Non ci si improvvisa baristi

A volte rimango allibita… sempre più volte rimango allibita e tutto questo mi rattrista molto.

Il campo dell’hci in genere e nello specifico degli utenti e degli user testing, può ad una prima occhiata sembrare dannatamente semplice, ovvio e intuitivo e questo aumenta il rischio di trovare qualcuno che potrebbe pensare di improvvisarsi “usability expert” dopo aver avuto solo qualche piccolo accenno di teoria e sperando di poter contare sulle proprie capacità mentali per dare luogo ad un buon user testing o ad una buona expert usability review.

Per carità, buon per chi ci riesce, osannerò  a vita codeste persone, ma sono convinta che serva più di quello che qualcuno crede sia sufficiente e necessario avere.

Non si può leggere una frase del tipo “devi capire i bisogni dell’utente” e uscirsene poi con un test stile: “Caro utente, scrivi qui quello di cui hai bisogno”, sapere che bisogna far capire all’utente che non è lui l’oggetto del test e che se sbaglia non è colpa sua e scrivere a lettere cubitali “Caro utente, sappi che se sbaglierai non sarà colpa tua” credendo davvero che questa frase non porti suggestioni nella mente dell’utente e che non lo farà assolutamente partire già col presupposto che sbaglierà…. bello…davvero un buon lavoro…

“Oh beata ignoranza” mi viene naturale dire, ma mi viene anche un nervoso pazzesco se penso che questa gente potrebbe un giorno andare a lavorare sul campo…

Beata ignoranza ma anche dannata presunzione!

Ed ecco due qualità che un buon usability expert non dovrebbe proprio avere! Ignoranza e presunzione.

Siamo tutti daccordo che l’ignoranza ti fa vivere più sereno nel tuo bel mondo e dunque la presunzione che il tuo bel mondo sia perfetto ti fa gongolare ancora di più ma in questo lavoro bisogna saper andare oltre…dove andare oltre significa che hai guardato e perfettamente imparato e capito cosa hai di fronte per poi oltrepassarlo… ma come si può pensare di “oltrepassarlo” se non si è perfettamente capito cosa si ha di fronte?? se si va avanti con la presunzione di potercela fare da soli con il proprio ragionamento e basta senza ascoltare i pareri di altre persone?!

E allora Norman Nielsen e Cooper cosa studiano da anni a fare?!? cosa hanno pubblicato libri su libri a fare?!?! e soprattutto, io perchè li ho comprati e letti tutti?!!?

Tutto questo mi sconvolge e rattrista molto…

Ma poi mi viene anche da pensare che, in fondo, ci sono una marea di bar dove andare…e se non ti piace il mojito che un certo barista ha fatto per te, bè, esci e trovatene un altro!

Guarda, un orso che balla!!

Racconterò ora una storia tratta da un famossissimo libro (che solo pochi come me possono vantare di avere )

“C’era una volta un tizio che condusse, tirandolo per una catena, un orso gigantesco fino alla piazza del paese e, dietro versamento di un obolo, lo faceva ballare.

Gli abitanti accorsero per ammirare lo spettacolo della bestia che si trascinava e ondeggiava sulle zampe posteriori.

Il tizio diventò così l’uomo più ricco del paese.”

L’orso ovviamente era un pessimo ballerino…

Ma allora…perchè quel tizio diventò ricco in un baleno?

Semplice, la meraviglia delle persone non stava nell’abilità dell’orso di ballare, ma nel fatto stesso che ballasse!!

..

Sì…la cosa ha lasciato un po’ attonita anche me…una di quelle frasi, uno di quei libri che mentre leggi ti viene da dire “ah sì è vero!!!” “lo sapevo anch’io solo che non ci mai avevo pensato” e tante altre cose(/scuse) simili…

Un po’ la stessa sensazione che lasciano i libri di Norman.

La sensazione che hai sempre visto e mai guardato. Sempre guardato e mai pensato. Sempre pensato e mai applicato.

Un po’ come quando poi mi si dice che, tutta la gente che “vede l’orso ballare” si può suddividere in sole due categorie di persone e io penso “Certo!… adesso voglio proprio sentire!!”

Poi andando avanti nella lettura mi accorgo che, non solo si può, ma che appartengo pienamente e senza sfumature ad una di queste: i cosiddetti apologeti.

Gli apologeti sono, in contrapposizione con i sopravvissuti, quella categoria di persone stordite dalla sensazione di onnipotenza della tecnologia, per le quali c’è sempre un modo per far funzionare un oggetto, basta semplicemente scoprire quale sia!

Quella categoria di persone che da piccole, mentre tutta la famiglia sbraitava contro il videoregistratore di turno all’apparenza impossibile da usare, si sedevano in un angolo (felici del nuovo oggetto iper tecnologico) e pazientemente imparavano a programmarlo per registrare il programma preferito esclamando poi cose del tipo “Hai visto? In fondo è facile! Basta solo premere questo poi questo poi quello e contemporaneamente quello vicino………….”

Quella categoria di persone per le quali non è il cellulare che non funziona, è la gente che non lo sa usare! Per le quali non è colpa del computer se tu ti dimentichi di salvare il file sul quale scrivi da ore…

Insomma, quella categoria di persone “obbedienti all’orso ballerino”.

Ma come avercela con loro?

Lo scalatore non se la prende con la ripidità della montagna così come l’appassionato di computer non se la prende per l’oscurità e la difficoltà dell’interazione.

Ogni tanto però, miei cari apologeti, è bene guardare anche con occhi diversi le cose, o non staremo mai combattendo davvero per un mondo più usabile!

Non ci si  può limitare ad essere felici per l’orso che balla senza considerare il fatto che se abbiamo bisogno di qualcosa che balli, forse un orso non è la cosa migliore……….

citazioni da: “il disagio tecnologico” di A.Cooper

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?