10x程序員是如何思考的？

作者 | 鄭曄

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

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

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

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

一個思考框架

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

我現在是個什麼水平？

我想達到一個什麼水平？

我將怎樣到達那個目標？

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

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

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

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

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

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

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

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

現狀

目標

實現路徑

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

「碼」上訂閱《10x 程序員工作法》

四個思考原則

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

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

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

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

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

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

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

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

以終為始

任務分解

溝通反饋

自動化

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

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

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

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

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

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

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

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

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

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

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

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

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

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

總結時刻

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

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

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

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

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

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

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

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

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

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

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

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

文章出自《10x 程序員工作法》專欄。資深架構師、前 ThoughtWorks 首席諮詢師鄭曄，教你如何在工作中「掌握主動權，忙到點子上」，帶你拉近與高手的距離。

今天￥68上新優惠價最後一天，1 月 5 日恢復原價￥99。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！