慢思考,快行動:怎樣做成大事?
有一種讀書方法,叫“把書讀薄”,就是看完書后根據自己的理解和認識寫讀后感。這篇文章就是一個典型的例子,作者讀完書后,根據自己的理解和自身案例,寫出了一篇參考意義非常大的文章,希望可以幫到大家。
《怎樣做成大事》作者收集了25個不同行業(如國防、建筑、核能、航空、奧運會等)的1.6萬個大型項目發現:
- 在預算、成本與收益三個方面,只有0.5%的項目達成預期目標;
- 在預算、成本兩個方面,也只有8.5%的項目達成預期目標;
- 僅預算一個方面,也只有47.9%的項目達成預期目標。
如何達成預期目標?作者提出了“慢思考,快行動”的方法論,以及“模塊化”的解決方案。
這本書帶給我很多啟發,仿佛打通任督二脈一般,所以今天分享給你,希望對你有啟發。
一、一個失敗的項目
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. 模塊化
最后,再聊一聊模塊化。
互聯網行業推崇的是:小步快跑,快速迭代的最小閉環產品原則,以及相互獨立且自我閉環的微服務設計。
同理,實體行業則推崇:模塊化。
它的本質是重復與抽象。
- 比如搭建一個巨型太陽能發電廠,核心就是設計一個個以太陽能電池為基礎組件的“積木塊”,在項目現場把多個太陽能電池組裝在一起,就可高效完成?;蛘咴谪毨У貐^創建成千上萬所學校,也可設計幾種學校結構,拆解為一間一間獨立的教室,再把它們進行組合,就可以得到許多所的學校。
- 比如特斯拉的一體式壓鑄技術,把上萬個零部件打包成一個模塊。如果把它遷移至互聯網軟件行業,本質也適用。
- 比如Workday是一款財務與人力資源SaaS產品,它的架構設計核心就抽象為兩大“積木塊”:業務流程、對象。
- 比如發簡歷、面試、入職、調崗、排班、加班等,都是一個個的業務流程,把它們進行抽象與封裝,形成一個個流程“積木”,不同的企業可以進行組合使用。
每一個流程則由:類型、觸發條件、觸發節點、觸發對象等組件組合而成,按需配置。
有了流程,剩下就是面向對象。
每個流程會面向一個或多個對象,同時流程流轉又會對對象產生信息流,遵循領域設計原則,把每個對象的流程與記錄獨立封裝,即可形成一個對象的詳情。
比如員工調薪是一個流程,它作用對象是員工,操作對象是薪酬專員,可以根據需求配置不同流程節點,流程結束后,員工花名冊跟薪資檔案信息同步更新。
- 對于員工來說,可以在自己的主頁看到所有對自身(即對象)的所有流程與信息變化(比如入轉調離,定薪調薪等);
- 對于薪酬專員,也可以在員工花名冊看到所有相關員工的操作流程與信息變化。
同時,當把架構設計抽象為流程和對象之后,產品頁面也可抽象為幾大類:流程配置頁、流程流轉頁面、對象詳情頁等,實現整個系統的操作體驗一致性。
四、總結
大型項目為什么容易失敗?
人們習慣策略性虛假稱述與心理因素導致的沉沒成本,所以采取“快行動,慢思考”導致。
如何解決?
采用“慢思考,快行動”的方式,具體可包含:
1、以終為始,從右往左思考。如果應用到互聯網行業,則可用一個大型項目需求分析表,以及遵循兩條原則:
- 原則1、產品經理應該把50%以上精力,用在項目立項之前;
- 原則2:如果一個項目工期超2個月,則一定考慮重新思考方案或拆分項目。
2、最大虛擬性產品。實施落地前,通過更精細的、更逼真的產品,驗證用戶需求,打磨所有細節,而不一定采取最小可行性產品。
3、模塊化。它的本質是重復,通過抽象與設計不同的“積木塊”的方式,實現模塊化,從而保證品質,提升效率,降低成本。
本文核心方法論,主要來自于丹·加德納教授的《怎樣做成大事》一書,書中有更詳實的論證,更精彩的案例,更逼真的細節,更引人入勝的文筆,推薦你親自閱讀。
專欄作家
邢小作,微信公眾號:邢小作之家,人人都是產品經理專欄作家。一枚在線教育的產品,關注互聯網教育,喜歡研究用戶心理。
本文原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自Unsplash,基于CC0協議
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
- 目前還沒評論,等你發揮!