事情的起点，是 Go 仓库里一个很普通的 issue（golang/go#77273）。
在 Go 这种量级的开源项目里，每天都有人提出各种各样的提案：增加一个语法糖、调整一处行为、复活一个曾经被否决的设计……其中有相当一部分，是在重新提起一个早已被讨论过、并且已经下过结论的话题。
对维护者来说，这是一件很消耗精力的事。如果每个人都可以无限次地把一个已经决定的问题重新拉出来辩论一遍，那么决策永远不会真正「落地」，团队会被无穷无尽的回锅讨论拖垮。
于是，在这条 issue 的讨论里，有人贴出了 Go 官方提案流程（go.dev/s/proposal）中的一段话：
一般来说，对于「重新审议此前已经决定的提案」这件事，我们的做法遵循 John Ousterhout 在他那篇 Open Decision-Making 中给出的建议，尤其是其中「Reconsideration（重新审议）」那一节。
换句话说，连 Go 团队这样的顶级工程组织，在「怎么做决策、决策之后还要不要重新讨论」这件事上，引用的也不是某套高深的管理学理论，而是 John Ousterhout —— 也就是写《软件设计的哲学》那位斯坦福教授 —— 的一篇博客。
那一节的核心其实只有一句话：当有人想推翻一个已经做出的决定时，先问一句 「你掌握了什么新的信息？」（What new information do you have?）。如果没有新信息，那就不必重新讨论；如果有，那随时欢迎修正。
这套关于「决策」的方法论，远不止「要不要重新讨论」这一个点。Ousterhout 在这篇文章里，系统地讲了他在两家创业公司里摸索出来的一整套**开放式决策（Open Decision-Making）**框架。
下面是这篇文章的完整翻译。
作者：John Ousterhout，斯坦福大学计算机科学系教授
原文：Open Decision-Making
最后更新：2021 年 6 月 8 日
在创办并领导两家创业公司的过程中，我亲历过形形色色的决策：有些成功，有些惨败。回过头看，那些好与坏的结果背后，其实有一套可以总结的规律。我逐渐形成了一套自己偏爱的决策方法，它处在「集权 — 开放」这条光谱中相当靠近「开放」的那一端：与其依赖少数几个人拍板，不如尽可能去汇聚许多人的集体智慧。
很多管理者对这种做法心存疑虑，担心它低效、担心自己失去掌控。但我的经验恰恰相反：
衡量一个决策流程的好坏，有三个目标：
这三个目标之间是有张力的、会互相牵扯，但任何一个都不能被彻底牺牲掉。
为什么效率重要？因为如果你非要等到信息百分之百完备才肯下决定，那等待本身的代价会高得离谱 —— 现实世界里，你永远不可能掌握全部信息。
为什么认同重要？因为一个无法被执行的决策，等于白做。如果做决定的人和执行的人各想各的，那么之前所有讨论的功夫都打了水漂。
我把整个过程拆成四步：广泛收集意见 → 推动达成共识 → 清晰地宣布 → 没有新信息就不再翻案。
广泛地收集意见，既能提升决策的质量，也能提升大家的认同感。
我推荐一种「宽 — 窄 — 宽」的会议节奏：
这里有一条很关键的原则：意见一定要在它还能改变结果的时候去征集。 如果你已经基本想好了，才走个过场去「问问大家的意见」，那不叫征集意见，那叫「索要认同」—— 大家心里都清楚，也会因此反感。
另一条反直觉的建议是：尽早把那些最有主见、意见最强烈的人拉进来，而不是把争议往后拖。很多管理者本能地想避开「刺头」，但越早暴露分歧，处理起来越容易；拖到最后，分歧只会变成爆炸。
当然，广泛征集意见也绝不能成为「决策拖延」的借口。
把关键的人聚到一起，讨论，然后投票。具体做法：
我个人倾向于公开投票，而不是无记名投票。
投票之后，会出现三种结果：
关于第三点，我有一段很惨痛的自我反省：在我职业生涯里几乎每一次「推翻团队共识」的决定，事后都被证明是我错了。 唯一一次成功的例外，是我们招了一个面试表现很差、但入职后表现极其出色的工程师。
这让我得出一个信念：最好的决策是被「识别」出来的，而不是被「制造」出来的（the best decisions are recognized, not made）。 你的任务不是凭空创造一个答案，而是营造一个环境，让那个本就正确的答案自己浮现出来。
把决定明确地公之于众，消除一切意外和「我怎么不知道」的情况。
对于一个确实错了的决策，要乐于、并且迅速地去纠正它。
但是，对于一个已经定下来、并没有错的决策，在没有新信息的情况下，不要反复重开。我应对这类「我想再讨论一下」的标准回答永远是那一句：
「你掌握了什么新的信息？」（What new information do you have?）
如果没有新信息，就不该重新讨论；如果有，那随时欢迎。
而且你会发现：只要前期的意见收集做得足够好，需要事后翻案的情况自然就会大大减少。
（译者注：这一节，正是本文开头那个 Go issue 所引用的部分。Go 官方的提案流程，处理「重提旧议」的方式，就是照搬了这套逻辑。）
1. Electric Cloud 的招聘流程。
每个面试官把对候选人的优点和缺点列在白板上，然后用一个 7 分制来投票。这里最关键的，是「positive（5 分，正面）」和「enthusiastic（6 分，热切支持）」之间的那道分界线 —— 如果一个候选人一个 6 分都没拿到，就不发 offer。事实反复证明：那些拿了低分的候选人，最后几乎都会让你后悔。
2. 「眨眼测试」（the blink test）。
对于像「给产品起什么名字」这类问题，与其反复纠结，不如让大家凭第一反应、凭直觉快速表态，借此迅速把一长串候选项砍短。
3. 高频投票（我们戏称为 "ouster-votes"）。
我习惯用大量快速的投票来感知群体的真实倾向 —— 小到团队例会，大到全公司大会，甚至上千人的行业大会现场，我都用过。
我记得有一次选公司 logo，一位员工一眼就看出某个候选方案「长得像一只羊的屁股」，一句话就帮公司避开了一个糟糕的选择。而且我发现，群体越大，投票的结果往往越好，大家的认同感也越强。
1. 害怕反馈（Fear of Feedback）。
缺乏安全感的管理者，会本能地压缩意见征集的环节，直接宣布结果，并且抗拒事后的任何批评。结果就是：又做出了糟糕的决策，又积累了团队的怨气。
2. 暗箱决策（Stealth Decision）。
管理者中途叫停流程，悄悄地把决定做了 —— 通常是为了回避一场公开的「推翻共识」。但消息总会走漏，大家会因为两件事而愤怒：一是自己的意见被无视了，二是这种偷偷摸摸的做法。
更好的做法是：把投票走完。如果你确实想推翻它，那就公开地推翻，给出解释，必要时道个歉。光明正大，远比鬼鬼祟祟好。
3. 草率收场（Premature Conclusion）。
讨论得含含糊糊，就宣布「好，那我们就这么定了，大家都同意吧？」—— 结果很多人一脸懵，事后才发现自己「被同意」了。
正确的做法是：先把选项理清楚，然后用直接的提问去快速确认大家是否真的达成了一致，而不是靠模糊的氛围去「脑补」共识。
管用的场景：
不管用的场景：
另外，这套相对「重」的流程，最值得用在那些重要的、影响面广的、或者难以逆转的决策上。至于那些影响很小、随时可以改回来的小决策，快速拍板就好，错了再改。
与「开放式决策」完全相反的，是「独裁者（Dictator）」风格 —— 极少征集意见，频繁推翻他人。
这种风格，只适合极少数拥有超凡直觉的天才型领袖，比如 Steve Jobs、Lee Iacocca。对于他们，我有两个一直没想明白的困惑：
两种风格（开放 vs 独裁）其实都能带来「组织内部的高度一致」。但我坚信：能成功扮演独裁者的人极少极少，因为那要求你几乎永远是对的 —— 这对绝大多数人来说，是不可能的。
开放式决策，依靠的是集体的智慧，以及一套非层级化的流程 —— 答案不是从上往下压下来的，而是从充分知情的讨论中自然生长出来的。
领导者并没有袖手旁观：他通过快速投票来感知群体、通过果断地打破僵局来维持效率。
而这整件事里最难的部分，恰恰是去学会信任这个流程：
管理过程，而不是管理结果；结果自然会照顾好它自己。（Manage the process, not the outcome; the outcome will take care of itself.）
最后，开放式决策带来的，远不止「一个更好的决策」而已。它还会反过来强化你的组织文化、社群归属感，以及那种「这是我们共同的事」的责任感。
译者后记：从一个 Go 的语法提案 issue，顺藤摸瓜摸到 John Ousterhout 这篇写于多年前的博客。我们写代码时讲究「为什么这么设计」，其实「怎么做决定」同样是一门需要刻意打磨的工程。下次当你想推翻一个已经定下的方案时，不妨先问自己那句话：我，掌握了什么新的信息？
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。