“The Italian most eclectic conference about management”

Con un tempismo degno dei migliori nerd, Better Software fa segnare la sua settima edizione, la terza del nuovo ciclo, proprio nell’anno dell’atteso settimo episodio di Star Wars… E come per la saga ideata da George Lucas, citatissima in numerosi talk, sono inevitabili i confronti con quello che è già stato fatto nel passato. Che però, nel nostro caso, sarebbero fuorvianti per il semplice motivo che mai come quest’anno la dichiarazione di un cambio di direzione è stata così esplicita, già a partire dal claim dell’evento. Fin dalle ultimissime edizioni si era chiaramente percepita una correzione di rotta dallo sviluppo del software alla gestione dei progetti e delle organizzazioni con approccio Lean/Agile.

Intorno al software

Ma questa nuova direzione si è concretizzata definitivamente quest’anno in cui, dichiaratamente, #BSW15 (questo è l’hastag ufficiale) si occupa di ciò che è intorno al software per migliorare l’ecosistema in cui si fa sviluppo: migliori risorse umane, miglior management, miglior organizzazione e così via.

Internazionalizzazione

Ma il deciso cambiamento non si è declinato solo in termini di tematiche e di taglio con cui sono state affrontate, ma anche per la marcata internazionalizzazione dell’evento: da un lato, tra i relatori sono stati presenti esperti provenienti da numerosi Paesi esteri; dall’altro, tutti gli interventi e i workshop (eccettuati alcuni sporadici casi in cui gli iscritti erano solo italiani) sono stati tenuti in lingua inglese.

Tutti questi cambiamenti hanno avuto un impatto sullo svolgimento della conferenza e riteniamo che saranno ulteriormente sviluppati nelle prossime edizioni.

Criticism and praise

Vista l’internazionalizzazione, facciamo il titolo in inglese per riportare, fin da subito, critiche e apprezzamenti. In una edizione come questa non era facile gestire il cambiamento e qualche criticità si è evidenziata, seppur ampiamente bilanciata da aspetti positivi che rappresentano oramai il punto di forza di questa iniziativa.

Alzare il livello della comunicazione in lingua

Cominciamo con una critica. Avere svariati relatori internazionali e proporsi come possibile evento di riferimento non solo in Italia è un’ottima mossa. Occorre però elevare il livello comunicativo in lingua di alcuni dei protagonisti. In alcuni casi, infatti, a fronte di una evidente ottima preparazione e di una proposta interessante, alcuni tra i relatori hanno pagato lo scotto di una limitata capacità comunicativa in inglese. È un aspetto su cui essere più esigenti: sappiamo benissimo che anche in altre conferenze, anche all’estero, il livello non è di molto superiore, ma è fondamentale lavorare anche su questo per portare a termine la definitiva transizione verso una conferenza internazionale e non una conferenza di italiani che parlano in inglese con qualche ospite straniero.

Nessuna novità… ed è un’ottima notizia!

Un aspetto che ha colpito molti è stata la mancanza di novità. Negli anni, Better Software ci aveva abituato a “scoperte”, “anteprime”, “innovazioni”… Da quasi ogni intervento, che si trattasse di talk o di workshop potevano emergere spunti e motivazioni derivanti dal venire a conoscenza di qualcosa di nuovo.

Quest’anno tale effetto sorpresa è mancato, e non ci sono stati interventi particolarmente “sconvolgenti” nel senso della novità. Ma questa, che potrebbe sembrare una critica, è invece un fatto assolutamente positivo. Le tematiche, gli approcci, le soluzioni che anche solo tre o quattro anni fa venivano presentate a Better Software e apparivano come rivoluzionarie non lo sono più semplicemente perché si sono ormai affermate come pratiche “quotidiane” nei contesti Lean/Agile e si affacciano ormai sempre più prepotentemente anche in situazioni abbastanza lontane da questo mondo che comunque vogliano fare delle sperimentazioni o valutare dei progetti condotti in tal modo.

In poche parole, i temi che per anni sono stati il “core business” di Better Software sono ormai definitivamente usciti da quell’alone di “carboneria” e di “esoterismo” che li ha connotati per un decennio e si sono inseriti nell’ambito generale, “mainstream” della gestione dei progetti tanto da non apparire più come “nuovi”. È, lo ribadiamo, un ottimo segnale… anche se ci toglie il cosiddetto “effetto wow!”.

Confronto, condivisione, collaborazione

Nel solco della “tradizione”, lo spirito di confronto, condivisione e collaborazione che ha sempre contraddistinto le precedenti edizioni si è perpetuato anche durante Better Software 2015. In tal senso siamo stati colpiti dal fatto che ogni momento “libero” fosse sfruttato al massimo per discussioni e scambio di impressioni che andavano ben al di là della socializzazione; e questo è accaduto al punto di far leggermente rilassare il “militarismo orario” tipico di Better Software. Le pause a metà mattinata e pomeriggio e l’interruzione delle attività per il pranzo sono stati vissuti come ulteriori momenti di riflessione di scambio.

L’altro ambito in cui la conoscenza collaborativa ha preso il sopravvento è stato quello dei workshop: mai come in quest’anno c’è sembrato che il vero momento clou della conferenza fosse rappresentato dai numerosi workshop in cui si sono affrontati i diversi temi in maniera esperienziale. Vogliamo sottolineare come, per chi decide di partecipare a una conferenza di due giorni come questa, diventa sempre più importante “trasformare” i costi in termini di tempo e di denaro in un investimento che porti qualche frutto: ed è proprio la formula del workshop che forse si presta maggiormente a garantire ai partecipanti di tornare a casa arricchiti, “portandosi dietro” un bagaglio di conoscenze e competenze maggiori.

Come abbiamo più volte ripetuto su queste pagine, a Better Software, effettivamente si può imparare qualcosa, e questo avviene maggiormente proprio nelle sessioni esperienziali.

Un racconto dei talk

Viste quindi alcune criticità e diverse note positive, passiamo a raccontare un po’ alcuni interventi cercando di riassumerne i tratti salienti.

A differenza di altre occasioni stavolta è risultato molto più facile “incasellare” i vari interventi all’interno di categorie piuttosto ben definite: questo non ci era riuscito in molte delle precedenti edizioni proprio poiché tanti e talmente diversi erano gli interventi da risultare solo forzatamente catalogabili con precise etichette. Quest’anno svariati interventi sono apparsi molto coerenti fra loro per tematica e portata, e molto congrui alle etichette scelte dagli organizzatori: Lean e Agile, Management e Human Resources, UX.

Un’occhiata alle due colonne di destra del programma [1] è d’obbligo: nelle “corsie” Workshop e Interactive è possibile vedere in cosa consistevano i diversi workshop, anche se ovviamente un conto è leggerne la descrizione, un altro è prendervi parte…

Stime e metriche

Una delle tematiche tornata in più di un intervento è stata quella relativa alle stime e alle metriche nell’ambito di progetti Lean/Agile: in questo campo i partecipanti hanno potuto farsi un’idea ascoltando punti di vista molto diversi fra loro, ma tutti caratterizzati da una seria e approfondita riflessione.

Vasco Duarte, No estimates: how you can predict the release date of your project without estimating

Tocca a Vasco Duarte [2] il compito di aprire la conferenza e lo fa presentando un quadro generale del suo approccio “niente stime”. Durante il suo intervento, oltretutto, regalerà ai presenti di la possibilità di scaricare gratuitamente il “famigerato” libro No estimates: un’ulteriore conferma che alle conferenze può convenire partecipare di persona…

Il succo del lungo e articolato intervento dell’esperto portoghese è che in definitiva nei progetti software quello delle stime (“Quanto tempo ci vuole?”, “Quando sarà pronto?”, etc.) è un po’ un falso problema. Le ragioni per queste deduzioni così drastiche vengono illustrate con una serie di dati che mettono in luce come, nonostante le stime effettuate con la massima cura, gran parte dei progetti sia comunque in ritardo; e questo accade sia nei progetti condotti con metodiche tradizionali, che in quelli portati avanti in ambito Lean/Agile, sebbene vada notato come in questo secondo caso la quantità progetti in ritardo sia comunque significativamente minore, ma pur sempre alta (circa un 40%).

Diventa importante allora concentrarsi su tutto quello che ci può, almeno in parte, aiutare ad avere in ogni istante una chiara visione di come il progetto sta andando effettivamente, piuttosto che impiegare tempo e risorse a fare previsioni di come andrà. L’esperienza ci viene in soccorso poiché ci insegna alcune lezioni interessanti.

Anzitutto, sappiamo che le cose vanno male quando un processo non è affidabile: per questo è fondamentale abbreviare il ciclo di feedback in maniera da essere sempre “pronti”. Poi abbiamo imparato che complicazioni intrinseche e complicazioni accidentali vanno a incidere entrambe su costo e durata del progetto: e in genere sono le complicazioni accidentali che “fanno il danno”. Di solito, però, si tende a fare stime sulla base delle complicazioni essenziali intrinseche (perché le possiamo individuare con più facilità), quando invece sono le altre, quelle accidentali, che peseranno sui ritardi.

Un altro “inganno” nel tentativo di fare stime è rappresentato da code e backlog, perché in questo ambito c’è una grande differenza tra manifattura ed “economia della conoscenza”: nell’industria, le code si vedano (materiali ammassati, macchine occupate, magazzini pieni etc.). Nello sviluppo software, le code sono meno evidenti e quindi si rischia di sottovalutarle, quando invece le code sono la chiave un ritardi,

Tra i comportamenti suggeriti rientrano quindi quello di fidarsi più dei dati che delle stime, di cercare alternative alle stime per prendere decision, di tenere sempre presente (e sottoporre a valutazione) più il valore che si sta apportando che non le funzionalità, misurando i progressi solo con il software funzionante.

Un intervento dai contenuti sicuramente ben assortiti, a tratti drastici (“Le stime sono spreco”) ma mai sfiorato dal gusto per la provocazione o per l’autocompiacimento. Si può essere d’accordo o meno, e si può discutere del fatto che qualcosa occorra rispondere ai referenti del progetto che chiedono di fare stime. Ma una cosa è certa: l’approccio No Estimates non può essere liquidato con superficialità, poiché parte da basi razionali e da esperienze comuni.

Alessandro Braga, It’s all about the right bit

Collochiamo qui questo intervento, che nella mattinata di lunedì 16 novembre ha seguito proprio quello di Duarte, perché, anche se marginalmente, ha toccato anch’esso il tema delle stime. In breve, Alessandro Braga [3] ha affrontato il tema degli investimenti nelle startup, dei suoi rischi e dell’importanza anche degli aspetti tecnologici in questa attività.

Messo in luce come il pattern delle aziende convenzionali, spesso incentrato solo sui risultati economici, non funzioni con le startup, è stato messo in evidenza come in queste ultime il business, la data/information application, e la tecnologia devono integrarsi in un modello circolare. Sono stati poi evidenziati degli archetipi di modello di business, con uno sguardo alle metriche e alle dinamiche di mercato.

Tra le pratiche raccomandate, rientrano quelle di identificare risultati tangibili, ridurre i rischi di produrre software che non rifletta il modello di business e, tentare di definire un tempo per la consegna, il che non significa fare stime.

Modelli organizzativi, gestione di progetti

Gran parte degli interventi nella due giorni si sono concentrati in chiave Lean/Agile sui modelli organizzativi e sulla gestione dei progetti, affrontando i problemi da diverse angolazioni. Ne è emerso un quadro non unitario, ma in cui i diversi contributi sembrano sempre più convergere verso alcune soluzioni condivise, a dimostrazione del progressivo affermarsi di questa visione in termini di maturità.

Mauro Ferratello, How we increased our productivity with good acceptance criteria

L’intervento di Mauro Ferratello [4] è dedicato a una “messa a fuoco” di ciò che può garantire un miglioramento della produttività, evitando molti malintesi a tal proposito: la produttività non corrisponde al numero delle linee di codice scritte, ma è fare le cose con i tempi e gli sforzi giusti (efficienza) e che raggiungano lo scopo prefisso (efficacia).

L’esempio che costituisce la portante di tutto il talk è quello della penna per astronauti, che forse molti lettori conoscono [5]: al di là dei dettagli e di molte leggende metropolitane che circondano lo sviluppo di tale strumento capace di scrivere a gravità zero, il fatto è che solo ben precisi criteri di accettazione, espressi molto chiaramente possono portare un progetto al successo. E sta anche in questo la chiave per una migliore produttività.

Il modello proposto è quello del BDD (Behaviour Driven Development): uno sviluppo guidato dai comportamenti. Dato un determinato prodotto, quando faccio un determinato test, deve avere questo determinato comportamento.

Alberto Brandolini, Guerilla large scale portfolio management

Quello di Alberto Brandolini [6] sarà il primo, ma non l’unico, intervento in cui emergerà con Forza — è il caso di scriverlo con la maiuscola? — la metafora che prende a prestito i personaggi di Star Wars per illustrare concetti legati al tema principale dell’intervento: Darth Vader rappresenta l’antagonista, Luke Skywalker è l’eroe positivo, l’Impero costituisce l’incarnazione delle organizzazioni che trattano le persone come banali celle di un foglio di calcolo, mentre l’Alleanza Ribelle simbolizza il tentativo di un modello organizzativo e di gestione basato su buon senso e un po’ di teoria di matrice Lean/Agile. Tornando fuori di metafora, il problema da affrontare è sostanzialmente come coordinare la pianificazione per diversi team di sviluppo, che lavorano su funzionalità interdipendenti.

Le organizzazioni “imperiali” che si trovano a gestire molti progetti paralleli aumentano gli sviluppatori, ma non fanno crescere la produttività In maniera equivalente. Il problema è sempre lo stesso: organizzazioni grandi, team mutipli, molti progetti “padronali”, mancanza di team cross funzionali che possano performare individualmente

Occore invece ricercare il valore dei compiti di supporto che spesso non emerge, e non fermarsi semplicemente a prendere atto delle “dipendenze” tra diversi team di sviluppo, del problema delle code, dei tanti progetti in contemporanea che non vengono completati. Seguendo quanto ci dice la teoria dei vincoli, è invece necessario:

• identificare il vincolo
• comprendere il collo di bottiglia
• subordinare il sistema al vincolo
• elevare il vincolo e…
• passare a esaminare il nuovo vincolo

L’Impero usa un approccio esattamente opposto, finendo per creare un sistema disfunzionale. Da tutto questo appare l’importanza di un’analisi più approfondita alla realtà dei costi. I costi non sono banalmente semplificabili valutando solo costi cumulativi e ricavi come spesso ritenuto.

Ci sono anche aspetti importanti difficili da misurare: imparare a trovare nuove soluzioni, apprendere, approfondire le competenze sono tutti elementi che fanno valore ma non sono facilmente quantificabili in termini di costi e ricavi. L’apprendimento, ad esempio, non viene considerato dal management allo stesso livello del deliverable… e invece ha grande importanza.

E cosi creare un contesto condiviso, creare una visione condivisa, avere “orgoglio” e “senso di appartenenza” diventano elementi di valore importante: le Human Resources hanno grande importanza. Le aziende devono ricercare il talento, e non la sostituibilità.

Giancarlo Sudano, DevOps: For whom the bell tolls?

Più sfumato è apparso l’intervento di Giancarlo Sudano [7] all’apertura del martedì mattina, anche se tutti lo ricorderanno per il divertente elenco dei “7 metodi per estrarre il ketchup della bottiglia di vetro”, come metafora delle pratiche di tipo diverso che è possibile adottare per affrontare uno stesso problema.

Il problema affrontato, infatti, consiste proprio nel comprendere come ci si possa muovere attraverso buone pratiche, esperienze maturate nei contesti reali e le lezioni apprese dai successi e dai fallimenti per gestire il ciclo di vita delle applicazioni nelle aziende, in particolar modo in quelle di una certa dimensione.

La soluzione esiste ed è DevOps che rappresenta il modo per accelerare le attività senza diminuire la qualità. DevOps è la soluzione all’acelerazione, che comunque pone dei problemi. In ogni caso, per il fatto di essere tecnologia guidata da una “filosofia” DevOps può ben rappresentare la seconda decade di Agile.

Francesco Degrassi, Fifty shades of fait: a lean perspective on success & failure

Piuttosto a suo agio con la lingua inglese, Francesco Degrassi [8] ha affrontato un tema importante e spinoso: come definire il “successo” o il “fallimento” per un progetto condotto con metodiche Lean/Agile.

C’è il caso in cui certi principi Lean non sono stati implementati, ma il progetto è stato concluso in tempo, rimandendo nel budget e anche con soddisfazione: è un successo (progetto terminato) o è un fallimento (principi non applicati)?

Oppure, la fatidica equazione “portata del progetto + (tempo | budget) = stime” è verificata. È un successo? Oppure è sbagliato misurare il successo in rapporto alle stime? E laddove gli obiettivi di business non siano chiari, i criteri di successo appaiano vaghi, ci siano supposizioni non convalidate, come si giudica un fallimento? Le cause possibili di fallimento possono essere molteplici: obiettivi “locali” possono addirittura inficiare degli obiettivi globali.

Occorre pertanto ridefinire il modo in cui si considera qual cosa come “successo”: servono quindi delle metriche di alto livello, orientate agli obiettivi. E serve un approccio in cui ci si continuino a porre domande e non ci si adagi sullo scontato.

Sunil Mundra, Agile transformation: the difference between success and failure

Anche nell’intervento di Sunil Mundra [9] torna il tema del successo e del fallimento presentato attraverso due storie: una è una trasformazione agile di successo, l’altra è un fallimento.

Molto interessanti sono le precisazioni fatte dal relatore, che mette in luce la differenza tra adozione e trasformazione. La prima si focalizza su cosa si fa, la seconda su cosa si è. Parimenti, c’è una differenza tra cambiamento e trasformazione: il cambiamento avviene ed è governato dalla tattica, la trasformazione si ricerca ed è governata dalla strategia.

Le sfide proposte dalla trasformazione vanno a impattare sulle dinamiche ormai conosciute dei grandi gruppi e delle organizzazioni complesse. Ma non è solo una questione di resistenze; spesso si tratta proprio di una incapacità di entrare nel corretto approccio mentale: il problema fondamentale sta nel fatto che ci si concentra sul “fare agile” invece che sull’“essere agile”. E per questo che il periodo di una reale trasformazione in senso agile è approssimativamente di 5 anni!

Ma come possiamo “misurare” il successo di una trasformazione? Be’ ci sono effettivamente degli “indicatori” che ci danno una certa sicurezza in tal senso:

• collaborazione tra business e IT;
• pratiche di ingegnerizzazione;
• una cultura dell’apprendimento e del miglioramento continuo;
• la conoscenza del proprio stato attuale e dello stato che si desidera raggiungere;
• la definizione dell’approccio per scalare;
• la creazione di “campioni” interni;
• l’allineamento dei KPI;
• il fatto che l’organizzazione condivide delle pratiche comuni;
• il tipo di politiche HR;
• l’infrastruttura informatica che si adatta all’Agile.

In definitiva, si evince che nelle trasformazioni di successo:

• conta la volontà dei leader;
• conta puntare a “essere agili” (e non a “fare l’Agile”);
• si prende atto del fatto che è un processo lungo, che richiede costanza e pazienza;
• si introduce quanto prima la gestione del cambiamento;
• si adotta un approccio di pensiero sistemico (system thinking).

Claudio Di Gregorio, Adopt a startup: Why and how the enterprise should open itself up to startups as vendors

Anche Claudio Di Gregorio [10] adotta la metafora dell’universo di Star Wars per fornire le “7 lezioni Jedi” che supportano questo semplice assunto: le grandi aziende dovrebbero considerare le startup come dei vendor poiché, per la loro struttura, le startup sono dei fornitori di tecnologie emergenti. Dopo aver analizzato le caretteristiche delle startup ordinate secondo il cosiddetto quadrante magico Gartner, che le divide in sfidanti, di nicchia, leader e visionarie, vengono elencati i 7 motivi per cui startup ed Enterprise dovrebbero lavorare insieme.

Nel complesso, una visione di buon senso in cui si adotta una strategia win-win: la startup e l’azienda enterprise possono aiutarsi vicendevolmente e trarre entrambe beneficio da tale collaborazione, proprio come accade nell’abituale rapporto tra enterprise e vendor.

Michele Orsi, A full startup journey, from a technical point of view

Dello stesso tema, ossia dell percorso delle startup, parla l’intervento di Michele Orsi [11]. Il taglio, però, è completamente diverso: in questo caso si racconta un vero e proprio “viaggio” che ha portato il relatore a creare una startup (map2app), a spostarsi per un certo periodo nella Silicon Valley, e a rientrare poi per seguire l’acquisizione della sua creatura da parte di Lastminute.com.

Molto interessante l’approccio realistico a tutta la questione che è emersa evidente durante il talk: niente facili entusiasmi per il mondo degli investitori statunitensi, niente trionfalismi per i risultati raggiunti, la consapevolezza delle difficoltà, la capacità di stabilire il limite più basso a cui è possibile arrivare senza chiudere, la consapevolezza con il ritorno in Italia che gli incubatori sono spesso scatole vuote.

Il processo di acquisizione, poi, va anch’esso seguito con capacità e realismo: occorre saper dire dei no e valutare i molti aspetti in essa impicati. In definitiva, un bel quadro di come far crescere una startup.

Risorse umane ed “ecosistemi” lavorativi

Alcuni talk hanno avuto come tema principale quello delle HR e del modo in cui costruire degli ambienti lavorativi capaci di favorire crescita e produttività del personale. Si tratta di argomenti fondamentali nell’ambito dell’organizzazione: vediamo di seguito che cosa è stato proposto.

Danilo Trebješanin, Using gamification to motivate employees

Tema ormai “classico” quello della gamification trattato da Danilo Trebješanin [12]. Anche in questo caso si è messo in luce come il coinvolgimento e la sperimentazioni implicite nei meccanismi di gioco funzionino effettivamente.

Ma, come con ogni strumento potente, occorre elaborare una strategia adeguata, comprendere bene gli elementi costitutivi del meccanismo (dinamica, meccanica, componenti) e non limitarsi ai soli componenti che creano il cosiddetto PBL (points, boards, levels. Occorre, in definitiva stabilire gli obiettivi di business, delineare i comportamenti desiderati, descrivere i profili dei giocatori, individuare i cicli di attività, graduare le difficoltà senza perdere di vista il divertimento, mettere in azione i tool appropriati.

È un ambito passibile di ulteriori sviluppi, in base alle nuove tecnologie, e che potrà sempre più allargarsi all’ambito social, coinvolgendo interi dipartimenti HR.

Natalie Yadrentseva, Fix the process, not the problem

Il talk di Natalie Yadrentseva [13] si è concentrato sulla possibilità di evidenziare processi, relazioni, strutturazioni all’interno delle organizzazioni. Trae la sua esperienza dal fatto che lavora per un’azienda che fa software per la visualizzazione della gestione di progetto. Ma rispondere alla domanda “Come lavorate?”, che ci si fa quando si osserva un’organizzazione, non è affato facile.

A volte realtà “caotiche” funzionano benissimo. E allora? Capire una struttura non è facile ma bisogna cominciare da qualche parte”, per esempio dalle persone. Esiste in ogni azienda un “vero” organigramma che magari è diverso da quello “ufficiale”. Dall’“organigramma” emergono le relazioni tra persone, i problemi, ciò che si sa, ciò che non si sa. Partendo dalle relazioni tra persone è possibile visualizzare la situazione per ciò che è, ed esistono delle metodiche, dei workshop di visualizzazione del processo, che evidenziano le caratteristiche e le relazioni delle persone, e dei piani su cui lavorano, e consentono di individuare delle metriche.

Questo tipo di attività ha il merito di mettere spesso in luce quella che è la realtà. Infatti c’è un processo “idealizzato” che spesso è molto diverso da come si lavora nella realtà dell’organizzazione. Il primo passo per risolvere i problemi è rendere visualizzabile il processo che spiega come si lavora

Questa visualizzazione deve essere aperta a tutti e con metodi diversi: immagini, schemi “fisici”, strumenti digitali). Non si finisce mai di ribadire l’Importanza della condivisione della visualizzazione dei problemi perché, se si vedono, è più facile comprenderti e risolverli. Oltre alla perfetta definizione dei vari aspetti, la visualizzazione dà importanza anche alla percezione: infatti mettiamo insieme le cose anche se non sono perfettamente definite.

Nella visualizzazione non va dimenticata l’importanza delle metriche che devono essere presentate così da essere comprensibili a chi deve fare le valutazioni. Addirittura, all’interno della stessa organizzazione potrebbe essere necessario visualizzare gli stessi dati in modo diverso per persone diverse.

Il talk, ricco di suggestioni, si conclude con una serie di consigli:

• aggiustare non appena qualcosa si rampe;
• prevenire attraverso i prodotti che fanno emergere quasi in anticipo problemi che devono essere risolti, e scoprire prima i problemi significa avere vantaggio competitivo;
• trovare la causa alla base del problema;
• tenere tutto in loop e coinvolgere tutti gli attori interessati.

Pier Alberto Gibellini, Some new jobs’ frightening rewards

Il rischio di uno scorretto rapporto fra metriche e personale viene affrontato nel talk di Pier Alberto Gibellini [14]. Nasce infatti da una scorretta impostazione del tema delle ricompense una serie di problemi che si possono riscontrare nelle organizzazioni.

Tutto dipende dal legame fra ricompensa e metrica scelta: le metriche devono avere uno scopo preciso e devono essere gestite, altrimenti sono inutili. Attenzione alla “vanità”: le metriche non devono misurare solo “quanto siamo bravi”; occorre invece usare il buon senso e non fare le cose in funzione delle metriche

Preferire quindi le direzioni rispetto all’obiettivo: se devo solo raggiungere l’obiettivo, rischio di perdere di vista il resto del “viaggio”, rischio di “barare”. Le metriche servono all’automiglioramento: meglio mantenere metriche e ricompense scollegate tra loro. Occorre nel personale promuovere una cultura della trasparenza e della fiducia ed è bene misurare spesso con indicatori di tipo leading e non lagging. È una delle lezioni di Jurgen Appelo e del suo Metrics Ecosystem.

Antonio Peric-Mazar, A recipe far effective leadership

Anche i temi affrontati da Antonio Peric-Mazar [15] CEO e fondatore di Locastic non sono nuovi. Ma non per questo risultano meno efficaci anche perché sono corroborati da una evidente esperienza sul campo che traspare nella maniera molto partecipata con cui è svolto l’intervento.

Gli argomenti affrontati sono quelli della differenza tra “boss” e “leader”, i limiti del controllo, la leadership basata sul rapporto con il proprio team, l’importanza del processo di selezione e assunzione per avere un gruppo “che funziona”. La cultura della squadra è fondamentale: dove si vuole andare, quale è la visione condivisa, quali sono i modi per farlo. In tutto questo è importante favorire il miglioramento delle persone e l’importanza della delega, così come occorre una comunicazione chiara che dica cosa, come e perché e una cultura della trasparenza e dell’onestà.

Non dimenticare, poi, di “celebrare” i successi: è bene dare importanza ai risultati delle persone e non dimenticare l’importanza delle emozioni e dell’umanità.

A ciascuno la sua UX

Non sono mancati interventi legati al tema della User eXperience, declinata con approcci molto diversi fra loro ma piuttosto interessanti.

Maurizio Boscarol, What UX is your UX?

Ritorna a Better Software dopo alcuni anni Maurizio Boscarol [16] a parlare di UX ponendosi il quesito: esiste un’UX più adatta a determinate attività e che fa del nostro prodotto un qualcosa di particolare? Dopo aver ricordato che la UX è incentrata appunto sull’utente, e aver illustrato alcune metodologie utilizzate per valutare le reazioni dell’utente alla UX, si passa ad analizzare i componenti più importati per la UX dei diversi tipi di progetto.

Quali sono i componenti più importanti per la UX del nostro progetto? Fiducia, affidabilità e utilità sono collegate e pesano circa il 44%. La facilità di uso pesa circa il 33%. Non vanno sottovalutati gli aspetti sociali (“mi posso esprimere a riguardo”, “posso rimanere in contatto grazie a”), che pesano il 27% . L’aspetto estetico pesa invece solo per un 8%. Sebbene questi valori siano simili per tutti i siti, nei siti di informazione, la cosa più importante è la facilità d’uso. Negli altri conta l’affidabilità: i problemi di usabilità, quindi, spesso non sono tecnici, ma di affidabilità.

Stefano Bussolon, A cognitive grammar to translate the UX research into requrements

Estremamente interessante e ad alto livello di astrazione è l’intervento di Stefano Bussolon [17] che propone un modo per tradurre i risultati dell’analisi della UX in un vero e proprio linguaggio.

La grammatica è un insieme di regole stabilite per un linguaggio naturale. Ma è anche vero che una grammatica formale può definire un linguaggio leggibile da una machina (linguaggi programmazione). La grammatica cognitiva implica una concettualizzazione.

Partendo dalla considerazione che le interfacce sono linguaggi, anche le interacce utente sono linguaggi. Si propone allora una traduzione di questo tipo: tradurre dal linguaggio naturale ai concetti e poi tradurre detta concettualizzazione alla interfaccia UX.

In quest’ottica, passando ai concetti:

• nome = concetto, categoria, istanza
• plurale = un insieme
• verbo = una funzione

Poi, passando da concetti a interfaccia:

• ontologia = nodo
• nome = pagine
• verbi = funzioni tipizzate semanticamente

Con questo tipo di approccio, si potrebbe arrivare alla definizione di un linguaggio obiect oriented, una sorta di OOUX. Un intervento suggestivo, i cui contorni sono tutti da perfezionari, ma potenzialmente molto importante.

Keynote finale

Stelio Verzera The near future of adaptive organisations: how you’re going to work tomorrow

Chiude la conferenza un talk che prova a “leggere il futuro” ma sulla base di dati molto concreti. Stelio Verzera [18] rompe il ghiaccio con il gioco dei dadi “ispiratori”: uno dei presenti viene invitato a lanciare dei dadi che riportano delle immagini sulle facce e a inventare una storia sulla base delle suggestioni ricevute dalle immagini uscite dal lancio. Lo scopo di tutto questo è quello di sottolineare il valore della creatività delle persone, anche se c’è la consapevolezza che le macchine saranno sempre più intelligenti nel futuro prossimo: il ciclo di hype di Gartner prevede che la scrittura di contenuti da parte di macchine possa arrivare per il 2018, che gli oggetti connessi sapranno chiedere assistenza e che agenti automatici sapranno fare trading coprendo il 5% delle transazioni entro il 2020.

C’è una dinamica del cambiamento dei sistemi umani: strumenti e processi cambiano molto più velocemente di competenze che, a loro volta, cambiano più velocemente di cultura e persone. Quindi, per “prevedere” il futuro non si deve guardare alle tecnologie, ma alle persone: le cose che verranno fuori tra vent’anni sono già presenti nelle persone, anche se non sono emerse.

La lezione che occorre accettare è la seguente

• la complessità è la realtà
• il lavoro non è un posto
• gli strumenti sono mezzi, non obiettivi

L’impostazione tayloristica ha cercato di ridurre la complessità del lavoro: per un secolo c’è riuscita, ma la complessità si è ripresa il suo posto nelle dinamiche.

Conclusioni

Abbiamo già fatto le nostre considerazioni generali nella prima parte dell’articolo e quindi resta ben poco da aggiungere. Non sappiamo quali ulteriori cambiamenti saranno eventualmente presenti nella prossima edizione, ma ci è parso che quelli riscontrati in questa edizione abbiano avuto il loro riscontro positivo.

Magari sarà il caso anche per noi di adottare gli adeguati cambiamenti di rotta e, con ogni probabilità, nella prossima edizione non seguiremo i talk ma tenteremo una full immersion nei workshop. E quindi, anche se manca quasi un anno, aspettiamo con interesse Better Software 2016.

Francesco Saliola

A MokaByte mi occupo dei processi legati alla gestione degli autori e della redazione degli articoli. Collateralmente, svolgo attività di consulenza e formazione nell‘ambito dell‘editoria "tradizionale" e digitale, della scrittura professionale e della comunicazione sulle diverse piattaforme.