我叫王梓晨，來自京東物流研發系統架構部，現在負責京東物流 GIS 團隊。今天， 我想和大家分享的是如何打造全棧團隊。
首先假設現在有一支團隊叫“如此團隊”，裏面的成員如下：
我們的 PM（產品經理）叫小汪，他提出的需求是設計一個“航空母艦”；
我們的業務負責人 Business Owner，給他取名叫偉哥；
同樣還有些 RD（研發工程師），就叫他們小明和小強好了，他們的 leader 叫大貓；
團隊裏的 QA (測試) 同學叫小麗。
現在，這些團隊成員因崗位設置不同，職責自然也不同。但是在相互溝通的過程中，卻產生了一些問題。這並不是奇怪的現象，在日常工作中很多團隊都會遇見同樣的情況。
場景 1 ：溝通不暢怎麼辦？給你“好看”的
第一個場景，RD（研發團隊）的領導大貓有一天跟大家說：現在已經進入到了集成測試階段，需要和其他部門一起進行聯調測試，所以從現在開始必須做到 bug 日清。
不久之後，大貓查看 jira 等工具，發現依舊有很多 bug。這時候，大貓就開始問研發工程師小明是什麼情況？小明說這不是自己的 bug 啊，PRD(產品需求文檔) 上就是這麼寫的。測試小麗同學卻說不是這個意思，PRD 上寫的是另一種情況。爭執不下，無奈最後搬出 PM（項目經理）小汪來裁判，仔細聽了小明和小麗各自的闡述後，無奈地搖搖頭說，都沒理解到位！
我們經常會遇到同樣的溝通場景，但出現的原因是什麼？該如何解決？我建議可以從看板輔助開始。
說白了，就是建立一套透明可視化、標準化的流程。這是一個普通的看板，Idea 列代表 user story 還是一個萌芽，需要進一步孵化。進入到 PO 產品階段，需要細化需求，魚骨圖似的不斷的問爲什麼。之後才能進入到 Backlog 階段，在此階段，產品負責人需要分解出任務列表並確定優先級事項；最後纔是開發測試，開發和測試都要包含 to do / doing 和 done。有一些任務出現問題時，可以先把它放在一邊。當任務進入迭代時，你會發現這些問題是沒有價值的。那麼我們再回想一下，剛纔關於 bug 做到日清的問題，對照看板的內容來看：
在 Idea 到 PO (Product Owner 產品負責人) 這個階段，產品負責人應該把業務的投入產出比分析清楚，並且能把業務需求轉化爲開發需求。最後當整個需求要進行開發的時候，再把它拆分出任務列表並確定優先級，作爲整個迭代的開始。
在進入 Backlog 的時候，產品、研發和測試三方的同學應當一起把產品所有驗證點核對一下，要捋清楚環節和重要的收益點。
像之前出現的問題，很明顯能看到，是開發、測試和產品之間沒有進行溝通，基本是靠 PRD（產品需求文檔）來傳遞信息。所以我們應該遵循的首要原則是，文檔只能用作留檔和以後的追訴，不能代替溝通的作用。
場景 2 ：責任不清、互相推諉怎麼辦？
這個場景也很常見：某次大家一起開晨會，研發團隊領導大貓說需求需要下週四上線，大家評估一下可以嗎？研發同學說沒問題，測試同學小麗也說問題也不大。快到時間時，大貓問進展得怎樣了？研發同學說已經搞定了；但小麗說，B 系統那個接口根本調試不通，數據庫也訪問不通，集成的測試也還沒寫，週四可能沒辦法上線了。
這個問題對於看板來說，就是交付開發和開發完成的問題。現在我給大家細說一下。
在交付開發的時候，to do / doing / done 是來梳理需求的。因爲之前在 backlog 階段，研發已經和產品經理、測試一起討論過這個需要了（to do），如果在這個環節大體上來梳理清楚，就能真正做了 (doing)。在 done 的時候，一定要把單元測試寫好，且整體代碼覆蓋率要達到 90% 以上，同時也要幫助下一個測試環節的同學部署好測試環境。
而測試也分爲 to do / doing / done 。在 to do 這個階段可以和開發並行，在這個階段就去整理每一個業務驗證點，形成並梳理最後的集成測試，之後就可以準備上線了。那在測試完成到上線的時候應該需要做些什麼？
一個全棧團隊需要做以下這些事情：最起碼的基本配置要解決，代碼最起碼要把它推到到 git 上，同時把代碼下載下來。要完成這樣的集成測試，需要把整個業務條線都整理清楚；集成測試做完後，一定要檢查線上的環境。
作爲一個全棧團隊，一定要非常清楚每個環節潛在交付物的定義；當然其中最重要的一點是，上線之前一定要做好回滾方案。
全棧團隊成員應該具備什麼樣的技能？
接下來，我要分享的是全棧型團隊成員都應該具備什麼樣的技能？首先從領導來說。
首先，全棧型領導應該做一個服務型領導，要對整個團隊的任何情況負責，團隊出現了任何問題，第一責任人肯定是領導，而不是團隊裏的任何一個成員。這樣的領導絕不是控制大家，而是更多挖掘大家的主觀能動性。同時，這樣的領導一定需要有個人魅力，要自律，最好還能有一些幽默感。當然，其實最重要的一點，不要扛着下屬的猴子，避免把團隊成員應該承擔的具體責任落到自己身上，否則你就會成爲整個團隊的瓶頸。
其次，全棧團隊一定要講究執行力。這裏想和大家分享京東的人事與組織鐵律十四條裏的幾條原則。第一條是“No No No 原則”，但凡涉及到用戶體驗以及公司發展的需求，無論是誰提的都不能說 No，一定要給出解決方案；第二條是“24 小時原則”，所有郵件必須 24 小時內回覆；第三條是“會議三三原則”，一個會議時長不要超過 30 分鐘，PPT 不要超過 3 頁，PPT 裏應該都是乾貨，同一事件決策不超過 3 次，否則升級處理，保持溝通的高效；第四條誰發起誰負責，成爲第一責任人，如果出現問題，處理問題的同時應該立刻上報風險，讓所有的團隊成員知道。
最後，全棧型團隊一定是自組織團隊，自組織就是要多問個 Why ，同時需要每個人都有這樣的習慣。當邊界出現模糊的時候，需要有個人有主人翁精神站出來協調整個事情。
場景 3：與下屬溝通，怎樣纔是正確的姿勢？
再接着看下一個場景，研發同學小明最近感覺很困惑，一邊想學習新框架，一邊業務需求太多根本忙不過來，天天加班到十一二點，該怎麼辦？小明對領導大貓“吐槽”，這時候大貓可以有三種思維方式：
第一種思維方式是理性統領。他會覺得每個技術人都會經歷這樣的階段，慢慢地熟悉和習慣就好了。所以對小明的疑惑，就隨便應付一下。
第二種思維方式是感性統領。大貓會問小明是不是最近狀態不好？那你回家好好睡一覺，明天再戰。但是這麼做其實也不能從根本解決問題。
第三種思維方式是同理關懷。大貓會幫助小明分析，爲什麼想要學習新框架？知識獲取來源於哪？哪些需求是緊迫且重要的？是不是有些需求可以放到二期來做？作爲團隊領導，應該切實去幫助員工解決問題，而前面的那兩項基本沒有什麼用。
我們還是拿研發團隊領導大貓來舉例。大貓說，你應該在上線後確認 checklist 裏的內容是否執行到位，觀察上線一小時後才走；你要看一下 CPU load 是多少？Disk 是多少？這可能是技術人一直以來的溝通方式，但現在是作爲領導來溝通，如果總是以這種形式，大家會心裏有什麼感受？
這就是我要講的同理心，更多時候是傾聽，那傾聽應該要注意什麼？我覺得要注意兩點。
第一，放下假設。我在每次和我的團隊成員去溝通的時候，我必須放空自己，把所有的假設全部去掉。
第二，要注意傾聽。在傾聽過程中呢，一定要站在對方的視角，只有站在他的角度，才能正確的幫助他來進行分析。
場景 4 ：如果下屬工作走偏了，該怎麼辦？
這裏有另外一個場景，領導大貓問小明這個季度主要做了哪些工作？小明回答說做了一堆的需求，每天都忙成狗。大貓接着問下週的計劃？小明說，持續學習，比如我在做 Nginx+Lua，想在前面加一層網關，或者也可以看看 Open resty 的源碼吧。
很顯然，小明是沒有清晰計劃的。這時候就需要領導來引導下屬進行目標管理。這個目標管理，不只是簡單的 OKRS，並且我們一定要細化。
針對不同的目標，我們把它細化爲門檻是什麼？目標是什麼？挑戰是什麼？這些都不能是統一一個標準。同時應該對定性和定量做一下區分，並且要給它們做不同的權重。
做到這些以後，每天做的工作都要對它進行細化，每天強迫自己做一個總結和計劃，每週、每月、每季度都應當如此。當你自己對這部分內容能不斷的給它做總結和反饋的時候，你慢慢地就發現你在這個過程當中成長了很多。
還有一個就是部門溝通。在部門溝通和彙報的時候，一定要注意結構化溝通，就是要結論先行，然後再逐層次細化。
場景 5 ：領導的職責界限在哪裏？
還是拿場景來說，研發團隊領導大貓說，要做一款時效類的產品，爲了足夠快只做到本地緩存就可以。小明聽了之後說，本地緩存是有限的，JVM 的 Max 對內存不確定得配到多大才足夠，否則容易導致 OOM。大貓想了想說，那就做內存集羣。小明回答說，如果做個內存集羣，那就可以做 Shard 和 schedule，那爲什麼要做一個這麼複雜的集羣？
作爲一個服務型領導，你不應該事無鉅細，你需要做的是確定每一個邊界設計合理的檢查點，在風險來臨之前及早地發現它，並且儘快地解決它。假設你交給小明一個任務，小明不能把它完成得很好，這時你不要讓另一個人替代他的工作，否則小明會很有挫敗感。最好的辦法是找個人和小明一起分析，以小明爲主來向來進行彙報，這樣更有助於小明的個人成長。
剛纔說的這個例子就是動機債的問題，那麼什麼是動機債？
作爲一個領導來說，首先要做好方向上的指引，確定好方向，定好邊界和檢查點後交給團隊成員。當然，對於風險要有預判性。比如這個成員可能會遇到什麼樣的問題，可以找誰輔助，在什麼階段輔助等等，這些都是要提前規劃好的。
其次是員工滿意度。團隊領導必須做到言必行，行必果，它的每一個承諾必須得如實來履約。最後，是一定要做適當的授權。授權的意義是培養有潛質的成員成爲新的領導，來承擔更多的責任。同時還要注意，因爲工程師心理都“很脆弱”，所以一定要注意他在組織中的地位，要讓他感覺到自己是不可或缺的一部分。
作爲全棧團隊的領導，如何激勵團隊和創新？
我的場景故事分享完了，其他部分是一些小枝節，全棧團隊基本是一個有差異性的團隊，它是由不同水平的成員構成。針對這樣差異性的團隊，我們需要給它營造一個比較好的環境，有利於成員發揮創造力和靈感，能進行及時的思考和反思。
比如說組織覆盤或者做一些創新遊戲、破冰遊戲等等來調動團隊氣氛，我認爲這是作爲 Leader 是非常重要的。其次，差異性的團隊應該從三個方面來綜合考慮，一是自主權，二是能力，三是地位。
我們要明白每一個人都是獨立的、不可替代的。不是說誰代碼寫得快，誰就是團隊裏最好的。在此基礎上還要保持一定的秩序，在某些方面要做到公開透明。比如說績效，誰是 A 誰是 C 都要做到公開透明。
對於成員來說，有時候可能需要你和他做深入溝通，要做一對一的專項輔導。對人才的梯度建設，京東有一個五星管理法就是把人分爲金子、鋼、鐵，以及鐵鏽這四個部分。
· 金子是最好的，能力和價值觀是最棒的；
· 80% 的人都是鋼，就是價值觀很好，能力一般；
· 鐵就是能力可能一般，價值觀還不錯；
· 鐵鏽可能能力很棒，但是價值觀不行，這種人一定要第一個從團隊中把他踢出，他一定會影響到整個團隊士氣，非常可怕。
在觀察成員的時候，我們需要注意某個成員是如何處理人際關係，包括處理組織內部關係和組織外部關係，處理個人和 HR、IT 運維支持之間的關係，這個一定能反應出來這個人的綜合素質。如果他在各個方面都處理非常好，那麼這個人一定是個非常不錯的人。
以上都是激勵團隊和成員的一些方法，接下來是說創新。創新是發展之本，那麼具體該如何做到呢？
· 持續地解決問題；
· 團隊之間一定要善於分享，彼此肯定；
· 善良勇敢。
這些是每個團隊裏面大部分人都應該必備的一些因素。在有節奏衝刺的時候，我們需要做到團隊目標和規則清晰，主動參與並能做到積極的反饋，這樣才能成爲團隊創新之本。
今天我把試圖打造全棧技術團隊之路上的一些經驗和踩過的坑分享給大家，未完待續，全棧團隊，我們依舊在路上。
TGO鯤鵬會，系極客邦科技旗下高端技術人聚集和交流的組織，旨在組建全球最具影響力的科技領導者社交網絡，線上線下相結合，爲會員提供專享服務。目前，TGO鯤鵬會已在北京、上海、杭州、廣州、深圳、成都、硅谷、臺灣、南京、廈門、蘇州十一個城市設立分會，武漢分會即將成立。現在全球擁有在冊會員 740 餘名，60% 爲 CTO、技術 VP、技術合夥人。
會員覆蓋了 BATJ 等互聯網巨頭公司技術領導者，同時，阿里巴巴王堅博士、同程藝龍技術委員會主任張海龍、蘇寧易購 IT 總部執行副總裁喬新亮已經受邀，成爲 TGO 鯤鵬會榮譽導師。
如果你想和這些優秀的科技領導者們一起前行，歡迎點擊「報名表單，申請加入」。