來自一線技術人的經驗分享｜如何寫出讓人眼前一亮的述職報告

金字塔原理：如果讓你1分鐘把你今年做的事給你領導匯報下，你怎么組織語言呢？如果給你10分鐘呢？如果給你1個小時呢？問題的答案就在金字塔原理這本書里，其實就是把自己做的事總結抽象成一個金字塔結構，思考原則：相互獨立，完全窮盡，想深入了解的建議看原書，當你把你做的事都用一個金字塔展現出來后，你只需要按照你的金字塔層次來組織語言就可以了。給你1分鐘，你把第一層的事情說下；給你10分鐘，你把第二層的事情再說一遍；給你1小時，把第三層的事情再說下，再舉幾個例子。

大道至簡：這里的概述其實就是當你要開始長篇大論前，請先用一分鐘總結下你都干了些什么，讓人有個總體的認知，如果你這個都沒說清楚，后面估計別人也沒心思繼續聽了。那概述具體寫什么呢，如果是業務的話，業務結果寫清楚就可以了，但這里個人認為有兩個重點：

• 歸因：也就是這個結果和你個人的關系，因為這里我們說的是個人述職，既然說業務結果如果能很清晰的說出這個結果跟個人的關系，那自然是很好的，不過有的時候做的技術基建本身就是沒辦法歸因的，譬如做了一個系統提升了小二的工作效率，但業務增長是沒辦法歸因的，但有時候優化了接口性能，是可以帶來業務效果增長的。

• 增量：個人認為業務價值一定是要有增量部分的，業務增長有時候也是有自然增長的，如果沒有合理的AB實驗，那這里的增長有可能是自然增長的，而不是你這個項目帶來的，所以合理的AB實驗產出的數據效果，更有說服力。

• 不要造輪子：之前內網也出現過造輪子的熱帖，很多大佬都有回帖，說的是慷慨激昂，我個人以為每個人心里都有桿秤，至于是選擇做正確的事，還是選擇當前的茍且，只有他自己才能權衡；我只能說當天平出現在我面前時，我會偏向做正確的事，但我也沒辦法保證在任何情況下不茍且。

• 帶來變化：今天你做了一套新的系統，或者重構了一塊代碼，到底帶來的前后變化點是什么？個人理解變化點大致有三類：作業效率的提升、業務的增量結果以及技術先進性的提升。
  

• 作業效率：這塊是大部分技術在做的事，譬如把一個原本線下的流程搬到線上來了，本來需要在excel里各種操作，現在只需要在線上點幾下就可以了，變化點線下變成線上了，節省了操作時間；或者把一個搜索系統的性能優化了，結果呈現從2s優化到500ms，買家可快速看到搜索結果，這樣不僅提升了買家的體驗，同時還能帶來增量業務效果；
  
  
• 業務增量：這個是大部分技術都想做但做不好的一塊，通過技術的手段帶來業務增量，這樣作為技術就可以證明出自己獨一無二的價值了，而不是作為資源工具人去實現PD的需求；算法的千人千面是個典型的例子，通過技術的模型預測來推算出買家的喜好商品，完全由技術算法驅動。但我還想說的是，有時候有些系統的開發跟業務效果本身真的完全沒有關系，真的不要硬上，真的很沒有意思，譬如你做一個活動招商系統，這個就是用來活動招商的，產品的自身定位就是為了提升小二的招商工作效率的，非要硬杠業務效果。
  
  

• 技術先進性：這個大概就是面向未來的技術吧，上面說的都是茍且，那遠方就是這個了。有可能是所在業務技術團隊的緣故，看到很多這樣那樣的系統，技術都差不多沒有太大變化，大部分人都在用最小化的方式完成當前的快速結果，但我們是不是不要那么眼前，是不是可以站的稍遠一點，自己感覺下未來三年大概是什么樣的，然后留下點什么不一樣的東西呢！

業務背景

一切從why開始：一件事如果可以把問題定義清楚的話，那這件事已經成功一半了，看到很多新人甚至是來了好幾年的同學，開始了一件事情，為啥做真的說不清楚，不知道自己為什么做，或者知道的只是很表層的原因。5W2H模式里面最重要的就是why了，why搞不清楚請不要開始。

怎么搞清楚why：如果你遇到一個很靠譜的pd，她會把為什么做說的很清楚，恭喜你，你遇到了一個超級好的pd，但大部分時候我們遇到的pd，自己都不知道為什么要做，或者說的邏輯完全不通。這時候我覺得你需要自己調研清楚，否則下一步的巨坑將等著你跳。那怎么調研呢，個人理解有幾個地方可以切入，第一：數據分析，盡可能多的拿到一些業務數據，分析這里面的邏輯，找數據的關聯性，不過這塊工作對一個后端同學來說還是挑戰不小的。第二：找資料看，論壇上、各個搜索引擎、買書，最大化的擴大自己的領域知識，這樣起碼可以快速了解這個領域內的小白知識，不至于犯低級錯誤；第三：找專家問，在各個渠道找到領域的專家，謙虛的請教咨詢，把自己遇到的問題都準備好問他們，看看這些高手之前遇到的坑是什么，作為自己的思考輸入，起碼可以站在前人的基礎上繼續往前走，而不是失敗再來一次（不要說你比他聰明，你不會犯那樣的錯，no！你跟他差不多聰明）。

三個why：通過以上各種輸入調研素材，表事實講道理，把問題都列出來，如果問題太多的話，建議抽象歸納成三個問題，當然三個不是絕對的。

解題思考

不要省略思考過程：同樣看到很多人的述職文檔，業務背景描述結束了，后面緊跟著就是一個系統架構設計，這就很奇怪，我并不是說大家沒有思考，但是的確是沒有看到，只是也許你的思考被你省略了，我想說高考作文你不思考就直接下筆嗎？起碼有個審題和解題路徑吧。

資源的權衡過程：我只想說很大一部分問題，只要能定義清楚出問題來，都是能解決的，只是在解決問題之前，需要盤一盤當前的形式以及手上的資源情況，然后給出一個最適合的ROI解決方案；這個權衡的過程其實就是解題思考，需要思考人力資源、機器資源、資金情況以及組織情況等等，這些所有的權衡過程都貫穿成一個解題路徑，把這些所有的思考和權衡過程寫出來，最終得出一個結論，我們要做一個什么什么樣的事情，那么目標就出來了。

最近看到一些大項目在如火如荼的進行中，但官方的文檔里并沒有這些業務背后的思考，直接一個目標，然后產品應該這樣做那樣做，然后結束了；也許是思考沒有寫，或者其他什么原因沒有附上，但如果執行的人自始至終都不知道背后的思考是什么，他們怎么會有信心呢，只能自己把自己當工具人了，大概率這種項目都是要失敗的。

目標制定

環境決定決策：業務目標由業務增長率的測算來完成，這里重點說下技術目標的設定。一句話：技術目標是圍繞著業務在當前的階段或形態來設定的。對于任何一個系統，它都有發展階段，按照歷史經驗，一般的系統都會經歷三個階段：產品化、數據化和智能化，在不同的階段技術目標一定是不一樣的。舉個例子：對于一個營銷平臺，產品化階段一定是把這個營銷平臺做出來，對外需要提供營銷費用的計算能力、營銷氛圍的統一管控、權益的傳播&核銷等等能力，對內需要需要搭建一個后臺營銷配置平臺，讓活動小二可以快速配置上線一個營銷活動玩法，做成這樣產品化階段應該就差不多了；數據化那就要把全鏈路打點、AB實驗能力、各種維度的數據效果看板做出來，甚至要做出一個自動化的效果數據分析能力了；智能化大多是要通過歷史的營銷數據做迭代反哺了，通過歷史數據加業務結構化的規則建設ROI模型，在營銷前期給出最佳營銷費用的投入，產出最大的收益，說句簡單的，就是算法模型告訴你營銷應該怎么玩ROI最大化。

切勿為了情懷：之前聽過一個真實案例，一位同學花了兩個月的時間，把一個頁面接口的性能從500ms提升到100ms，頁面出來的速度更快了，本來想在周會上show下自己的成果，結果反而被領導批了，領導說：對于一個網頁的瀏覽者來說500ms打開一個網頁和100ms打開一個網頁有什么區別；這個故事告訴我們，不要盲目追求高可用、高性能、高擴展，所謂的三高一定是在有被需要的情況下才有意義的。

技術方案

面向未來的架構設計：技術目標說白了就是著眼眼前，根據眼前的情況定一個合適的目標，但在設計系統的時候絕對不是著眼當前，設計系統要面向未來。系統架構圖應該怎么畫，聽到過一個靠譜的回答，包括四個部分：系統和外部的邊界、內部組件的上下左右關系、系統的非功能性設計以及面向未來的設計，所謂的面向未來的設計，個人理解起碼看到未來三年的發展形態，是抽象總結業務表層問題，看到問題背后的本質，然后把本質抽象歸納成領域模型概念，通過對領域的分析思考，產出一個面向未來的總體架構設計，其實就是多想三步，把未來的可能性都放進去。

落地再次貼近現實：總體的架構設計完成后，到具體的落地環節，還是要回歸到階段目標設計里去，根據當前的資源情況產出一套落地的具體技術方案出來，這時候類似時序圖、服務類圖、流程圖、應用關系圖等等就派上用處了。這里對于這些圖的詳細程度標準，個人理解最好是拿到這些設計就可以直接編碼的程度，千萬不要等要寫代碼的時候，還要重新思考一遍，那就太浪費時間了。后續多次的迭代其實就是對最初那個大圖的不斷完善和擴展了。

談一談技術深度：之前有一段時間，有個問題一直困惑了我很久，就是：你這個設計技術深度不夠！當聽到這個問題，瞬間蒙了，什么叫深度不夠，多深才是深呢？10米還是100米？關于這個深度有一個衡量標準嗎？當然問這個問題的人，他也沒解釋清楚什么叫深度，我當時真有點感覺他在pua我，但是我還是帶著這個問題日思夜想，終于得到了一個自己覺得稍微有點滿意的答案。技術深度其實可以用某一領域的專業技術壁壘來解釋，說到深度是在某個精細化的領域下，通過長時間的沉淀積累或者遇到特殊場景下的復雜問題，總結出一些專屬在這個領域場景下的技術方案，我覺得這可以稱作為技術深度。至于復雜問題我說明下，多復雜叫復雜？這其實也不好量化，說的簡單點，當你提出一個領域問題時，對于大部分的普通技術專家來說，他無法在短時間內給出解決方案，那么我認為這就是復雜問題（當然不排除天才級別的瞬間能想出辦法來）。當然我再重申一句，千萬不要為了技術深度而過度設計，只是當我們遇到了有技術深度特點的事，我們知道怎么去判斷并很好的表達出來。

結果說明

這里的結果邏輯思考路徑跟概述里是差不多的，但區別是這里的表達可以更細致一些。譬如業務數據可以把具體的計算公式列出來、AB實驗對比的時間維度列出來等等；技術結果可以把概述里面沉淀的平臺擴展開來，詳細說明下里面的核心模塊、擴展性，甚至是橫向方面的一些內容都可以，譬如性能、穩定性、安全方面等等。

總結反思

總結思考本質上和解題思考是前后呼應的，一件事情在一個階段結束后，一定是有做的好的和做的不好的地方，做的好的大大方方的寫出來，特別優秀的數字和戰績完全可以標紅加粗，做的不好的也大大方方的寫出來，千萬不要說今天只有Highlight沒有Lowlight，這個是絕不可能的，任何系統在不同的階段和環境下總有問題，只是組織在權衡了利弊后，選擇是否要去解決它而已。其實Highlight在前面的概述和結果說明里大體都提到了，這里重點還是要說下Lowlight，說句比較實際的話，沒有這里的Lowlight，下個階段的規劃怎么寫呢？

靈魂拷問的啟蒙：之前有一次分享，整個過程中的我滔滔不絕，一切盡在掌握中的感覺，結束后到了Q&A環節，有個前輩問了我一個問題：“你這個系統挺厲害了，但現在假如由于組織調整，必須要把你這個系統交給別人來做，你怎么看？”，當時第一反應就是：“我做了這么長時間，付出了這么多，馬上就要收割了，你讓我交給別人，肯定不干啊，強行拿走，我就辭職。”，當然那種場子肯定是場面話應付過去了，譬如尊重組織選擇啊、擁抱變化啊什么的，但沒等我說話，前輩緊接著又是一個問題：“如果你現在做的這套系統承接的業務沒了，業務被砍了，你怎么辦？”，說實話當時腦袋瓜嗡嗡的，臉很燙，自己從來沒有思考過這種問題，完全不知道怎么回答，后面只能說會后再思考下這個問題。

可遷移的個人能力：其實這個問題背后的邏輯就是個人成長問題，如果你的系統交給了別人，或者你的業務沒有了，那就給唄，沒有就沒有了，互聯網產品的變化本來就是這樣瞬息萬變的，重點是你在做這個系統的過程中，自己在哪些方面得到了成長，是架構設計能力、數據洞察能力還是結構化思考能力，這樣的能力提升是伴隨著你一生的，是刻在你腦袋里的，沒有人可以拿走，這個才是屬于你自己真正的財富。前段時間有個同學問我，個人成長都有哪些呢，我大概寫幾個大家參考下：組織協調能力、數據洞察能力、項目管理能力、復雜系統架構能力、團隊管理能力、結構化思考能力、溝通能力、演講能力等等，大家可以拿這些能力對照下自己，哪些方面比較弱，可以給自己定一個財年目標，今年重點訓練哪幾個。之前聽過一個人，把這種能力定義成叫可遷移的能力，這些能力是不分行業不分工種，每個人在職場都應該不斷完善豐富自己的這種底層基礎能力，假如哪一天互聯網落寞了，換個行業你也可以快速適應下來。

關于團隊貢獻：我認為其實本質上還是在于個人成長上，只是在你成長的某個階段你需要把你的成長外化出來，通過各種形式表達出來，通過文章的形式寫出來，通過在各個地方（團隊內、bu內、bu外、集團外）分享告訴更多的人，也可以針對創造性的技術點寫專利、論文，這些都是不同的渠道而已，重點是要輸出，成長其實就是輸入和輸出的過程，費曼學習法也是這樣的邏輯，輸入后一定要有輸出，你把不明白的人說明白了，你才是真正的明白了。當然通過這些外化的形式也可以帶來個人品牌影響力的提升，至于個人品牌的重要性就不多說了，大家自行想象。

看一個人對一塊業務的理解程度，只要問他對這塊業務的下一年規劃是什么就夠了，如果需要更深入的話，就問三年規劃。要回答這問題其實非常難，首先要知道業務的定位是什么，整個組織給這塊業務的位置在哪，需要完成什么樣的歷史使命，核心的衡量指標是什么，核心的領域問題本質是什么，當前處于一個什么樣的外部環境，核心的業務&技術問題有哪些，這些問題的優先級是什么，問題應該怎么解決，別人是怎么解決的，別人&自己的優勢&劣勢有哪些，當前的資源怎么組織可以最大化的解決這些問題，有沒有更好的解決方案，如果有需要哪些資源的配置，落地的節奏是什么，需要哪些團隊配合，有哪些風險等等這樣的問題，當然如果這些問題都想明白了，那真的是想的很明白了。

其實在上面一些小節中已經說了同樣的一些內容了，當前的形式環境下一定是有新的問題，透過問題找本質，面向未來做設計，把其中的邏輯說的足夠自洽其實就已經超過80%的人了，后面只需要一些文字功底、畫圖能力以及演講技巧，把問題表達清楚其實就可以了。

最近一年自己組織了一個新人學習小組，看到了很多新人遇到的一些這樣那樣的問題，有時候他們是真的不知道，在成長中遇到各種各樣的困惑，在這個過程中通過個人的努力也得到一些同學的正反饋，屬實有點欣慰，原來幫助別人得到反饋是這么幸福的，所以把自己的一些算經驗教訓吧通過文字分享給大家，希望能幫助到更多的人，這也許就是稻盛和夫「心」這本書里說到的「利他」的幸福感吧，感恩。