本文共2568個字，預估閱讀時間10分鐘

01 效率問題

程式設計師越高效產出越高，產出越高能力越強，於是形成一個增強環路。但是，就我觀察，現實中的程式設計師，大部分沒有用心去思考學習效率問題。

1975 年，弗雷德裡克·布魯克斯（Frederick Brooks）出版了軟體行業的名著《人月神話》，他給出了一個統計結果，優秀程式設計師的開發效率是普通程式設計師的 10 倍。

40 多年過去了，這個數字得到了行業的普遍認同，成為 10x 程式設計師是很多程式設計師的追求。那麼，問題來了，作為一個程式設計師，應該如何提升我們的工作效率呢？

02 思維框架

在打磨10x效率之前，我們先問自己三個問題：

• 我們想去哪兒？
• 我們現在哪兒？
• 我們打算怎麼去？

我們可以試著回答一下：

• 我想成為一名架構師
• 我現在只是一個菜鳥
• 我打算通過半年培訓入門架構設計

或者

• 我想從技術轉產品經理
• 我目前對產品經理一無所知
• 我打算拜師學藝兩個月入門產品經理

不管是誰，不管做的什麼職業，似乎都可以用這種三段式的提問來思考問題。這其實是一種思維框架。雖然很簡單，但是很實用，有時候我發現用在孩子的教育上也很管用，比如

• 暑假我要預習下個年級的語數英
• 我現在處在二年級下學期的水平
• 我打算通過專案管理的方式來完成任務

為什麼是這種思維框架呢？

• 去哪兒明確的是目標和方向
• 現在在哪兒明確的是現狀和座標
• 打算怎麼去要明確的是方法論和思維路徑。

反過來：

• 如果你對未來是茫然的，儘管你也知道要努力，但勁兒該往哪裡使呢？如果使勁的方向不對，那麼你越使勁兒，可能會在錯誤的路上跑得越遠。

• 如果目標明確，你卻不實事求是，從自己實際出發，你可能半路就掉進坑裡。
• 如果明確了目標，也知道了現狀，但是方法太lower，思維混亂，結果可能是事倍功半。

大家可以試著用這個思維框架，或者變體，或許你不需要記那麼多，但是沒關係，你只要記住上面這張圖。

03 改變詢問物件

我們通過平時和產品經理的溝通來進一步實踐該框架。在上面的假設裡，我們問的物件是自己，在和產品經理溝通的過程中，我們也可以改變詢問物件：

• 為什麼要做這個功能，他會給使用者帶來什麼價值？
• 現在沒有嗎，是不是一定要開發，還是偽需求？
• 使用者會怎麼使用這個功能，什麼場景下使用，怎麼用？

如果產品經理能夠回答好這些問題，說明他基本上已經把這個工作想得比較清楚了，這個時候，我才會放心地去了解後續的細節。

我們用思維框架對照一下，為什麼要這麼問？一般開發前我們是知道目前系統現狀的，所以，我比較關心最後的目標，這裡“為什麼要做這個功能”就是在問目標，“給使用者帶來什麼價值”是在問這個目標的合理性，確保不是偽需求。接下來我會關注實現路徑，使用者會怎麼用，是否有其他的代替手段，我需要了解產品經理設計的思考過程，是慎重考慮過的還是拍腦袋想出來的。衡量有效性，目的是要保證我的工作不被浪費。

04 實踐原則

上面我們明白了框架的使用方法，也許你會說我明白了為什麼要這麼做，但是具體的問題要怎麼問，有沒有實踐原則呢？我們可以考慮如下5個原則：

• 以終為始；
• 任務分解；
• 風險管理；
• 反思覆盤
• 自動化。

這些原則其實和我們的思維框架是一脈相承的關係：

• 以終為始就是在工作的一開始就確定好自己的目標，我們需要看到的是真正的目標。
• 任務分解是將大目標拆分成一個一個可行的執行任務，工作分解得越細緻，我們便越能更好地掌控工作，這是路徑。
• 風險管理是確保過程可控，多方交流渠道是暢通的，意見是一致的，要減少因為理解偏差導致的工作疏漏。
• 反思覆盤是為了迭代工作方法，完善工作中的不足，為下一輪迴圈做更好的準備。
• 自動化是程式設計師的優勢，能靠機器做的事情儘量不要手工執行，這是我們的工作最值得優化的地方。

以上原則其實是參考了專案管理的方法，當然你可以增加變種，但是主幹是不變的。

如表格所示：

• 現在在哪兒自個清楚，我有什麼，我放棄什麼，如果不清楚就要敲打自己的頭了。
• 想去哪兒就是以終為始，我們要交付什麼結果在里程碑的deadline？
• 打算怎麼去就是手段和實現路徑，這裡借鑑的專案管理的方法。

知道了這些原則，我們看下最佳實踐：

產品經理把要做的功能清單擺在我們面前，站在以終為始的角度，我需要了解真正的目標是什麼，所以，我會關心為什麼要做這個功能。為了保證目標是有效的，我會關心它給使用者帶來的價值。

有了任務分解的視角，我需要將一個大的目標進行拆解，如果我要達成這個目標，整體解決方案是遠遠不夠的，我需要把任務分解成一個一個小的部分。所以，我會關心一下具體的使用場景。一方面，我會了解到更多的細節，另一方面，當時間緊迫的時候，我會和產品經理來談談究竟優先實現哪個場景。

為什麼要學會風險管控？因為我需要明確，自己是否真正理解了產品經理提交的需求，自己真的和產品經理交代的內容一致？最壞的情況會是怎樣的，自己能否承受的了？風險管理的目的是確保任務按照預定的軌道順暢進行。

有些人會好奇，為什麼沒有溝通反饋？溝通的目的是達成一致，立即行動。如果溝通出現問題，那也是風險管控的一種方式，所以這裡沒有獨立出來。

其實風險管控涉及的面非常廣，貫徹整個研發生命週期，因為需求變化有風險、設計可能出現漏洞、開發有BUG、測試不完整等等，怎麼強調都不為過。

自動化是手段，我們做的方案通常是一個自動化方案，但我們需要了解這個方案沒有自動化之前是怎麼做的。如果不自動化，使用者會怎麼用？所以，我會關心是不是還有其它替換方案，比如，買一個現成的服務。

反思覆盤是流程的一個重要閉環，如果缺少了這一環節，可能整個思維框架由於缺少流量注入就固化、消亡了。

05 總結

大多數人工作低效是由於缺乏有效的思維框架，加上工作中偶然出現的複雜度，我們“真實”的工作效率自然會得大打折扣。

而想要減少偶然複雜度的消耗，就要了解一些高效的工作方式和行業的最佳實踐，而這一切是可以用統一的框架進行串聯思考。

運用這個思考框架，我們需要問自己三個問題：

• Where are we（我們現在在哪兒？）
• Where are we going（我們想去哪兒？）
• How can we get there（我們打算怎麼去？）

為了把這個框架應用在我們程式設計師的工作中，我給了你幾個個實踐原則：

• 以終為始，確定好終極目標；
• 任務分解，找到實施路徑；
• 風險管控，解決過程中可能出現的問題；
• 反思覆盤，儲存思維框架的活力；
• 自動化，解決與機器打交道出現的問題。

如果今天的內容你只能記住一件事，那請記住：面對問題時，經常用思維框架問問自己，我要去哪兒，我現在在哪兒，我應該如何過去。