Lasciate che vi faccia una domanda: Come product manager o scrum master, pensate che ci sia un punto di svolta in cui la coerenza diventa tirannia?

Ho posto questa domanda ad alcuni poveri ignari in alcuni recenti Meetup Agile e di prodotto qui nella zona di Raleigh. La mia ricompensa sono state numerose affermazioni che tali sciocchi folletti esistono.

Più recentemente, dopo aver pubblicato la mia domanda su una varietà di canali di social media, sono convinto che noi nel business della consegna del software a volte ci rendiamo davvero schiavi in nome della coerenza.

Perciò, spacchettiamo un po’ la questione e vediamo se possiamo essere d’accordo su come potrebbe essere questo punto di svolta …. esaminando prima cosa non è.

Consistenza saggia

Un esempio di coerenza benefica per i product manager è nel modo in cui creiamo le nostre user stories. Per esempio, mi piace seguire il principio INVESTIRE – NON come prescrizione standard – ma piuttosto come guida per assicurarmi che non sto chiedendo ai miei team di mangiare l’elefante intero in una singola storia utente.

Un altro esempio di buona coerenza viene dal mondo dell’UX, in particolare il sesto capitolo del seminale “The Design of Everyday Things” di Don Norman. Lì, Norman afferma che quelli di noi con esperienza di guida possono gestire una marca e un modello che non hanno mai usato prima grazie al posizionamento coerente di caratteristiche come il pedale del gas e gli specchietti laterali.

Steve Krug riprende questo esempio nel capitolo ‘Billboards Design 101’ del suo delizioso libro “Don’t Make Me Think”. Krug fa argomenti efficaci a favore del riconoscimento rispetto al richiamo, specialmente quando si tratta di trattamenti di gerarchie visive, collegamenti ipertestuali e layout di contenuto.

Tuttavia, Krug sostiene anche che ciò che vogliamo in definitiva è lottare per la chiarezza, con l’uso saggio della coerenza come mezzo efficace per arrivarci. Nello stesso capitolo offre anche questo avvertimento:

E infine, una parola sulla coerenza.

Si sente spesso citare la coerenza come un bene assoluto. La gente vince un sacco di discussioni sul design semplicemente dicendo “Non possiamo farlo. Non sarebbe coerente.”

La coerenza è sempre una buona cosa a cui tendere all’interno del vostro sito o app. Se la vostra navigazione è sempre nello stesso posto, per esempio, non devo pensarci o perdere tempo a cercarla. Ma ci saranno casi in cui le cose saranno più chiare se le rendete leggermente incoerenti.

Consistenza tirannica

La mia citazione di apertura viene da “Self-Reliance” di Emerson,”un saggio che argomenta in modo convincente la necessità di pensare con la propria testa, piuttosto che accettare un destino spesso associato a scogliere e lemming.

Come ho detto prima, ho posto la mia domanda di apertura in una varietà di canali sociali e Meetup. Qui sotto ci sono esempi che ho raccolto e che credo dimostrino una coerenza sciocca, se non tirannica:

• Uno scrum master che si arrabbia se uno sviluppatore non crea una storia JIRA per correggere un errore di battitura in un artefatto README.md.
• Un editore di un’organizzazione di notizie che insiste che l’app mobile nativa supporti esattamente le stesse 150 sezioni della loro soluzione desktop basata su browser per non confondere gli utenti.
• Un project manager che sostiene che la pianificazione delle capacità è il solo e unico vero modo per garantire che il cliente ottenga ciò per cui ha pagato, perché approcci più moderni alla consegna del software hanno troppe incertezze.
• Qualcuno dal campo chiede “Non c’è un modo per far allineare tutti i team di sviluppo su come dimensionano le storie?”
• Un architetto che sostiene il Big Design Up-Front di tutto per ogni scenario perché insiste che è l’unico modo per sapere cosa costruire per supportare un set di funzionalità.
• Un cliente che esige che i risultati forniti da una nuova infrastruttura di ricerca full-text basata su Lucene siano identici al 100% a quelli restituiti dall’implementazione del database NoSQL uscente.
• Un product manager che si rifiuta di accettare le user stories degli altri a meno che non siano formattate in modo impeccabile e completate in modo esaustivo usando un boilerplate TPS e il suo foglio di copertura.

Il risultato di tali scenari è la frustrazione macinante che i nostri team di sviluppo sopportano come una devozione servile alla coerenza … una priorità ben intenzionata ma sbagliata che ostacola notevolmente la loro capacità di scoprire e fornire rapidamente e continuamente le giuste caratteristiche di valore.

Saggezza aggiuntiva

Anche altri più intelligenti di me hanno messo in guardia da una sciocca sottomissione alla coerenza; qui sotto ci sono alcuni URL utili che ho visitato in preparazione di questo post.