10倍程序員的思考模型

本文共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（咱們打算怎麼去？）

爲了把這個框架應用在咱們程序員的工做中，我給了你幾個個實踐原則：

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

若是今天的內容你只能記住一件事，那請記住：面對問題時，常常用思惟框架問問本身，我要去哪兒，我如今在哪兒，我應該如何過去。