Le tre parole più costose per ogni software: “lo sistemiamo dopo”

900 milioni di dollari per una schermata sbagliata

C’è una frase che chiunque lavori su un softwar ha sentito almeno una volta, quasi sempre pronunciata con le migliori intenzioni: «rilasciamo così, lo sistemiamo dopo».

Questo perché bisogna rispettare la data di rilascio, non bloccare il team e a consegnare al cliente quello che ha chiesto.

Il problema è che, nel momento in cui viene detta, nessuno sa quanto costerà quel “dopo“, né chi lo pagherà.

L’11 agosto 2020 Citibank doveva versare ai creditori di Revlon circa 7,8 milioni di dollari di interessi.

Ne ha versati quasi 900 milioni. Il software utilizzato, Flexcube, richiedeva di spuntare più checkbox in punti diversi della schermata affinché il capitale restasse su un conto interno. Un operatore e due revisori hanno controllato che il procedimento andasse a buon fine, approvandolo successivamente.

Eppure, tre professionisti esperti, un protocollo di verifica e sei occhi non sono bastati, perché la schermata mostrava solo campi compilati, tralasciando le conseguenze dell’operazione.

La banca ha impiegato più di due anni per recuperare circa 500 milioni che alcuni creditori si rifiutavano di restituire.

Ma quello che interessa a chi progetta software è un altro aspetto.

Un’interfaccia di questo tipo peggiora poco alla volta, un rilascio dopo l’altro, perché ogni volta che qualcosa non funziona bene, e si decide di sistemarlo più avanti, quel momento non arriva mai.

Citibank è un caso estremo ma il meccanismo è lo stesso che osserviamo nei software logistici, nelle console cloud e nei gestionali che ci viene chiesto di riprogettare: decisioni rimandate che, nel frattempo, sono diventate strutturali.

La tesi di questo articolo è precisa. Dire “lo sistemiamo dopo” non è sbagliato; è fuorviante quando viene applicato alle decisioni che dopo non si possono più cambiare, e quasi nessun sa come distinguerle.

Il Design Debt di cui si parla troppo poco

Il debito tecnico ha almeno un nome riconosciuto e, nei team più maturi, anche uno spazio dedicato nel backlog.

Solitamente, il deisgn debt nessuno lo segna e il suo costo si disperde in voci di spesa che sembrano non avere nulla a che fare con l’interfaccia. Per vederlo bisogna guardare in tre posti diversi, che di solito rispondono ai rispettivi responsabili.

Impatto sull’assistenza clienti

Quando un utente non capisce in quale stato si trova un ordine, o non trova un’azione perché esiste in tre sezioni con tre nomi differenti, apre un ticket.

I benchmark di MetricNet stimano in circa 22 dollari il costo medio di un ticket risolto al primo livello, che diventano 91 quando la richiesta deve passare al secondo.

Sono dati di help desk IT nordamericani, quindi vanno letti come ordine di grandezza e non come misura del supporto di un SaaS, ma rendono l’idea di cosa significhi un’ambiguità non risolta moltiplicata per migliaia di utenti.

Nei progetti che seguiamo il sintomo è quasi sempre lo stesso: il customer support diventa un’interfaccia umana che compensa le mancanze di UX dell’interfaccia del software.

Impatto sullo sviluppo software

Nel 2018 Stripe ha chiesto a quasi 1.500 sviluppatori e responsabili tecnici come impiegassero il proprio tempo: in media circa 17 ore a settimana se ne andavano in manutenzione, debugging e refactoring, e circa 4 nella correzione di codice scritto male.

È un dato che riguarda il debito tecnico in generale, non quello di design, anche se una parte di quel tempo ha un’origine legata al design stesso.

Quando manca un design system e un modello condiviso di come funziona il prodotto, ogni sviluppatore front-end prende decisioni di interfaccia dentro la propria pull request, e ogni scelta diventa un’incoerenza da sistemare più avanti.

Impatto sul reparto sales

Una survey di Gartner Digital Markets su oltre 3.400 acquirenti di software B2B, ha rilevato che il 60% si è pentito di un acquisto fatto negli ultimi 12-18 mesi, e che le implementazioni lente o complesse erano la causa più citata. Quasi un quarto ha cancellato il contratto, e un terzo ha cambiato fornitore.

Nel B2B chi compra raramente coincide con chi sfrutta il servizio: la demo convince il primo, l’acquirente, ma è il secondo a stabilire, mesi dopo, se il software verrà adottato davvero o se il lavoro continuerà su un foglio Excel parallelo.

Nessuna di queste voci, presa da sola, porta qualcuno a dire “abbiamo un problema di design”. Messe insieme, raccontano dove è finito il tempo risparmiato con il “lo sistemiamo dopo”.

Dove non c’è Design Thinking, il risultato è Frankenstein

Quando un software B2B diventa difficile da usare, la spiegazione più comune è che “è cresciuto troppo in fretta”.

È vera, in parte. Un prodotto diventa confuso perché le funzioni sono state aggiunte senza una struttura capace di accoglierle.

Un responsabile di prodotto, durante una call di discovery, ci ha descritto il processo con una sincerità rara: le nuove funzioni venivano inserite nel menu “in ordine cronologico, dove c’era spazio”.

Un altro ci ha raccontato che nel suo software la stessa azione si poteva avviare da punti diversi, ciascuno con una logica propria.

Nel 1968 Melvin Conway osservò che le organizzazioni tendono a progettare sistemi che riproducono la propria struttura di comunicazione.

Nel software di prodotto la legge di Conway si vede subito: quando funzioni diverse vengono sviluppate da team diversi, in momenti diversi, senza un modello comune, l’interfaccia diventa la mappa delle problematiche presenti.

La stessa entità, che sia una spedizione, un dispositivo o una pratica, compare in tre sezioni con tre nomi, attributi incoerenti e percorsi incompatibili.

L’Object-Oriented UX, il metodo sviluppato da Sophia Prater, parte proprio da qui.

Prima delle schermate si definiscono gli oggetti con cui le persone ragionano, le relazioni tra di essi, le azioni possibili su ciascuno e gli attributi che ne descrivono lo stato.

È un lavoro poco visibile, che non produce nulla da mostrare in una demo, ed è per questo che viene rimandato.

Il costo di quel rinvio si scopre dopo.

Correggere un software sbagliato sei mesi dopo il lancio non significa cambiare qualche dettaglio: significa rivedere le API, migrare i dati, riscrivere le integrazioni e rieducare utenti che nel frattempo hanno imparato a muoversi nel caos.

Cosa si può rimandare, e cosa no

Sarebbe facile concludere dicendo che bisogna progettare tutto prima di scrivere codice.

Sarebbe anche sbagliato.

Chi lavora su un prodotto in fase iniziale sa che rimandare è spesso la scelta giusta: quando non si sa ancora cosa costruire, rilasciare presto e imparare dagli utenti vale più di qualunque progetto perfetto “sulla carta”.

Il problema non è il rinvio in sé, ma il fatto che venga applicato con lo stesso criterio a decisioni di natura completamente diversa.

Due strumenti nati in contesti lontani dal design ci aiutano a risolvere questo problema:

• Quadrante del debito tecnico
• Il metodo Jeff Bezos

Quadrante del debito tecnico

Il primo è il quadrante del debito tecnico proposto da Martin Fowler, che distingue il debito deliberato da quello inavvertito e il debito prudente da quello spericolato.

Un MVP con un perimetro volutamente ridotto è debito prudente e deliberato: il team sa cosa sta rimandando e perché.

Rilasciare senza aver chiarito quali siano gli oggetti del dominio, ripetendosi che ci si penserà dopo, è debito spericolato, anche quando viene presentato come pragmatismo.

Il metodo Jeff Bezos

È la distinzione tra decisioni di Tipo 1 e di Tipo 2 che Jeff Bezos ha reso popolare nella lettera agli azionisti di Amazon del 2015.

Le prime sono porte a senso unico: una volta attraversate, tornare indietro è molto costoso o impossibile.

Le seconde sono porte girevoli, che si possono riaprire con poca spesa.

Il suo consiglio è semplice: prendere le decisioni di Tipo 2 in fretta, con poche persone, e dedicare tempo e attenzione solo a quelle di Tipo 1.

Applicata al prodotto, questa distinzione produce una mappa piuttosto chiara.

Decisione di prodotto	Tipo	Cosa succede se la rimandi	Cosa fare
Modello a oggetti del dominio (entità, relazioni, stati)	1, irreversibile	Nomi e comportamenti incoerenti tra le sezioni; correggerlo richiede di rivedere API, dati e integrazioni	Definirlo e validarlo con gli utenti prima dello sviluppo
Ruoli e permessi	1, irreversibile	La navigazione va ripensata a ogni nuovo ruolo; rischi nei controlli di accesso	Disegnare la matrice dei ruoli all’inizio, anche se i ruoli attivi sono pochi
Flussi transazionali e azioni irreversibili	1, irreversibile	Errori operativi con conseguenze economiche o legali, come nel caso Citibank	Conferme che mostrano le conseguenze, non solo i campi compilati
Fondamenta del design system (token di colore, spaziature, tipografia, componenti base)	1, irreversibile	Stili scritti a mano nel codice e refactor esteso a tutto il prodotto	Codificarle subito, anche in forma minima
Struttura della navigazione principale	1 nel tempo	Ogni modifica costa rieducazione degli utenti, che crescono di numero	Progettarla per accogliere le funzioni dei prossimi due anni
Micro-interazioni e animazioni	2, reversibile	Nessun impatto sulla logica del prodotto	Rilasciare con l’essenziale e rifinire dopo
Stati vuoti e messaggi secondari	2, reversibile	Attrito limitato a situazioni marginali	Partire con testi standard e arricchirli nei cicli successivi
Filtri avanzati e personalizzazione delle tabelle	2, reversibile	Nessuna modifica alla struttura dei dati	Partire con ordinamenti di base e aggiungere i filtri dopo il rilascio

La navigazione merita una nota: la reversibilità non dipende solo dal codice ma anche dalle persone. Una scelta che tecnicamente si cambia in un pomeriggio diventa irreversibile quando duemila operatori hanno imparato a usarla ogni giorno.

Più un software cresce, più decisioni passano dal Tipo 2 al Tipo 1 senza che nessuno se ne accorga, ed è questo il momento in cui il “lo sistemiamo dopo” smette di essere un rinvio e diventa una rinuncia.

Quattro domande da portare al prossimo sprint planning

“Lo sistemiamo dopo” non va eliminato dal vocabolario, va solo trasformato.

Le domande che seguono non richiedono strumenti particolari, solo l’abitudine di farle ad alta voce:

1. Tra 6 mesi questa scelta si potrà cambiare senza toccare dati, API o abitudini degli utenti? Se la risposta è no, non è una scelta da rimandare, anche se oggi sembra un dettaglio.
   
2. Chi pagherà il “dopo”? Il team di sviluppo, il supporto, il commerciale che dovrà evitare quella schermata in demo, o il cliente che dovrà formare i propri operatori.
   
3. Dove abbiamo scritto cosa stiamo rimandando, e quando lo riprenderemo? Il debito deliberato è sano solo se è registrato. Quello che non compare in nessun backlog smette di essere un rinvio e diventa una caratteristica del prodotto.
   
4. Quale numero ci dirà che il debito sta crescendo? I ticket del tipo “come faccio a fare…”, i tempi di onboarding dei nuovi clienti, le funzioni rilasciate e mai adottate. Sceglierne uno e guardarlo ogni mese costa pochissimo e anticipa di trimestri il momento in cui il problema diventa visibile a tutti.

Nei software complessi la qualità dell’esperienza non si aggiunge alla fine.

Si decide all’inizio, in poche scelte strutturali. Il vantaggio competitivo non sta nel non rimandare mai, ma nel sapere esattamente cosa si sta rimandando, e nel tenere fuori dal rinvio le poche decisioni che dopo non si possono più cambiare.

---

eyestudios è uno studio di Experience Design che lavora dove la complessità è reale: prodotti digitali articolati, organizzazioni con molti stakeholder, ecosistemi in trasformazione. Non ci fermiamo alla superficie: portiamo strategia, ricerca e metodo nei progetti che richiedono più di un buon wireframe.

Abbiamo lavorato con Unox, Aiko, Shampora, Deliveristo, Restworld, Ulixe Group, Confindustria, Flying Tiger, The North Face, Reply, Gruppo Hera, Alkemy, Mondo Convenienza, Verisure, Unipol, Almaviva, We Are Marketers, PhotoSì, ESA, Reale Mutua.