Come prendere decisioni efficaci confrontando le alternative

Foto di rawpixel su Unsplash

Non meglio, non peggio ... solo diverso

"React.js è molto meglio di Angular". "Java fa schifo, nessuno lo usa più ... dovremmo usare Golang". "L'ananas è il condimento per pizza peggiore". Probabilmente hai sentito una di queste opinioni molto chiare. Un'opzione è la migliore, l'altra è la peggiore, X è migliore di Y e così via. Ma Java è ancora una delle lingue più popolari al mondo. Angular dà una lotta decente a React.js. Pizza con ananas ... beh, questo è Ewwww.

Ciò significa che più della metà delle persone sono all'oscuro? O non sai come capire quale tecnologia è migliore o fare le scelte giuste? Forse dovremmo smettere di usare termini come "migliore", "peggiore", "migliore" e confronti superficiali quando si valutano le alternative. Dovremmo invece concentrarci sui vantaggi di ciascuna soluzione, sugli svantaggi e su quale sia la soluzione migliore per il nostro problema specifico.

Alternative di valutazione

Un modo per farlo è creare una tabella di confronto delle alternative:

  • Scrivi le diverse alternative nell'intestazione. Utilizzare ciascuna colonna per valutare un'alternativa. Scegli 2–5 alternative.
  • Scrivi le diverse proprietà che ritieni siano importanti per valutare le diverse alternative. Scegli 2–5 proprietà di confronto più importanti.
  • Mantieni l'ultima riga per riassumere. Non esiste una soluzione migliore / peggiore, concentrati sul perché ogni alternativa risolve il problema.

"Cosa dovresti credere per scegliere questo approccio?"

Ad esempio, supponiamo che abbiamo un problema che può essere risolto in due modi. Uno è S.O.L.I.D e l'altro è hacker. Qualcuno potrebbe dire che dovremmo sempre usare una soluzione S.O.L.I.D, indipendentemente dalle circostanze. Ciò significa che chiunque usi il codice hacky è un cattivo sviluppatore? Ne dubito.

Mettiamo le alternative in una tabella:

Dopo aver composto questo tavolo, possiamo concentrarci sulla linea di fondo e legarla direttamente al nostro obiettivo.

Un esempio di "spedizione il più veloce possibile e siamo d'accordo con la compromissione della qualità futura" potrebbe essere:

  • Un grave bug che esiste nel sistema. Ogni giorno che passa senza una soluzione può causare danni a lungo termine.
  • Abbiamo un contratto con un cliente per spedire la soluzione in una data specifica. Se perdiamo la scadenza, potrebbero esserci conseguenze legali.
  • La società ha problemi di flusso di cassa. La spedizione anticipata della soluzione può avere un impatto enorme sulla stabilità del nostro business.

Come puoi vedere, usare S.O.L.I.D non è sempre l'approccio migliore. Se ci preoccupiamo della qualità del codice, dovremmo sicuramente impostarla di default, ma dobbiamo assicurarci di conoscere i compromessi. Scegli una soluzione rispetto all'altra perché ritieni che questo sia il percorso migliore per raggiungere i tuoi obiettivi. Non farlo solo perché lo zio Bob o qualcuno nella tua azienda ha detto che è meglio.

Non fare recensioni solo per ottenere il "timbro"

Foto di Hello Lightbulb su Unsplash

In molte aziende, le recensioni (recensioni di design, recensioni di prodotti, ecc.) Hanno lo stesso rituale. Il proprietario della funzione scrive le specifiche. Il loro manager quindi lo esamina. Il gruppo pianifica una riunione per rivedere le specifiche. Più di una volta, si ha la sensazione che lo scopo di questi incontri sia quello di ottenere il marchio dagli stakeholder piuttosto che impegnarsi in una discussione aperta. I motivi per cui ciò può accadere:

  • Se hai già una specifica pronta, perché dovresti aver bisogno di circa 7 persone per riunirsi in una stanza e "ripassarla"?
  • Le riunioni tendono ad essere noiose e possono diventare monologhi quando il proprietario della funzione legge le specifiche che ha scritto.
  • A volte questi incontri tendono ad essere pignoli. La conversazione può concentrarsi su cose che non sono cruciali per il successo della funzione ("perché usiamo int32 e non int16?", "Stringhe o enumerazioni?", "Tab o spazi?").
  • Alcune persone sono più introverse di altre. Vengono ascoltate tutte le voci o ci sono solo poche persone coinvolte nella conversazione?
  • La conversazione su alcuni dettagli può richiedere più tempo del previsto. Il tempo quindi scade prima che il proprietario della funzione possa coprire l'intera specifica, a volte anche meno della metà. Questo può essere frustrante. Inoltre, se è necessaria una riunione di follow-up, può anche posticipare il processo decisionale e l'intero calendario del progetto.

Sii preparato con alternative e obiettivi, non con la soluzione

Nella mia azienda attuale, adottiamo un approccio diverso. Le recensioni vengono fatte offline, usando Paper (beneficiando delle sue funzionalità come condivisione, commenti, attività che rendono la collaborazione più efficiente). Qualsiasi altro editor online può funzionare.

Per le riunioni di progettazione, utilizziamo un modello diverso. Il decisore sceglie le 3-4 domande aperte più importanti che sono fondamentali per il successo della funzione. Quindi compongono una tabella alternativa come abbiamo visto prima. Possono anche raccomandare un'alternativa, ma non dovrebbero essere molto supponente al riguardo. Lo scopo dell'incontro è scegliere l'approccio corretto in base agli obiettivi del progetto.

L'incontro passa quindi da un monologo incentrato sul "timbrare" una soluzione per una conversazione aperta sull'approccio migliore. Il pubblico si trasforma da approvatore a consigliere. Il proprietario della funzione non ha bisogno di "difendere" la soluzione selezionata. Si trasforma in un decisore che basa la loro soluzione sulla consulenza degli stakeholder. Impostando il tempo (10–15 min) per ogni domanda, puoi assicurarti di coprire tutte le domande aperte. Il proprietario della funzione decide quando il tempo è scaduto.

Accertarsi che la voce di tutti sia ascoltata, anche gli introversi, è facile come "Ehi Jane, non abbiamo sentito la tua opinione, quale opzione ritieni possa servire ai nostri obiettivi? X, Y o Z? "

Quindi la prossima volta che vuoi confrontare due o più alternative, sostituisci "React.js è meglio di Angular" con "React.js è più facile da imparare, più flessibile e viene aggiornato più frequentemente, quindi se miriamo a accelerare rapidamente nuove ingegneri e muoversi più velocemente con le tecnologie più all'avanguardia, questa dovrebbe essere la nostra scelta tra questi due ”.

Per quanto riguarda "L'ananas è il peggior condimento per la pizza", forse alcune cose non sono pensate per avere alternative.

Grazie per aver speso 4 minuti del tuo tempo, fino alla prossima volta.

-Alon

Ringraziamenti speciali a:

  • Eric Suh che ha guidato la creazione del processo di revisione ingegneristica presso Dropbox
  • Pierpaolo Baccichet, Steve Eisner, Gal Zellermayer, James Cowling e Devdatta Akhawe hanno tutti fornito un prezioso feedback, sia come primi tester del processo che come revisori
  • Rina Artstain & Keren per la correzione di bozze, la revisione di questo articolo e il feedback tecnico eccezionale