引言：技術(shù)硬實力很重要，然而技術(shù)軟實力同樣也很重要，本文一起探討下應(yīng)該怎樣做事。
吳孟達的一句”你在教我做事啊“成了生活中一個開玩笑的梗，大家都喜歡以自己的方式做事情，然而我們的做事方式真的正確嗎，是否有更好的做事方式了，值得深入研究探討。
如果本文是告訴你，要認真做事，要專心做事，巴拉巴拉，說一大推老生常談的東西，估計你看到直接想罵人：“真是閑的蛋疼，扯一堆沒用的”。如果真是那樣，我自己也會罵自己吃飽了撐的，浪費大好時間和精力。
那么，本文究竟想探討什么了？本文是想探討和總結(jié)一些好的做事方式或者是一些形成體系的方法論，它不是那種籠統(tǒng)的東西，而是一些具體的且行之有效的且經(jīng)過實踐檢驗的做事理論。
按照時間順序，對于做一件事情，我們將其分為事前、事中和事后三個階段，就每個階段，再分別探討分析下，應(yīng)該做什么以及怎么做。為什么要這么拆分了？是因為，我們很多時候，只關(guān)注“事中”階段，只想著怎么把事情做好做完，而事情做完后，又馬上投入了其他事情，忽略了事前和事后階段，然后那才是往往決定一個人成長和發(fā)展的關(guān)鍵環(huán)節(jié)。比如我們有沒有思考過什么要做這件事、目標是啥。做完后，是否有思考過這個是否可以適用其他場景甚至抽象出一些通用的東西，此外自己從中是否有學(xué)到什么了時候有總結(jié)了。
本文將圍繞“事前-事中-事后”三個階段，去展開各個環(huán)節(jié)中的一些方論論討論，最終希望形成一個成體系的閉環(huán)思維和做事方法論。
事前階段
“為什么要做這件事？”，“痛點是什么？”，這是很多大佬經(jīng)常問的問題，往往是在你滔滔不絕地介紹方案的時候，大佬們就用這個問題打斷了你，既然大佬們經(jīng)常問，說明背后一定有其深層原因，結(jié)合我自身的理解我從技術(shù)優(yōu)化類和產(chǎn)品需求類來分析這個思考的必要性吧，這是碼農(nóng)日常最常見的兩類事情。
產(chǎn)品需求類： 很多人說， 這個產(chǎn)品都已經(jīng)思考好了， 照著做就是了，哪來那么多為什么呀？的確，在我們這些碼農(nóng)接到需求之前，產(chǎn)品同學(xué)內(nèi)部應(yīng)該都討論多倫了，但是我們還是要去理解一下需求背后的深層原因，一方面能夠加深對需求的理解、提高業(yè)務(wù)理解能力， 另一方面也能通過對需求本質(zhì)的理解在設(shè)計方案的時候思路更清晰，例如技術(shù)方案評審的時候被問到為什么這么做、而不是那么做的時候， 你能結(jié)合需求業(yè)務(wù)場景和擴展性等作出清晰的解釋。
技術(shù)優(yōu)化類： 比如你覺得現(xiàn)在網(wǎng)絡(luò)框架中需要引入 quic ，你要思考的問題就是為什么要引入 ， 是 quic 比較弱網(wǎng)情況下性能比較好？那再問，我們目前的網(wǎng)絡(luò)庫性能表現(xiàn)不好嗎？ 有沒有數(shù)據(jù)支撐說明？ 另外做完這件事投入是多少？ 收益是多少？能不能從現(xiàn)有的數(shù)據(jù)情況推論出做這件事之后的收益？ 這些問題想清楚之后，規(guī)劃執(zhí)行才能有理有據(jù)，你的 leader 才可能給你爭取資源來做。
思考動機
知道經(jīng)常被問和理解其必要性之后，我們就來準備怎么才能清晰回答這些問題，要想應(yīng)對自如，就是提前問自己，方法論是：“2P挖掘法”：
即至少找出兩個痛點或者兩個論據(jù)來支持你做這件事的必要性， 這兩個痛點不是拍腦袋或憑感覺，最好要有嚴格的數(shù)據(jù)說明。
例如，現(xiàn)在要對一個百人的項目做組件化重構(gòu)，痛點是： 1. 編譯太慢，影響開發(fā)效率；2. 模塊耦合嚴重，維護成本高； 為了進一步說明這個痛點有多痛， 你可以用一些數(shù)據(jù)說明，例如一次編譯要 20min， 一般開發(fā)在開發(fā)和解 bug 平均一天編譯 6 次，一天花在編譯上的時間就是 2h， 一百人的團隊， 一天浪費的時間就是 200h； 如果能組件化后單獨編譯組件只要 2min ， 一天就能節(jié)約180h 的時間。 如果每件事情都逼迫自己至少挖出兩個以上類似的痛點或論據(jù)，后續(xù)被問到 why 的時候，一定能應(yīng)對自如， 因為你早就已經(jīng)經(jīng)過了深思熟慮 。
目標制定
如何深刻理解目標？一方面要有基礎(chǔ)的知識、能力積累，另一方面要靈活運用SMART原則從不同維度梳理目標。
● S：具體，把目標明確到一件具體的結(jié)果上，而不是虛無縹緲抓不住的想法；M：量化，搞清楚需要達到什么量化的結(jié)果；
● A：可實現(xiàn)，認真考量目標是否可以實現(xiàn)，團隊的資源、能力、士氣是否足夠達成目標所需的條件，如果不滿足怎么辦，如果遠遠超出能力范圍，就不要做承諾；
● R：有意義，做這件事對公司、對團隊、對個人是否有意義，深刻理解其中的意義是什么；
● T：有時限，明確了解完成目標最終實現(xiàn)的時間限制。
事中階段
想清楚為什么做這件事之后，做的時候就能放開顧慮去做了， 包括方案設(shè)計、落地實施、問題處理等重要的步驟。
設(shè)計優(yōu)先
“設(shè)計優(yōu)先”這條原則，相對來說更加具體一些。之所以單列一項，是因為架構(gòu)設(shè)計太重要了。Uncle Bob曾說過：“軟件架構(gòu)的目標，是為了讓構(gòu)建與維護系統(tǒng)的所需人力資源最小化。”
架構(gòu)設(shè)計，并不僅僅關(guān)系到系統(tǒng)的質(zhì)量，還關(guān)乎團隊的效能問題。很多團隊也有明文規(guī)定，開發(fā)周期在3pd以上的項目必須有設(shè)計文檔，開發(fā)周期在5pd以上的項目必須有設(shè)計評審。在具體的執(zhí)行過程中，由于各種原因，設(shè)計往往并不能達到預(yù)期的效果。究其原因，有的是因為項目周期緊，來不及設(shè)計得足夠詳細；有的是因為RD主觀上認為項目比較簡單，設(shè)計草草了事。無數(shù)事實證明，忽略了前期設(shè)計，往往會導(dǎo)致后續(xù)開發(fā)周期被大幅拉長，給項目帶來了很大的Delay風(fēng)險。而且最可怕的是，不當?shù)脑O(shè)計會給項目帶來巨大的后期維護成本，我們不得不騰出時間，專門進行項目的優(yōu)化與重構(gòu)。因此，無論什么時候都要記住“設(shè)計優(yōu)先”這一原則。磨刀不誤砍柴工，前期良好的設(shè)計，會給項目開發(fā)以及后期維護帶來極大的收益。
“設(shè)計優(yōu)先”這一原則，要求寫別人看得懂的設(shè)計。我們了解一個系統(tǒng)最直接的途徑就是結(jié)合設(shè)計文檔與代碼。在實際工作中，很多同學(xué)的設(shè)計文檔讓大家看得一頭霧水，通篇下來，看不出系統(tǒng)整體的設(shè)計思路。其實，設(shè)計的過程是一種智力上的創(chuàng)造，我們更希望它能成為個人與集體智慧的結(jié)晶。如何才能讓我們的設(shè)計變得通俗易懂？我個人認為，設(shè)計應(yīng)該盡量使用比較合理的邏輯，進而把設(shè)計中的一些點組織起來。比如可以使用從抽象到具體，由總到分的結(jié)構(gòu)來組織材料。在設(shè)計過程中，要以需求為出發(fā)點，通過合理的抽象把問題簡化，講清楚各個模塊之間的關(guān)系，再詳細分述模塊的實現(xiàn)細節(jié)。做完設(shè)計之后，可以發(fā)給比較資深的RD或者PM審閱一下，根據(jù)他們的反饋再進行完善。好的設(shè)計，一定是邏輯清晰易懂、細節(jié)落地可執(zhí)行的。
如何設(shè)計方案
“你為什么選擇這個方案？”、“你的方案考慮過xxx這種情況嗎？”、“業(yè)界是怎么做的？為啥不使用xxx開源方案？”，這些都是在一場技術(shù)評審會上被問得最多的問題， 如果你的回答是支支吾吾、臨時拼湊，那么就會給人留下你沒有深入研究的印象。 解決這個問題的方法是：每次設(shè)計方案的時候逼迫自己想出三個備選方案，如果你想出了三個方案，那么前面提到的哪些問題，你一定都提前問過自己了。這個其實就是3C 方案設(shè)計法：
3C ，即三個 Choice, 主要是逼迫自己去想更多的可能性， 橫向?qū)Ρ刃袠I(yè)是怎么做的，是不是可以拿來用， 自身業(yè)務(wù)情況下是不是有更多選擇， 嚴格按照這個思維去做方案， 久而久之也會無形中提高自己的深度和廣度，有人可能會覺得浪費時間，想快，這也是人的天性，但是我們用這些方法論不就是對抗人性的弱點嗎？ 如果為了快，方案有多潦草，技術(shù)評審會上討論就有多激烈， 最終也浪費了大家的時間，最終返工浪費的時間更多，還給大佬留下不好的印象， 所以”3C“還是值得花時間去做的。
穩(wěn)步推進
落地實施的進度條
方案設(shè)計之后， 就是怎么推動事情落地了。 首先把任務(wù)按照依賴關(guān)系最小粒度的劃分，評估每個模塊的工作量，最后評估出總的工作量， 然后排上計劃，執(zhí)行的時候就開始了我們的進度條， 如果太長 ，可以劃分為 2~3 個里程碑，執(zhí)行過程隨時檢測進度，是不是存在風(fēng)險。需要注意的是， 在拆解任務(wù)的時候盡量識別出依賴或被依賴的關(guān)鍵節(jié)點，盡早安排，實際開發(fā)中， 工作量評估最常見的盲區(qū)就是忽略了跨組聯(lián)調(diào)、對接話的時間，這些節(jié)點往往也容易成為項目進度風(fēng)險的關(guān)鍵因素。
借助他人的力量
程序員最容易犯的錯誤就是習(xí)慣自己一個人埋頭苦干，希望自己能搞定一切事情，怕打擾他人， 但是有些事情需要他人配合才能完成，甚至需要依賴外部團隊， 怎么推動他人按照自己的計劃配合完成事情呢？ 這里我覺得和平時做人有些關(guān)系（并不是指人品好壞），我覺得會有一篇《大佬們的做人方法論》， 如果是熟人、或有交情的人，推動起來就事半功倍，如果不熟悉，的確不太好推動，可能平時多和兄弟團隊多打打招呼、多認識認識會有些好處。 如果自己無法驅(qū)動時， 可以借助 leader 的力量， leader 出面，對方也會重視起來，別人配合你做事也有名有分。
問題分析
方案執(zhí)行或上線灰度中會遇到一些問題，需要我們第一時間去分析原因。這里，我們要注意直接原因和根本原因的區(qū)分，那么什么是直接原因和根本原因了？舉個例子：
問題：為何請求出現(xiàn)502？
回答：因為服務(wù)發(fā)生了重啟。
對于，上面這個例子，當用戶請求發(fā)生502時，分析下，很快就發(fā)現(xiàn)服務(wù)發(fā)生了重啟導(dǎo)致請求找不到服務(wù)，進而導(dǎo)致了502。因為服務(wù)重啟頻率很低，很多人到這一步可能就結(jié)束了。然而，真正原因是什么了，繼續(xù)深入：
問題：為何發(fā)生重啟?
回答：因為服務(wù)發(fā)生OOM？
問題：為何OOM?
回答：因為服務(wù)JVM參數(shù)設(shè)置不合理，導(dǎo)致OOM
可以，發(fā)現(xiàn)服務(wù)是由于JVM參數(shù)設(shè)置不合理，在某些特殊的場景后，就會發(fā)生OOM。對于上面這個例子，其中服務(wù)重啟就是直接原因，而JVM參數(shù)設(shè)置不合理才是根本原因。如果找到直接原因就打住，那么其實根本原因沒找到， 遲早還是會出問題。
因此，我們需要區(qū)分直接原因和根本原因，對于每一個問題都要找到根本原因，那么如何找到根本原因了？通過連續(xù)追問，就可以找到根本原因，這個方法叫做 “5W根因分析法”，最初是由豐田集團創(chuàng)始人豐田佐吉提出的, 這方法論指導(dǎo)豐田成為世界名企，具體內(nèi)容如下：
實踐應(yīng)用中，不一定要問5個問題，有時可能問到第三個就找到了根本原因了，這里需要注意的時，在連續(xù)追問的時候可能容易挑起情緒化，認為發(fā)問者是在刁難你，容易引發(fā)撕逼；問之前也可以強調(diào)下，接下來我們要用5W根因分析法找原因了，大家不要情緒化。 我相信大家在實際過程中都被 leader 的連環(huán)奪命問折磨過， 解決的方法是：提前用連環(huán)奪命問先折磨自己，避免同步問題的時候被 leader 連環(huán)奪命問折磨。
事后階段
事后包括：事后反饋，事后匯報，事后總結(jié)。
事后反饋
凡事有交代，件件有著落，事事有回音。很多人，事情做完了， leader 不問，你也不說，那leader就無法把握事情的進展，如果出現(xiàn)問題影響了項目整體進度，那這風(fēng)險就不可控了。
因此，面對別人交代的事，尤其是上級交代的一件事情，作為下屬應(yīng)該盡力去完成 ，而最后不管完成的質(zhì)量如何都應(yīng)該在約定的時間內(nèi)給領(lǐng)導(dǎo)一個反饋。
事后匯報
當我們把事情做完后，很多時候，像別人匯報或稱述時，總是邏輯混亂，或者啰哩啰嗦，抓不住重點，這里建議采用金字塔模式展開。
何為金字塔模式？簡單來講，就是任何事都可以總結(jié)出一個結(jié)論（結(jié)論先行），然后這個結(jié)論由三至七個分論據(jù)支撐，而這些分論據(jù)又本身也可作為分論點，如此延伸下去，猶如一個金字塔。
邏輯上，可以采用金字塔模式，形式上可以如果可以用上SCQOR法則，那就更完美了，何為SCQOR？其中：
● S是情景(Situation);由聽眾熟悉的情景引入——項目背景
● C是矛盾(Complication); 說明發(fā)生的沖突——現(xiàn)狀分析
● Q是問題(Question)：引發(fā)或提出問題？——問題解析
● O是具體內(nèi)容或過程（Obstracle)，如何解決問題，客服障礙
● R是解決收尾（Resolution ）
如果要將SCQOR大致做出區(qū)分，SCQ是故事的導(dǎo)入，通過匯報對象已經(jīng)熟知的事物或信息來導(dǎo)入，使匯報對象產(chǎn)生疑問，過渡到希望要引出回答的問題上。O為故事的中心，R則是故事的結(jié)尾。一般來說故事的導(dǎo)入和結(jié)尾內(nèi)容比較少，故事的中心內(nèi)容篇幅最多。以大家熟悉的“起、承、轉(zhuǎn)、合”架構(gòu)來做對照，SCQ為起，O為“承、轉(zhuǎn)、承、轉(zhuǎn)、承、轉(zhuǎn)”，R是合。
事后總結(jié)
很多人，事情做完了，自己也很少去總結(jié)，但是辛辛苦苦做完事情，如果不去做一個總結(jié)的話，其實是比較虧的。更重要的是給自己一個總結(jié)、幫組自己成長。哪些沒做好需要提升，哪些是做的好的，有沒有什么亮點、難點、挑戰(zhàn)等。
那么，如何總結(jié)了，可以采用4D總結(jié)法，從四個維度對這件事情做個總結(jié)： 結(jié)果、數(shù)據(jù)、技術(shù)提升、個人成長四個維度：
● 結(jié)果： 做完這件事，我們?nèi)〉昧耸裁唇Y(jié)果？ 可能是開發(fā)效率提升了， 也可能是穩(wěn)定性提升了，用戶 DAU 提升了。
● 數(shù)據(jù)： 這個是對結(jié)果的補充， 比如你說經(jīng)過你的重構(gòu)，開發(fā)效率提升了，提升了多少？ 這是很容易被挑戰(zhàn)的， 你在做之前應(yīng)該就統(tǒng)計過或者調(diào)查過開發(fā)團隊， 開發(fā)一個版本時間是多少， 解決一個 bug 平均耗時是多少； 經(jīng)過優(yōu)化之后， 一個版本迭代縮短了 xx 天。
● 技術(shù)提升： 個人技術(shù)得到了哪些提升， 是不是可以給團隊做一個分享， 是否可以在一個領(lǐng)域復(fù)用。
● 個人成長： 比如在執(zhí)行力上、事情推動力上、方法論沉淀等軟實力上是不是也有收獲。
后記說明
這里，我簡單介紹下自己，我只是一個在騰訊才工作三年的菜鳥，談不上自己的做事方法論總結(jié)，上述大多是參考其他大佬的建議和文章，本文是個開篇，我希望自己能時常來更新這篇文章，不斷豐富和調(diào)整其內(nèi)容。
參考文章：
一圖看透騰訊大佬們的做事方法論
寫給工程師的十條精進原則
淺談寫作邏輯思維之SCQOR模型
《金字塔原理》
5w2h分析法最全解析，收藏了
