一個稱職的技術負責人應該是什麼樣的？

01-19

技術
管理
分配工作
生活
預研

軟體工程
團隊規劃等方面都可以，各位資深的leader都來聊聊。

Good question！謝題主 @張明雲之邀！

看一個技術負責人稱不稱職，非常簡單地說，就兩條：

1、能出好活

帶領的團隊能按時按質的完成開發，持續地為公司創造利潤。

2、能壯大團隊

在創造業績的同時，開發團隊也能不斷地吸收優秀的人才、後續力量，不斷充實壯大，而不出現人才逐步流失的情況。

國內外的許多一流企業團隊都符合以上的正循環，他們的技術負責人自然是稱職的。然而如果要詳細分析技術負責人是否稱職的評判標準，那麼就有點複雜了。

定義

軟體研發的技術負責人有許多種類和稱呼，例如從 TL（Technical Lead or Team Lead，也叫班長、隊長、小組長等）、開發經理（主管）、技術經理（主管）、架構師（Architect）、主任架構師、首席架構師（Chief Architect）。。。一直到 CTO、總工等等，這些都是技術負責人，而不同職位、不同級別的技術負責人，對於「稱職」的評判標準和要求也各不相同。

此外，軟體研發組織可分為一流、二流、三流。三流企業或團隊的技術負責人肯定是不稱職的，而一流、二流組織對於「何為稱職的技術負責人」的要求也有所不同。

二流技術負責人

不管哪裡的江湖，二流、中等企業的數量是最多的，以下先結合二流企業的情況來談。一般來說，稱職的技術負責人具有以下幾個特點：

1、為人正派、可靠，具備較好的科學、工程修養。

首先，做人是第一位的，一位 TL 好不好首先看他為人的品性。

得到公司領導、團隊成員的基本信任（Trust）是開展任何工作的前提，沒有 Trust，何來稱職？

2、懂公司政治，善於處理好各種人際關係。

我把「懂政治」和政治素質放在第二位，這在中國人的企業文化環境中尤其重要。

歷史上許多技術骨幹、技術還不錯的新人由於不懂權力政治，年少傲嬌，不懂得把握說話做事的分寸，在這個上面摔過跤，吃過苦頭。這些 TL 常常以為自己技術牛，便不把別人放在眼裡（包括領導，甚至自己的直接上司），盛氣凌人、桀驁不馴，處理不好關係、得罪領導和同事的結局當然是被領導冷藏，逐漸邊緣化，最終被排擠出團隊。

五千年來，這樣的領導與下屬的案例舉不勝舉。大家可能都聽說過一兩個，而且有的就發生在自己身邊。最著名的大概是曹操與楊修的故事。

二流企業的公司政治環境，比起一流企業來，往往複雜得多。別忘了，作為技術負責人，你只是被老闆雇來幹活的。政治素質不好、平時愛大嘴、容易得罪人的人不可能升級到更高級的技術管理崗位。

3、技術過硬，熟悉軟體工程方法論。

4、熟悉管理，善於帶團隊。

待續。。。

1 技術上短期能搞定問題：在預算和時間要求內解決問題

2 技術上長期可以建立合理的技術架構，沉澱有價值的核心技術

3 能帶團隊：團隊戰鬥力和效率可以提升，個人綜合能力有提升

4 能代表技術和其他部門協調工作，告訴他們那些問題利用技術可以輕易解決，那些不要抱幻想，能不能換個方法。

5 能代表團隊去要待遇、要資源

6 該隱退的時候可以讓位

作為一個需求方，感受如下：

合作過的最稱職的技術負責人：

1. 能夠根據需求和問題所在，給出技術解決方案；

2. 給出的方案，能夠覆蓋到多種情況，多種因素，簡而言之，靠譜；

3. 在team遇到技術難題時，都找他，他能解決；

4. 給出方案後，能夠「按時」「保質」「保量」的完成；

5. 有風險預判和應急方案；

6. 有良好的溝通意識，責任心；

再說說遇到的各種奇葩：

1. 不敢承擔責任，每次做決策都要拉上一堆相干不相干的部門一起擔責任；

2. 「我說的完成，是指開發完成，後面還有有測試和聯調時間呢！」

3. 合作商整個team加班support他聯調，老兄到點一句話不說下班走人了；合作商傻傻的等了一個多小時，在qq里問調試結果怎麼樣了，答曰，我在地鐵，明天再說；

4. 合作商整個技術team，自己公司的運維，dba都等著調試結果，問了好多話，半天沒反應，過去一看，玩LOL呢；

5. 遇到問題不反饋，快到交貨的時間點，和他check，哎呀我遇到XXX問題了，這個時間恐怕不行了；

6. 「我本周內一定給」「周五我加班也給你做完」「這周我擠時間給你做」「明天要公測了啊，我現在做！」

與此類似的還有很多。。。。數不勝數，說真的，溝通問題，真的是最頭疼的事兒了

就一點補充。。。。

得能優雅的告訴產品經理他SB的地方。

哎呀這是個非常好的問題，題下張老師王老師的答案非常好，我的回答只是一點而已點贊的幾位仁兄謬讚了！

對技術負責人的要求，是和技術團隊的規模有關的。好的技術負責人應該有好的動態領導力，在團隊的不同階段，發揮不同的作用。下面就從技術團隊角度看看，稱職的Leader是啥樣的。

1. 小團隊，3~5人

團隊規模偏小，團隊協作上容易組織，團隊成員的分工比較清晰，此時的工作重心應該在技術上，而且在技術的深度上。

此時的Leader更像是技術攻堅者或技術領頭羊，將研發上的難點重點扛起來，能及時解決問題，能讓團隊成員感覺跟對人，有信心。
進度與質量控制方面，決定因素在於難點是否能及時攻克，如果問題都能及時解決，那進度壓力相對就小，也就有更多的時間來照顧代碼質量考慮程序架構。Leadr的研發能力基本就是決定性因素了。

2. 中小團隊，6~10人

團隊初具規模，此時Leader不僅要盯著技術更要重視團隊。

研發方面，在深度研究的同時，要拓寬視野，多了解所處行業的新動態新知識，即在廣度，在知識面上要鋪開來。這時的團隊規模，足夠出1-2個牛人了，在研發的深度上，可以交給這1-2個牛人，把人員梯隊給建設起來。而Leader應當尋找突破點，打破瓶頸，將整個團隊的研發能力，工作效率，都提升起來，提升木桶中最低木板的高度。
代碼方面，工作重點不再是如何實現某一兩個功能點，而是產品整體實現。以何種模式組織程序結構，如何實現低耦合高內聚，如何向前兼容，如何避免版本分裂，如何控制bug率，如何挖掘業務數據，如何有計劃地將上述問題逐步解決，才是Leader的重點。
進度方面，人多會出亂子，為了避免出現不可控的情況，要先分組。人員分組可以是動態的，根據迭代情況調整小組成員。分組能確保重點功能按時完成，但很容易出現能者多勞，其他濫竽充數的情況，所以及時反饋進度也必需跟上。Scrum的站會+郵件知會，可以將具體任務落實到人，既不佔用太多時間，又能實時掌握動態，很推薦。
質量方面，這個規模的代碼量註定了Leader不可能單挑所有成員了，需要靠規範，制度來提升質量。具體到每個團隊，會由於歷史原因，公司文化，進度壓力等等，出現不同的規範。舉例來說，設計文檔，介面文檔，代碼交叉review，單元測試，代碼檢查工具，自動化集成與測試工具，這些都可以有。
團隊建設，Leader需要培養好的團隊文化，說白了就是各種好習慣，各種好的潛規則。10人的團隊，技術水平，個人背景，年齡，都有差異，如何讓大家都認可團隊目標，都認可自己的工作，是一件長期且很有意義的事情。什麼是好的團隊文化呢？比如每個RD都覺得自己是PM，哈哈：）

3. 中型團隊，11~20人

十多個人研發人員共同做一個項目，肯定是大項目了，此時Leader的應當有足夠的經驗和能力，而在眾多能力中，我認為最重要的是「殺伐決斷」。

方向。Leader有權利也更有義務，確保整個團隊的方向是正確的，同時Leader要足夠堅定，獨立判斷，能扛得住上邊的壓力，也能分辨出身邊的誤導。不要猶豫不決，在決定前三思而後行，在決定後一鼓作氣勢如虎。
業務。如此規模的團隊Leader，只精通技術肯定不夠了，必須對所經營的業務也有深刻的認識。技術上的所有努力，最終的目標是讓產品有更多人喜歡，讓業務有更好的發展。如果不熟悉業務，很容易犯方向上的錯誤，在這個層面上出錯，往往又很要命。
資源。領導是拿來幹啥的，就是拿來要資源的嘛。你手上有這麼多兵，你也要給團隊足夠的彈藥，足夠的信息，足夠的後勤，要為了超額完成KPI爭取足夠多的資源。有了資源怎麼用，要放權。巧婦難為無米之炊，捨得放權，懂得給資源，才能有美味佳肴。

好了，由於個人經驗有限，超過20人的團隊該怎麼帶就不YY了，以上內容也算拋磚引玉，希望對有興趣的同學有所幫助~

真是個好問題，於是不請自來。

作為一個技術負責人，我按他身上的職能重要程度來一次說吧：

1、管理：這個是重要的一點，甚至重要過技術本身。之所以它最重要，是因為它決定了你在這個位置上的心態。所謂管理者，首先要對公司以及公司的股東負責，然後才是對用戶負責，最後是對手下團隊負責。請不要搞混這個順序。任何一個順序的搞混，都會讓你在管理崗位上犯下很嚴重的錯誤。你之所以坐在這個位置上，是你的領導覺得你在這個位置上能為公司創造更大的價值。僅此而已，所以千萬別想太多，做多餘的事情。

2、技術：作為一個技術負責人，技術肯定是安家立命之本。所以我的原則永遠是：絕不下第一線。見過很多技術見長的人，升任管理後，就退居二線，導致幾年以後業務生疏，新招的手下完全不聽管教，甚至鄙視領導。殊不知他的領導曾經也是業內有名的牛人。所以這樣的悲劇是不應該的，作為技術負責人，唯一能服眾的就是你的技術，絕對、絕對、絕對不能放下技術，而專註於管理。技術負責人不是帥才，而是將才。所謂將才，自然是衝鋒殺敵一馬當先，要有誰人不服，便斬誰人於馬下的霸氣。

3、預研和經費的問題：這是個老大難的問題，參照條目1。你站在公司利益的角度去思考這個問題，如果是一個長足的利益發展，自然很容易說服股東和你的領導。但是，往往很多很多的技術負責人真的不是從這個角度去思考預研這個問題的。所以也無法說服任何人來付出當前的若干利益。

4、團隊建設：原則性問題基於條目2。但作為團隊，你總要有人一起幹活。但關於技術的問題，絕對不要減分的人，是一個很關鍵的原則。我見過不少leader喜歡追求手下的數量，導致團隊臃腫但沒什麼卵用。所以你要做到的是團隊中的每個人都有他的價值。適度的精英文化很適合這樣的情景，畢竟工資差別不大的情況下，能力的差別非常大。當然，作為一般的leader，是沒有多大的機會決定人事相關的，更多的時候，只能有什麼人，用什麼人。這時候，人才的培養和合理安排就是非常關鍵的問題了。這個在下一個條目講吧。

5、分配工作：這個對於一個能力很強的技術負責人，真不是什麼問題。一個人頂一個團隊，還要什麼手下，手下的工資，我一個人全拿了，還更省心。（以上純屬玩笑）。好吧，一個人頂一個團隊的事情，我們先不去想了，既然有團隊，那自然逃不開分工的問題，在給手下分配工作的時候，原則性的指導方針永遠是：處理情緒的問題比處理技術的問題更重要。你必須善於去捕捉每一個屬下的情緒狀況，幫助他們去調節和控制。千萬不要把重要的工作分配給一個剛失戀或者剛吵架的情緒低落的傢伙，如果你這麼干，我相信你得自己花數倍的時間幫他收拾爛攤子。分配工作還有另一層次的概念：人才培養。有計劃的分配工作給特定的人，是可以讓他得到不斷的成長的，團隊面對的業務壓力肯定會隨著市場的變化而變大。所以作為leader是必須有足夠的遠見來預計未來團隊所需要面臨壓力時需要的人才儲備，及早的培養目前可以用的人，而且還包括現有人員離職的風險等等。

6、生活：如果你做不到生活和工作的完全剝離，那我就不談這個話題了。私人生活永遠不要和工作有任何交集。

上面很多答案，感覺把這個「技術負責人」當做神人了，啥都要管、什麼都要解決……

技術負責人其實就是負責從技術維度把關，協助確保項目成功交付。然後實際環境下，技術負責人還承擔了很多產品經理的需求工作、項目經理的進度和風險管理工作、團隊或研發經理的人員管理工作等等。

我推薦看看我在這個答案裡面推薦的書籍：IT項目管理有什麼好的書籍推薦？ - 徐毅的回答

說一下我所在部門的技術負責人

1.懂的維護手下，針對扯皮撕逼問題敢於置高層面前替下屬解釋，而不是推卸責任讓手下背鍋

2.懂的把控團隊節奏，張弛有度，不做強制規定，一切結果導向，充分發揮下屬主管能動性

3.出於對產品質量的考慮與風險的把控，敢於對產品經理及高層say no，不為KPI盲目實現需求趕進度（這點絕逼的重要）

4.技能樹強悍，樂於分享，把握得住技術上的大方向，又能實現得了小細節

5.了解每個下屬所擅長的及不擅長的，把每個人放到最需要，最合適他的工作位置上去（下屬每個人都乾的很嗨皮）

6.為人低調謙和，和其他職能部門的溝通、協調都很順暢（尤其和產品汪們相處的異常和諧）

7.獎賞分明，你工作努力，主動替你向高層申請獎勵

「He"s a man who got the job done.」

-《Spy Game》

一個好的技術負責人簡要就三點

1,技術把控能力

2.項目管理能力

3.團隊協作能力

總結: 一個技術負責人首先要做的就是能平等的對待部門的下屬，不管他做的哪個崗位，不能比如只重視開發，或者測試而對其他人不尊重，採取刻板的壓別人。

我們作為行銷，經常對外把產品包裝的各種高大上，回去各種說產品狗，用戶的需求是怎樣怎樣，你要添加什麼功能云云，然後產品狗就去逼死程序猿，最後程序猿要麼做出解決方案，要麼拿刀捅死產品狗。