Stoppen Sie endlose technische Diskussionen und treffen Sie eine Entscheidung

Ich treffe immer wieder Leute, die sich gerne über die kleinsten "technischen Dinge" austoben.

Verstehen Sie mich nicht falsch, ich bin ein Geek-Programmierer, der liebt, was ich tue, aber Sie kennen die Art der Unterhaltung.

• Mac ist so viel besser als Windows
• Verwenden Sie keine For Each-Schleife, sondern eine While-Schleife
• Kaufen Sie keinen Intel-basierten PC, sondern einen AMD-basierten.
• Wir sollten einen IoC-Container über einem anderen verwenden.

Alle diese "Dinge" haben für beide Seiten gültige Vor- und Nachteile, und Sie werden nie eine "richtige" Antwort erhalten, und die Person wird den Punkt niemals zugeben. (Natürlich wird es einige geben, auf die es vielleicht eine Antwort gibt :).

Meine Frage (ich komme dorthin !!) lautet: Wie können Sie in einem Softwareteam diese langen Diskussionen durchbrechen, ohne die Innovation zu behindern, damit eine Entscheidung getroffen werden kann und Sie die eigentlichen geschäftlichen Probleme lösen können.

Problem 1. Manche Leute mögen es nicht zu verlieren. Wenn sie nicht das Sagen haben, werden sie debattieren, bis sie durch Abrieb das Sagen haben.

Problem 2. Es steht nichts wirklich auf dem Spiel, so dass Debatten toleriert werden.

Nichts steht auf dem Spiel? Ja. Die meisten Entscheidungen haben fast keine Auswirkungen auf den US-Dollar. Die Tatsache, dass es darum geht, "für Ewigkeiten zu knallen", bedeutet, dass beide Entscheidungen effektiv identisch sind.

Was ist zu tun?

1. Erkenne, dass nichts auf dem Spiel steht.

2. Stellen Sie fest, dass in 2 oder 3 Jahren das gesamte Thema wieder geöffnet wird, weil sich etwas außerhalb der Organisation geändert hat.

3. Wirf eine Münze. Ernst. Einfach etwas auswählen und weitermachen. Einige Leute werden die Albernheit in der Debatte sehen. Einige Leute werden dann über die Art der geworfenen Münze diskutieren. Wenn die Leute mit einem Münzwurf nicht zufrieden sind, haben sie Ego-Probleme und müssen lernen, dass (a) nichts auf dem Spiel steht und (b) die Entscheidung in einigen Jahren geändert wird.

Wenn sie nicht herausfinden können, dass nichts auf dem Spiel steht, müssen sie den Dollarwert beider Seiten des Arguments aufschreiben. Irgendwann kann jemand feststellen, dass mehr Arbeitsstunden für die Analyse aufgewendet werden, als die eigentliche Entscheidung wert ist. Ein Münzwurf ergibt den gleichen Wert zu geringeren Kosten.

Ein paar Dinge zum Nachdenken:

1. Akzeptieren Sie nur quantifizierbare Argumente. Wenn jemand sagt, dass es Zeit spart, bitten Sie ihn, es zu quantifizieren und auf die Antwort zu beschränken. Auf diese Weise bekommen sie nur einen Versuch, bevor jeder weiß, dass sie einen kaputten Flush haben.

2. Bringen Sie die Leute dazu, Verantwortung für ihre Empfehlungen zu übernehmen. Machen Sie deutlich, dass am Ende des Jahres, wenn sie schlechte Anrufe getätigt haben, dies Teil ihrer Bewertung sein wird. Es macht mir nichts aus, zu debattieren, aber ich möchte, dass die Leute den Mut ihrer Überzeugungen haben. Wenn Sie schwören, dass etwas großartig ist und von uns angenommen wird, sollten Sie besser in der Lage sein, mit den Konsequenzen zu leben.

Dies sind echte Dinge, um S.Lotts zwei Problemen zu entkommen - dass manche Menschen nicht gerne verlieren und dass nichts auf dem Spiel steht. Meine Antwort ist etwas auf dem Spiel, so gibt es keine Debatte um der Debatte willen.

1. Timebox die Diskussion. - Wenn es mehr als 5 Minuten dauert, bis jede Seite ihren Fall darlegt, ist es zu komplex. Dafür verwenden wir eigentlich Küchentimer . Sie arbeiten wunderbar und kosten etwa 5 Dollar.
2. Fordern Sie, dass die Teilnehmer mit Daten und Erfahrungen streiten.
3. Wir behalten die Optionen auf dem Tisch. Nachdem jede Seite ihre Zeit hat, diskutieren wir weitere 5 Minuten über die Auswirkungen der einzelnen Ansätze. Nach 20 Minuten gehen wir raus und machen es (implementieren es). Wenn es nicht funktioniert, fahren wir mit dem anderen Ansatz fort.

Die Regel ist einfach. Wenn Sie nicht wissen, was Sie wählen sollen, überlegen Sie, was für das Unternehmen besser ist.

Ja, die Wahl zwischen Intel und AMD ist nicht so einfach. Aber was ist besser für Ihr Unternehmen? Zum Beispiel, wenn es eine Person gibt, die für die Bestellung von Sachen verantwortlich ist und es Ewigkeiten dauern wird, einen AMD-Prozessor-basierten PC zu bestellen, aber Intel-basiert kann in einer Minute bestellt werden und es ist Ihnen wirklich egal, was es sein wird - Bestellen Sie einfach ein Intel-basiertes Produkt, weil es für das Unternehmen besser ist.

Normalerweise handelt es sich bei diesen Gesprächen nur um Bikeshedding . Die Leute streiten sich, welches Übertragungsformat oder welcher Datenspeicher verwendet werden soll, und jede Menge andere Details, die für alle Komponenten wirklich transparent sein sollten, außer für die, die die Details implementieren. Niemand kümmert sich darum, solange die Komponente den Designvertrag erfüllt und die Verantwortlichen in der Lage sind, in angemessener Zeit auf Vertragsänderungen zu reagieren.

Die überwiegende Mehrheit aller technischen Probleme, auf die Sie bei der Softwareentwicklung stoßen, sind Probleme mit dem Fahrradverleih. Einfach, weil sie bereits Lösungen haben und die einzige Frage ist, welche Lösung Sie auswählen möchten.
Sie sollten sich nicht in solche Entscheidungen einschließen. Sie sollten solche Entscheidungen in einer Abstraktionsebene ausschließen, die Ihre Anwendung von solchen Details entkoppelt .
Die wirklich wichtigen Probleme bei der Softwareentwicklung sind Entwurfsprobleme auf Funktions- und Systemebene. Alles andere ist zweitrangig.

Beginnen Sie also nicht wirklich solche Debatten. Konzentrieren Sie Ihre Energie darauf, Ihr Projekt in unabhängige Teile zu unterteilen. Dies ergibt eine Software, die robuster und flexibler ist. Und sollten Sie in der Lage sein, technische Entscheidungen mit klaren Nachteilen zu treffen (was Sie nur tun können, wenn Sie eine laufende Software haben), können Sie eine andere Entscheidung treffen, ohne den Rest des Systems zu beeinträchtigen.

Standardisierung ist ein Ansatz

Ihr Team muss eine Einigung darüber erzielen, was es als Entwicklungsstandard verwenden wird, und sich dann für einen angemessenen Zeitraum daran halten (vom Team festgelegt). Wenn der Standard fehlschlägt, wird wahrscheinlich ein neuer aus einer neuen Reihe möglicher Lösungsframeworks übernommen.

"Hey, diese PCs waren am Ende nutzlos, lass uns Macs ausprobieren!"

oder

"Ich habe es dir doch gesagt! Frühling ist viel besser als EJB."

Und so weiter.

Ein Standard erleichtert die Zusammenarbeit mit Code in einem Team, was wiederum zu einer produktiveren Umgebung führt.

Ich teste derzeit Ansatz, Code mit dem Namen "Papal Conclave" und es ist ziemlich vielversprechend. Es basiert auf einer Geschichte, dass es während einer der Papstwahlen einen "Stillstand" gab und die Kardinäle einfach keine Wahl treffen konnten. Entität, die eine Wahl veranstaltet (höchstwahrscheinlich eine größere Stadt), sperrte zuerst Kardinäle in ein Gebäude, reduzierte dann drastisch die Nahrungsmittelversorgung und entfernte dann das Dach des Gebäudes, um die Debatte noch unbequemer zu machen. Wie erwartet trafen Kardinäle die Wahl, nachdem das Dach entfernt worden war und ein dreijähriger Deadlock beendet war.

Mein Ansatz ist also, dass Menschen, die sich in einigen Dingen nicht einig sind, gezwungen sind, darüber zu diskutieren, bis sie eine Wahl treffen. Ich bereite keine anderen Beschwerden, auch keine Zeitbeschränkungen, und natürlich mache ich nichts mit dem Dach :). Alles, was ich tue, ist, das Thema jeden Tag zur Sprache zu bringen. Wenn jemand sagt "Wir können keine Entscheidung treffen", antworte ich mit "Nun ... du musst". Bisher habe ich noch keinen Menschen getroffen, der so hoffnungslos auf ein technologisches Detail angewiesen war. Nach einer Reihe von Besprechungen neigen sie dazu, genau wie Kardinäle nach einem Kompromiss zu suchen.

Ich stimme zu, dass dies eher eine anhaltende Diskussion ist, als sie zu durchbrechen. Die Diskussionen sind jedoch nicht endlos und einige Leute neigen nach einem solchen "Abschluss" dazu, kleinere technologische Debatten zu vermeiden, was die Sache für das gesamte Team angenehmer macht.

Ich habe irgendwo gelesen, dass Sie nicht mehr als 6 zusammen reisen sollten, wenn Sie sich darauf einigen müssen, wohin Sie gehen und was zu tun ist, da Sie keinen Konsens erzielen.

Dies ist ein hervorragendes Beispiel dafür, warum es eine Person mit entscheidenden Befugnissen geben muss. In diesem speziellen Beispiel muss die Person eine Entscheidung treffen und sagen, "es muss so sein", und die anderen müssen diese Entscheidung respektieren, damit echte Arbeit geleistet werden kann.

Wenn sich die Entscheidung dann später als schlecht herausstellt, wissen Sie es zumindest genau und können daraus lernen.

Ein Ansatz ist die Abstimmung und funktioniert gut in kleineren Teams.

Während zwei Personen das Gespräch führen können; Verschieben Sie es in ein offenes Forum ... debattieren Sie N-mal und stimmen Sie dann ab, indem Sie die Hände heben.

Einfach und doch demokratisch und ermöglicht es Ihnen, voranzukommen.

Eine ähnliche Frage könnte sein:

Wie kann man Religions- / Flammenkriege in Foren stoppen?

Ich denke, @ S.Lott hat Recht in seinem Kommentar, wenn der einzige Punkt "Diskussion", "Weggehen" oder anderweitiges Ignorieren ist, könnte dies die einzige Antwort sein. Ich habe diese Technik in der Vergangenheit verwendet.

Wenn es darum geht, eine Lösung zu finden, wiegen Sie die Vor- und Nachteile für die betreffende Domain ab, legen Sie ein Zeitlimit fest und (nickt Nike zu) tun Sie es einfach.

Im Idealfall - IMO - sagt der technische Leiter oder die Autoritätsperson: "Okay, danke für Ihre Punkte, wir ..." klingen nach Würfeln "... und folgen der Idee von so und so." und alle gehen und setzen sich.

Geekery über winzige Punkte hat eine enorme Menge meiner Besprechungszeit verschwendet, und ich will es nicht mehr hören. : - /

Ich finde, wenn Sie das Gespräch nicht darauf konzentrieren, welche Alternative richtig ist, sondern darauf, welche Konsequenzen die Auswahl der falschen hat, sind Sie in der Regel nicht zu festgefahren. Wenn wir zu einem Konsens kommen können, dass B uns nicht tötet, auch wenn A Recht hat, wird niemand zu sehr verletzt, wenn wir mit B enden. Wenn wir nicht zu diesem Konsens kommen können, liegt das im Allgemeinen an einem echten Problem das müssen wir ansprechen.

Die Hauptsache ist, dass wir reif sein müssen und verstehen, dass wir uns nicht immer einig sein können. Die große und reife Sache ist, voneinander zu lernen, warum wir die Positionen haben, die wir haben und vielleicht mit meinen verwandt sind Frage, lerne welche Erfahrungen und den Grund warum. Dann können wir uns eine fundierte Meinung bilden und verdammt sein oder nicht.

Ich persönlich brauche oder erwarte nicht, dass andere mir zustimmen, es wäre nett, aber nicht wichtig. Und bis hierher zitiere ich Voltaire.

"Ich kann nicht zustimmen, was Sie sagen, aber ich werde bis zum Tod Ihr Recht verteidigen, es zu sagen." -Voltaire, Philosoph des 5. Jahrhunderts

Jede Besprechung sollte einen Vorsitzenden haben, der für die Tagesordnung und die Einhaltung der Ordnung verantwortlich ist (und Protokollierung benötigt, obwohl er diese Aufgabe an eine andere Person delegieren kann, wenn die Besprechung zu groß ist, um alle Aufgaben zu bewältigen). Die Aufgabe des Vorsitzenden ist es, jemanden anzuweisen, mit dem Streiten aufzuhören ("Jungs, bitte schalten Sie es aus" in Corporate Speak).

Wenn es sich nicht lohnt, einen Vorsitzenden zu ernennen, lohnt es sich auch nicht, eine Besprechung abzuhalten. Sie können sich auch am Wasserkühler unterhalten.

Man kann sagen "leichter gesagt als getan, quant_dev". Nun ... ein natürlicher Vorsitzender ist ein Teamleiter, ein Projektmanager, ein Teammanager. Sie sollten die notwendige Autorität haben. Meetings, bei denen niemand weiß, wer die Meetings wirklich leitet, sind Anzeichen von Chaos in der Organisation, ein tieferes Problem, das gelöst werden muss.

Lösen Sie zuerst die allgemeinen Probleme: Wir benötigen einen Webserver, einen App-Server, eine Datenbank usw.

Für die Debatten darüber, welche Datenbank oder welcher Server verwendet werden soll, parken Sie diese Elemente für eine andere Besprechung.

Lassen Sie in den folgenden Besprechungen eine Diskussion zu, um die potenziellen Angebote (z. B. MySQl, MS SQL Server, Postgres usw.) aufzulisten.

Ermöglichen Sie den Teammitgliedern, ihre Meinung zu äußern, aber fordern Sie sie auf, sie mit Fakten zu untermauern. Produkt X ist zum Kotzen! Schneidet nicht, Produkt Y skaliert nicht! Ist zu vage. Etc.

Sobald alle Details bekannt sind und auf dem Tisch liegen, müssen Sie entweder abstimmen oder als Teamleiter eine Entscheidung treffen.

Wenn Sie einen eindeutigen Gewinner ermitteln oder die Unterstützung / das Fehlen eines Features / Konzepts bestätigen müssen, nehmen Sie sich bitte etwas Zeit, um einen POC (Proof Of Concept) zu erstellen, aber stellen Sie fest, dass dies einige Zeit in Anspruch nimmt und die Entwickler dies tendenziell tun Ich möchte mit allem laufen, mit dem ich angefangen habe ... Stellen Sie sicher, dass Sie alle technischen Probleme überprüfen, bevor Sie sich an den POC wenden.

Als Teamleiter kommt es meiner Meinung nach darauf an, ob die Entscheidung hier und jetzt getroffen werden muss .

Wenn es sein muss, suche ich den mit den niedrigsten Umkehrkosten. Als Entwicklerteam ist es immer wichtig zu wissen, dass Ihre Entscheidung möglicherweise falsch ist. Möglicherweise müssen Sie die richtige Wahl treffen und Ihre Meinung ändern. Die Kosten dafür sollten immer minimiert werden.

Wenn es warten kann, dann bedenken Sie, dass keine der Parteien, die nicht einverstanden sind, über alle Fakten verfügt. Bitten Sie sie, wegzugehen und weiter zu forschen und selbst zu forschen.

Tun wir das immer in der Hitze des Kampfes? Nein, besonders wenn ich einer derjenigen bin, die eine hitzige Meinung haben (ich behaupte nicht, perfekt zu sein). Aber ich denke, dass dies der Weg ist, um solche Situationen anzugehen. Time-Boxing scheint nie dazu zu führen, dass sich alle einig sind, es führt nur zu einem unschlüssigen Argument.

Wenn Sie kein schwieriges Teammitglied haben, haben Sie normalerweise keine endlosen Debatten, es sei denn, es gibt keinen klaren Vorteil für beide Ansätze. Das Folgende sind einige gute Ansätze, um ein Unentschieden zu brechen:

• Lassen Sie die Person, die es tatsächlich umsetzen muss, entscheiden.
• Lassen Sie bei Problemen mit der Benutzeroberfläche die Person entscheiden, die die Kundenanforderungen am besten kennt.
• Lassen Sie die Person mit der größten Erfahrung in Bezug auf das Thema oder einen Teil der Codebasis entscheiden.
• Lassen Sie die Person mit den strengsten Zeitplanbeschränkungen oder Arbeitskräfte- und Ressourcenbeschränkungen entscheiden.
• Lassen Sie die Person entscheiden, wer konkretere als theoretische Einwände hat.
• Finden Sie einen Kompromiss zwischen den Ansätzen.
• Sammeln Sie weitere Informationen und entscheiden Sie beim nächsten Treffen, und geben Sie denjenigen mehr Gewicht, die offensichtlich seit dem letzten Treffen einige Zeit mit Nachforschungen verbracht haben.

Soweit wie eine Entscheidung bekannt zu geben, sagen Sie einfach : „Okay, wir mit dem Gehen dies wegen dieser .“ Wenn die Leute das Gefühl haben, dass Sie ihnen eine faire Anhörung gegeben haben und Sie als Anführer nicht verwaschen sind, werden sie Ihre Entscheidung mitmachen. Für besonders hartnäckige Spieler können Sie eine Neubewertung nach einer gewissen Implementierung versprechen, aber die meisten Leute werden sie zu diesem Zeitpunkt fallen lassen.

Ein guter Moderator für Besprechungen kann diese Art von Diskussionen unterstützen, ohne dass sie außer Kontrolle geraten.