知識星球（給ImportNew加星標，提高Java技能）
轉自：開源中國，作者：秋夢塵
在某一線網際網路公司的任職生涯馬上就要結束了，回想起來，從16年校招加入，到今年年初離職，在這快三年的時間裡，公司在飛速地發展和變化，我也從一個剛入職場的初級後臺開發成長為帶著十來個人團隊的小組長。這幾年遇到了很多事，認識了很多人，也學會了很多道理，無論是技術水平還是管理能力都得到了很大的鍛煉和提升。近來無事，正好總結一下這幾年工作，特別是團隊管理方面的幾點感悟和體會，一來方便日後翻閱，二來要是能夠給大家帶來一些有意義的參考和借鑒，那也是極好的。
回顧這幾年
在公司飛速發展和變化的大環境下，總是充滿了機遇和挑戰。一個想法從提出到落地，再到發展為一個重點專案，整個過程都是極快的。當然了，前提一定是這個想法要有價值並得到領導的認可和支援。16年校招加入公司時，我有幸加入了一個業務改寫範圍迅速擴大、領導高度重視並且組員都非常 nice 的高速成長、極具潛力的專案組。
更加幸運的是，我加入時整個專案在經歷了幾次電商大促的考驗後已經日漸趨於穩定，正處於業務改寫範圍迅速擴大、系統承載流量高速增長的關鍵階段。在這關鍵階段，最為重要的事情除了保證業務需求正常推進外，便是系統架構最佳化升級、不同業務領域的功能解耦、底層資料最佳化和獨立等一系列自研需求。
為了保證系統在流量迅猛增長的情況下依舊有優秀的效能表現和較高的穩定性，原有的兩三個系統從架構最佳化、關註點、業務改寫範圍及業務性質等多方面進行了拆分、重構與升級，逐步演變為現在由搭建系統、渲染系統、資料系統、國際化等眾多子系統共同組成的“大系統”。有幸參與其中，讓我對如何搭建億級流量的電商後臺系統有了清晰深刻的認識，也為我後來獨立帶團隊打下了堅實的基礎。
在公司的這幾年可以清晰地劃分為兩個階段。入職的第一年，主要是參與了很多業務需求和系統架構最佳化等自研需求的開發，在系統架構設計及最佳化方面收穫頗豐。後面才開始慢慢帶團隊，才有了今天要重點講的團隊管理方面的心得和體會。
團隊管理的心得和體會
由於我帶的團隊負責的專案，在部門裡算是一塊相對獨立的新業務，所以團隊內的大部分事情基本上都由我來直接負責。從新人招聘、培訓到業務需求跟進，再到電商大促備戰等，基本上都親力親為。在這個過程中，我深刻地認識到了，在以業務需求為驅動和導向的大環境下，根據組員技術水平、擅長的技術點、以往專案經歷等合理分配開發任務，並保證業務需求按時保質保量完成，只是一個合格組長的最基本要求。除此之外，你還需要考慮團隊文化建設、團隊技術水平提升、團隊穩定性、如何做好上通下達等方方面面。一路走來，踩了很多坑，也學到了很多知識，對於管理團隊也有了很多自己的心得體會，下麵就講講我認為比較重要的幾點。
團隊文化聽起來很虛，但是真的很重要
看過一句話：對於一個企業而言，決定短期的是技巧，決定中期的是戰略，決定長期的是文化。我想，對於一個團隊來說，亦是如此。幾乎每個企業都有自己獨特的企業文化，對於每個團隊來說，也應該有自己的團隊文化。
團隊文化，一聽起來就感覺假大空，其實，我們可以換一個名詞 —— 團隊氛圍。我認為，一個團隊的氛圍好壞和團隊文化有著密切的關係，甚至可以理解為，團隊文化是內在本質，而團隊氛圍是外在表現。 那怎麼樣的團隊文化才算是一種好的文化？
我認為，團隊文化是否獨特，是否彰顯個性，並不重要，重要的主要是兩方面。一方面，團隊文化要得到團隊內大多數人的認可，例如：某個團隊宣揚，如果家庭生活和工作無法平衡，你可以選擇離婚。我想，這樣的團隊文化，即使錶面上沒人反對，但是絕大多數人心裡都是不認可的，這就不是一種好的文化。
另一方面，這個文化說起來可以很抽象，但是必須有具體的例子可以參照或者可以具體實施。那些只能意會、言傳，不能落實到實際行動的文化，都未免有點假大空的嫌疑，正向效果也不顯著。例如：某個團隊宣揚，大家要有激情、要奮鬥、要勇於為公司未來奉獻青春，這些當做口號還行，喊著確實振奮人心。但是，振奮之後呢？冷靜下來想一下，怎麼做才算有激情？怎麼做才算奮鬥？怎麼做才是為公司未來奉獻青春？這種就很虛，除了喊的時候激情澎湃，真正作用卻不大。
做好上通下達，拒絕越級上報
作為一個管理者，特別是金字塔最底層的管理者，做好上通下達非常重要。你要讓你的組員清晰地知道，一方面，上層領導傳達下來的事情，你一定會及時地周知到大家，在你正式周知前，組員間儘量不要討論道聽途說來的訊息；另一方面，每個組員的努力、付出、成果與個人訴求等，你都會在評優選先或其它恰當的時機和上層領導如實反饋，絕對不會埋沒大家的聲音。
讓自己成為一個承上啟下、上通下達的中間橋梁，讓雙方都能夠及時順暢地交換資訊，當然了，適當地過濾、加工也是非常有必要的。
在這種大前提下，實踐中我發現，將上層領導的訊息傳達給組員相對來說比較容易，你可以採用晨會、周會、一對一私聊等多種方式進行溝通。但是，將組員反饋的資訊在恰當的時機同步到領導那裡，處理起來就要視時機、視具體內容、視領導處事風格等多種因素綜合考量。
一般來說，歸屬上層領導的最底層的員工數量眾多，領導平時也有很多事情要處理，如果你每個組員的每件事都要反饋的話，難免對領導造成騷擾，但是，如果你什麼都不反饋的話，又沒有做好上通這個點。以如何反饋組員成果為例：如果有很突出的表現或者很強有力的資料佐證，這種可以直接抄送上級領導和組內同學，並加上你對組員成果的認可和激勵。
但是，這種事情並不多，大家平時工作內容更多的是普通的業務需求、自研需求，也是我們常常自嘲的“增刪改查”，那這種工作應該怎麼總結或反饋呢？我一般是鼓勵組員寫月度總結、季度總結、年度總結等，特別要註意的是，這類總結必須要認真對待，認真寫。如何讓大家認真對待，其實方法很多，例如：可以找個時間讓大家每個人都把自己的總結講一下，總結要抄送組內所有人，組長要做個帶頭作用等等，我就不展開說了。
當你把這類總結的事情貫徹落實後，你就會發現作用很強大，用途也很多。如果組員很多的話，作為組長在月末的時候，很難做到很清晰地瞭解每個人這個月都做了什麼，甚至是對於組員自己來說，也極有可能對自己這個月做了什麼很模糊，這個時候月度總結就非常有幫助了，另外，你還可以擇優抄送上級領導和組員。
而季度總結、年度總結，可以儘量讓組員做成 PPT 彙報的形式，一方面，可以鍛煉組員的總結、表達與溝通等能力；另一方面，還可以邀請上級領導參加，也可以選在績效評定、升職加薪評定等時間點前，會帶來諸多好處和便利。大家都知道，研發一般加班較多，常常總結才能清晰地讓自己、同事與領導都知道你做了些什麼有價值有意義的事情。
其實，做好了上面說的幾點，做好了上通下達，也就不存在越級彙報的情況了。
註重培養歸屬感、責任感與主動性
說實話，自私確實是人的天性，不是自己的東西，很難談什麼責任感，更不用說主動性了。所以，我們才要強調培養主人翁意識，即培養歸屬感，這是後兩者的前提和基礎。那麼，怎麼培養歸屬感，怎麼培養主人翁意識呢？
你可以將系統、業務範圍等根據組員的興趣點、以往專案經歷等多種因素劃分給指定人負責，並明確賞罰機制。要清晰地傳達一種思想，那就是：這塊東西就是你的，乾好了評優、升職、加薪等都會優先考慮；乾不好，出事情了，你要負責，我也會負責。有了歸屬感，責任感也就自然有了，當然了，前提是他要是一個負責的人。
而對於主動性，就需要多多鼓勵、慢慢培養了。這個主動性呢，一言以蔽之，就是主動規劃或者做了一些除了你安排下去的任務之外的，對他負責的那塊未來有意義有幫助的事情。
建立 backup 機制
backup 機制，即互備機制，就是儘量讓組內的每一個人都有一個或多個備份存在，特別是在組內發揮重要作用的人。直白點說，就是儘量要讓組內的任何一個人都是可替代的，當然了，這裡面也包括你自己。要儘量達到一種狀態，那就是如果突然某天某個人不在組內了，這個小組以及負責的業務必須能夠保證正常運轉。
為什麼要這麼做呢？首先，我們任何一個人都無法保證“7*24小時”隨時待命，那麼，我們假設在某個時間點，有一塊線上業務出現問題，而熟悉這塊業務的只有一個人，這個人又恰巧不在公司且無法遠端支援，那這個問題處理起來就會非常棘手。但是，如果除了這個人外還有一個或多個熟悉這塊業務的人在，那情況就不一樣了。
其次，我們都知道網際網路從業人員跳槽頻繁，萬一某一天某個人離職了，如果這塊業務只有他熟悉，那必然會造成交接成本升高，交接後的隱患也會更多。所以，其實很多公司都要求中高層的管理者，上任之後必須在規定的時間內培養一個或多個可以接替自己工作的人。對於最底層的小團隊來說，也是一樣的，只有盡最大努力貫徹落實 backup 機制，才能在最大程度上保證團隊及業務的穩定性。
靈活的“7*24”，而不盲目推崇固定的“996”
談到 996，其實有很多網際網路公司是強制規定上下班時間的，強制大家執行 996。從我加入公司到現在，並沒有遇到公司強制要求 996 的情況，至少我所在的部門還沒有強制推行。偶爾專案比較忙的時候，995 還是有的，週末或節假日過來加班也是有的。
相對於 996，我更喜歡和提倡靈活的 7*24，這裡並不是指大家要一週7天24小時一直工作，而是說，無論什麼時間，是工作日還是休息日，是白天還是晚上，如果公司有事情需要你支援，例如：緊急的線上問題、緊急的需求開發等等，而你又比較方便的情況下，能夠隨時趕到公司或者在家遠端支援。
對於加班這件事呢，我一般都是提倡：事情多的時候，大家就辛苦點，多加點班；事情少的時候，大家就早點回家，多休息休息，養精蓄銳而不是在公司乾耗著混加班時間。如果休息日有特殊情況，需要大家犧牲自己休息時間來支援的，我們可以後續找一些恰當的時間請個調休假補償。
目的其實只有一個，讓大家保持熱情，線上出現問題時能夠積極及時處理，而不是用固定的 996 把大家搞得很疲憊，結果休息日出現問題的時候，沒有人願意支援處理。畢竟對於電商類產品來說，休息日也是使用者使用量較高的時間，保證良好的使用者體驗也是非常重要的。
流程、規範與穩定高於一切
要保證團隊穩定、業務穩定，那這個團隊就一定要制定屬於自己的流程和規範。每件事情都要按照指定的流程走，比如上線功能就必須按照測試、灰度、全量等流程走，任何步驟都不允許跳過；每件事都要按照指定的規範來，比如檔案資料要按照統一的格式來，而不是隨心所欲。
我們要清晰地認識到，很多線上事故都是執行者未按照流程、規範操作導致的，如果執行者按照流程、規範來做，至少能夠降低事故的負面影響。
崇尚技術深度，而不盲目崇尚新技術
作為一名研發人員，技術自然是大家的安身立命之本。很多研發人員都喜歡研究新出現的前沿新技術，不是說這樣不好，而是說，深度地學習和掌握工作中常用的現有技術才是更加重要的。
一方面，我們要清晰地認識到好多線上問題都是因為對現有技術理解有偏差或者對用法掌握不到位導致的；另一方面，新技術在穩定性上往往有待驗證，自己玩玩是可以，但是用在重要的專案上基本上不可能，萬一齣現問題，後果是非常嚴重的。記住，永遠都不要拿專案的穩定性開玩笑。
技術成長與業務需求相結合，產品需求和自研需求相結合
好多人抱怨我平時只是在做“增刪改查”，毫無技術含量，更不要扯什麼技術水平提升了。我覺得，並不都是這樣，好多業務需求還是很需要架構設計和細節把控的。技術和業務相結合，技術才有了價值，如果只會技術，那豈不是成了紙上談兵。
另外，作為組長，一定要控制下產品需求的進度和佔比，儘量留出一些時間用來做自研需求。畢竟隨著系統中的功能越來越多，重構和最佳化往往是難以避免的，特別是那些比較急的需求很有可能採用了很暴力的設計和開發，是必須要儘早填上的坑，不然後患無窮。
團隊管理的小技巧
做好新人培訓
無論是工作多年的職場老手，還是剛入職場的應屆生，在剛剛入職的那段時間都像一張白紙。他經歷了怎樣的新人培訓，很大程度上影響著他未來在公司工作的態度和方式。另一方面，新人培訓的好壞以及是否規範，也直接影響著新人對公司的第一印象。
所以，新人培訓是非常重要的，要認真謹慎對待，下麵是我認為幾個比較重要的點：
- 流程規範培訓要優先於技術培訓：技術水平不行，可以慢慢學。但是，流程和規範一定要第一時間好好培訓和指導。一旦某種不好的習慣養成了，後面再改就很難了。新人引發的問題中，很多都是由於操作不按照流程，不遵守規範導致的。
- 老人踩過的坑，新人也很有可能會踩：每個團隊都應該整理一份“踩坑手冊”，記錄一下以前踩過的坑，遇到的線上問題及對應的分析總結。然後，每個新人入職時，都把這些常見的坑提前多熟悉幾遍，不要求全都一一記住，至少要在腦海中留個印象，能夠極大地降低踩“同類坑”的機率。一個人踩過的坑，儘量讓整個團隊的人都不要再掉進去了。
- 明確新人熟悉系統、技術等的順序和進度安排：千萬不要和新人說，我們需要用到 A、B、C 與 D 等等，你自己去看吧。最好可以制定一個合理的熟悉順序和進度安排，明確好每天熟悉什麼，幾天熟悉完。你要知道，正確的熟悉順序確實可以幫助新人提高效率，加快上手速度。另外，不要忘記，任務以及對應的 deadline 才是第一生產力。
- 一對一導師制：儘量不要和新人說，組內每個人都很 nice，有問題隨便問任何人都可以。儘量安排一對一的導師，這種方式效果更好。
- 新人手冊：每個團隊儘量都要有一份新人手冊，可以大家一起維護編輯。這樣同一件事情就不用和 N 個新人說 N 遍了，大家自己翻閱即可，有問題再找帶你的導師問。極大地節省了大家寶貴的時間，也方便在以後遺忘時查閱。
巧用主題池，做好團隊技術分享
團隊技術分享的好壞和分享主題的選擇有著極大的關係。那麼，什麼樣的分享主題才算是一個好主題呢？
我認為，最重要的一點就是，分享主題要儘量和平時工作有點關聯，可以是平時用到的技術點的深入研究，也可以是同類技術的橫向對比。可以維護一個技術分享的主題池，每個人可以把自己想知道的問題點、技術點加到池子中，組長來做統一的把關和過濾，每個人分享的時候，一定要在過濾後的池子裡面選。
這樣，既有一定的靈活性，可以讓組員自由選擇分享主題，又能在一定程度上控制好主題選擇的範圍，保證主題都是大家想知道和瞭解的，對大家工作和技術提升有意義的。
建立時間線記錄，輔助排查線上問題
當出現線上問題時，第一要務是要儘快找到問題原因，儘快修複問題。那麼，如何快速定位到問題原因呢？總結分析了很多線上問題後，我發現了一個規律。
首先，我將線上問題分為以下兩類：
- 主動類問題：由研發人員主動操作引發的問題，我叫做主動類問題，也就是由功能上線、修改配置、修改開關狀態等引發的問題。
- 被動類問題：不是由研發人員主動操作引發的問題，我叫做被動類問題，即由使用者訪問量激增、非研發人員的常態化操作等引發的問題。
我所說的規律就是：無論哪種型別的問題都是與時間強相關的。例如，如果你剛剛完成系統的上線釋出，而後發現出現了線上問題，這個問題的出現時間又恰巧和你的釋出時間相吻合，那麼極大機率就是這次上線引發的問題。再例如，我們每年都非常關註的雙十一大促，每到 0 點的時候，各系統的流量必然會達到一個峰值，而這個時候也是最容易出問題的時候。
那麼，應該如何應對這兩類問題呢？
針對主動類問題，建立時間線記錄。將團隊內的每一次功能上線、修改配置、修改開關狀態等一切可能影響線上系統狀態的操作都記錄下來。記錄內容可以簡單地寫一下操作時間點及操作內容概述，大家一起負責維護和編輯。這樣，一旦發現線上問題，第一時間看一下問題的發生時間點附近是否有研發人員主動操作了什麼。如果有的話，大機率和這些操作有關，能夠較快地定位問題原因。
針對被動類問題，因為我們無法控制使用者、非研發人員的行為，所以只能靠預測和演練。例如，雙十一之前我們可以按照預測的流量進行演練、壓測等。再例如，如果系統執行得好好的，突然出現線上問題，而出現問題的時間點在時間線上又找不到對應的主動操作，那麼可以關註下該時間點使用者訪問量，系統呼叫量是否存在波動，是否由於非研發人員的操作導致。
結語
起初只是想簡單總結記錄一下，沒想到洋洋灑灑寫了這麼多。說實話，我做管理的時間也不長，有些想法也沒有深入去實踐，難免有些偏頗和誤差，歡迎大家隨時交流和指正。 我在該公司這三年來得到的鍛煉和成長，要由衷感謝一路走來的領導、同事與朋友。大家都非常優秀，無論是工作上還是生活上，都給我很多的幫助和指導，讓我獲益匪淺。感謝這三年時光裡的每一個人，每一件事，每一個難忘的瞬間。
作者介紹：秋夢塵，一線網際網路公司後臺核心研發工程師，立志成為一名優秀的架構師和研發管理者。
