Agile UX Italia 2013

Quadri da una esposizionedi

Presentiamo un breve resoconto dell'evento svoltosi a fine maggio. Si è trattato di un momento di incontro e di riflessione sicuramente importante, rivolto a categorie e ruoli differenziati, dai progettisti grafici ai web designer, dagli sviluppatori agli esperti di contenuti, dai direttori di progetto ai responsabili marketing. Al centro di questo incontro, un nuovo modo di concepire la User Experience.

L'evento

Presso la sede fiorentina dell'Istituto Europeo del Design [0], si è svolto il 31 maggio l'incontro Agile UX Italia 2013 [1] cui abbiamo partecipato come interessati spettatori, e su cui riportiamo alcune impressioni.

Nelle intenzioni degli organizzatori, "l'Agile UX Barcamp si rivolge a tutti: appassionati e professionisti, graphic e web designer, progettisti e sviluppatori, content specialist e marketing people, e a chiunque sia interessato a definire con noi i nuovi confini di una User Experience attraverso l'uso delle metodolgie agili".

Questo approccio onnicomprensivo ha avuto il risultato di una significativa partecipazione in termini numerici, ed effettivamente si è trattato di un pubblico eterogeno, con una certa componente di designer grafici tradizionali. L'eterogeneità si è notata anche negli speaker, che hanno proposto esperienze e riflessioni molto diverse tra loro, sia per taglio che per tematiche.

Al centro dell'incontro le tematiche della User Experience declinate in senso Agile. Riportiamo di seguito una breve traccia dei diversi interventi, rimandando al termine dell'articolo una serie di considerazioni generali sul tema e sul significato di un evento come questo.

Gli interventi

Suddivisa in due track tenute parallelamente in due sale diverse, la giornata si è svolta in modo abbastanza "standard" con i diversi relatori che si sono alternati nelle presentazioni. Chiaramente abbiamo assistito solo ad alcuni degli interventi e di quelli vi daremo conto.

Dada e la transizione verso l'Agile

La conferenza è cominciata con una presentazione da parte di Dada [2] in cui sono state illustrate le ragioni e il senso della transizione avvenuta in azienda verso le metodologie agili. Partita fra i primi attori italiani della "rivoluzione digitale" a metà anni Novanta, l'azienda è passata attraverso diverse fasi e ha subito delle ristrutturazioni inerenti il suo core business.

Negli ultimi anni, l'adozione di metodologie agili ha segnato una svolta decisiva nelle sorti di Dada. Quel che ha colpito è l'importanza che tali metodologie hanno assunto in modo pervasivo al punto che l'utilizzo dell'Agile non è limitato all'aspetto "informatico", ma è presente in tutte le discipline e in tutti gli ambiti, anche nel commerciale. Scrum diventa un elemento di successo.

 

 

Figura 1 - Presentazione da parte di Dada della transizione verso le metodologie agili.

 

Luca Mascaro - Experience Change

A Luca Mascaro [3] tocca una sorta di keynote, impostato sulla domanda "In che modo l'interazione con il cliente impatta non solo sull'aspetto di design funzionale ma sulla dimensione tecnologica e del modello di business?".

Presentando dei princìpi di miglioramento come il kaizen, con l'esempio delle lame giapponesi, il relatore si domanda "Come faccio a generare valore in/e qualità?", che è poi un tema base del Lean Manufacturing. Il valore si genera nella collaborazione tra chi "produce" e chi "controlla". È un processo iterativo e incrementale. Nel waterfall, chi controlla non collabora.

Nel lean startup: si parte da zero e quindi il customer development diventa un modello innovativo, in particolar modo nell'ambito della attuale situazione economica. In tal modo può anche succedere che il prodotto iniziale diventi qualcosa di diverso e "inatteso".

 

 

Figura 2 - Experience change.

 

Uno dei problemi fondamentali della lean startup è la difficoltà di trovare un ritmo tra ciò che accade nel gruppo di sviluppo e la velocità con cui arriva il feedback dal cliente, in genere molto veloce.

Per fare valore per il cliente e per l'utente, è necessario un insieme di loyalty, adoption, engagement. Un esempio in tal senso è quello delle aziende di telecomunicazione in Svizzera, in cui l'attore "tradizionale" inizialmente scalzato nel mercato dai nuovi player, è poi riuscito a riconquistare fette di mercato proprio grazie all'applicazione dei valori appena illustrati.

Il contesto cambia l'aspettativa, e quindi il "cliente" può cambiare tutto? Il product owner rischia di diventare un superman. Non deve essere così, altrimenti si va veramente verso un altro modello, che non è più agile e lean. In pratica... si parte molto snelli e si finisce per sclerotizzarsi. In Agile questo è un problema emergente che va tenuto presente. Il Product Owner deve essere molto sensibile e molto bravo, ma non può diventare l'unico responsabile del processo. Il ciclo dell'esperienza deve essere sviluppato in maniera collettiva e collaborativa.

 

Si è trattato di una riflessione articolata, forse con qualche incertezza in particolare quando il relatore ha inizialmente affermato che in fin dei conti il waterfall è un processo piuttosto naturale; ma a parte questo, alcuni degli spunti, specie per quel che attiene ai rischi della eccessiva preponderanza del Product Owner, si sono rivelati interessanti.

Federico Badaloni - Il linguaggio come tool

L'intervento di Federico Badaloni, architetto dell'informazione presso il Gruppo Editoriale L'Espresso, si focalizza sull'importanza del linguaggio e del dialogo. L'iterazione è caratteristica non solo della produzione digitale, ma anche della informazione. L'iterazione ci riporta anche a un mondo preindustriale in cui l'informazione si trasmetteva in maniera orale, con il linguaggio, in maniera ciclica

 

 

Figura 3 - L'importanza del linguaggio nelle metodologie agile: dialogo come "tool".

 

I metodi Agile recuperano questa arcaica ciclicità. Un altro aspetto importante delle metodologie agili è che in esse diventa fondamentale affrontare il singolo chunk, senza perdere di vista la visione complessiva. Che cosa avviene in una iterazione? La iterazione è un processo dinamico relazionale di creazione condivisa.

Ci sono alcuni fattori positivi che aiutano nel processo:

  • riuso di quanto ha già funzionato; ma occorre non restare ingabbiati: può essere positivo abbandonare la via solita;
  • contesto in cui avvengono le iterazioni; nel digitale, prima si pubblica, poi si filtra; meglio qualcosa che funziona, anche se rozzo, e che poi perfezioneremo: in tale ottica il dialogo prende grande importanza.

L'idea del dialogo come "tool", oltretutto si inserisce perfettamente nelle voci del manifesto Agile [5].

Si passa poi ad analizzare alcuni aggettivi che connotano il lilnguaggio e che ne rappresentano delle qualità che devono essere sempre presenti nel processo.

  • Linguaggio adattabile (si può sbagliare e correggere): dare un nome condiviso agli errori ricorrenti (passato). Dare un nome condiviso ai delta di valore (futuro).
  • Linguaggio trasparente: nessun sottinteso, diffidare del "facciamo" o del "si dovrebbe" (prima persona plurale o impersonale).
  • Linguaggio semplice: semplificare il linguaggio senza paura, come già diceva Italo Calvino nell'esempio sulla "antilingua". Riuscire a dire qualcosa in un linguaggio semplice, è già una prima garanzia che questa funzionerà. Ricordarsi sempre che ottimizzare la lingua porta alla semplicità, ma non alla banalizzazione, che sono due cose ben diverse. Show, don't tell.
  • Linguaggio unitario: gli obiettivi devono avere un nome condiviso per non essere interpretabili dai diversi attori in gioco.
  • Linguaggio esatto: nei gruppi interdisciplinari occorre usare parole precise ma comprensibili a tutti e senza abusare di analogie e similitudini. Imparare da subito a usare il nome dell'esigenza ("occorre appendere il quadro") e non quello della soluzione ("ci vogliono dei chiodi da piantare nel muro").

Il messaggio culturale di Agile è proprio quello di creare insieme con un linguaggio condiviso.

 

Questo intervento si è caratterizzato per l'alto profilo e per l'attenzione data a un aspetto a volte sottovalutato in certi gruppi di sviluppo solo apparentemente agili. Una piccola critica da fare al relatore, però, è di essere stato la prima "vittima" dell'uso di un linguaggio non esatto. Nel citare, infatti, il manifesto Agile, le affermazioni originali sono basate sul "più che" ("gli individui e le interazioni più che i processi e gli strumenti"); al contrario, nella presentazione si faceva riferimento a un "non" ("individui, non processi; interazioni, non tools…"). Fatte salve certe precisazioni, comunque, gli importanti spunti di riflessione non sono certo mancati, anzi...

Claudio Pustorino & Elena Zordan - Sperimentazioni di design agile

Molto pratica e basata su esempi derivanti dalle esperienze professionali è stata la presentazione di Pustorino e Zordan [6]. I due, del team dello studio di design UX Sketchin, partono da una semplice, ma fondamentale, domanda "È sempre possibile fare Agile?".

La risposta è abbastanza scontata: occorre trovare delle soluzioni a problemi ricorrenti. Con un approccio molto "laico", i due affermano che occorre contemperare le caratteristiche della tipica struttura aziendale con i principi dell'approccio agile, prendendo atto dei casi in cui le metodologie agili faticano a integrarsi nelle strutture aziendali.

 

 

Figura 4 - Sperimentazioni di design agile. EVO, un processo strutturato di design.

 

Ci sono limiti imposti da condizioni esterne, o dal progetto stesso, oppure dal cliente: la risposta è che non sempre è totalmente possibile.

Si passa poi all'illustrazione di una serie di casi d'esempio, dai quali si evince che ogni progetto è una esperienza, in cui la componente di apprendimento non va sminuita. Quattro sono gli esempi di progetti svolti:

  • Bazaar rappresenta la condizione ideale in cui applicare le metodologie agili. Workshop iniziale, collaborativo, cui tutti hanno partecipato in maniera entusiasta e da cui è derivata una piattaforma di condivisione delle informazioni che è servita molto durante il processo. Il cliente ha preso parte attiva a tutto lo sviluppo.
  • Dreamboard: spazio all'immaginazione con una piattaforma di tracciamento dei sogni. Anche qui c'è stato un lavoro di condivisione delle idee con il cliente. Il primo prototipo è stato fatto in waterfall, ma tutto il resto è stato fatto in agile.
  • Sketchin: massima efficacia, minima efficienza. Dovendo ricreare il nuovo sito della loro stessa azienda, erano al tempo stesso sia clienti, sia progettisti, sia fornitori: hanno ridisegnato tutto (icone, layout, etc.) e non hanno prodotto alcuna documentazione ma si era in presenza di tanta comunicazione continua. Qui erano "oltre" l'agile, poiche‘ il progetto evolveva continuamente.
  • inMondadori: un caso in cui il cliente è fortemente strutturato, con interlocutori differenziati, ruoli ben precisi e la difficoltà di coinvolgerli in un processo pienamente agile. Si è quindi lavorato parte in watefall, parte in agile, con documentazione "tradizionale", che però era iterativa, incrementale e time-boxed. Detta in maniera semplicistica, è stato un progetto agile all'interno del team di design, ma waterfall con il cliente.

 

La presentazione ha avuto il merito di mostrare casi reali, e di ammettere candidamente come in certi casi si siano utilizzate metodologie "tradizionali", almeno in parte. Molto concrete sono apparse le conclusioni dei due membri di Sketchin: ogni progetto è diverso e richiede, almeno in una certa misura, strumenti e metodi diversificati. L'agile non è solo una metodo, ma un'intenzione. Le persone e le interazioni sono più importanti di strumenti e processi, ma questo non significa che strumenti e processi non abbiano comunque una loro importanza. Occorre, insomma, essere agili piuttosto che "fare agile".

Stefano Trojani & Elisa Pasquini - I love testing with UX

Un intervento semplice ma efficace per presentare la figura dell'agile tester. I due relatori [7] ci tengono subito a mettere in chiaro che il ruolo del tester in Agile è diverso da quello di un debugger. Si tratta infatti di professionisti che partecipano a tutte le ceremonies tipiche dello sviluppo agile e che lavorano a stretto contatto con coloro che progettano la UX.

 

 

Figura 5 - Gli agile tester devono lavorare a stretto contatto con gli UX designer.

 

Vengono poi presentati alcuni tipici strumenti del tester:

  • UML e use case diagram;
  • activity & sequence diagram;
  • test case & UA test: danno una tabella che dettaglia il funzionamento di un flusso;
  • Selenium IDE: viene usato per i test automatici.

Gli scopi fondamentali di questo ruolo sono sostanzialmente di garantire qualità, creare documentazione comprensibile a tutti, facilitare la comunicazione tra il team (Product Owner, sviluppatori, designer UX) e gli stakeholder. Occorre sinergia tra UX e tester, poichè c'è condivisione di aree e concetti. L'uso di scenarios, personas e usability tests riveste grande importanza.

 

Da questa presentazione emerge soprattutto un aspetto: in un processo realmente agile, occorre valutare i diversi punti di vista a seconda delle diverse professionalità; infatti, il designer di esperienza utente tenderà a vedere maggiormente certi aspetti, mentre il valutatore di usabilità ne vedrà altri. Solo lavorando insieme in maniera agile si arriva a un risultato che sia effettivamente deliverable.

Yvonne Bindi - Writing is design

Architetto dell'informazione con un profondo interesse per il linguaggio, Yvonne Bindi [8] presenta un intervento che affronta l'importanza delle parole e del testo in un'ottica di massimizzazione dell'esperienza utente. Dopo aver ribadito concetti in teoria "scontati" (importanza del testo, influenza della forma delle parole, valore del microcontenuto) ma purtroppo spesso completamente disattesi, la relatrice richiama la nostra attenzione sul fatto che la metafora del "foglio, che ha funzionato per molti anni, adesso funziona sempre meno: la moltiplicazione dei device ha reso infatti obsoleto il concetto di pagina. Con ogni probabilità, infatti, il nostro utente leggerà il contenuto che gli forniamo su un device diverso da quello che è stato usato per progettare.

Occorre applicare appieno il concetto di future friendly: i contenuti possono cambiare forma, posizione e orientamento, ma non devono cambiare nella capacità di comunicare. E questo li garantisce in ottica futura per quanto riguarda la loro fruibilità anche su device che ancora non esistono.

 

 

Figura 6 - La scrittura come design: la distribuzione delle informazioni nelle diverse visualizzazioni (desktop e mobile) del sito del giornale The Guardian.

 

Pertanto i contenuti vanno spacchettati e organizzati in maniera da ridistribuirli in base allo schermo che li visualizza (o in accordo con il supporto dove vengono messi, compresa la carta). In questo modo abbiamo una buona possibilità di erogare contenuti in base al supporto: in pratica, si creano dei microtesti che poi vengono ricombinati in maniera adatta al contesto, secondo il sistema COPE (Create Once Publish Everywhere), applicato, ad esempio per quanto riguarda i contenuti della radio NPR.

In quest'ottica, anche scrivere "per i motori di ricerca" implica il concetto di "publish everywhere", ma non bisogna fare l'errore di scrivere pensando solo all'ottimizzazione nelle ricerche. I titoli, ad esempio, devono essere scritti per per gli umani e non per i motori di ricerca sebbene questi ultimi vadano tenuti comunque in considerazione: sui motori di ricerca, infatti, usiamo  parole semplici, ma poi, quando dobbiamo fare click su uno dei risultati restituiti, restiamo impressionati favorevolmente più dai titoli "migliori", quelli che colpiscono immaginazione e l'emozione.

 

L'intervento è stato di sicuro valore tecnico e ha affrontato con competenza ed esempi azzeccati un tema spesso marginale o sottovalutato. Il limite, se proprio lo vogliamo chiamare così, sta nel fatto che ci si è concentrati sulla componente di architettura dell'informazione in senso stretto e di progettazione della UX in senso ampio, tralasciando la componente più strettamente legata a Lean/Agile. Poco male, perche‘ ci ha pensato l'intervento successivo a concentrarsi su questi aspetti.

Fabio Armani & Marco Calzolari - Lean UX 1 + 2

La presentazione di Fabio Armani [9] e Marco Calzolari [10] si svolge tutta sulla metafora dei quattro "movimenti" all'interno di una sinfonia, e ipotizza una sorta di dialogo tra un "fautore" dell'approccio Lean/Agile e uno "scettico" che a poco a poco entra invece nell'ottica della filosofia e se ne lascia coinvolgere per quanto riguarda la progettazione della UX. A dire il vero, della tematica Lean UX, Fabio Armani aveva già parlato alla conferenza Better Software [11] dello scorso anno, ma con un taglio decisamente più tecnico. Qui il discorso è diverso: attraverso delle "suggestioni", comunque sempre molto rigorose e focalizzate, si vuol portare chi segue la presentazione a fare una sorta di "percorso introduttivo" che costringa a porsi delle domande e offra qualche indicazione su come cominciare a darsi delle risposte. In tale "evanescenza" sta la forza ma anche il rischio di un intervento del genere: per apprezzarlo appieno occorre un atteggiamento esplorativo desideroso di entrare nel meccanismo, e non quello di chi vuole andare a "comprare" una soluzione precostituita.

 

Il primo movimento comincia con un brano musicale ("Promenade" da "Quadri da un'esposizione" di Modest Petrovic Musorgskij) che illustra molti concetti della filosofia Agile. Attraverso diversi "quadri", vengono mostrati alcuni concetti che sono alla base del movimento Lean/Agile. Cites Obscures, una serie di fumetti dei primissimi anni Ottanta, serve a mostrare che non ci manca tecnologia, ma un processo fluido.  Il quadro con Taiichi Ohno e il sistema Toyota ci far riflettere su come tutto il movimento è nato, e perche‘. Il "quadro" in cui vengono mostrate le caratterische dei diversi tipi di progettazione UX (Traditional UX vs Agile UX vs Lean UX) ci mostra il diverso focus dei diversi approcci:

  • Traditional: che cosa dobbiamo fare (design, usabilità);
  • Agile: come dobbiamo lavorare (collaborazione, consegna);
  • Lean: princìpi User Centred Design e Lean Startup.

Successivamente si passa ad analizzare i principi di Lean UX:

  • gruppi in cui le funzioni si mescolano (grafici, sviluppatori, tester etc.);
  • squadra piccola;
  • squadra dedicata;
  • squadra presente nello stesso luogo;
  • niente "rockstar", basta primedonne (è un antipattern);
  • analisi sì, ma senza esagerare (come ci insegna il gioco della marshmallow challenge);
  • la conoscenza arriva prima della crescita;
  • vivere fuori dalla schiavitù della produzione.

È un percorso, non è un metodo.

 

Il secondo movimento sceglie come musica introduttiva "L'uccello di fuoco" di Igor Stravinskij. Si dà molta importanza ad alcune "puntualizzazioni". Anzitutto, si ribadisce che occorre abbattere i muri tra competenze, e che occorre vivere la trasformazione come valore. Lean rende maggiormente agili; lean è filosofia, agile è metodologia. Un punto che viene messo in luce, e giustamente, viste le incomprensioni che a volte si ingenerano, è il fatto che le metodologie agili richiedono grande disciplina: non si tratta di pratiche eccentriche e disorganizzate, ma di medodi che funzionano solo in presenza di grande motivazione e disciplina da parte di chi le adotta. Agile è un processo empirico e non deterministico: ma chi lo guida? Chi decide? Non servono eroi, ma un processo collaborativo e condiviso, in cui non esistano figure di "morti viventi" (i relatori li definiscono scherzosamente zombies) ossia progettisti solitari, manager che pensano solo al diagramma di Gantt, clienti passivi e inattivi.

 

 

Figura 7 - La lunga e interessante riflessione a due voci tra Fabio Armani e Marco Calzolari.

 

Parafrasando la composizione incompiuta di Bach sulla fuga, il terzo movimento viene definito "L'arte della sintesi". Qui si affrontano certi temi "tecnici" nell'ottica dell'approccio lean UX, ad esempio l'annosa dicotomia velocità vs estetica. In tal senso occorre convincersi che non esiste il "bello in se‘" ma quello contestualizzato all'interno del tipo di progetto, e quindi va considerato debito tecnico non solo quello legato alla scrittura del codice di programmazione, ma anche quello inerente lo UX design, ad esempio interfacce inutili che sono belle ma poi non risultano funzionali. Qui il ruolo dell'UX designer diventa quello di "custode di valori" coerenti con l'approccio Lean UX.

Altro tema trattato è l'importanza del feedback e del modo in cui viene fornito ed elaborato: la paura del fallimento è un limite della nostra cultura che non ci consente l'innovazione, ma il fallimento va messo in conto.

Un altro aspetto è quello del funzionamento del team: la squadra è integrata, tutti sono pari, e le responsabilità sono condivise. Con riferimento al tema "musicale" della presentazione, viene illustrato l'esempio della orchestra sinfonica classica (un direttore, molti esecutori, alcuni dei quali "sconosciuti") confrontata con l'ensemble di gamelan, la musica tradizionale indonesiana, basato su concetti molto diversi: è poliritmico e ogni ensemble lavora con accordatura personale. Nel funzionamento del team, appare evidente il coraggio in Scrum: dire quello che si pensa, fare delle scelte, fare delle domande etc. È infine necessario fermare il "rumore", togliere "rumore", togliere spreco. No a riunioni non necessarie, a ripetizioni di operazioni, a ruoli non definiti, a deliverable non necessari e così via.

 

Il movimento finale è una chiusura con un video [12] che ricapitola in maniera simbolica e suggestiva il percorso appena illustrato, e di cui si parla già nell'editoriale di questo numero.

Considerazioni finali

Questi incontri sono sempre positivi poiche‘ mettono in contatto persone ed esperienze diverse e consentono confronti su temi importanti vissuti da punti di vista differenziati. Su Agile UX Italia 2013 abbiamo una serie di considerazioni, in un'ottica di critica costruttiva, che tentiamo di sintetizzare di seguito.

Da un lato, molti dei contributi sono stati di buon livello, ma forse è mancato un momento di confronto e di discussione che avrebbe contribuito a creare maggiore valore condiviso. L'organizzazione è stata perfetta, e i tempi sono stati rispettati, con interventi ne‘ troppo brevi, ne‘ troppo lunghi, ma qualche momento di "decompressione" adatto allo scambio di impressioni e alle discussioni fra persone e in gruppi non avrebbe fatto male.

Un altro aspetto importante è quello della "liquidità" del tema. I diversi relatori hanno parlato di Agile UX da molti punti di vista diversi (ed è un bene) concentrandosi magari qualcuno sull'architettura dell'informazione, qualcuno sugli aspetti del processo di progettazione, qualcun altro su un concetto di UX molto "tradizionale", e altri ancora sulle differenze tra tutti questi aspetti e l'approccio Lean UX. Questo ha ingenerato un po' di "confusione" in quella parte di pubblico meno addentro ai processi di sviluppo e maggiormente afferente alle aree del design grafico "classico" che pure era numeroso tra i presenti.

Non c'è niente di strano o di sbagliato in tutto ciò: riscontriamo una analogia con quanto accadeva qualche anno fa nelle conferenze non strettamente Lean/Agile che presentavano Scrum o Kanban e in cui molti project manager "tradizionalisti" faticavano a trovare linee comuni e punti di contatto fra i diversi interventi, proprio perche‘ si era in un momento di transizione in cui certe metodologie si stavano affermando trovando, anche con qualche intoppo, la loro reale dimensione.

Ritengo che, per quanto riguarda lo UX Design, siamo in una fase simile: non è ancora matura la comprensione e l'adozione di un processo veramente Lean UX, molti approcci e molte "tradizioni" diverse si incontrano e si scontrano in questo ambito e, come è avvenuto per i processi di sviluppo del software, occorre ancora qualche anno affinch� certe tematiche e certe metodologie si affermino definitivamente, anche in virtù di una maggiore quantità di "casi esemplari" da portare come testimonianza di una possibile e proficua transizione a questa filosofia/metodologia di progettazione dell'esperienza utente. Del resto, come detto da alcuni relatori, "è un percorso". Che è chiaramente tracciato, ma che aspetta sempre più professionisti pronti a "camminarci dentro".

Riferimenti

[0] Istituto Europeo di Design, sede di Firenze

http://www.ied.it/firenze/home

 

[1] Il sito di Agile UX Italia

http://agileux.it/

 

[2] Il sito di Dada, uno degli organizzatori dell'evento

http://www.dada.eu

 

[3] Luca Mascaro

www.linkedin.com/in/lucamascaro

 

[4] Federico Badaloni

it.linkedin.com/pub/federico-badaloni/6/481/565

 

[5] Manifesto per lo sviluppo agile di software

http://agilemanifesto.org/iso/it/

 

[6] Sketchin

http://www.sketchin.ch/it/

 

[7] Register, a Dada brand

http://we.register.it/

 

[8] Yvonne Bindi

http://www.linkedin.com/in/yvonnebindi

 

[9] Fabio Armani

http://www.open-ware.org/eng/home.htm

 

[10] Marco Calzolari è Senior Project Manager presso Intesys

http://www.intesys.it

 

[11] Better Software 2012

http://www2.mokabyte.it/cms/article.run?permalink=mb177_BetterSoftware2012

 

[12] Un video "riassuntivo" sulle note di "Signal to Noise" di Peter Gabriel

https://www.youtube.com/watch?v=F85hpOak08A

 

 

 

 

Condividi

Pubblicato nel numero
185 giugno 2013
A MokaByte mi occupo di gestire la redazione, gli autori e gli articoli. Collateralmente, svolgo attività di consulenza e formazione nell‘ambito dell‘editoria "tradizionale" e digitale, della scrittura professionale e della comunicazione sulle diverse piattaforme.
Ti potrebbe interessare anche