有一種讀書方法，叫「把書讀薄」，就是看完書後根據自己的理解和認識寫讀後感。這篇文章就是一個典型的例子，作者讀完書後，根據自己的理解和自身案例，寫出了一篇參考意義非常大的文章，希望可以幫到大家。
【怎樣做成大事】作者收集了25個不同行業（如國防、建築、核能、航空、奧運會等）的1.6萬個大型計畫發現：
如何達成預期目標？作者提出了 「慢思考，快行動」 的方法論，以及 「模組化」 的解決方案。
這本書帶給我很多啟發，仿佛打通任督二脈一般，所以今天分享給你，希望對你有啟發。
一、一個失敗的計畫
2023年9月初，我們立項透過了一個大型計畫（代號：S）。
S計畫在產品方案階段歷時1個多月，前後推翻了3個版本後，磕磕絆絆進入研發階段；
2024年2月下旬提測，但在3月下旬測試進度完成40%後，因方案的使用者復雜度、計算的精確度與後期維護成本等原因決定放棄。
計畫投入7、8個人，歷時近5個月，損失近百萬。
為什麽會這樣？
當計畫階段性復盤時，我們發現的都是執行階段的問題。
比如產品經理需求文件不清晰，溝通後也更新不及時，導致研發過程中進度被影響；
比如現有系統復雜度太高，基於當前架構，無法有效控制研發周期與最終效果，導致無法達到預期目標；
或缺少計畫經理角色，無風險預警與管理，才導致工期延誤。
事實卻並非如此，它大機率是失敗於計畫立項之前。
二、策略性虛假稱述與沈沒成本才是主因
S計畫由一位領導主抓，其在2023年下半年時承諾某標桿客戶A，將於2024年3月底之前上線。
當承諾過後，剩下的就是實作，這是一種策略性虛假稱述。
策略性虛假稱述是指出於策略性目的而有意的、系統的歪曲或錯誤稱述資訊的傾向
比如領導為了挽留這一家標桿客戶，策略性選擇把它當做通用需求做，並尋找相關需求來作證通用化的必要性。
前期先讓產品經理介入方案設計，中間反復溝通，確認初版方案時，已經到了2023年10月；
為確保方案可行，提前讓研發同學介入評審，發現方案不可行，又反復調整了兩個版本，時間又過去了一個多月；
伴隨著沈沒成本的不斷累加，所有人（研發/設計/測試等）都已經被卷進來，每個人心裏都覺得有問題，卻礙於沈沒成本與權威，只是私下抱怨，卻無人說推翻方案。
研發2個多月後提測，誰都無法保證品質與效果，直到臨近截止日期，無法如期交付，最終只能登門拜訪當面道歉後，重新設計新方案，再次承諾2024年6月底解決。
如何才能避免這類事情的發生？
三、慢思考，快行動
林肯曾經說過：如果我有5分鐘砍一棵樹，我會用3分鐘來磨刀 。這就是我們常說的「磨刀不誤砍柴工」，也是「慢思考，快行動」的本質。
與之相反的是「快行動，慢思考」，就像上述案例一樣，前期好像行動迅速，實際評審、研發、測試階段卻問題不斷，最終導致計畫失敗。
什麽才是「慢思考，快行動」？
1. 以終為始，從右往左思考
因思考慣性，我們的思考習慣是從左往右。
左邊是什麽？是看得見摸得著的產品方案（且大機率是第一個方案），是眼前的這家標桿客戶；
右邊是什麽？是為什麽要立項？計畫目標是什麽？有最佳解決方案嗎？
為什麽S計畫要立項？
因為這是一家標桿客戶，且領導已承諾？顯然不應如此。
計畫目標是什麽？
目標是解決標桿客戶的需求，還是解決所有類似客戶的需求？
如果是前者，則解決方案可以用更低成本的方式；
如果是後者，那其他客戶的需求是什麽？對應解決方案能覆蓋嗎？
實際情況是：有3-4家客戶有同類需求，但實際業務規則差異非常大，根本無法通用化處理。
當前是最佳解決方案嗎？
從評審反復近1個月到研發時間2個多月，測試1個多月排期確認時，基本已經說明方案的可行性，卻因沈沒成本而忽略風險而繼續投入，直到崩潰。
吃一塹，長一智。
下次如何避免此類問題？
我提煉了一個大型計畫（1個月以上工期）的 需求分析表 （如下圖），以及兩個產品原則。
原則1：產品經理應該把50%以上精力放到立項之前，只有慢思考，才能快行動。
原則2：但凡計畫工期超過2個月，則重新思考方案或分拆子計畫。
2. 最大虛擬性產品
互聯網行業推崇的是：最小可行性產品，而現實世界的大型計畫卻推薦：最大虛擬性產品。
關鍵區別在於：時間周期與成本。
如果做一款互聯網產品，時間周期短，可用最小成本驗證需求後，逐步叠代，使用者是可接受的；
如果是拍一部電影、建一棟樓等，時間周期長，投入巨大，這就需要用最大化虛擬性產品。
它的本質與最小可行性產品一致，即盡可能用更小的成本驗證需求，獲取反饋後叠代方案，但為了保證驗證效果，則應采用更逼真、更精細化的方案。
比如建築行業的數位建模與實體模型，它不是最小可行性產品，而是一個超逼真、細節極其精細的產品（即最大虛擬性產品）；
或者是電影行業的模擬視訊，它是有一幀幀真實畫面構建而成，所有圖片細節都是逼真的，所有動效都是真實的，這是最大虛擬性產品。
那對於互聯網產品來說，最小可行性產品與最大虛擬產品的界限在哪兒呢？
最小可行性產品更適用於C端產品，而最大虛擬性產品更適用於B端產品（尤其是大型計畫），它的形態可以是逼真、有細節數據、有真實互動的原型方案。
是的，它在前期非常耗時耗力，但也是綜合成本最低的方案。
因為計畫研發前的工作，最多只是浪費產品經理的時間精力，而立項透過後，將浪費設計、研發、測試等同學的時間精力，後者成本是前者的N倍
所以我才提出：產品經理應該把50%以上精力放到立項之前。
具體把時間花在哪呢？
- 透過調研、分析等方式，明確需求（需求是1，方案是0）；
- 思考並完成需求分析表，明確為什麽做與目標；
- 制作最大化虛擬性產品，與使用者完成反確認，並基於反饋反復打磨它。
3. 一個成功的計畫
即我入職時接收到的任務目標是：全面研究競品，重構考勤系統。
經過【需求是1，方案是0】的方法論指引，最終選擇的並非重構路徑，而是有效解決客戶需求的方案。
當時也犯了一個錯誤，初審時的產品方案太大（評審3個小時才完成一半）。
初審完成後，及時止損，重新把方案拆分為5個獨立可上線的子計畫，逐步叠代，最終歷時近8個月，全部如期上線。
現在復盤成功經驗的話，至少有三個方向決策正確：
這背後的本質，就是「慢思考，快行動」在互聯網行業的踐行（尤其是面向企業端產品）。
所以我才提出：但凡計畫周期超過2個月，就需要重新設計方案或拆分子計畫。
4. 模組化
最後，再聊一聊模組化。
互聯網行業推崇的是：小步快跑，快速叠代的最小閉環產品原則，以及相互獨立且自我閉環的微服務設計。
同理，實體行業則推崇：模組化。
它的本質是重復與抽象。
每一個流程則由：型別、觸發條件、觸發節點、觸發物件等元件組合而成，按需配置。
有了流程，剩下就是物件導向。
每個流程會面向一個或多個物件，同時流程流轉又會對物件產生資訊流，遵循領域設計原則，把每個物件的流程與記錄獨立封裝，即可形成一個物件的詳情。
比如員工調薪是一個流程，它作用物件是員工，操作物件是薪酬專員，可以根據需求配置不同流程節點，流程結束後，員工花名冊跟薪資檔案資訊同步更新。
同時，當把架構設計抽象為流程和物件之後，產品頁面也可抽象為幾大類：流程配置頁、流程流轉頁面、物件詳情頁等，實作整個系統的操作體驗一致性。
四、總結
大型計畫為什麽容易失敗？
人們習慣策略性虛假稱述與心理因素導致的沈沒成本，所以采取「快行動，慢思考」導致。
如何解決？
采用「慢思考，快行動」的方式，具體可包含：
1、以終為始，從右往左思考 。如果套用到互聯網行業，則可用一個大型計畫需求分析表，以及遵循兩條原則：
2、最大虛擬性產品 。實施落地前，透過更精細的、更逼真的產品，驗證使用者需求，打磨所有細節，而不一定采取最小可行性產品。
3、模組化 。它的本質是重復，透過抽象與設計不同的「積木塊」的方式，實作模組化，從而保證品質，提升效率，降低成本。
本文核心方法論，主要來自於丹·加德納教授的 【怎樣做成大事】 一書，書中有更詳實的論證，更精彩的案例，更逼真的細節，更引人入勝的文筆，推薦你親自閱讀。
專欄作家
邢小作，微信公眾號：邢小作之家，人人都是產品經理專欄作家。一枚線上教育的產品，關註互聯網教育，喜歡研究使用者心理。
本文原創釋出於人人都是產品經理。未經授權，禁止轉載。
題圖來自Unsplash，基於CC0協定
該文觀點僅代表作者本人，人人都是產品經理平台僅提供資訊儲存空間服務。
