无王而治：如何在一个扁平组织高效地做出好的决策？

在Doist公司，我们相信开放和真诚的沟通可以改善我们的决策过程。这就是为什么我们建立了这样一种文化，从纯技术解决方案到团队建设和产品管理，在所有决策级别我们都鼓励大家提出反馈意见。我们建立了团队沟通的 APP——Twist，大家围绕公共话题可以进行热烈讨论，这使得我们和其他远程工作的团队都能达到较高程度的透明性和参与性。

刚开始，我们曾经以为，收集到的意见越多，决策就会越好。这个想法确实天然地符合工程学的精神气质，因为更多的数据意味着更好的决策。

然而随着团队的成长，我们认识到，有时好事成堆就不见得是好事了。曾经看到一位设计师向团队征求关于 Twist APP 的 logo 草图的反馈。突然间，所有人都摇身一变成为了字体和 logo 专家（感到内疚的是，我也是其中一员），然后大量反馈汹涌而至。

作为 Doist 后端团队的领导，我认为这种过量反馈是对我们团队高效运转能力的一大挑战。实在有太多反馈意见需要处理了。越来越多的时间花费在回应反馈上，而不是执行决策上。就在那时，我无意中看到了一份详细阐述“粗略的共识”（rough consensus）原则的文档。

粗略的共识

互联网工程任务组（IETF）是一个会员制的组织，由设计人员、运营人员、设备商和研究人员共同组成，他们开发的标准将互联网塑造成如今人人使用的通信工具。他们的主要决策原则是由 Dave Clark 在 1992 年提出的：

我们拒绝：国王、总统和投票。

我们相信：粗略的共识和运行的代码。

我一直很好奇“粗略的共识”是什么意思。而且，人们如何知道已经达成了一个“粗略共识”呢？

后来才发现，有一份名为“RFC 7282：IETF中的共识和异议”的文档，详细地解释了 IETF 决策方法背后的流程和思想。这篇 RFC 提供了非常实用的指南，指导人们如何推进技术讨论，在避免无意义延误的情况下，围绕解决方案达成共识。这份文件对我们所有人都是极有帮助的，尤其是对于产品和团队的领导而言。

IETF 和所有技术团队其实有共通之处，在塑造产品和细化其组件行为时，面临着相同的挑战。正如这篇 RFC 文档所述：

“工程中总是会有一系列权衡。几乎可以肯定的是，在工程中任何需要做出抉择的时候，总会有一些选项对一些人有吸引力，但对另一些人却没有吸引力。”

于是问题就变成：在没有明显正确答案的情况下，一群人如何在没有“国王”的情况下做出最佳决策？首先，有必要让大家就如何做出决策达成共同的理解。

用“嗯哼”来投票

在 IETF 中，投票时他们有时会用发出“嗯哼”的声音来代替举手。这样做的目的是让投票变得更加匿名，同时也是为了抵制仅根据投票数量就做出决定的诱惑。正如 RFC 文档中所强调的，众人交汇的“嗯哼”音量大小，给了会议主持者一个试探整体意见风向的机会。但这只是他们用来推进讨论的一个工具，绝非结束讨论的手段。

虽然由于显而易见的原因，通常远程团队不能直接照搬这种方法，但这个方法确实展示了粗略共识背后的一些主要原则，以及这与“自顶向下”、“少数服从多数”这两种决策过程的重要区别。

两种反馈：“非最佳选择”和“有根本性缺陷”

粗略的共识依赖于对两种反对意见的区分：

1. “非最佳选择”的反馈：“我不认为解决方案 A 是最佳选择，因为 XYZ 这几条理由。我相信方案 B 会更好，但是我也可以接受方案 A。”

2. “有根本性缺陷”的反馈：“我认为解决方案 A 是不可接受的，因为 XYZ 这几条理由。”

粗略的共识并不是少数服从多数决策原则。如果某一个解决方案，并非全体人员赞同，甚至大多数人都认为它不是最好的选择，仍然可以继续讨论这个方案。“非最佳选择”的意思是，虽然相信有更好的方法来解决问题，但你也认为这个方法会奏效。这种类型的反馈应该被鼓励，但不应该因此拖慢决策过程。

另一方面，在这次讨论结束之前，探讨和解决所有的根本性缺陷是至关重要的。根本性缺陷代表着一些关键问题，带有这种致命缺陷的解决方案应该被舍弃。确实很难定义什么是根本性缺陷，但有几个可供参考的出发点如下：

• 它将大大增加技术债务。

• 它的可扩展性不强（除非在特定情况下对可扩展性并无要求）。

• 它需要极大的工作量来实现，并且不能证明该解决方案所增加的价值。

这个可供参考列表并不完整，其他团队自然会以不同的方式来定义一个根本性缺陷。例如，基于我们团队价值观中对用户时间、注意力和意愿的尊重，产品设计团队可能认为，任何会不必要地分散用户注意力的解决方案都存在根本性缺陷。基于我们公司将保持独立自主和可持续发展作为首要考虑，团队经常会认为任何成本超过收入的解决方案都存在根本性缺陷。

所以，对于一个组织来说，重要的是先要对“根本性缺陷”的定义有一个共同的理解，再去对提出的解决方案展开讨论。即使这个定义随着时间的推移而不同，但讨论前有共同理解也是很关键的。

征询意见的艺术

如何确保根本性缺陷得到充分的解决，而又不会被无关紧要的反馈淹没或拖慢速度？当讨论陷入僵局时，IETF 是这样建议达成粗略共识的：

一个会议主持问：“每个人都同意方案 A 吗？”，不出意外地，会听到一些反对声音。但如果一个会议主持问：“有人绝对不能接受方案 A 吗？”， 很有可能听到一些人会说：在某些限制条件下，方案 A 是不可能实现的。反对者可能会说服工作组的其他成员，让他们相信这些反对意见是站得住脚的，然后工作组可能就会根据这些讨论做出不同的选择。

正如您所看到的，反对者不能简单地说“我不喜欢方案 A”，甚至不能提供他们认为更好的替代方案来进行反对，他们必须首先证明为什么方案 A 有根本性缺陷。

一旦每个人都能接受某个给定的解决方案，即使存在有明显的异议，但也算是已经达成了粗略的共识。

妥协

这篇 IETF 的 RFC 文档花了很多笔墨专门讨论妥协问题，还为之区分了两种类型：

遗憾的是，“妥协”这个词有两种不同的用法。在工程中总会涉及权衡：例如，我们可能不得不在处理器速度上做出一些妥协以降低功耗，或者在吞吐量上做出妥协以降低流量拥塞带来的阻力。诸如此类的妥协是工程中种种抉择的一部分，它们是意料之中的，也是必不可少的。

然而，还有另一种意义上的“妥协”，它只涉及人与人之间的妥协，而与工程原理毫不相干。例如，团队中少数人可能会反对某个特定的提议，即使在讨论之后，他们仍然认为该提议存在严重问题，但是他们觉得自己并没有精力去为之争辩和反驳，就说：“那就算了，就按你们说的来吧”。这当然也可以称为妥协，但实际上他们所做的一切是一种屈从。这就不算达成共识，因为还有尚未解决的反对意见。

同样，如果反对的理由仅仅是觉得这个选择并不算完美，但在其他方面还是可以接受的，那么这样的妥协是可以接受的。但是，当存在真正未解决的技术异议时，弃权让步并不是达成共识的有效手段。

有时候，面对一个讨论得热火朝天的话题，你忍不住加入讨论并提出一些你的个人“拙见”。可能的情况是，这些见解要么是不值一提的老生常谈，要么是需要进一步解释才能完全站得住脚的观点。

在后一种情况下，决策者可能会忽略你的反馈，因为他们不能充分理解你的意见，或者不得不花时间做出一些后续跟进才能找到你反对的根源。所以，你需要尽可能提供他们需要的信息，以便他们预先对你的论点做出评估。如果你认为你的反馈很重要，那就勇敢说出来，并从一开始就花额外的时间来解释和捍卫你的立场。

这在远程团队的工作环境下中尤其重要。在这样的环境下，我们并没有便捷的来回沟通来阐明一个观点，所以一个人随意提出的一点意见就有可能会严重拖慢决策过程。

如果你觉得根本不值得花费过多时间为你的一个观点去沟通，那么这个反馈或许并不值得提出来去拖慢讨论的速度。

粗略的共识与我们宣扬的完美主义相矛盾吗?

与粗略的共识方法形成鲜明对比的是，“只要不是绝对的‘是’，那就是‘不’” 这样非黑即白的严格标准。我们在招聘时会使用这样的标准，即除非每个人都非常赞同某个候选人入选，否则就拒掉这个人。然而，我认为，对于我们工作中遇到的大多数技术和产品相关的挑战，为决策过程采用宽松一些的标准是可以接受的，甚至很多时候是必要的。

我们可能会在招聘和其他决策中使用这种“非黑即白”的原则，但一般在交付产品时，我们会使用快速迭代原则。我们不会在第一次交付就追求完美，我们快速构建、交付、学习、迭代，然后再一次交付。一步一步，我们就能到达我们的目标。如果将完美的标准和达成完全一致的共识套用到我们的产品交付上，我们的步伐就会变得呆滞迟缓。

幸亏采用了“非黑即白”的高标准来进行招聘，所以我们能够完全信任所有参与决策的人的能力和勤奋。是的，在达成粗略共识的情况下，我们确实有可能没有做出最佳选择，但如果决策者认为这是当前的最佳解决方案，我们就充分信任这个方案能奏效。

即使这不是最好的决定，最终由于我们运作速度的提高，就平均意义而言，这会抵消其间所遇到的挫折。当我们为了达到完全一致共识而推迟决定时，反而会冒更大的风险。

粗略的共识并不意味着我们在解决方案的具体实施中不去追求完美。在实施过程中，我们应该始终追求技术上的卓越。但往往正是因为实施过程中坚持追求卓越，常常把原本不完美的解决方案打磨成正确的解决方案。这类似于 Amazon 公司的“不同意但依然致力做好”的哲学。

从 IETF 粗略的共识中可以学到什么（为什么要分享这些内容）

IETF 案例很好地说明了具有不同结构和文化的组织如何解决普遍的决策问题。

我不是建议我们对所有的决策都采用粗略共识的方法。毕竟我们不是 IETF，我们组织的目标和结构和 IETF 完全不同。然而，我依然认为我们可以从他们的经验中吸取宝贵的教训。

我们的目标是维持一个相对扁平、透明和包容的组织。因此，基于共识的决策比自上而下的决策更理所当然。我们如何在保证快速决策的同时充分发挥广纳谏言的优势?

粗略的共识是一个很好的标准，可以确保次要评论或非关键问题不会影响团队绩效，随着越来越多的声音加入到团队中，这是一个非常有效的工具。

以下是让决策过程变得更高效的一些具体建议：

• 如果你是那个对解决方案提出异议的人：

• 在你提出反对意见之前，先衡量一下你的反对意见是否反映了一个严重的问题。你可以这样做出评论：“我相信有比这更好的决定，但我也可以接受目前的选择。” 还可以在不否决当前选择的情况下，对该方案或其实施提出改进性建议，比如一起讨论 pull request。首先得弄清楚你提出的反对意见是什么类型的。

• 如果你认为这个选择有阻塞性的致命缺陷，试着让你的反馈意见表达得尽可能清晰，这样决策者才能对它进行正确处理。

• 如果你认为这个选择有阻塞性的致命缺陷，试着找出足够的时间和精力去说服意见上的对手。在明确非关键性反馈和根本性缺陷之间区别的情况下，你会优先考虑提出根本性缺陷的相关意见，这样就能把时间和精力放在最重要的讨论上。

• 如果你是那个做决策的人：

• 时刻保持警惕，确保讨论不会因为非关键性的“不是最佳解决方案”的反馈而停滞不前。

• 如果有一场讨论始终无法达成共识，请参会者澄清针对一项建议的反对意见是否真的涉及到不可忽视的根本性缺陷。

• 如果有一个足够好的方案 X，不要问人们对此怎么想。相反，问问每个人是否能接受这个方案，如果不能接受，为什么。

• 不要认为非得遵从默认的“少数服从多数”原则。

共识只是道路，而非终点

最后引用 IETF 文档中的一句：

在 IETF 里，我们从不认为努力达成共识就算结束了。当我们做出决策时，把建立共识作为获得最佳技术或程序成果的一种工具。

在 Doist 公司，我们努力创造一种文化，每个人的反馈意见都会被倾听。我们相信我们因为这种文化会越来越强大。但正如我们所知，这需要参与讨论的各方都做出努力和调整自我意识。我们依然任重道远，但粗略共识的原则可以有助于我们在所有决策过程中去平衡反馈和效率。

英文原文：

https://doist.com/blog/decision-making-flat-organization/