Architetti delle scelte.

Ci sono volte che ti senti addosso grandi responsabilità, capaci di bloccarti completamente quasi non ci fosse altra possibilità.

Progettare un software è questione complessa, che non attiene solo alla conoscenza dei linguaggi, del codice o dei sistemi macchina che garantiscano maggiori performance.

La programmazione di un software riguarda il comportamento delle persone che saranno chiamate ad utilizzare il programma che stai scrivendo.

Quando progetti un software non pensi a te, ma devi pretendere da te stesso di immaginarti nei panni dell’altro.
Il concetto di “architetti delle scelte” è un tema conosciuto e dibattuto da molti, non tanto come modello di organizzazione sociale, ma come responsabilità che comunque la vuoi mettere, ti assumi quando le tue decisioni influenzano l’agire degli altri. In sostanza non è questione di “se”, ma è questione legata al come e al quando sarai chiamato a fare scelte che influenzano anche la vita degli altri.
C’è un testo che tutti dovrebbero leggere, o almeno tutti coloro che fanno un lavoro le cui decisioni poi determinano il comportamento e le azioni di altri: “Nudge, la spinta gentile”.
Se non avete avuto modo di leggere il libro. C’è una pagina di Wikipedia che può essere un buon approfondimento sul tema.
Quando progettiamo un Software il tema della architettura è sempre presente con una serie di domande a cui è obbligatorio dare risposte, vediamole insieme:

Quali sono le impostazioni di default del programma.

Ogni programma nasce con uno scopo preciso, o almeno questo è come noi lo intendiamo. Il tema centrale è che questo scopo si realizza solo dopo aver compreso con precisione le necessità dell’impresa che dovrà utilizzarlo, solo dopo aver stabilito i criteri di usabilità, solo dopo avere creato uno schema preciso di tutte le correlazioni ad ogni singolo passaggio. Di fatto il software nasce per fare una cosa e farla in un determinato modo. La domanda è: “quanto lasciare alle libere scelte degli utilizzatori la possibilità di modificare questi processi?” La risposta è fondamentale, perché influenza tutto il processo di realizzazione e programmazione.

Quale controllo è necessario e quanta possibilità nella gestione del possibile errore dobbiamo considerare.

Quando usi un Software puoi sempre fare una cazzata (si può dire cazzata?). Evitare che questo possa essere un problema sembra facile: inserisci una serie di click di convalida e il gioco e fatto. Si, se vivessimo in un luogo meraviglioso in cui la fretta con ci guida, in cui il cosiddetto “errore da post-completamento” (che si verifica quando abbiamo svolto l’attività principale e tutto il resto perde di attenzione – come quando dimentichi il bancomat dopo aver prelevato – ) oppure dove l’eccesso di fiducia e ottimismo prevalga rispetto alla fatica (e difficoltà) nel fare continua verifiche e conferme del proprio operato. Per inciso, se continuate a chiedere ad una persona se è sicuro di quello che ha fatto, dopo i primi “si” continuerà a rispondere di “si”.
Il tema fondamentale che è la gestione dell’errore di manifesti come “una possibilità” in più offerta dal programma a chi lo utilizza, con un’attenzione: il programma è li per collaborare alla realizzazione di un protocollo, di conseguenza una gestione dell’errore bloccante non è una buona soluzione perché rende il software un nemico. Una cosa che possiamo provare anche tutti noi, nel quotidiano, quando un sistema di blocca per un errore, senza dirti che errore stai facendo, oppure quando i passaggi di verifica sono così lunghi (e banali) che vale la pena continuare (istericamente) a cliccare “ok” pur di andare avanti.

Quando semplificare non deve rendere facile un processo.

Semplice e facile non sono la stessa cosa, ne abbiamo ragionato qui. Quando realizzi un processo e lo rendi un software, il pericolo delle semplificazione come rinuncia a delle funzioni è sempre in presente. Qui ci aiuta, tantissimo, comprendere il “perché” abbiamo bisogno di un Software e concentrarci solo sulle componenti necessarie per fare in modo che il programma si occupi di risolvere i compiti per cui viene concepito. Ma, ed è importantissimo, dobbiamo sempre considerare il programma come uno strumento in mano alle persone per fare meglio quello che già fanno bene e non il loro sostituto. Quando consideriamo la persona che lavora come punto di partenza di ogni software, consideriamo anche le sue competenze, le sue abilità ed esperienze e possiamo concepire un programma come uno strumento per amplificarle. Ma quando il programma diventa centrale e l’uomo un accessorio, ragioniamo inevitabilmente che il tema centrale è rendere tutto più facile per dare a tutti la possibilità di usare quel programma. Un software costruisce la sua complessità a partire dal valore delle persona che lo utilizzano, anche se non è sempre facile ipotizzare il valore vero delle persone.

Produrre un software è un percorso verso un ignoto da illuminare con le risposte che sappiamo darci, non propriamente una passeggiata, ma all’arrivo si trovano sempre luoghi un po’ magici dove succedono cose che non ti aspettavi potessero accadere.