[[373663]]

 前幾天在脈脈職言看到這樣一個提問：帶團隊的人，你們是怎么了解業務細節的?如果不了解，怎么懂的比實際干活的多的?

從技術管理的角度來看，這個問題可以很典型地反映出研發崗與技術管理崗的差異。今天我們就來聊一聊這個事情。

技術管理的思維

從提問者的文字描述來看，我們大致可以推斷出他的想法：Leader 肯定要比員工懂得更多的技術細節，不然怎么做 Leader 呢!站在技術 Leader 的角度，這句話其實對錯分半。對的地方在于技術 Leader 確實懂的比員工多，但不是細節，而是全局。錯的地方在于技術 Leader 并不需要懂所有細節。

當你從一個員工變成了 Leader 的時候，你的職責不再是做完這個需求就完事，而是對這個團隊的產出負責。這個時候你個人是否實際去做事，是否了解具體的細節，其實變得不再重要了。你關注的重點應該是整個團隊，你應該去做哪些對整個團隊有益的事情。

之前你能很好地完成一個需求，并且能非常出色地完成。但即使你再怎么努力，你最多也就影響這一個需求而已。但如果你是一個團隊的 Leader，那么你做的事情就可以影響整個團隊，此時你的產出就是這件事乘以所有人。從這個角度來說，你此時考慮的應該是整個團隊，而不是具體某個需求。

關注團隊的整體產出，而不是自己具體做了多少需求，是成為技術管理者的思維轉變第一步。

現實情況不允許

為什么說技術 Leader 不需要懂所有業務細節?

這是因為現實情況不允許!因為這是一個不可能完成的任務!

當團隊只有兩三個人的時候，技術 Leader 確實是可以親力親為，什么事情都自己干，任何一個業務細節都摸透了，遇到線上問題自己沖在前面。但是當你的團隊變成 8 個人了呢?當你的團隊變成 20 個人了呢?你的團隊變成了 100 個人了呢?你還能了解所有細節，你還能所有問題都自己解決嗎?

想必對于這個問題的答案，大家都清楚，答案肯定是不可能!那么既然不可能，那么我們有什么辦法去解決「大團隊」的工作協作問題呢?此時這個問題就不再是技術問題，而是一個具體的學科問題，我想這或許是組織管理、領導力的概念了。這塊我也不是很懂，所以這里就不展開了。下面我結合我的實際經驗，聊聊十幾個人的團隊怎么做組織管理和分工協作。

團隊達到十幾個人，我們需要有授權的概念。授權的意思是我把一部分權利分給員工，員工可以在權利范圍內自行決定，不需要經過 Leader 的同意。通過這種方式，來提高事情的處理效率。但授權同時也伴隨著責任，這就像法律的義務與權利一樣。

授權講得直白點就是：這塊業務給你搞了，這塊業務上發生的任何事情，你都需要關注，包括線上問題、系統優化等等。你可以自行決定需求的技術方案以及優化改進措施(權利)。你是這塊業務的直接負責人，業務有什么問題你就是第一責任人(責任)。

經過授權之后，一般十幾個人的團隊會拆分成 3-5 個人一組的小組，單獨負責 1-3 個系統。這時候這幾個小組是一個獨立的單元，可以高效地自行運轉，不需要你做太多的干預。這時候很多業務細節，其實并不需要你去干預。你只需要在關鍵時刻給予支持和輔導就可以了。

那么是不是 Leader 就完全不需要懂這塊業務的內容了?那肯定不是，技術 Leader 只需要了解個大概，知道這個東西大致是什么，業務細節可以等到具體需要的時候再了解。

如何總覽全局?

那對于技術 Leader 來說，怎么樣快速了解一個系統?又怎樣在需要的時候可以快速上手了解業務細節呢?對于我來說，了解一個系統最重要的其實就是兩個東西：數據庫 ER 圖、系統架構圖。

數據庫 ER 圖，其實就是業務模型。 所有的系統到最后其實就是數據，如果你弄懂了數據庫 ER 圖，明白了實體與實體之間的關系，那其實你就弄懂了這個業務。在你遇到問題的時候，你就知道怎么去找關聯關系，怎么去排查問題。所以弄懂數據庫 ER 圖是很重要的。

系統架構圖，其實就是系統的具體實現結構。 如果說 ER 讓你弄懂了業務模型，那系統架構圖就是讓你明白系統是如何運作的!你弄懂了業務模型，但你不懂系統運作的原理，那你還是無法入手去排查問題、去寫代碼。但如果你弄懂了系統架構圖，那你就知道系統數據流是如何走的，問題可能出現在哪里，我這個需求需要改動到哪些地方。

ER 圖和系統架構圖，基本上是我了解一個系統的關鍵。在實際工作中，我也是只了解這兩個東西，再加上一些需求的大方向。而具體的細節，恕我直言，真的太多了，無法一一了解。如果真的到了那種需要技術 Leader 自己動手排查問題、自己動手寫需求代碼，那這個團隊真的離崩塌不遠了，所以這個問題其實可以忽略。

或許下次可以寫一個：為什么技術 Leader 自己寫代碼、排查問題，這個團隊就離崩塌不遠了?

他山之石

上面就是我對這個問題的一些只言片語，說得有點亂，沒啥太多的邏輯，但思想是對的。這個問題下也有不少熱心的網友寫了很不錯的回答。這里也摘錄一些。

諸葛瑾推薦了三本管理相關的書：

1. 拉姆查蘭《領導梯隊》，管理領域的經典力作，詳細闡述了從基層 leader 到 CEO 各個層級的能力要求和工作方法。2. 陳春花《管理的常識》，顧名思義這本書是講管理的基礎概念，越是基礎越需要理解，每次讀都有不一樣的收獲。3. 前美軍特種作戰司令斯坦利麥克里斯特爾《賦能》，闡述的是如何像園丁一樣通過給團隊賦能，最大限度發揮團隊成員的主觀能動性，打造應對不確定性嗯敏捷團隊，這本書對于如何對自己不擅長的專業領域進行有效管理非常有啟發(這也是高層級管理者需要具備的可遷移的通用能力)

諸葛瑾聊了聊他的一些想法：

帶團隊重要的是如何帶領團隊形成合力創造更大的價值，并走向一個更好的未來。如果還一直在關注當下很多細節，說明團隊沒有成長起來，下面的人還不能獨擋一面，或者內部外部的協同有問題。大概可以從以下幾個方面思考：1. 定目標，短期與長期，個人與團隊;2. 劃邊界，團隊內與外;3. 追過程，關鍵節點;4. 拿結果，保質保量拿到目標結果;5. 建團隊，選用育留開人;每個方面要做好都要花很多心思。一個優秀的管理者應該是這個團隊有他沒他都能運轉的很好，這樣才能更好地往下一個層級發展。

華山弟子舉了一個很形象的例子：

如果你管理的團隊，還要靠你來主力輸出的時候，就需要考慮自己的問題在哪里了。這就好比京東物流，每天東哥送貨量占比 50% 以上，這是什么畫面。

騰訊員工聊了聊他的想法：

肯定不了解業務細節啊… 帶領著一幫人做成一些事，才是 team leader 的職責，至于這些事需不需要他自己來做，根本無所謂，要的是結果。最基本的，一個項目扔給你們團隊，能否保質保量按時交付。重要的是交付，而不是 leader 和大家一起寫代碼。更進一步，團隊是否有戰斗力，比如能否交付有難度的項目。這取決于團隊成員的技術能力和協作能力，技術大佬可以是但沒必要是組長。組長最重要的還是協調組織能力。如果自己不在一線，那就要想辦法給一線兄弟們帶去更多利益，不然誰跟著你干?樓主：也許我的思維還沒轉變，總想讓別人知道自己干了多少事。回復樓主：干了多少事很簡單啊，哪些活是你接過來的?這些活的意義你有沒有了解清楚，價值是什么?怎么拆解給兄弟們的，怎么管理研發進度的?作為一個 tl 對整體項目負責，你做了哪些去負責?比如服務掛了你是不是不知道?為了監控到可能的問題，有沒有做詳細的監控方案，有沒有兜底方案?這些事情你想到了，可以交給組員來實施，什么進度了你有沒有跟進?為了提高迭代速度，你做了哪些研發流程的管控，從而提高組員的工作效率和需求響應時間?最終通過你的組織協調甚至直接參與架構和代碼設計，團隊做出了哪些成績。

名草求主的回答也有不少人贊同：

不要想著帶人的了解系列比底下人多，否則你就是不合格的主管，了解個大概，知道對方在做什么，給方向爭取資源利益才是你該做的，否則就是不懂瞎指揮，做主管的自以為比別人懂導致實質意義的瞎指揮的真不少。

小結

回歸到這個問題：技術 Leader 是怎么了解業務細節的?

我的答案是：不需要了解太多的業務細節!作為技術 Leader 只需要大致了解業務模型、系統架構就可以，細節問題交給手下的弟兄們。作為技術 Leader 的你還有更多、更重要的事情去做!

大家是否有類似的經歷?是否也曾吐槽過自己的 Leader 啥都不懂瞎指揮?是否不理解為啥啥都不懂還能做 Leader?是否也曾陷入到業務細節的坑里面，無法自拔?

本文轉載自微信公眾號「陳樹義」，可以通過以下二維碼關注。轉載本文請聯系陳樹義公眾號。