10倍程序員的思考模型

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

01 效率問題

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

1975 年,弗雷德裏克·布魯克斯(Frederick Brooks)出版了軟件行業的名著《人月神話》,他給出了一個統計結果,優秀程序員的開發效率是普通程序員的 10 倍。

40 多年過去了,這個數字得到了行業的普遍認同,成爲 10x 程序員是很多程序員的追求。那麼,問題來了,作爲一個程序員,應該如何提升我們的工作效率呢?

02 思維框架

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

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

我們可以試着回答一下:

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

或者

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

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

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

爲什麼是這種思維框架呢?

  • 去哪兒明確的是目標和方向
  • 現在在哪兒明確的是現狀和座標
  • 打算怎麼去要明確的是方法論和思維路徑。
10倍程序員的思考模型

 

反過來:

  • 如果你對未來是茫然的,儘管你也知道要努力,但勁兒該往哪裏使呢?如果使勁的方向不對,那麼你越使勁兒,可能會在錯誤的路上跑得越遠。
  • 如果目標明確,你卻不實事求是,從自己實際出發,你可能半路就掉進坑裏。
  • 如果明確了目標,也知道了現狀,但是方法太lower,思維混亂,結果可能是事倍功半。

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

03 改變詢問對象

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

10倍程序員的思考模型

 

  • 爲什麼要做這個功能,他會給用戶帶來什麼價值?
  • 現在沒有嗎,是不是一定要開發,還是僞需求?
  • 用戶會怎麼使用這個功能,什麼場景下使用,怎麼用?

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

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

04 實踐原則

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

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

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

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

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

10倍程序員的思考模型

 

如表格所示:

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

知道了這些原則,我們看下最佳實踐:

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

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

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

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

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

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

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

05 總結

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

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

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

  • Where are we(我們現在在哪兒?)
  • Where are we going(我們想去哪兒?)
  • How can we get there(我們打算怎麼去?)

爲了把這個框架應用在我們程序員的工作中,我給了你幾個個實踐原則:

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

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

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章