隨著JD.COM的快速發展和變化，它總是充滿機遇和挑戰。壹個想法從提出到落地，再到發展成重點項目的整個過程是極快的。當然，前提必須是這個想法必須有價值，得到領導的認可和支持。
16年學校招生加入JD.COM的時候，我有幸加入了壹個成長迅速、潛力巨大的項目團隊，業務覆蓋面迅速擴大，領導重視度高，團隊成員非常好。好在我加入的時候，整個項目經過幾次電商的試水已經逐漸穩定，正處於業務覆蓋範圍快速擴大，系統承載流量快速增長的關鍵階段。在這個關鍵階段，最重要的不僅是保證業務需求的正常進行，還有系統架構優化升級、不同業務領域功能解耦、底層數據優化、獨立性等壹系列自主開發的需求。為了在流量快速增長的情況下保證系統的優異性能和高穩定性，從架構優化、關註點、業務覆蓋、業務性質等方面對原有的兩三個系統進行拆分、重構和升級，逐步演變為由搭建系統、渲染系統、數據系統、國際化等多個子系統組成的“大系統”。我有幸參與其中，讓我對如何打造壹個億級流量的電商後臺系統有了清晰深刻的認識，也為我後來獨立帶領團隊打下了堅實的基礎。
JD.COM的這些年可以清楚地分為兩個階段。入職第壹年，主要參與了業務需求、系統架構優化等多項自研需求的開發，在系統架構設計和優化方面收獲頗豐。只是後來開始慢慢帶團隊，才有了今天要重點講的團隊管理的經驗和理解。
因為我所在團隊負責的項目是部門裏相對獨立的新業務，所以團隊裏的大部分事情基本都是我直接負責。從新人招聘培訓到業務需求跟進，再到電商推廣準備，基本都是親力親為。在這個過程中，我深刻認識到，根據團隊成員的技術水平、專業知識和以往的項目經驗，合理分配開發任務，確保按時保質保量完成業務需求，只是壹個合格團隊領導最基本的要求。另外，妳還需要考慮團隊文化建設，團隊技術水平提升，團隊穩定性，如何做好溝通和發布工作。壹路走來，踩了很多坑，學到了很多知識，也為管理團隊收獲了很多自己的經驗。我來說說我認為比較重要的幾點。
我看過壹句話是這麽說的:對於壹個企業來說，是技能決定短期，是戰略決定中期，是文化決定長期。我覺得壹個團隊也是如此。幾乎每個企業都有自己獨特的企業文化，每個團隊也應該有自己的團隊文化。團隊文化，壹聽就覺得空洞。其實我們可以換壹個名詞，團隊氛圍。在我看來，壹個團隊的氛圍與團隊文化密切相關。甚至可以理解為，團隊文化是內在本質，團隊氛圍是外在表現。
什麽樣的團隊文化才是好的文化？在我看來，團隊文化是否獨特並不重要，主要是兩個方面。壹方面，團隊文化要得到團隊中大多數人的認可，比如某團隊宣揚，如果家庭生活和工作無法平衡，可以選擇離婚。我認為，這樣的團隊文化，即使表面上沒有人反對，但內心卻不被大多數人認可，這不是好的文化；另壹方面，這種文化可以很抽象，但必須有具體的事例可以參考或者可以具體實施或執行。那些只能言傳身教，而不能付諸實踐的文化，多少有點虛假的嫌疑，正面作用也不大。比如壹個團隊宣揚每個人都要有激情，有奮鬥，勇於為公司的未來奉獻自己的青春。這些口號還可以，喊起來真的很鼓舞人心。然而，熱鬧過後呢？冷靜下來想壹想。怎樣做才能充滿激情？什麽是奮鬥？我該怎麽做才能把自己的青春獻給公司的未來？這種很虛，除了喊的時候有激情，但真正的效果並不大。
作為管理者，尤其是金字塔底層的管理者，做好溝通和分配是非常重要的。妳要讓妳的團隊成員清楚地知道，壹方面，妳會及時知道最高領導傳達的所有事情，在妳正式知道之前，盡量不要在團隊成員中討論道聽途說的消息；另壹方面，每個團隊成員的付出、努力、成就、個人訴求等。，妳會在第壹時間或者其他適當的時候，給高層領導誠實的反饋，絕不會淹沒大家的聲音。讓自己成為承上啟下的紐帶，讓雙方及時順暢地交流信息。當然，適當的過濾處理也是非常必要的。
在這個前提下，我在實踐中發現，把壹把手的消息傳達給團隊成員是相對容易的。可以通過晨會、周會、壹對壹私聊等方式溝通。但要在合適的時間同步團隊成員對領導的反饋，需要綜合考慮時機、具體內容、領導風格等多種因素。壹般來說，底層有大量員工屬於高層領導，領導通常有很多事情要處理。如果非要反饋每個團隊成員的每壹件事，必然會對領導造成騷擾。但是，如果妳根本不給反饋，那妳就沒有做好和他們的溝通。
以如何反饋團隊成員的成績為例:如果有突出的表現或者強有力的數據證據，這種報告可以直接抄送給小組裏的上級領導和同學，加上妳對團隊成員成績的認可和鼓勵。但是，這樣的事情並不多。大家平時的工作內容更多的是常見的業務需求和自我研究需求，也是我們經常自嘲的“增刪查”。這類工作應該如何總結或反饋？我壹般鼓勵團隊成員寫月度總結、季度總結、年度總結等。特別需要註意的是，這樣的總結壹定要認真對待，認真寫。其實有很多方法可以讓大家認真對待。比如可以找個時間讓大家說說自己的總結，總結要抄送給群裏的每個人，組長帶頭，我就不開始說了。
當妳把這種總結付諸實踐的時候，妳會發現它非常強大，非常萬能。如果團隊成員很多，作為壹個團隊領導，很難在月底清楚的了解到大家這個月都做了什麽。甚至對於團隊成員本身來說，很有可能對自己這壹個月做了什麽都很模糊。這時候月度總結就很有幫助了。此外，您還可以選擇上級領導和團隊成員。季度總結和年度總結可以讓團隊成員盡可能的做PPT報告。壹方面，他們可以鍛煉自己的總結、表達和溝通能力。另壹方面，也可以邀請上級領導參加，也可以選擇在績效考核、升職加薪考核之前的時間，這樣會帶來很多好處和便利。眾所周知，R&D平時加班加點，經常總結是為了讓自己、同事、領導都清楚自己做了什麽。
其實以上幾點做好了，溝通發好了，就不會越級上報了。但是，這壹點還是可以跟團隊成員再強調壹遍。
說實話，雖然大家都不願意承認，但是自私確實是人的本性。不是自己的事情，就很難談責任，更談不上主動。所以要強調主人翁意識的培養，也就是歸屬感的培養，這是後兩者的前提和基礎。
那麽，如何培養歸屬感和歸屬感呢？妳可以根據團隊成員的利益、以往的項目經驗等因素，將系統、業務範圍等分配給指定的人，明確獎懲機制。要明確傳達壹個理念，這個東西是妳的，優先考慮評先、升職、加薪等。出了事，妳負責，我負責。
有了歸屬感，責任感自然就來了，當然前提是他是壹個有責任心的人。但是，對於主動性，我們需要多鼓勵，慢慢培養。這個主動，壹言以蔽之，就是在妳安排的任務之外，主動去計劃或者做壹些對他未來有意義、有幫助的事情。
備份機制，即互備份機制，就是讓群體中的每個人都盡可能有壹個或多個備份，尤其是在群體中起重要作用的人。說白了就是盡量讓群體中的每個人都可以被替代，當然也包括妳自己。盡量達到壹個狀態，如果有壹天突然有人出組，這個組和它負責的業務必須能夠保證正常運轉。
為什麽要這麽做？首先，我們誰也不能保證“7*24小時”隨時待命。那麽，我們假設在某個時點，某個線上業務出現了問題，而熟悉這個業務的人只有壹個，而這個人恰好不在公司，無法遠程支持，那麽處理這個問題就會非常困難。但是，如果除了這個人之外，還有壹個或幾個熟悉這個業務的人，情況就不壹樣了。其次，我們都知道互聯網從業者頻繁跳槽。如果有壹天有人走了，如果這個業務只是他熟悉的，那麽必然會導致交接成本更高，交接後的隱患更多。所以，實際上很多公司都要求中高層管理者在上任後的規定時間內，培養壹個或幾個能夠接手工作的人。對於底層的小團隊來說，也是壹樣。只有盡最大努力落實備份機制，才能最大程度保證團隊和業務的穩定。
說到“996”，其實很多互聯網公司都把規定上下班時間做成了強制性的，強迫大家執行“996”。自從我加入JD.COM，我還沒有達到公司的強制性要求“996”，至少我的部門還沒有強制執行。偶爾項目忙的時候“995”還是有的，周末或者節假日過來加班也是有的。
相比“996”，我更喜歡和提倡彈性的“7*24”，不是說每個人都要壹周24小時工作，而是說無論什麽時間，無論是工作日還是休息日，白天還是晚上，如果公司需要妳的支持，比如緊急的在線問題，緊急的需求開發等。，而且妳很方便，可以隨時到公司或者在家遠程支持。
關於加班，我壹般主張:事情多的時候，大家會更努力，多幹活；事情少的時候，大家都會早點回家，多休息，養精蓄銳，而不是在公司加班。如果休息日有特殊情況需要大家犧牲休息時間來支持，我們可以找壹些適當的時間來要求休假補償。其實目的只有壹個，讓大家保持熱情，及時處理線上問題，而不是用壹個固定的“996”讓大家疲憊不堪。結果休息日出現問題，沒人願意支持。畢竟對於電商產品來說，休息日也是用戶大量使用的時間，所以保證良好的用戶體驗也非常重要。
為了保證團隊和業務的穩定，團隊必須制定自己的流程和規範。壹切都必須遵循指定的流程。比如上線功能必須遵循測試、灰度、總量的流程，不允許跳過任何壹個步驟。壹切都要按照規定的規範來做，比如文件要做統壹的格式，不能隨意。我們應該清醒地認識到，很多網上的事故都是因為被執行人沒有按照程序和規範去做，或者說如果被執行人按照程序和規範去做，事故是可以避免的，至少可以減少事故的負面影響。
作為研發人員，技術自然是大家安身立命的根本。很多R&D人員喜歡研究新興的前沿新技術，不是說這個不好，而是說深入學習和掌握工作中常用的現有技術更重要。壹方面，我們要清醒地認識到，很多網上的問題都是因為對現有技術的誤解或者對用法掌握不到位造成的；另壹方面，新技術的穩定性往往需要驗證。自己玩是可以的，但是在重要的項目上基本用不上。壹旦出現問題，後果會很嚴重。記住，永遠不要拿項目的穩定性開玩笑。
很多人抱怨我平時只是在做“增刪查”，沒有什麽技術含量，更談不上技術水平的提升。我不認為總是這樣。許多業務需求仍然需要架構設計和詳細控制。技術只有和商業結合起來才有價值。如果妳只懂技術，那將是紙上談兵。
另外，作為團隊負責人，壹定要控制好產品需求的進度和比例，盡量留出壹些時間進行自研需求。畢竟，隨著系統中的功能越來越多，重構和優化往往是不可避免的，尤其是那些迫切的需求很可能會被暴力設計開發，這是壹個必須盡快填補的坑，否則後患無窮。
無論是工作多年的老手，還是剛入職場的應屆畢業生，在剛入職的時候都像壹張白紙。他經歷了什麽樣的新訓，很大程度上影響了他以後在公司的工作態度和方式。另壹方面，新人培訓的質量和規範程度也直接影響新人對公司的第壹印象。所以新人的培養很重要，要謹慎對待。以下是我認為比較重要的幾點:
團隊技術分享的好壞與分享主題的選擇有很大關系。那麽，什麽樣的分享主題才是好主題呢？在我看來，最重要的是盡可能與平時的工作分享主題，可以是對平時使用的技術點的深入研究，也可以是同類技術的橫向比較。妳可以維護壹個技術共享的主題池。每個人都可以把自己想知道的問題點和技術點添加到池中，組長會做統壹的檢查和篩選。當所有人分享時，他們必須從過濾池中選擇。這樣就有了壹定的靈活性，讓團隊成員可以自由選擇和分享主題，同時也在壹定程度上控制了主題選擇的範圍，保證主題是每個人都想知道和了解的，對每個人的工作和技術提升都有意義。
當出現在線問題時，第壹要務壹定是盡快找到問題原因，盡快修復。那麽，如何快速定位問題原因呢？在總結分析了很多網上的問題後，我發現了壹個規律。也就是說，在線問題大致可以分為以下兩類:
但是，無論什麽樣的問題都和時間有很強的相關性。舉個例子，如果妳剛剛完成系統的上線發布，然後妳發現有壹個上線問題，而且這個問題的時間和妳的發布時間重合，那麽最大概率就是這個上線發布導致的問題。再比如，我們每年都很註重雙十壹促銷。0點的時候，各個系統的流量必然會達到壹個峰值，這個時候也是最容易出現問題的時候。那麽，我們應該如何處理這兩類問題呢？
對於活躍的問題，建立時間線記錄。記錄團隊中每壹個可能影響上線系統狀態的操作，如功能上線、修改配置、修改交換機狀態等。記錄內容可以簡單寫下操作時間點和操作內容概述，大家壹起負責維護和編輯。這樣壹旦發現線上問題，第壹時間就能看到問題發生的時間附近是否有R&D人員在積極操作什麽。如果有，大概率與這些操作有關，可以快速定位問題原因。
對於被動問題，因為我們無法控制用戶和非R&D人員的行為，所以只能依靠預測和演練。比如在雙十壹之前，我們可以根據預測的流量進行演練和壓力測試。再比如，如果系統運行良好，突然出現在線問題，在問題出現的時間線上找不到對應的主動操作，那麽可以關註這個時間點的用戶訪問量，系統調用量是否有波動，是否是非R&D人員操作造成的。
壹開始只是想簡單總結記錄壹下，沒想到寫了這麽多洋洋灑灑。說實話，我從事管理的時間不長，有些想法還沒有深入實踐，難免會出現壹些偏差和錯誤。歡迎隨時交流指正。
我想真誠地感謝壹路走來的領導、同事和朋友，感謝他們讓我在JD.COM的三年裏得到了鍛煉和成長。大家都很優秀，無論是工作上還是生活上，給了我很多幫助和指導，讓我受益匪淺。感謝這三年裏的每壹個人，每壹件事，每壹個難忘的瞬間。