Fermare discussioni tecniche infinite e prendere una decisione

Mi capita sempre di incontrare persone a cui piace resistere da anni alle più piccole "cose ​​tecniche".

Non fraintendetemi, sono un programmatore geek che ama quello che faccio, ma conosci il tipo di conversazione.

• Il Mac è molto meglio di Windows
• Non utilizzare un ciclo For Each, utilizzare un ciclo While
• Non acquistare un PC basato su Intel, prendine uno basato su AMD.
• Dovremmo usare un contenitore IoC su un altro.

Tutte queste "cose" hanno pro e contro validi per entrambe le parti e non otterrai mai una risposta "corretta" e la persona non concederà mai il punto. (ovviamente ce ne saranno alcuni in cui c'è una risposta, forse :).

La mia domanda (ci sto arrivando !!) è: in un team di software, come riesci a superare queste lunghe discussioni senza inibire l'innovazione, in modo che una decisione possa essere presa e tu possa continuare a risolvere i veri problemi di business.

Problema 1. Ad alcune persone non piace perdere. Se non chiamano i colpi, discuteranno fino a quando non chiameranno i colpi per logoramento.

Problema 2. Non è in gioco nulla, quindi è tollerato il dibattito.

Non è in gioco niente? Sì. La maggior parte delle decisioni ha un impatto quasi nullo. Il fatto che si tratti di "resistere per secoli" significa che entrambe le scelte sono effettivamente identiche.

Cosa fare?

1. Renditi conto che non è in gioco nulla.

2. Renditi conto che tra 2 o 3 anni, l'intera materia verrà riaperta perché qualcosa al di fuori dell'organizzazione è cambiato.

3. Lancia una moneta. Sul serio. Scegli qualcosa e vai avanti. Alcune persone vedranno la stupidità nei dibattiti. Alcune persone discuteranno quindi della natura della moneta lanciata. Se la gente non può essere soddisfatta del lancio di una moneta, ha problemi di ego e deve imparare che (a) non è in gioco nulla e (b) la decisione cambierà tra qualche anno.

Se non riescono a capire che non è in gioco nulla, devono scrivere il valore in dollari di entrambe le parti dell'argomento. Ad un certo punto, qualcuno potrebbe vedere che vengono trascorse più ore-uomo in analisi di quanto valga la decisione effettiva. Un lancio di monete produce lo stesso valore per un costo inferiore.

Un paio di cose da considerare:

1. Accetta solo argomenti quantificabili. Se qualcuno dice che farà risparmiare tempo, chiedigli di quantificarlo e di tenerlo alla risposta. In questo modo, se parlano di immondizia, ci provano solo prima che tutti sappiano che sono a livello.

2. Chiedi alle persone di assumersi la responsabilità delle loro raccomandazioni. Metti in chiaro che alla fine dell'anno se hanno fatto delle cattive telefonate faranno parte della loro valutazione. Non mi occupo dei dibattiti, ma voglio che le persone abbiano il coraggio delle loro convinzioni: se hai intenzione di giurare che qualcosa di eccezionale è e ti aspetti che lo adottiamo, è meglio che tu riesca a convivere con le conseguenze.

Queste sono cose reali per allontanarsi dai due problemi di S.Lott: che ad alcune persone non piace perdere e che non è in gioco nulla. La mia risposta è messa in gioco, quindi non c'è dibattito per il bene del dibattito.

1. Timebox la discussione. - Se ci vogliono più di 5 minuti per ciascuna parte per dichiarare il loro caso, allora è troppo complesso. Per questo usiamo i timer da cucina . Funzionano meravigliosamente e costano circa 5 dollari.
2. Richiedere ai partecipanti di discutere con dati ed esperienza.
3. Manteniamo le opzioni sul tavolo. Dopo che ciascuna parte ha il suo tempo, passiamo altri 5 minuti a discutere le implicazioni di ciascun approccio. Dopo 20 minuti, usciamo e lo facciamo (implementandolo). Se non funziona, andiamo con l'altro approccio.

La regola è semplice Una volta che non sai cosa scegliere, pensa a cosa è meglio per l'azienda.

Sì, la scelta Intel v AMD non è così semplice. Ma quale è meglio per la tua azienda? Ad esempio, se c'è una persona che è responsabile per l'ordinazione di roba e gli ci vorranno anni per ordinare un PC basato su processore AMD, ma Intel può essere ordinato in un minuto e davvero non ti importa cosa sarà - basta ordinarne uno basato su Intel perché è meglio per l'azienda.

Di solito queste discussioni sono davvero solo in bikini . Persone che discutono quale formato di trasferimento o quale archivio di dati utilizzare e tonnellate di altri dettagli che dovrebbero essere davvero trasparenti per tutti i componenti, ma quello che implementa i dettagli. Nessuno se ne frega se il componente soddisfa il contratto di progettazione e chi ne è responsabile sarà in grado di rispondere alle modifiche del contratto in un lasso di tempo ragionevole.

La stragrande maggioranza di tutti i problemi tecnici che si incontrano nello sviluppo del software sono problemi di ciclismo. Semplicemente perché hanno già delle soluzioni e l'unica domanda è: quale soluzione vuoi scegliere.
Non dovresti bloccarti in tali decisioni. È necessario bloccare tali decisioni in un livello di astrazione che disaccoppia l'applicazione da tali dettagli .
I problemi veramente importanti nello sviluppo del software sono problemi di progettazione a livello di funzionalità e di sistema. Tutto il resto è secondario.

Quindi non iniziare nemmeno questi dibattiti. Concentrare la tua energia nel dividere il tuo progetto in parti indipendenti. Questo produce software, che è più robusto e flessibile. E se dovessi essere in grado di individuare decisioni tecniche che presentano chiari svantaggi (cosa che puoi fare solo dopo avere un software in esecuzione), puoi prendere una decisione diversa senza influire sul resto del sistema.

La standardizzazione è un approccio

Il tuo team deve raggiungere un consenso su ciò che adotterà come standard per lo sviluppo e quindi attenersi ad esso per un periodo di tempo ragionevole (deciso dal team). Se lo standard fallisce, probabilmente ne verrà adottato uno nuovo da un nuovo batch di possibili framework di soluzioni.

"Ehi, quei PC alla fine erano inutili, proviamo i Mac!"

o

"Te l'ho detto! La primavera è molto meglio di EJB."

E così via.

Avere uno standard significa che il codice diventa più facile da lavorare attraverso un team, il che a sua volta porta a un ambiente più produttivo.

Attualmente sto testando un approccio, il codice chiamato "conclave papale" ed è abbastanza promettente. Si basa su una storia, secondo cui durante una delle elezioni papali si è verificato un "punto morto" e che i cardinali semplicemente non hanno potuto fare una scelta. L'entità che ospita un'elezione (molto probabilmente una delle maggiori città) ha prima bloccato i cardinali in un edificio, quindi ha drasticamente ridotto la fornitura di cibo e poi rimosso il tetto dell'edificio per rendere il dibattito ancora meno confortevole. Come previsto, i cardinali hanno fatto la scelta dopo che il tetto è stato rimosso, terminando un punto morto di tre anni.

Quindi il mio approccio è che quando le persone non sono d'accordo su alcune cose, sono costrette a discuterne fino a quando non escogitano una scelta. Non offro nessun altro disagio, nemmeno un vincolo di tempo e ovviamente non faccio nulla con il tetto :). Tutto quello che faccio è sollevare costantemente il problema ogni giorno. Se qualcuno dice "Non possiamo prendere una decisione", rispondo con "Beh ... devi farlo". Finora non ho mai incontrato una persona così irrimediabilmente dipendente da alcuni dettagli tecnologici minori. Dopo un sacco di incontri tendono a cercare un compromesso proprio come i cardinali.

Concordo sul fatto che si tratta più di una discussione di sostegno, piuttosto che di superarla. Tuttavia, le discussioni non sono infinite e, in più, alcune persone dopo tale "conclave" tendono ad evitare piccoli dibattiti tecnologici, il che rende le cose più comode per l'intero team.

Ho letto da qualche parte che non dovresti viaggiare più di 6 insieme se devi concordare dove devi andare e cosa fare, poiché non raggiungerai il consenso.

Questo è un ottimo esempio del perché ci deve essere una persona con poteri decisivi. In questo esempio particolare, detta persona deve prendere una decisione e dire "deve essere così", e gli altri devono rispettare quella decisione in modo da poter svolgere un vero lavoro.

Se la decisione si rivela poi negativa, almeno lo sai per certo e puoi imparare da essa.

Un approccio è per voto e funziona bene in squadre di dimensioni più piccole.

Mentre due persone potrebbero avere la conversazione; spostalo in un forum aperto ... discuti per N tempo, quindi tieni un voto alzando la mano.

Semplice ma democratico e ti permette di andare avanti.

Una domanda simile potrebbe essere:

Come fermare le guerre di religione / fiamma nei forum?

Penso che @ S.Lott abbia ragione nel suo commento, se l'unico punto è "discussione", "allontanarsi" o ignorare altrimenti potrebbe essere l'unica risposta. Ho usato quella tecnica in passato.

Se il punto è trovare una soluzione, valutare i pro / contro per il dominio in questione, impostare un limite di tempo e (annuire a Nike) farlo.

Idealmente - IMO - il responsabile della tecnologia o la figura dell'autorità dice: "ok, grazie per i tuoi punti, siamo ..." suono del lancio dei dadi "... andando con l'idea di così-così-così." e tutti vanno a sedersi.

La geek su punti minuscoli ha sprecato una quantità enorme del mio tempo di incontro e non voglio più sentirlo. : - /

Trovo che quando focalizzi la conversazione non su quale alternativa sia giusta, ma su quali siano le conseguenze della scelta di quella sbagliata, tendi a non impantanarti troppo. Se possiamo giungere a un consenso sul fatto che anche se A ha ragione, B non ci ucciderà, nessuno otterrà troppo ma se finiremo con B. Se non riusciamo a raggiungere quel consenso, è generalmente perché c'è un vero problema che dobbiamo affrontare.

La cosa principale è che dobbiamo essere maturi e capire che non possiamo sempre essere d'accordo l'uno con l'altro, la cosa grande e matura è imparare gli uni dagli altri, perché abbiamo le posizioni che abbiamo e forse legate alle mie domanda, scopri quali esperienze e il motivo per cui. Quindi possiamo inventare la nostra opinione informata ed essere dannati o no.

Personalmente non ho bisogno o mi aspetto che altre persone siano d'accordo con me, sarebbe bello, ma non importante. E a questo punto, cito Voltaire.

"Potrei non essere d'accordo con quello che dici, ma difenderò fino alla morte, il tuo diritto di dirlo." -Voltaire, filosofo del V secolo

Ogni riunione dovrebbe avere un presidente responsabile per l'ordine del giorno e per mantenere l'ordine (e prendere minuti, anche se possono delegare questo compito a qualcun altro se la riunione è troppo grande per poter gestire tutto). Il compito del presidente è di dire a qualcuno di smettere di discutere ("ragazzi, per favore, mettetelo offline" in discorsi aziendali).

Se la riunione non vale la pena nominare un presidente, non vale la pena avere una riunione. Potresti anche fare una chiacchierata al watercooler.

Si può dire "più facile a dirsi che a farsi, quant_dev". Bene ... un presidente naturale è un caposquadra, un project manager, un team manager. Dovrebbero avere l'autorità necessaria. Gli incontri in cui nessuno sa chi sta veramente guidando gli incontri sono segni di caos nell'organizzazione, un problema più profondo che deve essere risolto.

Risolvi innanzitutto i problemi generali: abbiamo bisogno di un server web, un server app, un DB, ecc.

Per i dibattiti su quale DB o server utilizzare, parcheggiare tali elementi per un'altra riunione.

Durante le riunioni successive, consentire la discussione di "short list" sulle potenziali offerte, ad esempio MySQl, MS SQL Server, Postgres, ecc.

Consentire ai membri del team di esprimere le proprie opinioni, ma richiedere di sostenerle con i fatti. Il prodotto X fa schifo! Non lo taglia, il prodotto Y non si adatta! È troppo vago Eccetera.

Una volta che tutti i dettagli sono stati pubblicati e sul tavolo, è necessario votarli o in qualità di responsabile della squadra prendere una decisione esecutiva.

Se devi eliminare un chiaro vincitore o confermare il supporto / la mancanza di una caratteristica / concetto, sentiti libero di dedicare del tempo a fare un POC (Proof Of Concept), ma ti rendi conto che ci vorrà del tempo e c'è una tendenza per gli sviluppatori vogliono correre con qualunque cosa abbiano iniziato ... Assicurati di verificare eventuali ostacoli / problemi tecnici prima di andare con il POC.

Come capo squadra, penso che dipenda se la decisione deve essere presa qui e ora.

Se è necessario, cerco quello con il minor costo di inversione. È sempre importante, come team di sviluppo, sapere che la tua decisione potrebbe essere sbagliata, potresti dover fare la scelta sbilenca e cambiare idea. Il costo per farlo dovrebbe sempre essere ridotto al minimo.

Se può aspettare, considera il fatto che nessuna delle parti in disaccordo è in possesso di tutti i fatti. Chiedi loro di andarsene, di approfondire le ricerche e di fare le tue ricerche.

Lo facciamo sempre nel vivo della battaglia? No, in particolare quando sono uno di quelli con un'opinione accesa (non pretendo di essere perfetto). Ma penso che questo sia il modo di affrontare tali situazioni. Il time-boxing non sembra mai portare tutti d'accordo, ma porta solo a un argomento non concluso.

A meno che tu non abbia un membro del team difficile, di solito non hai un dibattito infinito a meno che non ci sia un chiaro vantaggio per entrambi gli approcci. Di seguito sono riportati alcuni buoni approcci per rompere un pareggio:

• Lascia che la persona che deve effettivamente attuarlo decida.
• Per problemi con l'interfaccia utente, lascia che sia la persona più consapevole delle esigenze del cliente a decidere.
• Lascia che la persona con la maggiore esperienza in materia o parte della base di codice decida.
• Lascia che la persona con i vincoli di programma più rigorosi o le limitazioni di risorse umane e risorse decida.
• Lascia che la persona decida chi ha obiezioni più concrete che teoriche.
• Trova un compromesso tra gli approcci.
• Raccogli maggiori informazioni e decidi alla prossima riunione, dando più peso alle persone che ovviamente hanno trascorso un po 'di tempo a fare ricerche dall'ultima riunione.

Per quanto riguarda il modo di annunciare una decisione, basta dire, "Va bene, stiamo andando con questo a causa di questo ." Se la gente ha la sensazione che tu abbia dato loro un ascolto equo e non sei desideroso di essere un leader, andranno d'accordo con la tua decisione. Per i particolarmente testardi, puoi promettere di rivalutare dopo che è stata eseguita una certa quantità di implementazione, ma la maggior parte delle persone lo abbandonerà a quel punto.

Un buon facilitatore di riunioni può facilitare questo tipo di discussioni senza lasciarle sfuggire di mano.