如何停止无休止的讨论

我经常看到人们相信他们的解决方案，并认为他们的解决方案比其他解决方案要好。他们在没有确切理由的情况下为案件辩护。这些情况通常会导致漫长而毫无意义的讨论，无济于事。通常，它们会导致冲突，人们会被他人冒犯。行为。

有些人采取行动并实现他们的想法。快速行动，快速失败，更快学习。但是，当两个或两个以上的人讨论如何实施更改或使用新的炒作技术时，此方法将无效。当人们只说几句并实施新的炒作时，它常常以怨恨而告终。当我们采取行动并接受如此迅速的失败时，我们就无法对某人负责。

另一方面，有些人试图获得所有人的认可，以实施影响大型团体的事情。此策略也不起作用。因为不可能每个人都在同一页面上，因为每个人都有不同的意见。当我们试图说服所有人时，我们根本无法执行任何措施。我们只是交谈，而做出的决定比我们需要的迟。

这就是为什么我们需要在采取行动和要求人们就某个话题发表意见之间取得平衡。通过出色的过程可以实现这种平衡。我在一个旨在解决另一个问题（缺乏反馈）的组织中建立了平衡的流程。我们引入了一个称为“请求注释”（RFC）的过程。它是Internet协会（ISOC）提出的软件世界中的一种普遍反馈机制，目前正以Rust语言使用。

RFC流程使用某人撰写的有关其主题提案的文档。它有一个特定的时间表，每个人都可以提供反馈。 RFC和反馈已公开发布。每个人都可以参加讨论。目标是让尽可能多的人参与进来，以获取更多观点并同时传播知识。好消息是，人们专注于所提出的想法，并基于事实而不是仅凭信念给出反馈。另一方面，它具有更大的作用。

尽管RFC的最初目标是收集反馈，但我认为仅编写文档本身就能获得更大的收益。写作塑造思想。每个人对任何话题都有意见。但是，写下自己想法的人会根据事实将它们变成精彩的内容。

写作有助于清除思想。在撰写任何主题时，我们都会将提案与自己分开。它仍然是我们的一部分。但是，由于我们计划将其展示给公众并永远保留在那里，因此我们开始谨慎。而且在大多数情况下，我们不是从白纸开始的。

RFC流程使用模板或遵循文档中的一种标准样式。目的是帮助作者以结构化的方式解释他们的计划，同时使反馈更容易。文档的每个部分都有其自己的目标，这有助于以某种方式将意图与想法区分开。

我们使用了斯坦福大学的NABC模型。该模型首先定义需求，然后定义方法，收益，最后是竞争者。将需求与方法分开非常聪明。在编写需求时，作者必须非常了解它。方法和收益部分非常简单，作者定义了策略并列出了收益。由于大多数人在谈论想法时都将重点放在他们身上，因此也很容易编写。然后是比赛部分。这是作者必须考虑其建议书竞争对手的部分。考虑替代解决方案而不是他们的建议需要人们专注于问题，而不是盲目地热爱和捍卫他们的解决方案。通过这四个部分，NABC是一个很好的模型。但这不是唯一的。

每个人都有不同的需求。因此，格式可能会有所不同。我们的工作经理还提出了一种更简单的结构，仅需回答四个问题。这仅适用于我们的团队，而工程部门拥有RFC流程，可以覆盖更多的受众。

RFC对组织有另一个影响。该过程寻求基于共识的环境，而不是基于共识的环境。如果某些人非常关心某个主题，并且想出一份详细解释许多事情的书面文件，那么每个人都可以（并且应该）信任它们。作者不应该等待所有人对他们提议的确认。当他们获得足够的反馈时，他们应该能够继续进行或放弃这一想法。这是他们的决定。由于他们准备了文档并收集了许多评论，因此他们可以做出更好的判断。

该过程也带来了责任感。撰写建议的人应负责。当人们知道自己将要负责时，他们往往会更加谨慎地对待并认真考虑各个方面。追究某人的责任并不意味着在失败的情况下应承担责任。这仅意味着他们必须跟进他们的建议，确保其以某种方式产生结果，并在此途中回答问题。同样，在大多数情况下，RFC流程与实现流程是分开的。尽管作者对RFC本身负责，但是实现可以由不同的人员完成，并且RFC作者可能根本不参与其中。

这些以结构化方式编写想法并随后要求人们发表评论的隐秘宝石可以防止许多无休止的辩论。文化也随之改变。我们将根据事实创建讨论和解决方案，而不是无休止的辩论。这个过程阻止人们说话和无所事事。即使RFC流程本身可能并不完美，但编写足以终止无休止且毫无意义的讨论。它还有助于建立对社区的信任。因此，如果您是RFC系统的新手，请先写下您的建议。我非常确定结果会好于预期。