引言
時間回到8年前，我人生中第一份實習的作業，是在某互聯網公司的無線搜索部做一個C++工程師，當時的我可謂意氣風發，想要大干一場，結果第一次上線就寫了人生中第一個Casestudy，由于對部署環境的不了解，把SVN庫里的組態檔錯誤地發到線上，并且上完線就去吃晚飯了，等吃飯回來發現師傅在焦頭爛額地回滾配置，那次故障造成了一個核心服務20分鐘不可用，影響了幾百萬的用戶，這僅僅是一個開始，在后來半年的時間里，我幾乎把所有職場新人可能犯的錯誤都犯了個遍，架構師讓我調研一個抓取性能提升方案，我悶頭搞了兩周，也沒有得出任何結論；本來安排好的開發計劃，由于我臨時要回去寫論文，搞得經理措手不及；參加專案座談會，全程“打醬油”……那段時間，自己也很苦惱，幾乎每天晚上11點多才走，很累很辛苦，但依然拿不到想要的結果，
8年過去了，自己從一個職場小白逐步成長為一名技術Leader，我發現團隊中的很多同學在不停地重復犯著自己當年類似的錯誤，他們并不是不努力，到底是哪里出了問題？經過一段時間的觀察與思考后，我想我找到了答案，那就是：我們大多數同學在作業中缺乏原則的指導，原則，猶如指引行動的“燈塔”，它連接著我們的價值觀與行動，不久前，橋水基金創始人雷·達里奧在《原則》一書中所傳達的理念，引爆了朋友圈，每個人都應該有自己的原則，當我們需要作出選擇時，一定要堅持以原則為中心，但是在現實生活中，我們往往缺少對原則的總結，對于很多人來說這是一門“只可意會不可言傳”的玄學，是屬于老司機的秘密，其實不然，
“追求卓越”是美團的價值觀，作為一名技術人員，我們應該如何踐行呢？本文總結了十條精進原則，希望能夠給大家帶來一些啟發，更好地指導我們的行動，
原則一：Owner意識
“Owner意識”主要體現在兩個層面：一是認真負責的態度，二是積極主動的精神，
認真負責是作業的底線，首先，要對我們交付的結果負責，專案中每一個設計檔案、每一行代碼都需要認真完成，要對它的質量負責，如果設計檔案邏輯混亂，代碼沒有注釋，測驗時發現一堆Bug，影響的不僅僅是RD的工程交付質量，還會對協同作業的RD、QA、PM等產生不好的影響，久而久之，團隊的整體交付質量、作業效率也會逐步下降，甚至會導致團隊成員之間產生不信任感，其次，我們要對開發的系統負責，系統的架構是否需要改進，介面檔案是否完善，日志是否完整，資料庫是否需要擴容，快取空間夠不夠等等，這些都是需要落地的事情，作為系統Owner，請一定要認真履行，
積極主動是“Owner意識”更高一級的要求，RD每天要面對大量的作業，而且很多并不在計劃內，這就需要具備一種積極主動的精神，例如我們每天可能會面對大量的技術咨詢，如果客戶提出的問題很長時間得不到回應的話，就會帶來不好的客戶體驗，很多同學說忙于自己的作業沒有時間處理，有同學覺得這件事不是很重要，也有很多同學是看到了，但是不知道怎么回答，更有甚者，看到了干脆裝沒看見，這些都是缺乏Owner意識的體現，正確的做法是積極主動地推動問題的解決，如果時間無法排開或者不知道如何解決，可以直接將問題反饋給能解決的同學，積極主動還可以表現在更多方面，比如很多同學會自發地梳理負責服務的現狀，根據介面在性能方面暴露的問題提出改進意見并持續推動解決；也有同學在跨團隊溝通中主動承擔起主R的角色，積極發現問題、暴露問題，推動合作團隊的進度，保證專案順利推進，這些同學無一不是團隊的中堅力量，所以，我們在做好自己份內作業的同時，也應該積極主動地投入到“份外”的作業中去，一分耕耘一分識訓，不要給自己設限，努力成為一個更加優秀的人，
原則二：時間觀念
相信大家都有時間觀念，但是真正能執行到位的可能并沒有那么多，互聯網是一個快速發展的行業，RD的研發效率是一個公司硬實力的重要體現，專案的按期交付是一項很重要的執行能力，在很大程度上決定著領導和同事對自己靠譜程度的評價，大家可能會問：難度幾乎相同的專案，為什么有的同學經常Delay，而有的同學每次都能按時上線？一個很重要的原因，就是這些按時交付的同學往往具備如下兩個特質：做事有計劃，作業分主次，
作業安排要有計劃性，通常，RD在設計評審之后就能預估出精確的開發時間，進而再合理地安排開發、聯調、測驗計劃，如果是專案負責人，那么就會涉及協調FE、QA、PM等多個工種的同學共同完成作業，凡事預則立，不預則廢，在計劃制定程序中，要盡可能把每一項拆細一點（至少到pd粒度），事實證明，粒度越細，計劃就越精準，實際開發時間與計劃之間的誤差就會越小，此外，務必要規定明確的可檢查的產出，并在計劃中設定一些關鍵的時間點進行核對，無數血淋淋的事實告訴我們，很多專案延期都是因為在一些關鍵交付點上雙方存在分歧造成的，例如后臺RD的介面檔案計劃在周五提供，FE認為是周五上午，而RD認為是周五下班前提交，無形中會給排期帶來了1pd的誤差，所以，我們要做到計劃粒度足夠細，關鍵時間點要可檢查，
作業安排要分清楚主次，我們每天要面對很多的事情，要學會分辨這些作業的主次，可以嘗試使用“艾森豪威爾法則”（四象限法則），把作業按照重要、緊急程度分成四象限，優先做重要緊急的事情；重要不緊急的事情可以暫緩做，但是要持續推進；緊急不重要的事情可以酌情委托給最合適的人做；不重要不緊急的事情可以考慮不做，很多專案無法按期交付的原因，都是因為執行人分不清主次，比如在開發中需要使用到ES，一些不熟悉ES的同學可能想系統性地學習一下這方面的知識，就會一頭扎進ES的汪洋中，最后才發現，原本一天就能完成的作業被嚴重拖后，實際作業中，我們應當避免這種“本末倒置”的作業方式，在本例中，“系統性地學習ES”是一件重要但不緊急的事情，要學會分辨出這些干擾的作業項，保證重要緊急的事情能夠按時交付，
原則三：以終為始
“以終為始”（Begin With The End In Mind），是史蒂芬·柯維在《高效能人士的七個習慣》中提到的一個習慣，它是以所有事物都經過兩次創造的原則（第一次為心智上的創造，第二次為實際的創造）為基礎的，直觀的表達就是：先想清楚目標，然后努力實作，
在作業中，很多RD往往只是埋頭走路，很少抬頭看天，每次季度總結的時候，羅列了很多專案，付出很多努力，但是具體這些專案取得了哪些收益，對業務有哪些提升，卻很難說出來，這就說明在作業中并沒有遵守“以終為始”這一原則，此外，很多同學在做需求的程序中，對于目標與收益關注不夠，系統上線之后，也沒有持續地跟進使用效果，這一點在技術優化專案中體現得尤為明顯，例如在一個介面性能優化的專案中，經過RD的努力優化，系統TP99縮短了60%，支持QPS提升了2倍，但是系統到底需要優化到什么程度呢？是不是縮短60%，提升2倍就能滿足需求呢？在優化之前，很多同學常常忘記設定一個預設的目標（TP99小于多少，支持QPS大于多少），我們必須清楚，優化一定是有原因的，比如預期某節假日流量會暴增或者某介面超時比例過高，如果不進行優化，系統可能會存在宕機風險，解決特定的問題才是技術優化的最終目的，所以要根據問題設定目標，再進行優化，
“以終為始”，這一原則還可以作用于我們的學習中，很多同學看過很多技術文章，但是總是感覺自己仍然一無所知，很重要的一個原因，就是沒有帶著目標去學習，在這個資訊爆炸的時代，如果只是碎片化地接收各個公眾號推送的文章，效果幾乎可以忽略不計，在學習之前，我們一定要問自己，這次學習的目標是什么？是想把Redis的持久化原理搞清楚，還是把Redis的主從同步機制弄明白，亦或是想學習整個Redis Cluster的架構體系，如果我們能夠帶著問題與目標，再進行相關的資料搜集與學習，就會事半功倍，這種學習模式的效果會比碎片化閱讀好很多，
原則四：倍訓思維
你是否遇到過這樣的場景：參加了一個設計（或需求）評審，大家興致勃勃地提了很多合理的意見，等到再次評審的時候，卻發現第一次提的很多問題都沒有得到改進，很多討論過的問題需要從頭再開始討論，這種情況就是一種典型的作業不倍訓，
之前看過一句話：一個人是否靠譜，就看他能否做到凡事有交代，件件有著落，事事有回音，這就是倍訓思維的重要性，它強調的是一種即時反饋倍訓，如果別人給我們分配了一個任務，不管完成的結果如何，一定要在規定的時間內給出明確的反饋，例如在跨部門的溝通會議中，雖然各方達成了一致，會議發起者已經將最終的記錄周知大家，但是，到這一步其實并沒有完成真正的倍訓，在落地執行程序中很可能還存在一些潛在的問題，例如，會議紀要是否經各方仔細核對并確認過？會議中明確的To Do進展是什么？完成結果有沒有Check的機制？如果這些沒有做到的話，就會陷入“溝通-發現問題-再溝通-再發現問題”的惡性回圈中，真正的倍訓，要求我們對作業中的事情都能夠養成良好的思維習慣，溝通要有結論，通知要有反饋，To Do要有驗收，
“倍訓思維”還要求能夠定期主動進行階段性的反饋，剛參加作業時，我接了一個工期為兩個月的專案，整個專案需要獨自完成，自己每天按照計劃，有條不紊地進行開發，大概過了兩周之后，Leader詢問專案進度，雖然我已經跟他說沒問題，然而，Leader告訴我，因為我每天對著電腦也不說話，讓他心里很沒底，這時，我才意識到一個很重要的問題，我跟Leader之間存在資訊不對稱，從那以后，我就時不時得跟他匯報一下進度，哪怕就只有簡短的一句話，也可以明顯感覺，他對我的信心增加了很多，特別是我做Leader之后，對這種倍訓反饋的理解，就更加深刻了，從Leader的角度看，其實只是想知道專案是否在正常推進，是否遇到問題需要他協助解決，
原則五：保持敬畏
“君子之心，常懷敬畏”，保持敬畏之心能夠讓我們少犯錯誤，在作業中存在各種各樣的規范，例如代碼規范、設計規范、上線規范等等，我們必須明白，這些規范的制定一定是基于某些客觀原因的，它們都是歷史上無數Case積累而來的經驗，團隊里的每一個成員都應該學習并嚴格遵守，這一點對于新人尤其重要，
當我們進入到一個新的團隊，請先暫時忘掉之前的習慣，要盡快學習團隊既有的規范，并且讓自己與團隊保持一致，以編碼風格為例，很多同學往往習慣于自己之前的代碼寫作風格，在做新公司第一個專案時，也按照自己的習慣進行變數、包的命名等等，結果在代碼Review程序中，被提了很多修改意見，不得不返工重寫，得不償失，如果能夠保持敬畏之心，提前了解編碼規范，這種問題完全可以避免，類似的問題，還包括對上線流程不了解，對回滾操作不熟悉，對SRE線上變更程序不了解等等，除了這些顯而易見的規范，還有一些約定俗成的規則，個人建議是：如果有事情拿不準，不妨多問問其他同事，不要憑自己的感覺做事情，
保持敬畏之心并不意味著要“因循守舊”，在我們充分了解這些規范和約定之后，如果覺得存在不妥之處，可以跟全組同學討論，是否采納新的建議，然后及時去更新迭代，其實，讓規范與約定與時俱進，也是另一種形式的敬畏，
原則六：事不過二
“事不過二”，是我們團隊一貫堅持的原則，它可以解讀為兩層含義，
一層含義是“所有的評審與問題討論，不要超過兩次”，之所以有這樣的要求，是因為我們發現，很多RD都把時間花費在一些無休止的評審與問題討論中，真正投入到實際開發中的時間反而很少，在實際作業場景中，我們經常會遇到一些不是很成熟的需求評審，這些需求檔案，要么是背景與目標含糊不清，要么是產品方案描述不夠細化，或者存在歧義，RD與PM被迫反復進行討論，我曾經遇到過一個需求評審，進行了三次還被打回，同樣的問題，在設計評審中也屢見不鮮，方案固然需要經過反復的討論，但是如果遲遲不能達成一致，就會耗費很多RD與PM的寶貴時間，這就與提升研發效率的理念背道而馳，因此，我們團隊規定：所有的評審最多兩次，通過這種方式，倒逼利益相關方盡可能地做好需求與方案設計，評審會議組織前，嘗試與所有相關人員達成一致，詢問對方的意見，并進行有針對性的討論，這樣能夠大大提升評審會議的效率和質量，如果在第一次評審中不通過，那么就只有一次機會進行復審，一旦兩次不通過，就需要進行Casestudy，
“事不過二”原則的另一層含義，是“同樣的錯誤不能犯第二次”，每次故障之后，Casestudy都必須進行深刻的總結復盤，對故障原因進行5Why分析，給出明確可執行的To Do List，每次季度總結會，大家自我反省問題所在，在下個季度必須有所改善，不能再犯類似的錯誤，孔子云：“不遷怒，不貳過”，在錯誤中反思與成長，才能讓我們成為更優秀的人，
原則七：設計優先
“設計優先”這條原則，相對來說更加具體一些，之所以單列一項，是因為架構設計太重要了，Uncle Bob曾說過：“軟體架構的目標，是為了讓構建與維護系統的所需人力資源最小化，”
架構設計，并不僅僅關系到系統的質量，還關乎團隊的效能問題，很多團隊也有明文規定，開發周期在3pd以上的專案必須有設計檔案，開發周期在5pd以上的專案必須有設計評審，在具體的執行程序中，由于各種原因，設計往往并不能達到預期的效果，究其原因，有的是因為專案周期緊，來不及設計得足夠詳細；有的是因為RD主觀上認為專案比較簡單，設計草草了事，無數事實證明，忽略了前期設計，往往會導致后續開發周期被大幅拉長，給專案帶來了很大的Delay風險，而且最可怕的是，不當的設計會給專案帶來巨大的后期維護成本，我們不得不騰出時間，專門進行專案的優化與重構，因此，無論什么時候都要記住“設計優先”這一原則，磨刀不誤砍柴工，前期良好的設計，會給專案開發以及后期維護帶來極大的收益，
“設計優先”這一原則，要求寫別人看得懂的設計，我們了解一個系統最直接的途徑就是結合設計檔案與代碼，在實際作業中，很多同學的設計檔案讓大家看得一頭霧水，通篇下來，看不出系統整體的設計思路，其實，設計的程序是一種智力上的創造，我們更希望它能成為個人與集體智慧的結晶，如何才能讓我們的設計變得通俗易懂？我個人認為，設計應該盡量使用比較合理的邏輯，進而把設計中的一些點組織起來，比如可以使用從抽象到具體，由總到分的結構來組織材料，在設計程序中，要以需求為出發點，通過合理的抽象把問題簡化，講清楚各個模塊之間的關系，再詳細分述模塊的實作細節，做完設計之后，可以發給比較資深的RD或者PM審閱一下，根據他們的反饋再進行完善，好的設計，一定是邏輯清晰易懂、細節落地可執行的，
原則八：P/PC平衡
“P/PC平衡”原則，即產出與產能平衡原則，伊索寓言中講述了一個《生金蛋的鵝》的故事，產出好比“金蛋”，產能好比“會下金蛋的鵝”，“重蛋輕鵝”的人，最終可能連產蛋的資產都保不住；“重鵝輕蛋”的人，最終可能會被餓死，產出與產能必須平衡，才能達到真正的高效能，為了讓大家更清晰的了解這一原則，本文舉兩個例子，
從系統的角度看，每一個系統都是通過持續不斷地疊加功能來實作其產出，而系統的產能是通過系統架構的可擴展性、穩定性等一系列特性來表征，為了達到產出與產能的平衡，需要在不斷支持業務需求的程序中，持續進行技術架構層面的優化，如果一味地做業務需求，經過一定的時間，系統會越來越慢，最終影響業務的穩定性；反之，一個沒有任何業務產出的系統，最侄訓消亡，
再從RD的角度來看這個問題，RD通過做需求來給公司創造價值，實作自己的產出，而RD的產能是指技術能力、軟素質、身體健康狀況，有這些資本后，我們才能進行持續的產出，在日常作業中，我發現很多RD往往只重視產出，他們也在很努力地做專案，但是每一個專案所使用的方法，還是沿用自己先前一貫的思路，最終，不僅專案做得一般，還會抱怨自己得不到任何成長，這就是P/PC不平衡的體現，如果能在做專案的程序中，通過學習總結持續提升自己的技術能力和軟素質，并將其應用于專案實施交付中，相信一定會取得雙贏的結果，
“P/PC平衡”原則還適用于很多其他的領域，例如團隊、家庭等，我本人也非常推崇這一原則，希望大家也能將其作為自身的一項基本原則，努力尋找到產出與產能的平衡點，
原則九：善于提問
“善于提問”，首先要勤于提問，求知欲源于好奇心，是人類的一種本能，在作業中要養成勤于提問的好習慣，不懂就問，不要因為自己一時懶惰或者礙于情面，就放棄提問的機會，當遇到不同的觀點時，也要禮貌地問出來，波克定理告訴我們，只有在爭辯中，才可能誕生最好的主意和最好的決定，
在設計評審、代碼評審這類體現集體智慧的活動中，遇到有問題的地方一定要提出來，我經常看到，很多同學評審全程一言不發，這就是浪費大家的時間，設計評審的目的，是讓大家針對方案提出改進意見并達成一致，如果全程“打醬油”，那就失去了評審的意義，我們鼓勵大家多提問，把自己內心的疑惑表達出來，然后通過交流的方式得到答案，
“善于提問”，還要懂得如何提問，為什么同樣是參加設計評審，有的同學就能提出很好的問題，而有的同學卻提不出任何問題？除了知識儲備、專業技能、經驗等方面的差異外，還有一點很重要：批判性思維，
批判性思維主張通過批判性思考達到理性思維，即對事物本質的認知和掌握，關于如何進行批判性思維，大家可以參考一些經典的圖書如《批判性思維》、《學會提問》等，在作業中面臨一項決策時，會有各種各樣的意見擺在你面前，所以我們必須要學會使用批判性思維來進行分析，每個人的論據是否可靠，論證是否合理，是否有隱含的立場，同樣，在閱讀一篇技術博客的時候，也要使用批判性的思維，多問幾個為什么，作者得出的結論是否合理？論據是否充分？只有這樣，才能不斷地獲取真正的知識，
原則十：空杯心態
“滿招損，謙受益”，“空杯心態”是最后一項原則，我覺得這也是一個人能夠持續成長的前提，做技術的人，骨子里通常有股傲氣，并且會隨著資歷、成績的提升而不斷增加，初入職場的小白，可能會非常謙虛，但是作業幾年之后，專業技能逐步提升，可能還取得了一些小成就，人就會越來越自信，這時候，如果不能始終保持“空杯心態”，這種自信就會逐步演變為自滿，自滿的人，往往表現為作業中把別人的建議當成是批評，不接受任何反對意見，學習上也缺乏求知的動力，總是拿自己的長處去跟別人的短處做比較，其實每個人多少都會有一些自滿，可怕的是不知道甚至不愿承認自滿，
保持“空杯心態”這一原則要求我們時刻進行自我檢視與反省，在作業中，多去跟不同級別的同學聊一聊，或者做一個360度評估，這有助于我們更加客觀地評價自己，在橫向對比中，多向那些優秀的同學看齊，學習他人的優點，很多同學在設計評審或者代碼review程序中，針對別人提出的問題與建議，往往都采用一種對立的態度，錯誤地認為別人是在挑刺，是在針對自己，誠然，在某些方面，我們可能確實比其他人想得深入，但是這不代表在所有方面都能考慮周全，對于別人的建議，建議使用“善于提問”原則里提到的批判性思維仔細分析一下，虛心地吸取那些好的建議，
作業學習就像“練級打怪”，技能儲備的越多，就越容易走到最后，保持空杯心態，可以讓我們發現很多以前注意不到的新能力，我們要做的就是努力學習它，將它們轉化為自己能力庫的一部分，
總結
以上，是我總結的作業與學習的十潭訓本原則，其中有的側重于個人做事情的方法，如“Owner意識”、“時間觀念”、“以終為始”、”倍訓思維”；有的側重于團隊作業標準規范，如“保持敬畏”、“事不過二”、“設計優先”；有的側重于團隊或個人效能提升，如“P/PC平衡”、“善于提問”、“空杯心態”，這些原則是我多年在作業與學習中，不斷總結得來的經驗，希望在大家面臨選擇時，這些原則能夠起到一定的幫助和指導作用，
以原則為中心地作業與生活，讓自己與團隊變得更加強大，
作者介紹
- 云鵬，2014年加入美團，先后參與了美團酒店供應鏈體系、分布式調度系統的建設，現在負責美團旅行客戶關系管理系統、基礎資訊服務的建設作業，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/481.html
標籤：其他