終わりのない技術的な議論をやめて決定を下す

私はいつも、最も小さな「技術的なもの」を長年にわたって叩きたい人に出会います。

誤解しないでください。私はオタクのプログラマーで、自分の仕事を愛していますが、会話のタイプは知っています。

• MacはWindowsよりもはるかに優れています
• For Eachループを使用せず、Whileループを使用します
• IntelベースのPCを購入するのではなく、AMDベースのPCを入手してください。
• 1つのIoCコンテナーを別のコンテナーよりも使用する必要があります。

これらすべての「モノ」には、双方にとって有効な長所と短所があり、「正しい」答えは決して得られず、その人はその点を認めません。（もちろん、答えがあるところもあるでしょう:)。

私の質問（私はそこに着いています!!）：ソフトウェアチームにおいて、イノベーションを阻害することなく、これらの長い議論をどのように切り抜けて、決定を下し、実際のビジネス上の問題を解決できるようにするかです。

問題1.一部の人々は失うことを好まない。彼らがショットを呼んでいないなら、彼らは消耗によってショットを呼ぶまで議論するつもりです。

問題2.本当に問題になるものはないので、議論は容認されます。

何もかかっていない？はい。ほとんどの決定は、ほとんど影響を与えません。「長年に渡って」という結果になるのは、両方の選択肢が事実上同一であることを意味します。

何をすべきか？

1. 何も問題がないことを認識してください。

2. 組織外の何かが変更されたため、2、3年後に主題全体が再開されることを認識してください。

3. コインを投げます。真剣に。何かを選んで先に進みましょう。一部の人々は、議論の愚かさを見るでしょう。一部の人々は、投げられているコインの性質について議論します。人々がコイントスで満足できない場合、彼らは自我の問題を抱えており、（a）何も危険にさらされていないこと、および（b）数年後に決定が変更されることを知る必要があります。

何も問題がないことを理解できない場合、彼らは議論の両側のドル価値を書き出す必要があります。ある時点で、実際の決定に値するよりも多くの工数が分析に費やされていることに気付く人がいるかもしれません。コイントスは、より低いコストで同等の価値を生み出します。

考慮すべきいくつかのこと：

1. 定量化可能な引数のみを受け入れます。誰かがそれが時間を節約すると言うならば、彼らにそれを定量化し、答えを保持するように頼みます。このように、彼らがゴミを話している場合、誰もが彼らがつぶされたフラッシュであることを知る前に、彼らは一度だけそれを取得します。

2. 人々に彼らの推薦に責任を持ってもらいましょう。彼らが評価の一部となる悪い電話をしていた場合、年の終わりにそれを明確にしてください。私は議論を気にしませんが、人々の信念の勇気を持ちたいです-あなたが何か素晴らしいことを誓い、それを採用することを期待するなら、あなたはその結果で生きることができるでしょう。

これらは、S.Lottの2つの問題から逃れるための本当のことです-負けたくない人もいれば、何も危険にさらされていないということです。私の反応は何かを危うくするので、議論のために議論はありません。

1. タイムボックスの議論。-ケースの説明に各側で5分以上かかる場合、複雑すぎます。私たちは、実際にこのキッチンタイマーを使用します。彼らは素晴らしく働き、約5ドルかかります。
2. 参加者がデータと経験について議論することを要求します。
3. オプションをテーブルに保持します。各側が時間をとった後、各アプローチの意味について議論するためにさらに5分間を費やします。20分後、外に出て実行します（実装します）。うまくいかない場合は、他のアプローチを使用します。

ルールは簡単です。何を選ぶべきかわからない場合は、会社にとって何が良いかを考えてください。

はい、Intel v AMDの選択はそれほど簡単ではありません。しかし、あなたの会社にとってどちらが良いですか？たとえば、ものの注文を担当する人がいて、AMDプロセッサベースのPCを注文するのに何年もかかるが、Intelベースはすぐに注文でき、あなたはそれが何であるか気にしない場合- Intelベースのものを注文するだけです。なぜなら、それは会社にとってより良いからです。

通常これらの議論は本当にただのバイクシェッドです。どの転送フォーマットまたはどのデータストアを使用するか、および非常に詳細を実装するコンポーネント以外のすべてのコンポーネントに対して本当に透過的でなければならない他の詳細のトンについて議論する人々。コンポーネントが設計契約を満たし、その担当者が合理的な時間内に契約の変更に対応できる限り、誰も気にしません。

ソフトウェア開発で発生するすべての技術的な問題の大部分は、バイクの脱落の問題です。単に彼らが既に解決策を持っているからであり、唯一の質問は、どの解決策を選択するかです。
そのような決定に縛られるべきではありません。そのような決定を、アプリケーションをそのような詳細から切り離す抽象化レイヤーにロックアウトする必要があります。
ソフトウェア開発で本当に重要な問題は、機能およびシステムレベルでの設計の問題です。それ以外はすべてセカンダリです。

そのため、実際にそのような議論を始めないでください。プロジェクトを独立した部分に分割することにエネルギーを集中します。これにより、より堅牢で柔軟なソフトウェアが得られます。また、明らかな欠点（ソフトウェアを実行した後にしかできないこと）がある技術的な決定を特定できる場合は、システムの他の部分に影響を与えることなく別の決定を行うことができます。

標準化は1つのアプローチです

あなたのチームは、開発の標準として採用するものについてコンセンサスを得てから、妥当な期間（チームが決定）固執する必要があります。標準が失敗した場合、おそらく新しいソリューションフレームワークの新しいバッチから新しいものが採用されます。

「ねえ、これらのPCは結局役に立たなかったので、Macを試してみましょう！」

または

「そう言いました！SpringはEJBよりもはるかに優れています。」

等々。

標準があるということは、チーム全体でコードが扱いやすくなり、生産性の高い環境につながることを意味します。

私は現在、「Papal conclave」という名前のコードとその非常に有望なアプローチをテストしています。それは、教皇の選挙の間に「行き詰まり」があり、枢機sは単に選択をすることができなかったという物語に基づいています。選挙（おそらく都市の一部）をホストしているエンティティは、最初に枢機sを建物に閉じ込め、次に食糧供給を大幅に減らし、次に建物の屋根を取り除いて議論をさらに快適にしました。予想どおり、屋根が取り外されて3年のデッドロックが終わり、枢機sが選択しました。

だから私のアプローチは、人々がいくつかのものに同意しないとき、彼らは彼らが選択肢を思いつくまでそれを議論することを余儀なくされるということです。私は他の不快感、時間制限さえも提供しませんし、もちろん私は屋根で何もしません:)。私がしていることは、毎日問題を絶えず持ち出すことです。誰かが「私たちは決定を下すことができません」と言ったら、「まあ...あなたがしなければならない」と答えます。これまでのところ、私はそれほど小さな技術的詳細にそれほど絶望的にはまっている人に会ったことがありません。たくさんの会議の後、彼らは枢機inalのように妥協を探す傾向があります。

これは、これを切り抜けるのではなく、持続的な議論であることに同意します。しかし、議論は無限ではなく、プラスとして、そのような「コンクレーブ」の後の一部の人々は、マイナーな技術的議論を避ける傾向があり、それはチーム全体にとって物事をより快適にします。

コンセンサスが得られないので、どこに行くべきか、何をすべきかについて同意する必要がある場合、6人以上一緒に旅行するべきではないということを読んだことがあります。

これは、決定的な力を持つ人が必要な理由の代表的な例です。この特定の例では、上記の人は決定を下し、「このようにする必要がある」と言う必要があり、他の人は実際の作業を行えるようにその決定を尊重する必要があります。

その後、決定が悪いことが判明した場合、少なくとも確実に知っており、そこから学ぶことができます。

1つのアプローチは投票によるもので、小規模なチームでうまく機能します。

2人が会話している場合があります。それをオープンなフォーラムに移動します... N時間議論し、手を挙げて投票します。

シンプルでありながら民主的であり、前進することができます。

同様の質問は次のとおりです。

フォーラムで宗教/火炎戦争を止める方法は？

@ S.Lottは彼のコメントで正しいと思います。唯一のポイントが「議論」、「立ち去る」、そうでなければそれを無視することが唯一の答えかもしれない場合です。私は過去にそのテクニックを使用しました。

問題が解決策になる場合は、問題のドメインの賛否両論を検討し、時間制限を設定して（Nikeにうなずく）それを行います。

理想的には-IMO-技術リーダーまたは権威の人物は、「大丈夫、あなたのポイントに感謝します、私たちは...」サイコロの音「... まあまあのアイデアで行く」と言います。みんな行って座ります

極小ポイントを超えるオタクは、私のミーティング時間の膨大な量を浪費しているので、もうそれを聞きたくありません。：-/

どの選択肢が正しいかではなく、間違った選択肢を選択した場合の結果に会話を集中させると、行き詰まりがちになることがあります。我々はAが正しいとしても、Bは私たちを殺すしないことに合意に来ることができるならば、誰も私たちがした場合、我々はB.一緒に行くに終わる場合butthurtませんますができないというコンセンサスに来て本当の問題があるので、それは一般的です対処する必要があります。

主なことは、私たちは成熟していなければならず、常にお互いに同意できるとは限らないことを理解していることです。質問、どのような経験とその理由を学びます。それから、私たちは自分自身の情報に基づいた意見を作り、のろわれます。

私は個人的には他の人が私に同意する必要はありませんし、期待していません。それは素晴らしいことですが、重要ではありません。そして、ここまでで、ヴォルテールを引用します。

「あなたの言うことに反対するかもしれませんが、私はあなたの言う権利である死を擁護します。」-ヴォルテール、5世紀の哲学者

すべての会議には議題と秩序を維持する責任者が必要です（ただし、会議が大きすぎてすべてを処理できない場合はこのタスクを他の人に委任できますが、数分かかります）。議長の仕事は、誰かに議論をやめるように言うことです（企業の発言で「みんな、オフラインにしてください」）。

会議が議長を任命する価値がない場合、会議を開催する価値はありません。同様に、ウォータークーラーでチャットをすることもできます。

「言うより簡単だ、quant_dev」と言えます。ええと...自然な議長は、チームリーダー、プロジェクトマネージャー、チームマネージャーです。彼らには必要な権限が必要です。誰が実際に会議をリードしているのか誰も知らない会議は、組織内の混乱の兆候であり、解決する必要があるより深い問題です。

最初に一般的な問題を解決します。Webサーバー、アプリサーバー、DBなどが必要です。

使用するDBまたはサーバーに関する議論については、それらのアイテムを別の会議のために保留します。

後続の会議中に、MySQl、MS SQL Server、Postgresなどの潜在的な製品を「ショートリスト」するためのディスカッションを許可します。

チームメンバーが意見を表明できるようにしますが、事実をバックアップするように依頼します。製品Xがダメ！カットしません、製品Yはスケーリングしません！あいまいすぎる。等。

すべての詳細が公開され、テーブルに掲載されたら、投票するか、チームリーダーが経営陣の決定を下す必要があります。

明確な勝者を追い出すか、機能/概念のサポート/欠如を確認する必要がある場合は、POC（Proof Of Concept）を行うのに時間がかかりますが、これには時間がかかることを認識し、開発者はPOCを使用する前に、障害物や技術的な懸念事項を必ず確認してください。

チームリーダーとして、今ここで決断を下さなければならないかどうかにかかっていると感じています。

それが必要な場合、私は最低の反転コストを持つものを探します。開発チームとして、あなたの決定が間違っている可能性があることを知ることは常に重要です。そのためのコストは常に最小限に抑える必要があります。

待つことができる場合は、異議を唱える当事者のどちらもすべての事実を所有していないという事実を考慮してください。立ち去ってさらに調査し、独自の調査を行うよう依頼します。

私たちは常に戦いの最中にこれを行いますか？いいえ、特に私が熱烈な意見を持つ人の1人である場合（完璧だとは言いません）。しかし、私はこれがそのような状況にアプローチする方法だと思います。タイムボクシングは、すべての人が同意することは決してないようであり、結論のない議論につながります。

難しいチームメンバーがいない限り、どちらのアプローチにも明確な利点がない限り、通常、無限の議論はありません。次は、タイを壊すためのいくつかの良いアプローチです。

• 実際にそれを実装しなければならない人が決定してみましょう。
• UIの問題については、顧客の要件を最もよく知っている人が決定してください。
• 件名またはコードベースの一部について最も経験のある人が決定できるようにします。
• スケジュールの制約が最も厳しい人、または人員とリソースの制限がある人が決定できるようにします。
• 理論的な異論ではなく、より具体的な異議を誰が持っているかを人に決めさせます。
• アプローチ間の妥協点を見つけます。
• より多くの情報を収集して次の会議で決定し、前回の会議以降明らかに調査に時間を費やした人々により多くの重みを与えます。

決定を発表する方法に関しては、「わかりました、このため、これを使用します」と言うだけです。あなたが彼らに公正な聴聞会を与えたように人々が感じ、あなたがリーダーとしてのわがままな望みではないなら、彼らはあなたの決定と一緒に行くでしょう。特に頑固な人は、一定量の実装が完了した後に再評価することを約束できますが、ほとんどの人はその時点でそれを削除します。

優れた会議のファシリテーターは、これらの種類の議論を手放すことなく促進できます。