10倍程式設計師的思考模型

張飛洪[廈門]發表於2021-07-21

本文共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(我們打算怎麼去?)

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

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

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

相關文章