停止无休止的技术讨论并做出决定

我总是遇到喜欢在最小的“技术性东西”上花了很多年的人。

不要误会我的意思，我是一个喜欢我所做的事情的怪胎程序员，但是您知道对话的类型。

• Mac比Windows好得多
• 不要使用For Each循环，请使用While循环
• 不要购买基于Intel的PC，而是购买基于AMD的PC。
• 我们应该在另一个IoC容器上使用。

所有这些“东西”在双方都有有效的利弊，您将永远不会得到“正确”的答案，而且这个人也永远不会承认这一点。（当然，可能会有一些答案的地方：）。

我的问题（我要到达那里！）是：在一个软件团队中，您如何在不抑制创新的情况下完成这些漫长的讨论，以便可以做出决定，然后继续解决实际的业务问题。

问题1.有些人不喜欢输。如果他们不做主，他们将辩论直到通过减员做主。

问题2：没有什么真正危险的，所以辩论是可以容忍的。

没关系吗？是。大多数决定对美元的影响几乎为零。归结为“千载难逢”的事实意味着这两种选择实际上是相同的。

该怎么办？

1. 意识到没有任何危险。

2. 意识到在2或3年内，整个主题将重新开放，因为组织外部发生了某些变化。

3. 抛硬币。说真的 只是选择一些东西然后继续前进。一些人会在辩论中看到愚蠢的行为。然后，有些人将辩论被抛硬币的性质。如果人们对掷硬币感到不满意，他们就会遇到自我问题，需要了解（a）危急关头，以及（b）几年后将改变决定。

如果他们不能弄清楚什么都没有危险，就需要写出论证双方的美元价值。在某个时候，有人可能会发现，花费在分析上的工时超过了实际决策的价值。投掷硬币可以降低成本，产生相等的价值。

需要考虑的几件事：

1. 仅接受可量化的参数。如果有人说这可以节省时间，请他们量化并坚持下去。这样，如果他们在谈论垃圾，他们只会一口气在所有人都不知道自己是同花顺的人面前。

2. 让人们对他们的建议负责。明确指出，在年底时，如果他们拨打了不好的电话，这将是他们评估的一部分。我不介意辩论，但我希望人们怀有勇气的信念-如果您要宣扬一件很棒的东西并希望我们采纳它，那么您最好能够承受后果。

这些是摆脱S.Lott的两个问题的真实事物-有些人不喜欢失去，没有任何危险。我的回答受到了威胁，所以就辩论而言，没有辩论。

1. 定时讨论。-如果双方陈述情况的时间都超过5分钟，那么这太复杂了。我们实际上为此使用了厨房计时器。它们工作出色，售价约5美元。
2. 要求参与者与数据和经验进行辩论。
3. 我们将选项保留在桌子上。在双方都有时间之后，我们又花了5分钟讨论每种方法的含义。20分钟后，我们出去做（实施）。如果它不起作用，那么我们采用另一种方法。

规则很简单。一旦您不知道要选择什么-考虑对公司更好的选择。

是的，选择英特尔v AMD并非易事。但是哪个对您的公司更好？例如，如果有一个人负责订购商品，并且花了很长时间才能订购基于AMD处理器的PC，但是基于Intel的产品可以在一分钟内订购，而您真的不在乎它会是什么-只需订购基于Intel的处理器，因为它对公司来说更好。

通常，这些讨论实际上只是骑自行车而已。人们在争论使用哪种传输格式或使用哪种数据存储以及大量其他细节，这些细节对于所有组件来说应该是真正透明的，但是实现这些细节的组件却是透明的。只要该组件满足设计合同，任何人都不会给出该死的，并且负责该组件的人将能够在合理的时间内响应合同的更改。

您在软件开发中遇到的所有技术问题中，绝大多数都是自行车脱落问题。仅仅因为他们已经有了解决方案，唯一的问题就是您要选择哪种解决方案。
您不应将自己锁定在这样的决定中。您应该将此类决策锁定在一个抽象层中，该抽象层将您的应用程序与此类细节分离。
软件开发中真正重要的问题是功能和系统级别的设计问题。其他一切都是次要的。

因此，甚至根本不要开始此类辩论。将精力集中在将项目分成独立的部分上。这样就产生了更加健壮和灵活的软件。并且，如果您能够查明明显的缺点（一旦拥有运行的软件，您只能做些什么）的技术决定，那么您可以做出其他决定而不会影响系统的其余部分。

标准化是一种方法

您的团队必须就他们将采用什么作为开发标准达成共识，然后在合理的时间内坚持（由团队决定）。如果该标准失败，则可能会从一批新的可能的解决方案框架中采用新的标准。

“嘿，这些PC最终没用，让我们尝试Mac！”

要么

“我告诉过你！Spring比EJB更好。”

等等。

拥有标准意味着代码变得易于在整个团队中使用，从而带来了更高产的环境。

我目前正在测试方法，代码名为“教皇的秘密会议”，它的前景很好。它是基于一个故事，在一次罗马教皇选举中出现了“僵局”，而枢机主教根本无法做出选择。举行选举的实体（很可能是一些城市专业人士）首先将红衣主教锁定在建筑物中，然后大幅度减少食物供应，然后拆除建筑物的屋顶以使辩论变得更加不舒服。不出所料，枢机主教在拆除屋顶后做出了选择，结束了三年的僵局。

所以我的方法是，当人们不同意某些东西时，他们被迫进行讨论，直到他们做出选择。我没有任何其他不适，甚至没有时间限制，当然，我对屋顶什么也不做:)。我要做的就是每天不断地提起这个问题。如果有人说“我们无法做出决定”，我会回答“嗯...您必须这样做”。到目前为止，我还没有遇到一个如此沉迷于一些次要技术细节的人。经过一堆会议之后，他们倾向于像红衣主教一样寻求妥协。

我同意这只是一个持续的讨论，而不是贯穿整个讨论。但是讨论并不是无止境的，而且，有一些人在这样的“秘密会议”之后倾向于避免进行较小的技术辩论，这使整个团队的工作变得更轻松。

我读过某个地方，如果您需要就去哪里和做什么达成一致意见，那么您不应该一起旅行不超过6人，因为您不会达成共识。

这是为什么需要一个具有决定权的人的典型例子。在此特定示例中，所述人员需要做出决定并说“它必须像这样”，而其他人则需要尊重该决定，以便可以进行实际工作。

如果后来证明这个决定很糟糕，您至少可以肯定地知道，并可以从中学习。

一种方法是通过投票，在较小规模的团队中效果很好。

虽然两个人可能正在交谈；将其移至一个开放的论坛...辩论N时间，然后举手表决。

简单而民主，可让您前进。

类似的问题可能是：

如何在论坛上停止宗教/烈焰战争？

我认为@ S.Lott在他的评论中是正确的，如果唯一的要点是“讨论”，“走开”或以其他方式忽略它可能是唯一的答案。我过去曾经使用过这种技术。

如果要提出解决方案，请权衡相关领域的利弊，设置时间限制，然后（对耐克点头）就可以了。

理想情况下-IMO-技术负责人或权威人士说：“好的，谢谢您的意见，我们正在……” 骰子声 “……随某某人的想法而来”。每个人都坐下来

微不足道的怪胎浪费了我大量的开会时间，我不想再听了。：-/

我发现，当您将谈话重点放在哪种选择是正确的而不是正确的选择上的后果上时，您往往不会陷入困境。如果我们能够达成共识，即使A是正确的，B就不会杀了我们，如果我们最终会B.如果我们没有人受到过butthurt 不能走到那共识，那通常是因为有一个现实的问题我们必须解决的问题。

最主要的是我们必须成熟，并且了解我们不能总是彼此同意，而最大的成熟事物是彼此学习，为什么我们拥有自己的职位，也许与我自己的职位有关问题，了解什么经验和原因。然后，我们就可以得出自己的见解，并且不受谴责。

我个人不需要或期望其他人同意我的看法，这很好，但并不重要。至此，我引用伏尔泰。

“我可能不同意你说的话，但我会为死而捍卫你的话语权。” -伏尔泰，五世纪哲学家

每次会议都应有一位主席负责议程并保持秩序（并花几分钟时间，但是如果会议太大而无法处理所有事情，他们可以将这项任务委派给其他人）。主席的任务是告诉某人停止争论（公司发言中的“人，请脱机”）。

如果会议不值得任命主席，那也不值得举行会议。您也可以在watercooler上聊天。

可以说“更容易完成，quant_dev”。好吧...一位自然主席是团队负责人，项目经理，团队经理。他们应该具有必要的权限。没有人知道谁真正领导会议的会议是组织混乱的迹象，这是一个更深层次的问题，需要解决。

首先解决一般问题：我们需要Web服务器，应用服务器，数据库等。

有关使用哪个数据库或服务器的辩论，请将这些项目存放在另一个会议上。

在随后的会议中，允许进行讨论以“列出”潜在产品，例如MySQl，MS SQL Server，Postgres等。

允许团队成员发表意见，但要求他们提供事实依据。产品X很烂！不削减，产品Y不缩放！太模糊了。等等。

一旦所有细节都摆在桌面上，您需要将其付诸表决，或者由团队领导做出行政决定。

如果您需要抽出明确的赢家或确认对某项功能/概念的支持/缺乏，请花一些时间进行POC（概念验证），但要意识到这将需要时间，并且开发人员倾向于想要与他们开始时的一切一起运行...在使用POC之前，请确保验证所有障碍/技术问题。

作为团队负责人，我认为这取决于是否必须在此时此地做出决定。

如果必须，那么我会寻找成本最低的产品。作为开发团队，了解您的决定可能是错误的始终很重要，您可能必须做出明智的选择并改变主意。这样做的成本应始终保持最小。

如果可以等待的话，请考虑一个事实，即没有任何不同意的当事方拥有所有事实。让他们走开，继续研究，然后自己做研究。

我们总是在战斗激烈的时候这样做吗？不，特别是当我是有强烈见解的人之一时（我并不声称自己是完美的）。但是我确实认为这是处理这种情况的方法。时间限制似乎永远不会导致每个人都同意，而只会导致一个毫无争议的争论。

除非您有一个困难的团队成员，否则通常不会有无休止的辩论，除非这两种方法都没有明显的优势。以下是打破平局的一些好方法：

• 让真正必须执行它的人来决定。
• 对于UI问题，请最了解客户需求的人员决定。
• 让对此主题或部分代码基础上最有经验的人决定。
• 由最严格的计划约束或人力和资源限制的人来决定。
• 让这个人决定谁有更具体而不是理论上的反对。
• 在这些方法之间找到折衷方案。
• 收集更多信息并在下次会议上做出决定，从而使自上次会议以来显然花了一些时间进行研究的人们更加重视。

至于如何宣布一个决定，你刚才说，“好吧，我们会用这个，因为这个。” 如果人们觉得您给了他们公正的听证会，而您又不想成为领导者，那么他们会接受您的决定。对于特别顽固的人，您可以保证在完成一定数量的实施后重新评估，但是到那时大多数人都会放弃它。

一个好的会议主持人可以促进这些类型的讨论，而又不会使它们失控。