E così capita che la nostra macchinetta Nespresso smette di forare le cialde nel bel mezzo della giornata lavorativa. Prova, riprova ma niente da fare. Non ne vuole più sapere. Interviene il CEO che era in coda anche lui per prendere il caffé e dopo l’ultimo tentativo dichiara: “Ok! È rotta!”. Con risolutezza si avvia verso il suo ufficio, apre l’anta di un mobiletto, ci entra dentro con testa e spalle, sposta un paio di scatole e tira fuori una Nespresso nuova di pacca che nessuno sapeva ci fosse: “Ecco qua! Avanti coi caffè!”
Mai lasciare i programmatori senza lo strumento di produttività numero uno!
Lì! Clicca lì! No, più a destra… più a destra… Clicca sul pulsante di scelta… Il pallino vuoto… (Pianta il dito sullo schermo) Ecco, qui devi cliccare.
Il miglior modo per sapere come pensa un utente è osservarlo. Chiedete a un utente di svolgere un compito “della vita reale” su un pezzo di software che state sviluppando, prendete i pop-corn, osservate e godetevi la scena.
È uno spettacolo perché nel giro di pochi secondi verranno smontate le vostre ipotesi di partenza con cui avete progettato l’UI.
Utente prende posto nella postazione a appoggia la mano sul mouse. Fissa lo schermo per qualche secondo come chiedendosi che roba è mai questa?
Utente che usa il vostro programma per la prima volta
Legge qualche parola qua e là e poi proverà a fare ciò che gli avete chiesto. A questo punto vi state già accorgendo che Utente sta usando il programma in modo decisamente diverso da come l’avete immaginato. Crescerà in voi una fortissima tentazione di correggerlo, di guidarlo: la sofferenza che provate nel vedere che un’operazione da cinque secondi, per voi che avete sviluppato il programma, ci sta impiegando quasi mezzo minuto è insopportabile. Ecco allora che intervenite e dite qualcosa tipo la frase di apertura del post.
Quando Utente si bloccherà la prossima volta, sperando che non sia per un bug, usate le mani per prendere i pop-corn dal secchio che avete predisposto prima e riempitevi la bocca per non parlare. Probabilmente noterete che il suo sguardo si concentrerà sul punto dove è rimasto bloccato, senza andare a cercare aiuti in altri parti dell’interfaccia. Questa è una ragione del perché i menù di aiuto sono una scelta poco efficace. Le istruzioni di aiuto/messaggi di errore dovrebbero essere posizionati il più vicino possibile alla zona interessata dal problema.
Messaggio di aiuto ben posizionato.
Gli utenti usano il software intuitivamente, senza ragionare nel dettaglio. Trovano un modo che funziona per fare una cosa, anche se improprio, e poi la faranno sempre così. È meglio fornire un solo modo per fare un’operazione: il più ovvio possibile.
Tutto ciò accade perché gli utenti non passano tutto il tempo che passiamo noi al computer e, se lo fanno, è per scopi completamente diversi dai nostri. Noi usiamo il computer per il gusto di farlo: con talmente tanto gusto che il nostro mestiere che ci siamo liberamente scelti è far fare al computer ciò che vogliamo, plasmarlo al nostro volere, dominarlo. Un impiegato in ufficio invece subisce l’uso del computer: il suo lavoro è fatturare, inviare ordini ai fornitori, spostare materiale in un magazzino. Magari il computer anche lo odia, ha problemi di vista e soprattutto ragiona con schemi mentali completamente diversi da quelli che noi programmatori usiamo mille volte al giorno.
Quella roba l’ha scritta Giovanni, io non la tocco! Problema suo!
Pranzando con altre persone del settore IT di altre aziende spesso sento dei “capi programmatori” che si lamentano dei loro sottoposti perché si concentrano solo sulla loro parte di codice e quando vedono errori di altri sono pronti a puntare il dito.
Non conosco nel dettaglio come mai succedano queste dinamiche in alcuni gruppi di lavoro; tuttavia penso che siano sintomo di una errata gestione delle persone, di scarsa stima e rispetto reciproco.
Credo che dovremmo aver un rispetto inteso in senso lato del codice su cui lavoriamo: per noi stessi e per i nostri compagni di team. Tutti sappiamo quanto facile sia commettere errori. In teoria potremmo, per esempio, impegnarci per lasciare il sorgente sempre un po’ migliore di come lo abbiamo trovato, prima di eseguire git push.
Cosa succederebbe se seguissimo questa semplice regola? Cosa succederebbe se ci impegnassimo a migliorare il codice, anche di poco, indipendentemente da chi sia stato l’autore originale?
Io penso che porterebbe a un sistema poco a poco sempre migliore, porterebbe a creare un intero team che ha a cuore il sorgente nella sua completezza invece di individui che tengono solamente alla loro piccola fetta…
Prendersi cura del proprio codice è un discorso. Invece, i membri di un team coeso si aiutano e si correggono a vicenda.
P.S.: A proposito di git push, un collega ha appeso questa sulla nostra lavagna
Il club delle 6 