1975 年，弗雷德里克·布魯克斯（Frederick Brooks）出版了軟件行業的名著《人月神話》，他給出了一個統計結果，優秀程序員的開發效率是普通程序員的 10 倍。40 多年過去了，這個數字得到了行業的普遍認同。

成為 10x 程序員是很多程序員的追求。但工作產出并不只是由寫代碼的效率決定的，一些不恰當工作方法很大程度上影響著你的產出。在接下來的這段時間里，我希望通過這個專欄和你一起探討，作為一個程序員，該如何更高效地工作，怎樣才能把時間和精力盡可能地放在處理本質復雜度的事情上，減少在偶然復雜度上的消耗。

? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

作者 | 鄭曄

出處 | 極客時間《10x 程序員工作法》專欄

作為整個專欄第一講，我就從我常用的一個思考框架開始。

一個思考框架

我曾經組織過針對應屆畢業生的培訓，第一堂課往往是我親自操刀，其中有一個頭腦風暴的環節“暢想未來”，我會讓大家思考三個問題：

（1）我現在是個什么水平？

（2）我想達到一個什么水平？

（3）我將怎樣到達那個目標？

大家會圍繞著這三個問題，從各種角度展開討論。這是一個有趣的練習，你會發現大家“最擅長”回答的是第一個問題：我現在處于什么水平？和有經驗的人相比，他們大多自認為比較“菜”。但對于后兩個問題的討論，卻可以切實看出人和人之間處理問題的能力差異。

有人通過之前的資料搜集，已經對自己的未來有了一個打算。比如想成為一個研發大牛，或者想做一個開源軟件等，也就是說，對于第二個問題，他有明確的答案。而有的人則是一臉茫然，他很可能根本沒有考慮過這個問題。而從題目本身來看，目標相對清晰的同學，才會進入到第三個問題，而茫然的同學，則完全無從下手。

那么我為什么會問這幾個問題呢？我是想讓大家跳出現有的思考模式，擺脫僅憑直覺“悶頭做事”的習慣方式，把低著的頭抬起來，看一眼未來，給自己找一個方向。否則，如果你對未來沒有定位，是茫然的，盡管你也知道要努力，但勁兒該往哪里使呢？如果使勁的方向不對，那么你越使勁兒，可能會在錯誤的路上跑得越遠。南轅北轍的道理大家都懂，但具體到自己的工作和發展上，真正能體會并實踐的卻是少數。

其實，這三個問題來自一個思考框架。在給其他公司團隊做咨詢時，我也經常會運用到它，原來的問題是：

Where are we?（我們現在在哪？）

Where are we going?（我們要到哪兒去？）

How can we get there?（我們如何到達那里？）

這三個問題實際上是幫我們確定：

現狀

目標

實現路徑

如果一個人能夠清晰地回答出這三個問題，通常意味著他對要做的事有著清晰的認識。這個框架雖然看似簡單，但卻非常有效，它已經成為我工具箱里一件非常稱手的思考工具。在我的職業生涯里，與很多人討論不同的事時，我都會用到這個思考框架的不同變體，而在這個專欄里，我也會用它來幫助回答“怎樣高效工作、怎樣做好軟件”這件事。

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??

四個思考原則

在實際的工作中，這個思考框架會幫助我更好地了解自己的工作。比如，當一個產品經理給我交代一個要開發的產品特性時，我通常會問他這樣一些問題：

為什么要做這個特性，它會給用戶帶來怎樣的價值？

什么樣的用戶會用到這個特性，他們在什么場景下使用，他們又會怎樣使用它？

達成這個目的是否有其它手段？是不是一定要開發一個系統？

這個特性上線之后，怎么衡量它的有效性？

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

我們用思考框架對照一下，為什么我會問這些問題。一般來說，一個新特性要開發時，現狀我是知道的。所以，我更關心目標，這里“為什么要做這個特性？”就是在問目標，“給用戶帶來怎樣的價值”是在確定這個目標的有效性。接下來，我會關注實現路徑，用戶會怎么用，是否有其他的替代手段，我需要了解產品經理的設計是經過思考的，還是“拍著腦袋”給出的。衡量有效性，則是要保證我的工作不會被浪費。

通過這個例子，我給你展示了怎么用這個思考框架提出問題。但我估計你更想了解的是，我怎么會想到問這些問題。給出思考框架是為了讓你明白為什么要提出問題，而具體問題要怎么問，就可以遵循下面這四項原則：

（1）以終為始

（2）任務分解

（3）溝通反饋

（4）自動化

這是我從思考框架延伸出來的。在這個專欄里，我會圍繞這四項原則和你詳細討論。

解釋一下，以終為始就是在工作的一開始就確定好自己的目標。我們需要看到的是真正的目標，而不是把別人交代給我們的工作當作目標。你可以看出這個原則是在幫助我們回答思考框架中，Where are we going?（我們要到哪兒去？）這個問題。

任務分解是將大目標拆分成一個一個可行的執行任務，工作分解得越細致，我們便越能更好地掌控工作，它是幫助我們回答思維框架中，How can we get there?（我們如何到達那里？）的問題。

如果說前兩個原則是要在動手之前做的分析，那后面兩個原則就是在通往目標的道路上，為我們保駕護航，因為在實際工作中，我們少不了與人和機器打交道。

溝通反饋是為了疏通與其他人交互的渠道。一方面，我們保證信息能夠傳達出去，減少因為理解偏差造成的工作疏漏；另一方面，也要保證我們能夠準確接收外部信息，以免因為自我感覺良好，阻礙了進步。

自動化就是將繁瑣的工作通過自動化的方式交給機器執行，這是我們程序員本職工作的一部分，我們擅長的是為其他人打造自動化的服務，但自己的工作卻應用得不夠，這也是我們工作中最值得優化的部分。

這四個原則互相配合，形成了一個對事情的衡量標準。總體上可以保證我的工作是有效的，在明確目標和完成目標的過程中，都可以盡量減少偶然復雜度。

怎么把這四個原則用在工作中呢？我們回過頭來看一下前面的場景，產品經理把要做的產品特性擺在我面前。站在以終為始的角度，我需要了解真正的目標是什么，所以，我會關心為什么要做這個特性，為了保證目標是有效的，我會關心它給用戶帶來的價值。

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

為什么要學會溝通反饋？因為我需要明確，自己是否真正理解了產品經理提交的需求，所以，我要不斷地問問題，確保自己的理解和產品經理交代的內容一致。另外，我也需要保證我的產品做出來確實能夠達到目標。所以，我會關心它上線后的衡量手段。因為我知道，這個行業里有太多代碼上線后，從來沒有運行過。

自動化的角度很有意思，我們做的方案通常是一個自動化方案，但我們需要了解這個方案沒有自動化之前是怎么做的。如果不自動化，用戶會怎么用。所以，我會關心是不是還有其它替換方案，比如，買一個現成的服務。因為很多需求的提出，只是因為我們有了一個開發團隊而已。

好，現在你已經對這四個原則在工作中的應用有了一個直觀的認識。但你也會發現，我問的這些問題似乎已經“超綱”了，超過了一個普通程序員應該關注的范圍。但這就是真實世界，它不像考試一樣，有一個標準答案。

我們不是一個人孤獨地在工作，而是與其他人在協作，想要做到高效工作，我們就要“抬起頭”來，跳出寫代碼這件事本身。所以，我在開篇詞里說，程序員解決的問題，大多不是程序問題。

可能你對這些原則的了解還沒過癮，沒關系，這一講只是讓大家清晰地了解思考框架和原則的背后邏輯。接下來，我會結合行業里的最佳實踐，給你進一步講解這些原則和具體應用。

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??

總結時刻

總結一下今天的內容。大多數人工作低效是由于工作中偶然復雜度太多造成的，只要能夠更多地將注意力放到本質復雜度上，減少偶然復雜度造成的消耗，我們“真實”的工作效率自然會得到大幅度提升。而想要減少偶然復雜度的消耗，就要了解一些高效的工作方式和行業的最佳實踐，而這一切是可以用統一的框架進行思考的。

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

Where are we?（我們現在在哪？）

Where are we going?（我們要到哪兒去？）

How can we get there?（我們如何到達那里？）

為了把這個框架應用在我們程序員的工作中，我給了你四個思考原則：

a、以終為始，確定好真實目標；

b、任務分解，找到實施路徑；

c、溝通反饋，解決與人打交道出現的問題；

d、自動化，解決與機器打交道出現的問題。

如果今天的內容你只能記住一件事，那請記住：面對問題時，用思考框架問問自己：現狀、目標和路徑。

最后，我想請你思考一下，如果把這個思考框架運用在你的職業發展規劃上，你會如何回答這三個問題呢？歡迎留言。

如果你學習C/C++編程知識感覺有困難，想要和人一起交流討論，可以來：C/C++編程，一起來成長學習！

總結

以上是生活随笔為你收集整理的优秀程序员的开发效率是普通程序员的 10 倍，那么如何提升呢？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。