個人京東管理生涯隨想

1、寫在前面

在京東的任職生涯立刻就要結束了，回想起來，從16年校招加入京東，到今年年初離職，在這快三年的時間裏，京東在飛速的發展和變化，我也從一個剛入職場的初級後臺開發成長爲如今帶着十來我的團隊的小組長。這幾年遇到了不少事，認識了不少人，也學會了不少道理，不管是技術水平仍是管理能力都獲得了很大的鍛鍊和提高。

近來無事，正好總結一下這幾年工做，特別是團隊管理方面的幾點感悟和體會，一來方便往後翻閱，二來要是可以給你們帶來一些有意義的參考和借鑑，那也是極好的。

2、回顧這幾年

在京東飛速發展和變化的大環境下，老是充滿了機遇和挑戰。一個想法從提出到落地，再到發展爲一個重點項目，整個過程都是極快的。固然了，前提必定是這個想法要有價值並獲得領導的承認和支持。

16年校招加入京東時，我有幸加入了一個業務覆蓋範圍迅速擴大、領導高度重視、組員都很是nice的高速成長、極具潛力的項目組。更加幸運的是，我加入時整個項目在經歷了幾回電商大促的考驗後已經日漸趨於穩定，正處於業務覆蓋範圍迅速擴大、系統承載流量高速增加的關鍵階段。在這關鍵階段，最爲重要的事情除了保證業務需求正常推動外，即是系統架構優化升級、不一樣業務領域的功能解耦、底層數據優化和獨立等一系列自研需求。爲了保證系統在流量迅猛增加的狀況下依舊有着優秀的性能表現和較高的穩定性，原有的兩三個系統從架構優化、關注點、業務覆蓋範圍及業務性質等多方面進行了拆分、重構、升級，逐步演變爲如今由搭建系統、渲染系統、數據系統、國際化等衆多子系統共同組成的「大系統」。有幸參與其中，讓我對如何搭建億級流量的電商後臺系統有了清晰深入的認識，也爲我後來獨立帶團隊打下了堅實的基礎。

在京東的這幾年能夠清晰地劃分爲兩個階段。入職的第一年，主要是參與了不少業務需求和系統架構優化等自研需求的開發，在系統架構設計及優化方面收穫頗豐。後面纔開始慢慢帶團隊，纔有了今天要重點講的團隊管理方面的心得和體會。

3、團隊管理的心得和體會

因爲我帶的團隊負責的項目，在部門裏算是一塊相對獨立的新業務，因此團隊內的大部分事情基本上都由我來直接負責。重新人招聘、培訓到業務需求跟進，再到電商大促備戰等，基本上都親力親爲。在這個過程當中，我深入地認識到了，在以業務需求爲驅動和導向的大環境下，根據組員技術水平、擅長的技術點、以往項目經歷等合理分配開發任務，並保證業務需求按時保質保量完成，只是一個合格組長的最基本要求。除此以外，你還須要考慮團隊文化建設、團隊技術水平提高、團隊穩定性、如何作好上通下達等方方面面。一路走來，踩了不少坑，也學到了不少知識，對於管理團隊也有了不少本身的心得體會，下面我就講講我認爲比較重要的幾點。

1. 團隊文化聽起來很虛，可是真的很重要

看過一句話，是這麼說的：對於一個企業而言，決定短時間的是技巧，決定中期的是戰略，決定長期的是文化。我想，對於一個團隊來講，亦是如此。幾乎每一個企業都有本身獨特的企業文化，對於每一個團隊來講，也應該有本身的團隊文化。團隊文化，一聽起來就感受假大空，其實，咱們能夠換一個名詞，團隊氛圍。我認爲，一個團隊的氛圍好壞和團隊文化有着密切的關係，甚至能夠理解爲，團隊文化是內在本質，而團隊氛圍是外在表現。

那怎麼樣的團隊文化纔算是一種好的文化？我認爲，團隊文化是否獨特，是否彰顯個性，並不重要，重要的主要是兩方面，一方面，團隊文化要獲得團隊內大多數人的承認，例如：某個團隊宣揚，若是家庭生活和工做沒法平衡，你能夠選擇離婚。我想，這樣的團隊文化，即便表面上沒人反對，可是絕大多數人內心都是不承認的，這就不是一種好的文化；另外一方面，這個文化提及來能夠很抽象，可是必須有具體的例子能夠參照或者能夠具體執行或實施。那些只能意會、言傳，不能落實到實際行動的文化，都未免有點假大空的嫌疑，正向效果也不顯著。例如：某個團隊宣揚，你們要有激情、要奮鬥、要敢於爲公司將來奉獻青春，這些當作口號還行，喊着確實振奮人心。可是，振奮以後呢？冷靜下來想一下，怎麼作纔算有激情？怎麼作纔算奮鬥？怎麼作纔是爲公司將來奉獻青春？這種就很虛，除了喊的時候激情澎湃，真正做用卻不大。

2. 作好上通下達，拒絕越級上報

做爲一個管理者，特別是金字塔最底層的管理者，作好上通下達很是重要。你要讓你的組員清晰地知道，一方面，上層領導傳達下來的事情，你必定會及時地周知到你們，在你正式周知前，組員間儘可能不要討論道聽途說來的消息；另外一方面，每一個組員的努力、付出、成果、我的訴求等，你都會在評優選先或其餘恰當的時機和上層領導如實反饋，絕對不會埋沒你們的聲音。讓本身成爲一個承上啓下、上通下達的中間橋樑，讓雙方都可以及時順暢地交換信息，固然了，適當地過濾、加工也是很是有必要的。

在這種大前提下，實踐中我發現，將上層領導的消息傳達給組員相對來講比較容易，你能夠採用晨會、週會、一對一私聊等多種方式進行溝通。可是，將組員反饋的信息在恰當的時機同步到領導那裏，處理起來就要視時機、視具體內容、視領導處事風格等多種因素綜合考量。通常來講，歸屬上層領導的最底層的員工數量衆多，領導平時也有不少事情要處理，若是你每一個組員的每件事都要反饋的話，不免對領導形成騷擾，可是，若是你什麼都不反饋的話，又沒有作好上通這個點。

以如何反饋組員成果爲例：若是有很突出的表現或者很強有力的數據佐證，這種的能夠直接抄送上級領導和組內同窗，並加上你對組員成果的承認和激勵。可是，這種事情並很少，你們平時工做內容更多的是普通的業務需求、自研需求，也是咱們經常自嘲的「增刪改查」，那這種工做應該怎麼總結或反饋呢？我通常是鼓勵組員寫月度總結、季度總結、年度總結等，特別要注意的是，這類總結必需要認真對待，認真寫。如何讓你們認真對待，其實方法不少，例如：能夠找個時間讓你們每一個人都把本身的總結講一下，總結要抄送組內全部人，組長要作個帶頭做用等等，我就不展開說了。

當你把這類總結的事情貫徹落實後，你就會發現做用很強大，用途也不少。若是組員不少的話，做爲組長在月末的時候，很難作到很清晰地瞭解每一個人這個月都作了什麼，甚至是對於組員本身來講，也極有可能對本身這個月作了什麼很模糊，這個時候月度總結就很是有幫助了，另外，你還能夠擇優抄送上級領導和組員。而季度總結，年度總結，能夠儘可能讓組員作成PPT彙報的形式，一方面，能夠鍛鍊組員的總結、表達、溝通等能力；另外一方面，還能夠邀請上級領導參加，也能夠把時間選在績效評定、升職加薪評定等時間點前，會帶來諸多好處和便利。你們都知道，研發通常加班較多，經常總結才能清晰地讓本身、同事、領導都知道你都作了些什麼有價值有意義的事情。

其實，作好了上面說的幾點，作好了上通下達，也就不存在越級彙報的狀況了。可是，這個點呢仍是能夠和組員再次強調下的。

3. 注重培養歸屬感、責任感、主動性

說實話，雖然你們都不肯意認可，可是自私確實是人的天性。不是本身的東西，很難談什麼責任感，更不用說主動性了。因此，咱們纔要強調培養主人翁意識，即培養歸屬感，這是後二者的前提和基礎。

那麼，怎麼培養歸屬感，怎麼培養主人翁意識呢？你能夠將系統、業務範圍等根據組員的興趣點、以往項目經歷等多種因素劃分給指定人負責，並明確賞罰機制。要清晰地傳達一種思想，那就是，這塊東西就是你的，幹好了評優、升職、加薪等都會優先考慮，幹很差，出事情了，你要負責，我也會負責。

有了歸屬感，責任感也就天然有了，固然了，前提是他要是一個負責的人。而，對於主動性呢，就須要多多鼓勵，慢慢培養了。這個主動性呢，一言以蔽之，就是主動規劃或者作了一些除了你安排下去的任務以外的，對他負責的那塊將來有意義有幫助的事情。

4. 創建backup機制

backup機制，即互備機制，就是儘可能讓組內的每個人都有一個或多個備份存在，特別是在組內發揮重要做用的人。直白點說，就是儘可能要讓組內的任何一我的都是可替代的，固然了，這裏面也包括你本身。要儘可能達到一種狀態，那就是若是忽然某天某我的不在組內了，這個小組以及負責的業務必須可以保證正常運轉。

爲何要這麼作呢？首先，咱們任何一我的都沒法保證「7*24小時」隨時待命，那麼，咱們假設在某個時間點，有一塊線上業務出現問題，而熟悉這塊業務的只有一我的，這我的又恰巧不在公司且沒法遠程支持，那這個問題處理起來就會很是棘手。可是，若是除了這我的外還有一個或多個熟悉這塊業務的人在，那狀況就不同了。其次，咱們都知道互聯網從業人員跳槽頻繁，萬一某一天某我的離職了，若是這塊業務只有他熟悉，那必然會形成交接成本升高，交接後的隱患也會更多。因此，其實不少公司都要求中高層的管理者，上任以後必須在規定的時間內培養一個或多個能夠接替本身工做的人。對於最底層的小團隊來講，也是同樣的，只有盡最大努力貫徹落實backup機制，才能最大程度上保證團隊及業務的穩定性。

5. 靈活的「7*24」，而不盲目推崇固定的「996」

談到「996」，其實有不少互聯網公司是強制規定上下班時間的，強制你們執行「996」。從我加入京東到如今，並無遇到公司強制要求"996"的狀況，至少我所在的部門尚未強制推行。偶爾，項目比較忙的時候，「995」仍是有的，週末或節假日過來加班也是有的。

相對於「996」，我更喜歡和提倡靈活的「7*24」，這裏並非指你們要一週7天24小時一直工做，而是說，不管什麼時間，是工做日仍是休息日，是白天仍是晚上，若是公司有事情須要你支持，例如：緊急的線上問題，緊急的需求開發等等，而你又比較方便的狀況下，可以隨時趕到公司或者在家遠程支持。

對於加班這件事呢，我通常都是提倡：事情多的時候，你們就辛苦點，多加點班；事情少的時候，你們就早點回家，多休息休息，養精蓄銳而不是在公司乾耗着混加班時間。若是休息日有特殊狀況，須要你們犧牲本身休息時間來支持的，咱們能夠後續找一些恰當的時間請個調休假補償一下。目的其實只有一個，讓你們保持熱情，線上出現問題時可以積極及時處理，而不是用固定的「996」把你們搞得很疲憊，結果休息日出現問題的時候，沒有人願意支持處理。畢竟對於電商類產品來講，休息日也是用戶使用量較高的時間，保證良好的用戶體驗也是很是重要的。

6. 流程、規範、穩定高於一切

要保證團隊穩定、業務穩定，那這個團隊就必定要制定屬於本身的流程和規範。每件事情都要按照指定的流程走，好比上線功能就必須按照測試、灰度、全量等流程走，任何步驟都不容許跳過；每件事都要按照指定的規範來，好比文檔資料要按照統一的格式來，而不是爲所欲爲。咱們要清晰地認識到，不少線上事故都是執行者未按照流程、規範操做致使的，或者若是執行者按照流程、規範來作，就可以避免事故的發生，至少可以下降事故的負面影響。

7. 崇尚技術深度，而不盲目崇尚「新技術」

做爲一名研發人員，技術天然是你們的安身立命之本。不少研發人員都喜歡研究新出現的前沿新技術，不是說這樣很差，而是說，深度地學習和掌握工做中經常使用的現有技術纔是更加劇要的。一方面，咱們要清晰地認識到好多線上問題都是由於對現有技術理解有誤差或者對用法掌握不到位致使的；另外一方面，新技術在穩定性上每每有待驗證，本身玩玩是能夠，可是用在重要的項目上基本上不可能，萬一出現問題，後果是很是嚴重的。記住，永遠都不要拿項目的穩定性開玩笑。

8. 技術成長與業務需求相結合，產品需求和自研需求相結合

好多人抱怨我平時只是在作「增刪改查」，毫無技術含量，更不要扯什麼技術水平提高了。我以爲，並不都是這樣，好多業務需求仍是很須要架構設計和細節把控的。技術和業務相結合，技術纔有了價值，若是隻會技術，那豈不是成了紙上談兵。

另外，做爲組長，必定要控制下產品需求的進度和佔比，儘可能留出一些時間用來作自研需求。畢竟隨着系統中的功能愈來愈多，重構和優化每每是難以免的，特別是那些比較急的需求頗有可能採用了很暴力的設計和開發，是必需要儘早填上的坑，否則後患無窮。

4、團隊管理的小技巧

1. 作好新人培訓

不管是工做多年的職場老手，仍是剛入職場的應屆生，在剛剛入職的那段時間都像一張白紙。他經歷了怎樣的新人培訓，很大程度上影響着他將來在公司工做的態度和方式。另外一方面，新人培訓的好壞以及是否規範，也直接影響着新人對公司的第一印象。因此，新人培訓是很是重要的，要認真謹慎對待，下面是我認爲幾個比較重要的點：

• 流程規範培訓要優先於技術培訓： 技術水平不行，能夠慢慢學。可是，流程和規範必定要第一時間好好培訓和指導。一旦某種很差的習慣養成了，後面再改就很難了。新人引起的問題中，不少都是因爲操做不按照流程，不遵照規範致使的。
• 老人踩過的坑，新人也頗有可能會踩： 每一個團隊都應該整理一份「踩坑手冊」，記錄一下之前踩過的坑，遇到的線上問題及對應的分析總結。而後，每一個新人入職時，都把這些常見的坑提早多熟悉幾遍，不要求全都一一記住，至少要在腦海中留個印象，可以極大地下降踩「同類坑」的概率。一我的踩過的坑，儘可能讓整個團隊的人都不要再掉進這個坑裏了。
• 明確新人熟悉系統、技術等的順序和進度安排： 千萬不要和新人說，咱們須要用到A、B、C、D等，好吧，你本身看吧。最好能夠制定一個合理的熟悉順序和進度安排，明確好天天熟悉什麼，幾天熟悉完。你要知道，正確的熟悉順序確實能夠幫助新人提升效率，加快上手速度。另外，不要忘記，任務以及對應的deadline纔是第一輩子產力。
• 一對一導師制： 儘可能不要和新人說，組內每一個人都很nice，有問題隨便問任何人均可以。儘可能安排一對一的導師，這種方式效果更好。
• 新人手冊： 每一個團隊儘可能都要有一份新人手冊，能夠你們一塊兒維護編輯。這樣同一件事情就不用和N個新人說N遍了，你們本身翻閱便可，有問題再找帶你的導師問。極大地節省了你們的寶貴時間，也方便了將來遺忘時查閱。

2. 巧用主題池，作好團隊技術分享

團隊技術分享的好壞和分享主題的選擇有着極大的關係。那麼，什麼樣的分享主題纔算是一個好主題呢？我認爲，最重要的一點就是，分享主題要儘可能和平時工做有點關聯，能夠是平時用到的技術點的深刻研究，也能夠是同類技術的橫向對比。能夠維護一個技術分享的主題池，每一個人能夠把本身想知道的問題點、技術點加到池子中，組長來作統一的把關和過濾，每一個人分享的時候，必定要在過濾後的池子裏面選。這樣，既有必定的靈活性，可讓組員自由選擇分享主題，又能在必定程度上控制好主題選擇的範圍，保證主題都是你們想知道和了解的，對你們工做和技術提高有意義的。

3. 創建時間線記錄，輔助排查線上問題

當出現線上問題時，第一要務必然是要儘快找到問題緣由，儘快修復問題。那麼，如何快速定位到問題緣由呢？總結分析了不少線上問題後，我發現了一個規律。那就是，線上問題大體能夠分爲如下兩類：

• 主動類問題： 由研發人員主動操做引起的問題，我叫作主動類問題，即，由功能上線、修改配置、修改開關狀態等引起的問題。
• 被動類問題： 不是由研發人員主動操做引起的問題，我叫作被動類問題，即，由用戶訪問量激增、非研發人員的常態化操做等引起的問題。

而，不管哪一種類型的問題都是和時間強相關的。例如，若是你剛剛完成系統的上線發佈，然後發現出現了線上問題，這個問題的出現時間又恰巧和你的發佈時間相吻合，那麼極大機率就是此次上線引起的問題。再例如，咱們每一年都很是關注的雙十一大促，每到0點的時候，各系統的流量必然會達到一個峯值，而這個時候也是最容易出問題的時候。那麼，應該如何應對這兩類問題呢？

針對主動類問題，創建時間線記錄。將團隊內的每一次功能上線、修改配置、修改開關狀態等一切可能影響線上系統狀態的操做，都記錄下來。記錄內容能夠簡單地寫一下操做時間點及操做內容概述，你們一塊兒負責維護和編輯。這樣，一旦發現線上問題，第一時間看一下問題的發生時間點附近是否有研發人員主動操做了什麼。若是有的話，大機率和這些操做有關，可以較快地定位問題緣由。

針對被動類問題，由於咱們沒法控制用戶、非研發人員的行爲，因此只能靠預測和演練。例如，雙十一以前咱們能夠按照預測的流量進行演練，壓測等。再例如，若是系統運行地好好的，忽然出現線上問題，而出現問題的時間點在時間線上又找不到對應的主動操做，那麼能夠關注下該時間點用戶訪問量，系統調用量是否存在波動，是否因爲非研發人員的操做致使。

5、感謝

起初只是想簡單總結記錄一下，沒想到洋洋灑灑寫了這麼多。說實話，我作管理的時間也不長，有些想法也沒有深刻去實踐，不免有些偏頗和偏差，歡迎你們隨時交流和指正。

我在京東這三年來獲得的鍛鍊和成長，要由衷感謝一路走來的領導、同事、朋友。你們都很是優秀，不管是工做上仍是生活上，都給我不少的幫助和指導，讓我獲益匪淺。感謝這三年時光裏的每個人，每一件事，每個難忘的瞬間。