La cocciutaggine di una biglietteria automatica

L’usabilità del quotidiano è anche nelle piccole cose, che a volte hanno un impatto enorme.

Luisa Carrada

Gli farò un’offerta che non potrà rifiutare.

Don Vito Corleone

Non direi che la biglietteria automatica ATM abbia un impatto enorme sulla mia vita quotidiana, però quando mi sono scontrato con la sua cocciutaggine mi è venuto in mente il post L’usabilita delle piccole cose di Luisa Carrada.
Ho filmato il disinteresse di questo software per le mie scelte d’utente in un video di 28 secondi. Che lo vogliate o no, decidendo di acquistare un set di 10 biglietti e pagando con carta di credito non avrete scampo, riceverete un’offerta che non potrete rifiutare.

Software: “Desidera la ricevuta?”

Io: “NO”

Software: “Stampa ricevuta in corso …”.

Io: “…”

Un offerta che non potrà rifiutare from Gabriele Gigliotti on Vimeo.

Il fattore autobus, gli impiegati del catasto e i costi (esorbitanti) di una documentazione inesistente

Un indice di rischio del progetto molto singolare: il fattore autobus!
Foto di Allen Watkin distribuita con licenza Creative Commons.

Il fattore autobus di un gruppo di lavoro (team’s bus factor) è l’espressione utilizzata dai due autori di Team Geek1 – per esprimere il grado di rischiosità di un progetto prodotto dall’improvvisa assenza di uno o più componenti del gruppo di lavoro.

La definizione di questo indice di rischio è:

Il numero di persone (appartenenti allo stesso gruppo di lavoro) che è necessario siano investite da un autobus prima che il progetto possa dirsi spacciato.

Minore è questo numero, maggiore è la concentrazione di conoscenza su aspetti critici del progetto e maggiore ne è la sua rischiosità.

Uno dei modi per ridurre il rischio rappresentato dal fattore autobus è quello di produrre e mantenere in vita una sana documentazione (una parte della quale sarà utile anche nei successivi progetti, ad es. Lessons Report). Tuttavia mentre programmare è affascinante, sembra quasi un’arte, equivale a creare, scrivere documentazione è come ritrovarsi d’un tratto a fare l’impiegato del catasto: non rientra tra quelle attività che generano simpatia, tantomeno entusiasmo.

Non cercherò di convincervi con le parole, proverò con un’immagine.

Costo relativo della correzione di un difetto nelle varie fasi di sviluppo software.
Costo relativo della correzione di un difetto nelle varie fasi di sviluppo software.

Questo grafico a barre2 illustra il costo relativo necessario a correggere un difetto in base alla fase del ciclo di vita di un software in cui questo baco viene scoperto. Il costo aumenta in modo significativo tanto più ci ci avvicina al rilascio in produzione.
Una sana documentazione abbassa il rischio rappresentato dal fattore autobus perché aiuta a distribuire la conoscenza tra tutti i membri del gruppo di lavoro e permette di mantenere i costi sotto controllo. Forse produrre buona documentazione non sarà affascinante ma vi permetterà di avere ancora un progetto, sensato, su cui lavorare!


1. Fitzpatrick, Brian W., e Ben Collins-Sussman. Team Geek: A Software Developer’s Guide to Working Well with Others. O’Reilly Media, 2012.
2. Wiegers, Karl E. Software Requirements by Karl Wiegers 2nd ed. Microsoft Press, 2003