编者按：公司的发展道路是由一个个大大小小的决定铺就的。有时候一个错误决定会毁了一家公司的前途，所以决策要慎重；但有时候迟迟未决一样会耽误公司前途。那么如何才能做好决策，什么时候需要集思广益，什么时候必须当机立断，什么样的流程才适合不同的决策场景呢？Coinbase分享了他们的经验之道。

在本文中，我会跟大家分享我们公司用来帮助大家更高效地形成决策的一个框架。我们的核心价值观包括清楚地沟通以及高效地执行。这个框架时我们如何践行这些价值观的一个例子。

这个框架可用来决定：

• 要不要招聘一位应聘者
• 产品路线图的下一步应该优先做什么
• 要不要收购或者卖出一家公司
• 产品或者团队的新名字
• 等等……

如果艰难决定导致没完没了的开会拖慢了你的组织，伤害了大家感情，或者导致不断的时候批评的话，这个可能会有所帮忙！

此外我们还制作了一个决策模板帮助你走完这个流程。把它存到网盘上，然后复制一份就可以做决策了。

Coinbase决策流程模板

这个流程的三个步骤是：

1. 设定参数
2. 审议
3. 决策

下面我们就一个个来阐述这些步骤，不过在此之前，我们先站在比较高的角度去看看好决策和坏决策的特征是什么。

好决策是什么样的？

什么时候需要决策框架？

公司内部绝大部分的决策都是低风险的，且最终应该由那个领域的所有者做出的（比方说我们是否应该把本周的站立会议从周一改到周二）。

决策框架只有在对高风险的决策缺乏明确性的情况下才需要。高风险意味着决策存在长期影响或者如果做出了错误决定的话挽回的代价会非常高昂。

这个过程可以是相当轻量（我曾经见过从开始到结束不到15分钟的情况），但也可以用于持续数周之久的更大决策。

有经验的话，你会预先知道什么时候用这个框架会有好处。而在其他情况下，只有当你注意到出现异议或者对下一步不清楚的时候才会知道应该用这个框架。

不管是哪一种情况，一旦你决定需要这个框架时，就可以按照下面的步骤执行。

Coinbase决策框架

1. 设定参数

这一步的目的是让大家对决策如何制订达成共识。预先做好这一步是有帮助的，因为它可以争取大家的支持，并且将事后指责这种事情降到最低。

预先设定决策参数

你会注意到这几方面：

（1）决策日期

预先选定截止期限可以避免分析麻痹（为了获取更多信息而等待时间太久）。这还可以让等待这一决策出来而受阻的任何一方得到保证。

（2）重新讨论日期

让大家预先就决定的有效时间达成一致。这有助于避免过早对决定进行重新讨论。没有什么决定是一成不变的，你只时希望就何时以及如何对决定进行重新讨论达成一致。当出现决策错误的情况下，决策者也有权按下“紧急按钮”，以便对决定提前进行重新讨论。

任何决策都牵涉到3类人：

• 决策者——那些做出决定的人。
• 输入提供者——那些影响决策的人
• 受影响者——那些受到决定影响的人

输入提供者的亮相数量是在3到8人之间。超过这个数的群体讨论就会出现收益递减的情况。而决定则可能会影响到的群体范围可能会大得多（受影响者），所以应该尽量让每一个受影响群体至少都有一个输入提供者作为代表。

最后，决定也可以分成3类：

• 二元型——是/否型决定，比如招不招这个人或者买不买一家公司。
• 优先型——强制对若干选项进行排序，比如在100个选择中挑选接下来要做的5项功能。
• 选择型——在众多可能性中选择一个选项，比如一个新产品的名字。

今天就能执行的好计划胜过明天才能执行的完美计划——巴顿将军

决策者应该是1个人还是多个人？

对于大多数决策而言，我喜欢选择一个决策者以保持简单性。然而，高风险决定有多个决策者也是讲得通的（不正确的yes的代价比不正确的no的代价更高）。

就像银行可能需要多人同意才能对一大笔资金实施转账一样，你可以通过增加更多决策者并且Angular没人偶拥有否决权而对高风险决策进行“控制”。这意味着一个yes决定只会在每个决策者均同意的情况下才会发生。

如果你再极端一点要求全体输入提供者也要一致同意的话，则（决策）的潜在坏处就会降到最低，当然好处也会受限（“委员会构思”）。实际上，在某些领域yes决定有时候会像是一种逆势操作，这种情况下群体意见时不大可能同意的，所以有时候太过保守是十分危险的。

要权衡好这些利弊，为你的特定决定找到合适的决策者数量。

权衡决策者数量的利弊

一般而言，如果一个错误决定的代价是可以容忍的话，那就选择一个决策者以便利用好速度的优势。如果一个错误的决定代价太过高昂无法逆转的话，那就增加更多的决策者。

2. 审议

接下来你需要把所有的输入提供者聚到一起共享信息，然后获得他们的投票。

审议步骤的样例，这一步用来获取投票，以及对每一选项的优缺点：

（1）列举选项

这里对选项进行小型的头脑风暴。先求量，把判断推迟。让每个人都创造性地进行思考。一旦完成这一步，看看是否可以将一些重复的选项合并。注意：如果你进行的是二元型的决策的话这一步可以跳过，因为你已经知道选项了：只有是或否。

（2）展示数据

如果有从客户、对比测试、法律团队、外部顾问等处收集到的数据，现在就是将这些数据呈现给决策组的时候了。理想情况下这些会作为预读材料在会议之前提供给相关人员审阅。

（3）第一个投票轮（盲投）

进行第一轮投票（来自输入提供者），先估量一下大体情况，理想情况下是任何人事先都没有看到其他人的投票。对于二元型的决定来说，可以倒数3声让屋子里的每个人同时拇指向上或者向下。对于优先型或者选择型决策来说，让每个人在电子表格上分配自己的投票（鼓励他们不要看其他列）。

（4）讨论优缺点

把屋子里的每个人，从最底层到最资深的人都找来谈谈，问问为什么他们要这样投票。进行自由形式但时间限定的讨论。以备注的形式把每一选项的优缺点都记录下来。鼓励每个人发言，要有好奇心，并且学到新东西。这个阶段你经常会发现你列举的不同选项之间会有一些不是非黑即白的灰色部分，并没有明确的“最佳”选项。你可以继续升级这一清单，增加或者合并选项。

（5）第二轮投票

最后，当每一位输入提供者都听到了别人的想法（全连接的信息共享）之后，请求进行第二轮投票，看看有没有人的投票改了。把这一轮投票的结果记录在电子表格上以供后用。

到这一步偶尔会出现大家意见一致的情况，这时候决策者的工作就简单了。他们只需要把决定知会一声流程就结束了。不过更通常的情况是，决策者得走到最后一步。

必要的话，你还可以进行额外轮次的讨论和投票，不过要在决策日期的截止范围内。

3. 决策

记录决策以供后用

（1）做出决策

决策者现在可以用1、2天的时间审议输入，然后做出最后决定。即便没有明显的“最佳”选项，他们也要在决策截止日前前做出决定。

（2）传达决定

把决定发邮件给所有受到决定影响的人。把输入提供者清单、考虑过的选项，概要理由（优缺点）以及重新考虑决定的日期作为附件列进去。你不需要把谁投了什么列进去，因为到了这个点上作为一个统一的团队你们已经达成共识，翻篇了。

（3）记录决定

最后，把电子表格保存到一个永久性的地方（比如Google Docs）以供随后审核。你可能还希望就复盘日期安排一个提醒，把所有输入提供者都召集过来进行一次学习练习。看看错误的决策是如何做出来（事后分析）的会很有趣，同时这也是为了预防历史修正主义者（我就知道它行不通的！）。

如果有人对决定有异议，通过电子邮件提交出去会让大家有时间以异步的方式进行处理，这种做法要比在屋子里获得他们的第一反应要好。

结论

艰难决定会成为许多组织的压力来源，但这种压力未必需要产生。在高效能的组织里，这是取得快速进步、进行创新以及取胜的机会。

把决策搞砸有很多方式，但是就像任何事情一样，随着时间转移你会做得越来越好。我汇编了一个失败模式清单，并且尝试着给它们各自取了一个比较令人难忘的名字：

• 杂音太多：一堆的一次性对话而不是把所有的输入提供者聚集到一起分享知识（全连接信息共享）；
• 苍蝇王（无头苍蝇）：没有选出明确的决策者，直到战线都已经划定；
• 最后时刻追加：在流程的后期才意识到某人应该成为输入提供者，然后试图偷偷加进来；
• 利益冲突：选出了一位带偏见的决策者而不是中立的决策者；
• 手忙脚乱：在本可以委派团队的某人时经理选自己为决策者；
• 滥用职权：经理选别人为决策者，然后在最后时刻否决他们！（如果你决定授权别人的话你必须真诚地接受决策者做出的任何决定）；
• 唯唯诺诺：让最资深/最有特权的人影响会谈，而不是先听听别人的意见。
• 意外的同意：讨论是通过电子邮件（形成+1的势头），一次性对话，或者匆忙召集一群忙人开的会进行的。看起来大家似乎都达成了共识，但其实输入提供者并没有对决定予以适当考虑。
• 分析麻痹：决定推迟到截止日期之后做出，因为希望能收集更多的数据。（“Wimbledon做一下对比测试！”就是形式之一，如果做得太多的话。）
• 创意杀手：无法将选项枚举与选项评估分离开来。
• 撕开邦迪：让“没有好的选项”阻止你选择“最不坏”的选项。
• 流程太多：把决策流程用到低风险决定上，但其实经理马上单方面就可以做出更快速的决定。
• 无意识民主：决策者受到压力，选择了投票数最多的一个选项，放弃了选择他们觉得真正的最佳选项的责任。

这一框架已经帮助了Coinbase更快地做出更好的选择，而且支持的人也更多了。希望你能发现这对你的团队也有帮助。

原文链接：https://medium.com/@barmstrong/how-we-make-decisions-at-coinbase-cd6c630322e9

译者：boxi，由36氪编译组出品。编辑：郝鹏程。

译文地址：http://36kr.com/p/5134159.html

本文由 @郝鹏程 授权发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自 Pexels，基于 CC0 协议