Cose che continuo a imparare osservando i sistemi.
Non considero questi principi delle regole.
Sono idee che continuano a tornare.
Le ho imparate progettando sistemi diversi, in contesti molto diversi.
Alcune potrebbero cambiare.
Altre mi accompagnano da anni.
Quasi tutte sono nate da un’osservazione, prima ancora che da una soluzione.
1. Ogni informazione ha bisogno di una casa.
Prima ancora di chiedermi come automatizzare un processo, cerco di capire dove nascono davvero le informazioni.
Molti sistemi non sono inefficienti perché utilizzano gli strumenti sbagliati.
Lo diventano quando la stessa informazione viene riscritta, copiata e aggiornata in luoghi diversi.
Email.
Fogli sparsi.
Documenti.
Post-it.
Messaggi.
Il problema raramente è la tecnologia.
È la frammentazione.
Il primo passo non è scrivere codice.
È dare alle informazioni un luogo in cui vivere.
Solo dopo diventa naturale trasformarle in pagine web, cataloghi, QR code, PDF, report o qualsiasi altra destinazione.
Ogni informazione dovrebbe avere una sola casa.
2. La tecnologia dovrebbe adattarsi alle persone.
Quando un nuovo sistema costringe tutti a cambiare radicalmente il proprio modo di lavorare, mi domando se sia davvero un buon sistema.
Preferisco partire dalle abitudini che già funzionano.
Se chi gestisce un catalogo lavora da anni su un foglio di calcolo, forse è quello il posto giusto da cui far nascere tutto il resto.
Le persone non dovrebbero imparare uno strumento nuovo solo perché esiste.
La tecnologia dovrebbe adattarsi alle persone.
Non il contrario.
Il miglior software è quello di cui ci si dimentica.
3. I buoni sistemi lasciano porte aperte.
Una delle frasi che sento più spesso è:
“Tanto questa cosa non succederà mai.”
Oppure:
“Avremo al massimo tre utenti.”
Le ipotesi sono utili per iniziare.
Diventano pericolose quando si trasformano in regole.
Preferisco progettare sistemi che rimangano flessibili anche quando il contesto cambia.
Non perché voglia prevedere ogni scenario.
Perché so che gli scenari cambiano sempre.
È lo stesso motivo per cui gli ecosistemi più resilienti non sono quelli perfettamente ottimizzati per una sola condizione.
Sono quelli capaci di adattarsi.
Le ipotesi invecchiano. I buoni principi molto più lentamente.
4. La semplicità è una forma di sostenibilità.
Per me la semplicità non è minimalismo.
È eliminazione dello spreco.
Ogni passaggio inutile consuma tempo.
Ogni informazione duplicata richiede manutenzione.
Ogni eccezione aggiunta senza una vera necessità aumenta la complessità futura.
Negli ecosistemi naturali l’energia viene utilizzata con estrema economia.
Mi piace pensare che anche un buon sistema informativo dovrebbe fare lo stesso.
L’efficienza non significa fare di più. Significa ottenere lo stesso risultato con meno attrito.
5. Riutilizzare è spesso più creativo che sostituire.
Quando posso evitare di sostituire qualcosa che funziona, lo faccio.
Vale per i materiali.
Vale per le idee.
Vale anche per il software.
Costruire uno strumento nuovo è spesso la soluzione più evidente.
Far collaborare bene quelli esistenti richiede più osservazione, più creatività e, quasi sempre, produce sistemi migliori.
Il riuso non è un compromesso. È una scelta progettuale.
6. Mi piacciono le orchestre.
Amo la musica.
Forse per questo continuo a vedere orchestre ovunque.
Ogni strumento ha caratteristiche diverse.
Nessuno è sufficiente da solo.
Google Sheets.
CSV.
WordPress.
Python.
Mapbox.
API.
Per me non sono tecnologie.
Sono strumenti musicali.
La parte interessante non è scegliere il migliore.
È trovare il modo di farli suonare insieme.
I ponti sono spesso più importanti degli strumenti che collegano.
7. La curiosità è un punto di partenza migliore dei requisiti.
Molti dei progetti che ricordo con più piacere non sono nati da una richiesta.
Sono nati da una domanda.
“Possibile che non esista un modo migliore?”
Questa domanda continua a seguirmi anche lontano dal computer.
Mentre cammino.
Mentre nuoto.
Ascoltando musica.
Leggendo.
Per me progettare ha molto in comune con costruire con i LEGO o risolvere un buon enigma.
Le risposte migliori iniziano quasi sempre da una buona domanda.
8. Un buon sistema dovrebbe sopravvivere a chi lo ha progettato.
Un buon sistema non dovrebbe funzionare solo finché è presente chi lo ha costruito.
Dovrebbe continuare a essere comprensibile, modificabile ed evolvere anche quando cambiano le persone.
Per questo preferisco strutture modulari.
Sorgenti dati semplici.
Regole generali.
Poche dipendenze.
Più autonomia.
L’obiettivo non è rendersi indispensabili.
È rendere il sistema indipendente.
Se un sistema dipende da una persona, non è ancora finito.