La concettualizzazione

Come vediamo il mondo

Se ti chiedessi di riassumere la tua giornata di ieri, cosa mi racconteresti?

Che sei andata a lavorare, che hai pranzato, che hai fatto l'aperitivo con gli amici. Oppure mille altre cose. Probabilmente mi racconteresti gli eventi della tua giornata, le attività che hai fatto.

Le persone percepiscono il mondo in forma di eventi (attività, esperienze), luoghi, agenti (persone), oggetti e altri concetti, più o meno astratti.

Gli ux designer progettano prodotti e servizi digitali. I prodotti digitali sono, in buona sostanza, delle rappresentazioni dinamiche di un dominio concettuale: gli eventi, le persone, gli oggetti, i concetti.

Pertanto, anche il lavoro degli sviluppatori è quello di usare linguaggi di programmazione, database, server, per implementare le rappresentazioni dinamiche, digitali, del dominio.

Perché sì, un software fatto bene è una rappresentazione dinamica di un micro mondo. E perché sia fatto bene deve rispettare alcuni requisiti non funzionali. Non deve andare in crash, deve essere veloce, non deve usare troppe risorse hardware. Insomma, deve adattarsi all'hardware e al software su cui gira.

Ma soprattutto la rappresentazione deve riflettere il mondo rappresentato, e corrispondere alla rappresentazione che le persone hanno di quel mondo.
Un software ha dunque tre ordini di vincoli da rispettare:

• il dominio rappresentato
• la rappresentazione che le persone hanno di quel dominio
• l'infrastruttura tecnologica su cui "gira" la rappresentazione dinamica

Sviluppatori e rappresentazioni

L'idea che gli sviluppatori creino rappresentazioni può sembrare insolita, ma non è affatto nuova.

In un articolo del 1985 Peter Naur, un signore che ha vinto il premio Turing, sosteneva che il lavoro dei programmatori non consiste tanto nel creare codice, quanto nello sviluppare delle teorie del mondo che si intende rappresentare:

What I am concerned with is the activity of matching some significant part and aspect of an activity in the real world to the formal symbol manipulation that can be done by a program running on a computer

L'articolo di Naur ha avuto un impatto piuttosto forte soprattutto nella comunità agile. Alistair Cockburn l'ha riportato nel suo libro Agile Software Development, e Dave West l'ha citato in un post:

Theory building, ala Naur, is the individual and collective effort to:

• Understand the World
• Understand how the software is shaped by the World and how it will integrate with that World
• Understand the essence of the software and how best to articulate (code) that essence
• Understand if you have gotten the first three understandings right.

Una prospettiva simile è sostenuta da questo articolo: How to Build Good Software

Agile e user stories

Paradossalmente, però, l'approccio agile prevede due soli mezzi per rappresentazione la conoscenza da implementare: il codice / software stesso, e le user stories. Tutto il resto rimane - implicito - nella testa di sviluppatori, scrum master e product owner. L'assunto è che, prima di scrivere codice, il mondo da rappresentare possa essere sintetizzato in un elenco di storie (la backlog).
Questo è - secondo me e secondo Dario Betti - uno dei tre problemi del metodo agile - gli altri due li ho affrontati nel post Ux e Agile. Dario ed io siamo convinti che un buon lavoro di concettualizzazione sia fondamentale.

User stories e concettualizzazione: un esempio

Per capire perché, in pratica, la concettualizzazione sia importante, può essere utile fare un esempio.

Prenderò spunto dal documento Example User Stories (pdf), che è uno degli esempi più noti di un backlog di user story: si riferisce al backlog delle storie scritte nel 2004 per sviluppare il sito scrumalliance.org.

Analizziamo alcune storie. Una di queste recita:

As a trainer, I want my profile to list my upcoming classes and include a link to a detailed page about each so that prospective attendees can find my courses

Ok, la storia è chiara: sono un formatore, nel mio profilo voglio che ci sia l'elenco delle mie classi e dei miei corsi.
Ma che cos'è una classe, cos'è un corso? Nella storia non si dice. Lo si evince, in parte, in un'altra storia:

As a trainer, I can create a new course or event, so site visitors can see it. Note: This includes the following information: name, description (HTML), trainer names (multiple selection from a list), start date, end date, venue name (HTML) and address, contact name, contact phone, contact email, a link for more information, and a link to register. For a certification course the name of the class is a dropdown list; for others, it is free text.

In questa storia si trova una descrizione implicita di cos'è un corso (o una classe?). Un corso è un evento con un titolo (name), una descrizione. È tenuto da dei docenti (i trainer), ha una data di inizio, una data di fine, un luogo. Si parla poi di contatti (nome, mail, telefono), un link a ulteriori informazioni, un link per registrarsi.

In altre storie si dice che il formatore può aggiornare le informazioni di un corso, cancellarlo, può copiare un corso in un nuovo corso simile. Vi sono storie in cui un site visitor può visualizzare i corsi. Per capire cosa andrà messo nelle pagine di modifica, di visualizzazione, sarà necessario pescare le informazioni dalla user story della creazione del corso.

Vediamo un altro esempio. Nella sezione Buying courses la prima storia recita:

As a trainer, I can set the prices for my course so that I can make filthy lucre.

Questo lascia supporre che per partecipare ai corsi bisogna pagare. Ma il costo è un attributo dei corsi?

Ambiguità semantica

Chiunque faccia formazione sa che - se prepara un corso, spera di replicarlo in circostanze diverse. Immaginiamo un cuoco che voglia fare due corsi: uno sulla preparazione dei dolci, ed uno sugli antipasti. Preparerà un programma dettagliato per ognuno dei due corsi, e poi proporrà i suoi corsi a potenziali utenti. Ovvero, organizzerà delle classi. Semanticamente - almeno in italiano - c'è una ambiguità, perché spesso chiamiamo corso sia l'argomento ("Preparazione dei dolci") sia la classe: "iscriviti al corso Preparazione dei dolci che si terrà il 15 settembre a Perugia".

Concettualmente, però, sono due cose diverse.

• Il corso ha un titolo, delle finalità, un programma, magari dei metodi di valutazione dell'apprendimento, probabilmente un prezzo di riferimento, uno o più docenti, un monte orario.
• La classe è una edizione di un corso. Avrà una data di inizio, una data di fine, degli orari, una sede. La classe avrà un numero di posti, che potranno essere prenotati.

Perché è importante distinguere i due concetti? I motivi sono molteplici:

• in primo luogo, perché sono due cose diverse, mappare correttamente le cose è importante, e non farlo porta a conseguenze negative

• l'utente può navigare il catalogo dei corsi, senza vedere doppioni; una volta identificato il corso (l'argomento) di interesse, potrà visualizzare l'elenco delle classi attive (i luoghi, le date, i posti disponibili);

• alcuni corsi possono essere organizzati in-house, nella sede di una azienda che lo richieda, concordando la data; ovvero, è possibile concordare una classe di un corso con un cliente;

• se il sito presenta il catalogo dei corsi, anche di quelli senza classi pianificate, si può offrire all'utente la possibilità di esprimere l'interesse per dei corsi non ancora pianificati;

• la creazione di una nuova classe di un corso non avviene copiando un corso esistente, come recita questa storia:

  As a trainer, I can copy one of my courses or events so that I can create a new one. When copying it I am asked for the date(s) of the new course or event.

  Non so a te, ma a me una soluzione del genere fa rabbrividire. La creazione di una classe dovrebbe avvenire attraverso una funzione add class del corso.

Questo processo di concettualizzazione dovrebbe avvenire per tutti i concetti (classe, corso, posto, sede ...), per i diversi ruoli del servizio (amministratore, trainer, visitatore del sito, partecipante al corso ...) e per le attività: non dobbiamo dimenticarci che questo dominio è finalizzato a permettere ai partecipanti di seguire i corsi (pagando) e ai docenti di tenere i corsi (per essere pagati). E dunque vale la pena mappare anche le attività principali: teach class e attend class.

Mappare i ruoli è utile anche perché, sia per il partecipante che per il trainer, sono previste delle pagine di profilo. Alcuni degli attributi e degli elementi saranno gli stessi, altri saranno diversi. Il trainer avrà l'elenco dei corsi che tiene e delle prossime classi in calendario, il partecipante avrà l'elenco dei corsi che ha frequentato.

Prendiamo un'altra storia:

As a site member, I can search for profiles based on a few fields (class attended, location, name) so I can find others I might want to connect with.

Questo significa che nei profili personali dev'essere possibile riportare la location. Il problema è che il termine location, nel backlog, è citato solo in questa storia. Dunque, per capire quali sono gli attributi che devo inserire nel profilo delle persone, devo andarmi a scandagliare tutta una serie di storie.

La concettualizzazione

A partire da queste riflessioni, ho creato una mappa mentale dei principali concetti implicitamente descritti nel backlog di esempio.
Questa mappa è il frutto di poche ore di lavoro. Una vera concettualizzazione dovrebbe essere più completa, più dettagliata, e descrivere non soltanto gli agenti (amministratore, formatore, partecipante) e gli oggetti (corso, classe, posto, sede) ma anche le attività: insegnare in una classe, partecipare ad una classe, e così via.

L'immagine seguente mostra un grafo di una concettualizzazione che feci per un progetto reale. Per ovvi motivi di non disclosure agreement ho reso i contenuti illeggibili, ma credo sia evidente la ricchezza e la complessità del dominio.

Questa mappa - ed i documenti ad essa legati - sono il frutto di molte giornate di lavoro, finalizzate a rendere esplicita la ricca conoscenza - prevalentemente implicita - degli esperti di dominio. Dunque, è un investimento importante. Ma non farlo significherebbe non capire il dominio e la sua complessità, e svilupparne una rappresentazione molto più approsimativa.

Concettualizzazione e user story

La concettualizzazione può essere un ottimo punto di partenza per costruire le user story, che risulterebbero più sintetiche e più strutturate. Ad esempio:

As a trainer I can create, update and even delete my personal profile.

Cosa ci andrà nel profilo lo si evince dalla concettualizzazione.

As a site visitor i can view the profile of the trainers.
As a trainer i can print my profile.
As a trainer i can share my profile (on the social meda).

Cosa ci andrà nel profilo del trainer? Lo si evince dalla concettualizzazione.

I verbi dell'interaction design

Nel backlog di esempio, le azioni che i vari ruoli possono fare sono, principalmente: crare, modificare, cancellare, visualizzare, cercare, aggiungere al carrello e acquistare, compilare ("I can fill out an application"), scrivere degli articoli, comunicare, gestire, approvare / non approvare, leggere, sottoscrivere. Sono quelli che io ho definito i verbi dell'interaction design. Questa ventina di verbi copre buona parte delle azioni che generalmente un utente può voler fare. Incrociare concetti con verbi può essere un modo per generare le storie:

as a [actor] i can [create|update|read|write|print|share ...] the [profile|course|class|location ...]

Questo template probabilmente copre l'80% delle combinazioni che possiamo immaginare.

Conclusioni

In questo post sostengo che progettare ed implementare prodotti e servizi digitali significa creare delle rappresentazioni dinamiche di un dominio, che devono rispecchiare il dominio ed i modelli mentali - o, più correttamente, i modelli concettuali - di esperti ed utenti finali.

Far emergere e rendere espliciti i modelli concettuali e la struttura del dominio è un passaggio importante, soprattutto se il dominio è complesso. È un investimento di tempo e di risorse, a volte non trascurabile, ma che permette - a designer, sviluppatori e stakeholder - di avere un quadro molto più chiaro del dominio, di generare delle storie più sintetiche ed in maniera più sistematica e di creare, in ultima istanza, dei prodotti e servizi digitali che meglio corrispondono ai modelli concettuali degli utenti e rispondono alle loro esigenze.

Link utili

Le slide del nostro talk al Wiad Vicenza 2020: Sugli alberi le foglie: concetti e user stories.