編者按：公司的發展道路是由一個個大大小小的決定鋪就的。有時候一個錯誤決定會毀了一家公司的前途，所以決策要慎重；但有時候遲遲未決一樣會耽誤公司前途。那么如何才能做好決策，什么時候需要集思廣益，什么時候必須當機立斷，什么樣的流程才適合不同的決策場景呢？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）以供隨后審核。你可能還希望就復盤日期安排一個提醒，把所有輸入提供者都召集過來進行一次學習練習?？纯村e誤的決策是如何做出來（事后分析）的會很有趣，同時這也是為了預防歷史修正主義者（我就知道它行不通的?。?。

如果有人對決定有異議，通過電子郵件提交出去會讓大家有時間以異步的方式進行處理，這種做法要比在屋子里獲得他們的第一反應要好。

結論

艱難決定會成為許多組織的壓力來源，但這種壓力未必需要產生。在高效能的組織里，這是取得快速進步、進行創新以及取勝的機會。

把決策搞砸有很多方式，但是就像任何事情一樣，隨著時間轉移你會做得越來越好。我匯編了一個失敗模式清單，并且嘗試著給它們各自取了一個比較令人難忘的名字：

• 雜音太多：一堆的一次性對話而不是把所有的輸入提供者聚集到一起分享知識（全連接信息共享）；
• 蒼蠅王（無頭蒼蠅）：沒有選出明確的決策者，直到戰線都已經劃定；
• 最后時刻追加：在流程的后期才意識到某人應該成為輸入提供者，然后試圖偷偷加進來；
• 利益沖突：選出了一位帶偏見的決策者而不是中立的決策者；
• 手忙腳亂：在本可以委派團隊的某人時經理選自己為決策者；
• 濫用職權：經理選別人為決策者，然后在最后時刻否決他們?。ㄈ绻銢Q定授權別人的話你必須真誠地接受決策者做出的任何決定）；
• 唯唯諾諾：讓最資深/最有特權的人影響會談，而不是先聽聽別人的意見。
• 意外的同意：討論是通過電子郵件（形成+1的勢頭），一次性對話，或者匆忙召集一群忙人開的會進行的?？雌饋泶蠹宜坪醵歼_成了共識，但其實輸入提供者并沒有對決定予以適當考慮。
• 分析麻痹：決定推遲到截止日期之后做出，因為希望能收集更多的數據。（“Wimbledon做一下對比測試！”就是形式之一，如果做得太多的話。）
• 創意殺手：無法將選項枚舉與選項評估分離開來。
• 撕開邦迪：讓“沒有好的選項”阻止你選擇“最不壞”的選項。
• 流程太多：把決策流程用到低風險決定上，但其實經理馬上單方面就可以做出更快速的決定。
• 無意識民主：決策者受到壓力，選擇了投票數最多的一個選項，放棄了選擇他們覺得真正的最佳選項的責任。

這一框架已經幫助了Coinbase更快地做出更好的選擇，而且支持的人也更多了。希望你能發現這對你的團隊也有幫助。

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

譯者：boxi，由36氪編譯組出品。編輯：郝鵬程。

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

本文由 @郝鵬程 授權發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自 Pexels，基于 CC0 協議