技術經理時間經常被下屬的業務問題或者技術問題佔用，這個現象合不合理，如果不合理如何改善？

01-29

自己日常工作中也會有一些開發任務，我會盡量分配給其他人，但是有時因為要解決其他人的問題自己的任務就延期。那麼工作任務量化的時候幫助其他人完成任務該怎麼量化？

感覺技術經理這個title真碉堡了。。。想想我還只是個資深工程師的title好弱。

團隊10個人左右的時候，的確是我這輩子最手忙腳亂的時候，一邊招人，一邊填坑，一邊業務增長快，一邊搞規範整技術方案，一邊接手node，然後各種bug各種臟代碼，然後還要關心團隊成員，制定目標，鼓動大家積極性，還要承受有人離職的痛苦。

真心是每天手忙腳亂啊，跟產品撕逼的時候脾氣那個暴躁啊，後來直接把產品都氣走了。。

後來團隊到了20個人的時候，感覺一切都開始慢慢走向正軌了，我也輕鬆了不少，現在要做的就是調整好自己的狀態和角色，給大家更多的空間承擔更重的責任，而我則推進一些技術或者業務上的事情。想想以前那麼悲催，感覺一切都值了。

謝飄揚君邀請。

這個問題可能比很多朋友想得要難。簡單的回答當然是不合理，因為一個人的原因讓另一個隊友花時間補他的工作，肯定是不合適的。但是，在某個具體的階段，它確實又有合理的成份。不能一概而論。在我的工作中確實曾經多次遇上過這種情況。在此分享一點經驗吧。

首先，我希望說明一件事，以下討論都基於兩個前提，這是我自己的工作狀況，也是目前觀察到的許多情況下技術經理的現實狀況。如果您的情況不同，那麼也許完全沒有可比性。

技術經理沒有人事權，或者沒有完全人事權。也就是說，遇到不滿意的人，解僱或要求離隊，只能是最後方案，或者根本不是選項。
技術經理有技術工作，但也需要對團隊建設負責。
技術經理保有任務分配權。

當我注意到我的時間被頻繁打斷時，我會設法做一個判斷：下屬不停提問，背後究竟是什麼原因？我遇到的例子無外乎四種之一：是對領隊有依賴；不熟悉新環境；單純地是能力不足；不願意鑽研。而四種情況的解決之道也不同：

對領隊有依賴，多發於新人身上，特別是剛畢業沒多久，缺少自信的小盆友。這種情況其實沒有什麼好辦法，因為他們需要跨過不自信到自信的這道坎。作為技術經理，是有義務幫助新人過這道關的。所以當隊伍中有新人來時，我會有意地分配一些時間給他們，幫他們熟悉。另一個技巧是，盡量讓他們按自己想法嘗試。
不熟悉新環境。如果是個老手，就給他一塊東西讓他負責，然後指定一個資深隊友回答問題。順便背後觀察一下他有沒有交流溝通上的問題。如果有的話可以在背後幫助一下，如果沒有就讓他自己折騰去。如果是新人，同前一種。
能力不足。這個情況需要進一步判斷：他有沒有繼續學習和進步的潛力？如果有，而且隊伍又確實需要人手，那麼該花時間的就得花。如果確實鑽研能力也不足，就得調換一個相對容易的崗位，讓他總能為隊伍做力所能及的貢獻。
不願意鑽研。這是態度問題，但未必都是負面的。我還需要繼續做一個判斷：他是不是因為對目前的工作沒有興趣？還是根本就是來混事的？所以我會先觀察一段時間看看他的興趣所在，然後考慮調個崗位讓他試試。如果是前者，往往就能解決問題；如果是後者——多見於領導派下個親戚——那就給個清閑任務讓他自己折騰，不要影響隊伍的產出即可。

但無論哪一種情況，總有一些通用的技巧總可以用：

給自己劃定固定的時間用於解答。作為技術經理，幫助隊友總是必需的。比如我自己的心理預期是每天兩小時（25%）。
允許隊友偶爾問多一些。只要沒有超過自己劃定的用時限度，沒必要太精神過敏。
如果決定對某個隊友確實需要特別關照，給自己的一個固定的時間階段，比如兩個月。做這個決定之前，需要聯繫有人事權的老闆反映情況並彙報計劃。

如果朋友們讀到這裡，應該能看到我跟前面朋友看法的一個區別。在我這裡，培養別的隊友代替我回答問題，不是選項。理由有二：首先，這是在轉移而非解決問題；其次，別的隊友的績效會因此受影響，這不是身為團隊負責人應該選擇的方式。

就這樣。

推薦你兩本書，

1. 別讓猴子跳回背上：為什麼領導沒時間，下屬沒事做？

2. 領導梯隊

搞清楚責任和界面，oop的本質

我的經驗就是，儘可能的讓別人去做，不必擔心別人搞不定，哪怕他的技術水平的確不如你，你也要相信，母豬逼急了也能上樹。

我曾經在一個項目組裡面扮演差不多的角色，項目經理基本不懂技術（只能寫點copy paste的代碼，也在最忙的時候幫忙copy paste了不少代碼就是了。。。），只管進度，我一方面負責寫核心邏輯部分的代碼，一方面要幫助組員解決各種技術問題，更麻煩的是，那個時候其實我也還是個水貨，所以我的大部分時間都花在幫他們研究問題上了，我每天從上班開始在別人的電腦前坐到七八點鐘，然後回到自己電腦前寫代碼寫到半夜12點下班。。。

某天，我跟公司的一個資深老員工抱怨這個事情，他看著我，就說出了我上面告訴你的話：「儘可能的讓別人去做，不必擔心別人搞不定，哪怕他的技術水平的確不如你，你也要相信，母豬逼急了也能上樹。」，說完這些，他抽了一口煙，噴出來，任由煙霧蓋住了我的臉，悠悠的又補了一句：豬啊，你看，你不也上樹了么。。。

受益於之前在知乎各種安利大家給我投簡歷，現在我們的前端團隊也越來越多人了。同樣的，我也遇到題主的這些問題。關於這些問題，我在知乎看了不少討論，尤其是「阿里、騰訊以及一些創業公司是如何進行研發管理和績效考核的？ - 團隊管理」這個問題下提到的 OKR 模式，讓我覺得很有用。

所以業務需求及工程需求到了我手頭上的時候，我會對它進行拆分，把它分成各個模塊，這些模塊就是 Keep Result，輸出對應的設計文檔。而這些 Keep Result 分配到各前端工程師手裡的時候，就變成了他們的 Objective，他們自己再進行拆分，變成他們的 Keep Result。

然後，我們要求對自己每周的時間進行分配，使用 Google 日曆之類的，share 給我，這樣我就可以隨時對他們正在做什麼比較了解了。這從另一方面提高了他們的工作效率。

這樣之後，每周一我都會進行 review，檢查他們的 Keep Result 完成的程序，對他們的進度提出建議。

------------------------------------

對於如何解決他們經常來問你問題，而打斷自己的思路或者延遲了自己的安排這個問題，我是這麼處理的：

讓他們儘可能地使用非同步的方式來進行提問。什麼是非同步的方式呢？就是我會讓他們儘可能地用郵件或者在 Github Repo 上提 Issue 的方式來向我提問，要求在一封郵件 / issue 里把問題描述清楚。很多時候，當他們把一個問題描述清楚的時候，就已經解決一大半的問題了，剩下的可能只需要一些關鍵詞的提醒而已。
鎖定某個時段不允許被打斷。大家都明白，程序員被打斷思路是一個把多麼讓人苦惱的事，所以我和他們約定下午 2:00~5:00 不能來打斷我，有事要用微信或者郵件給我留言。我也會把電腦和手機的 Do Not Desturb 功能打開，讓自己不受干擾，專註工作三個小時。因為技術上的問題不會因為延遲三個小時解決而出什麼大問題，每個人手頭上肯定還有別的活要干，所以當有問題需要我幫忙的時候就留言，等待我的回復。

團隊管理我懂得不多，很多思想是從 BOSS 身上和網上學來的，如果有什麼能改善的地方，歡迎大家來討論~

最重要的信息沒給，你直接下屬多少個人？

如果小於10個，那麼你日常的工作應該是8/2原則，8是就應該是在處理具體的業務和技術問題，2是處理一些管理的問題。

如果大於10個，小於20個，原則上就需要有1到2，lead的中間層了。你應該是一半處理業務和技術，一半做團隊決策和管理了。

如果大於20個。前面有位朋友說的對，人才梯隊問題變得無比重要。你一定需要至少2個lead，lead的成熟度和能力就至關重要。你的任務應該是8分的管理，2分的技術和具體業務。抓大放小變成了你的主要任務。具體大部分技術指導應該是由lead來完成，你負責lead之上更高層次的方向把握和技術決策。

合理。

技術經理對團隊最大的價值，就在於能夠節約成員調查學習的時間，降低總體成本。

一個問題可能講解半個小時，就足以指導開發人員順利寫出代碼，而他自己研究卻需要1天。

你們兩個半小時的成本 vs. (初級開發人員1天的成本 + 交付工期延遲風險)

這就是技術經理的價值所在。

對這個問題的解決辦法。

1，培訓。技術經理應該，並且有必要對員工展開定期的培訓。不用擔心教會徒弟餓死師傅，你做了什麼，有什麼貢獻，大家心裡都有數。

2，建立可復用，可積累的知識庫。

例如搭建一個內部wiki，把工作中經常被問到的問題花一些時間進行總結。減少重複講解的浪費。

1，5個人左右升一個你這樣的，代替你做這些，你分配任務的時候少給他們分些，這樣做既能解決你的問題，又能給其他人發展機會，但是要非常注意這些人的培養。

2，你的時間用來做你認為最重要的事情，比如人員招聘，管理，技術培訓，核心業務開發

作為一個技術經理，我可以跟你分享一下我的時間管理方法。

我一天的工作中，30%的時間是關注下屬的工作進度和幫助解決下屬的問題。這些問題大多是基於工作方法和流程，而不是具體的技術問題。相信我，技術問題不應該由技術經理來解決，而是應該由該領域的技術專家、供應商的技術專家或者他們自己來解決。技術經理應該給予的指導是工作方法和流程，幫助他們了解如何正確的做事和做正確的事情。避免他們把過多的時間放在不重要也不緊急的事情上。而這個偏偏是所有技術人員最容易犯的毛病。

50%的時間用來跟上級領導開會、溝通工作進度、講述工作中遇到的困難並尋求資源上的幫助。我所說的資源包括人員、經費、授權等等。另外，寫報告、做總結、做工作計劃也會計算在這個時間百分比裡面。

最後20%的時間是靈活機動的，主要用於個人提升，總結管理經驗教訓，提高管理技能以及提高自身的技術能力。我不必是這個技術領域的專家，但我必須保證下屬所說的技術問題我有最起碼的認知。這20%的時間我也會用來休閑、學英語以及刷知乎。

我的前任老闆有個理論，如果你整天忙得腳不沾地，那隻能說明你效率太低、能力太差以及沒有做好工作授權和指導。我覺得是有道理的。

教會別人教別人。

團隊成員都太弱了？假如你的團隊成員都像知乎上那些伸手黨的話，那肯定你是一點時間都沒有了。

你至少要找一些會自己研究解決問題的人在團隊里，需要時給點意見建議提示，剩下的就讓他們自己去研究唄。你每天只要在有限的時間裡解決他們問題就行了。

說明你們團隊裡面沒有其他比較大拿的人

今天指導一個同事實在無語，運行效果不對，還硬說自己沒錯，看來平時簡單問題指導多了，阻礙他的進步，也耽誤了自己的工作。以後一般技術問題一概自理，實在不行就自然淘汰。

我現在的情況和題主類似，最初覺得大多數時間耗費在幫助別人解決問題上了，慢慢找到了辦法：

1.培養一個和自己類似的開發人員，讓他去幫助他人，解決不了再自己出馬，大家共同進步了。

2.組織team內技術分享，可以每周一次，關鍵是每人輪流主持，自己開頭。讓團隊形成良好的分享氛圍，同時也可發現每個人的擅長領域。

3.不雅什麼事情都親力親為，他們比你想像中更強。要委派他們，指明方向即可。

培養一個技術專家的角色，還可以對新兵蛋子做培訓

說實話，有時候我的情況也和你一樣。

會叫你解決問題的，一般有兩種，要麼是你的team內的，那如果他的工作結果會影響到你這邊的工作的，那不解決也要硬著頭皮解決，當然，可一可二不可三，如果真的是他能力問題，那呵呵，公事公辦該多辦就怎麼辦。如果不是自己team裡面的，我一般都是除非手上忙死了，不然都是過去看看，然後一看知道什麼問題的跟他說一下，如果不知道的，花幾分鐘看一下，如果解決不了，我就說呵呵，我手頭上還忙，你先自己看看哈，。。