Interruzione di discussioni tecniche senza fine e decisione

Problema 1. Alcune persone non amano perdere. Se non chiamano i colpi, discutono fino a quando non chiamano i colpi attraverso l'attrito.

Problema 2. Niente è veramente in gioco, quindi il dibattito è tollerato.

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

Che cosa fare?

1. Renditi conto che nulla è in gioco.

2. Considera che in 2 o 3 anni, l'intero argomento verrà riaperto perché qualcosa all'esterno dell'organizzazione è cambiato.

3. Lancia una moneta. Sul serio. Scegli qualcosa e vai avanti. Alcune persone vedranno la stupidità nel dibattito. Qualche gente discuterà quindi della natura della moneta che viene lanciata. Se la gente non può essere soddisfatta con un lancio di moneta, ha problemi di ego e ha bisogno di imparare che (a) nulla è in gioco e (b) la decisione sarà cambiata in pochi anni.

Se non riescono a capire che nulla è in gioco, devono scrivere il valore in dollari di entrambi i lati dell'argomento. Ad un certo punto, qualcuno potrebbe vedere che più ore di lavoro sono spese per l'analisi di quanto valga la decisione effettiva. Un lancio di monete produce lo stesso valore a un costo inferiore.

Un paio di cose da considerare:

1. Accetta solo argomenti quantificabili. Se qualcuno dice che risparmierà del tempo, chiedi loro di quantificarlo e tienili alla risposta. In questo modo, se stanno parlando di spazzatura, ne prendono solo uno prima che tutti sappiano che sono a pezzi.

2. Fai in modo che le persone si assumano la responsabilità delle loro raccomandazioni. Metti in chiaro che alla fine dell'anno se hanno fatto cattive chiamate che faranno parte della loro valutazione. Non mi dispiacciono i dibattiti ma voglio le persone con il coraggio delle loro convinzioni - se hai intenzione di giurare che qualcosa è grande e ci aspetti di adottarlo, è meglio che tu possa vivere con le conseguenze.

Queste sono cose vere per allontanarsi dai due problemi di S.Lott - che alcune persone non amano perdere e che nulla è in gioco. La mia risposta è messa in gioco, quindi non c'è discussione per il dibattito.

1. Timeboxladiscussione.-Seoccorronopiùdi5minutiperciascunaparteperdichiarareilpropriocaso,alloraètroppocomplesso.Abbiamo attualmente utilizza i timer da cucina per questo . Funzionano meravigliosamente e costano circa 5 dollari.
2. Richiede che i partecipanti discutano con i dati e l'esperienza.
3. Manteniamo le opzioni sul tavolo. Dopo che ciascuna parte ha il suo tempo, trascorriamo altri 5 minuti a discutere le implicazioni di ciascun approccio. Dopo 20 minuti, usciamo e lo facciamo (implementalo). Se non funziona, allora andiamo con l'altro approccio.

La regola è semplice. Una volta che non sai cosa scegliere, pensa cosa è meglio per la società.

Sì, la scelta di Intel contro AMD non è così semplice. Ma quale è meglio per la tua azienda? Per esempio, se c'è una persona che è responsabile per l'ordinazione di roba e ci vorrà un po 'di tempo per ordinare un PC basato su processore AMD, ma Intel può essere ordinato in un minuto e davvero non ti interessa quello che sarà - basta ordinare uno basato su Intel perché è meglio per la società.

Di solito queste discussioni sono in realtà solo vendita di biciclette . Le persone sostengono quale formato di trasferimento o quale archivio dati utilizzare e molti altri dettagli che dovrebbero essere veramente trasparenti per tutti i componenti, ma quello che implementa i dettagli. Non importa a nessuno se il componente soddisfa il contratto di progettazione e coloro che lo gestiscono saranno in grado di rispondere alle modifiche del contratto in un ragionevole lasso di tempo.

La stragrande maggioranza di tutti i problemi tecnici che si incontrano nello sviluppo del software sono i problemi relativi allo spostamento delle biciclette. Semplicemente perché hanno già delle soluzioni e l'unica domanda è, quale soluzione vuoi scegliere.
Non dovresti chiuderti in tali decisioni. Devi 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 in realtà non iniziare nemmeno questi dibattiti. Concentra 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 le decisioni tecniche che hanno evidenti svantaggi (qualcosa che puoi fare solo quando hai un software in esecuzione), puoi prendere una decisione diversa senza influire sul resto del sistema.

La standardizzazione è un approccio

La tua squadra deve arrivare ad un accordo su ciò che adotterà come standard per lo sviluppo e quindi attenersi ad esso per un ragionevole periodo di tempo (deciso dal team). Se lo standard fallisce, ne viene adottato uno nuovo probabilmente da un nuovo lotto di possibili quadri di soluzione.

"Hey, those PCs were useless in the end, let's try Macs!"

o

"I told you so! Spring is much better than EJB."

E così via.

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

Attualmente sto testando l'approccio, codice chiamato "conclave papale" ed è piuttosto promettente. È basato su una storia, che durante una delle elezioni papali c'è stato un "punto morto" ei cardinali semplicemente non potevano fare una scelta. Entità che ospitava le elezioni (molto probabilmente alcune delle maggiori città) prima cardinali bloccati in un edificio, poi drasticamente ridotto l'approvvigionamento di cibo e poi rimosso il tetto dell'edificio per rendere il dibattito ancora meno constrongvole. Come previsto i cardinali hanno fatto la scelta dopo che il tetto è stato rimosso, terminando un deadlock 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 escogitano una scelta. Non offro nessun altro disagio, nemmeno un limite di tempo e ovviamente non faccio nulla con il tetto :). Tutto ciò che faccio è costantemente portare il problema ogni giorno. Se qualcuno dice "Non possiamo prendere una decisione", rispondo con "Beh ... devi". Fino ad ora non ho mai incontrato una persona così irrimediabilmente dipendente da alcuni dettagli tecnologici minori. Dopo un sacco di incontri tendono a cercare un compromesso come i cardinali.

Sono d'accordo sul fatto che si tratti più di una discussione di sostegno, piuttosto che di una sua riduzione. 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ù constrongvoli per l'intera squadra.

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

Questo è un primo esempio del perché ci sia bisogno di una persona con poteri decisivi. In questo particolare esempio, la persona ha bisogno di prendere una decisione e dire "deve essere così", e gli altri devono rispettare quella decisione per poter fare un lavoro reale.

Se in seguito la decisione si rivelerà negativa, almeno lo saprai per certo e potrai imparare da esso.

Un approccio è votato e funziona bene in team di dimensioni minori.

Mentre due persone potrebbero avere la conversazione; spostalo in un forum aperto ... dibattiti per N quantità di tempo quindi tieni un voto alzando le mani.

Semplice ma democratico e ti consente di andare avanti.

Una domanda simile potrebbe essere:

How to stop religious/flame wars on forums?

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

Se il punto è arrivare a una soluzione, pesa i pro / contro per il dominio in questione, imposta un limite di tempo e (annuisce a Nike) fallo e basta.

Idealmente - IMO - il leader tecnologico o l'autorità dice "okay, grazie per i tuoi punti, siamo ..." suono del lancio dei dadi "... andando con così- e così è l'idea. " e tutti vanno e si siedono.

Il geeker su punti minuscoli ha sprecato un'enorme quantità del mio tempo di incontro e non voglio più sentirlo. : - /

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

La cosa principale è che dobbiamo essere maturi e capire che non possiamo essere sempre d'accordo, la cosa grande e matura è imparare gli uni dagli altri, perché abbiamo le posizioni che abbiamo e forse siamo legati alla mia stessa domanda, impara quali esperienze e il motivo per cui. Quindi possiamo inventare la nostra opinione informata e essere dannati o no.

Personalmente non ho bisogno o non 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 dell'ordine del giorno e dell'ordine (e prendere minuti, sebbene possano delegare questo compito a qualcun altro se la riunione è troppo grande per consentire loro di gestire tutto). Il compito del presidente è di dire a qualcuno di smettere di discutere ("ragazzi, per favore, portatelo offline" in un intervento aziendale).

Se la riunione non vale la pena nominare un presidente, non è un incontro che valga la pena avere. Potresti anche fare una chiacchierata con il distributore di acqua.

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

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

Per i dibattiti su quale DB o server utilizzare, parcheggia questi articoli per un'altra riunione.

Durante le riunioni successive, consenti la discussione sulla "lista ristretta" delle potenziali offerte, ad es. MySQl, MS SQL Server, Postgres, ecc.

Consenti ai membri del team di esprimere le loro opinioni, ma richiedi che le confermino con i fatti. Il prodotto X fa schifo! Non taglia, Prodotto Y non scala! È troppo vago Ecc.

Una volta che tutti i dettagli sono disponibili e sul tavolo è necessario metterli in votazione o come capo del team prendere una decisione esecutiva.

Se hai bisogno di scovare un chiaro vincitore o confermare il supporto / la mancanza di una funzionalità / concetto, sentiti libero di prendere tempo per fare un POC (Proof Of Concept) ma renditi conto che ci vorrà del tempo e c'è una tendenza per gli sviluppatori di voler eseguire con qualsiasi cosa abbiano iniziato con ... Assicurati di verificare eventuali ostacoli / problemi tecnici prima di andare con il POC.

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

Se deve, allora cerco quello con il più basso costo di storno. È sempre importante, come team di sviluppo, sapere che la tua decisione potrebbe essere sbagliata, potresti dover fare la scelta più difficile e cambiare idea. Il costo di 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 e di fare ulteriori ricerche e di fare le tue ricerche.

Lo facciamo sempre nel pieno 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 queste situazioni. Il time-boxing non sembra mai portare a tutti d'accordo, porta solo a un argomento non concluso.

A meno che tu non abbia un membro della squadra difficile, di solito non hai un dibattito senza fine a meno che non vi sia un chiaro vantaggio per entrambi gli approcci. I seguenti sono alcuni buoni approcci per rompere un pareggio:

• Lascia che decida la persona che deve effettivamente implementarla.
• Per i problemi dell'interfaccia utente, consentire alla persona più consapevole dei requisiti del cliente di decidere.
• Lascia decidere alla persona con più esperienza sull'argomento o parte della base di codice.
• Lascia che decida la persona con i vincoli di programma più severi o limiti di risorse umane e di risorse.
• Lascia che la persona decida chi ha più obiezioni concrete piuttosto che teoriche.
• Trova un compromesso tra gli approcci.
• Raccogli maggiori informazioni e decidi al prossimo incontro, dando più peso alle persone che hanno ovviamente dedicato un po 'di tempo alla ricerca dall'ultimo incontro.

Per quanto riguarda come per annunciare una decisione, devi solo dire "Ok, stiamo andando con questo a causa di questo . " Se le persone si sentono come se tu avessi dato loro un'udienza imparziale, e non sei un ciarlatano sdolcinato come leader, loro andranno insieme alla tua decisione. Per chi è particolarmente testardo, 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 farli sfuggire di mano.