作為前端負責人，團隊成員工作自己不能分配，前端工作又要我協調，好痛苦？

01-29

作為前端負責人，團隊成員都分配到各個業務特性組，每個特性組一個前端，若干android，若干伺服器，日常需求都是特性組負責人安排，說的好聽點，就是一個光桿「司令」，特性組內工作我不能直接干預.現在的問題是我自己也是特性組一個的前端，需求一樣要自己做，同時又要負責日常的團隊管理和技術規劃，參加日常需求技術討論等事情.而特性組有5個，其中有四個特性組獨佔前端資源，另外一個特性組有前端需求需要協調其他特性組人員支撐；這時特性組之外的需求（緊急插入需求，活動需求，運營需求，管理系統，外部配合等）全部到我，這個時候悲劇了！某個特性組前端需要協助時，需要協調PK借人.這種情況下，前端團隊很難有自己的規劃，要做點什麼事情要提前只會，還要一一PK，同時因特性組前端成員沒有backup，一個人撐起一片天，一直串列做需求（需求特別多，做不完），團隊成員會壓的太狠，自己又好累好累，請問各位同行有什麼建議？
下面是根據大家的回復補充的相關信息：
業務特性組是有上面決定的，短時間來說無法更改，當然這個主管也在考慮這個問題。我們的工程化都是做的還不錯和一些前端新技術也都到應用和跟進，這些大部分都是我的主管自己早期建設的，其他團隊成員都忙於需求，很難有時間做些技術性的工作，最多也是了解，具體應用還需要有時間積累！我是最早的一批入職的前端，經歷整個項目的生命周期，業務以及業務相關使用技術（前端，移動開發，Hybrid App）可以說非常熟，所以面對其他問題或者需要協助時，知道團隊成員已經被業務壓的很死，很多事情都是自己親力親為，保證整個大組業務線不出問題。雖然需求和技術的月度規劃有做，但對於前端來說，要的快，機動性強，這就導致很多情況不能按原計划進行。目前情況是經常會有插入性緊急需求，臨時需求，比較突然的新業務等等，我們也不想接，但產品又說優先順序高，先做這些，其他暫停，一些計劃全打亂了，自己優化需求即使排了，都很難做，因為都是自己擠時間做，即使能做，也是斷斷續續。有時候在想，為什麼android和server團隊都有專門的框架組，性能專項組，可以不用做業務，H5為什麼就這麼難？是團隊還沒到那個時候？還是大家對前端的觀念沒有轉換過來？

四個小夥伴加你一共五個人力，作為leader 你是一定要寫代碼的，這沒什麼好討論的。聽起來你們業務線就五條還不算加急需求。

那麼無論前端這個團隊在不在一起你都是要一個業務組一個人了，所以為了高效和減少溝通成本你們這種開發方式前端接受業務線leader領導也是對的。

有人說了加人。

這是一個辦法但是加人要有理由要有老大支持要有資源不知道你有沒有啦作為leader 你這個情況加人是必須的至少保證一個組一個固定前端一個可以處理臨時需求的並且隨時補充到各個組的人我的意思很明白你至少還要加2個人。

這樣才能保證你不被業務牽扯有精力做團隊管理和技術儲備等leader應該做的事。

還有一個就是工作任務分配的問題，一個人是否可以支持2個業務線？不清楚你們的業務但是在一些公司確實是可以的也都存在的。

如果不行需求一定要先到你手裡然後你再和業務組的leader討論安排工作排期，用排期來控制人力不足的情況。要不你會累死你的兄弟們，作為了leader 要學會對需求方說不不是不做而是表示不加人就做不完加班也做不完。砍需求 or 上線延期 or 加人。

這樣你就可以補人。否則你一直不會有補人的機會。

最後 5，6個前端的team，建議先做好技術積累解放生產力在需求評估時做好排期保證team的學習和成長進度這些在評估時都要考慮，我就不教你啦，比如自測，連調時間等等，和pm還有產品的關係一定要好，該做的做不該做的不做。

等團隊到了10幾個人的時候你再考慮不寫代碼的管理吧。

既然必須寫代碼那麼非代碼的管理時間也評估到寫代碼的時間周期里就好了。這應該是常識了…比如一個功能你1天寫完但是因為瑣事多要照顧的事情多你預估三天就好了老闆pm問你為什麼這麼簡單的功能要做三天？

你把別的組的事給他一列，說我精力都分散到哪些哪些地方了，不就好了？聰明的老闆會明白你的意思的。大家都是講道理的。

沒有backup也是個問題這會導致項目新需求和老bug日常需求無法串列進行這個要和pm商量了，解決辦法還是加人要不就老老實實排期做完日常再做項目人數有限不要死扛死扛你也扛不住的。

還有有的大神可以1擋2 有的可以1擋3 但是你指望1擋4這麼搞換我我就離職咯。。

再補充一下評估需求時間的技巧一定要開發的人和leader一起 leader負責把控和解疑開發負責根據自身能力預估開發時間倆者結合再打個0.5到1的自測時間是一般的情況了。連調是連調這部分再算哈。

這個現狀在我上一家公司中赤裸裸的出現過，當然最後的結局是我出局了。做為一個管理12個人的所謂的leader，被架空的感覺非常不好受。

我也有過爭取和老闆聊到目前的狀況，項目的進度等情況，後來我發現我錯了，在老闆眼中，我是一個悲觀主義者，是一個事事跟老闆唱對台戲的人，老闆只要求你能做還是不能做，並不會管你是不是super man。

我做的第一件錯事是把架構師的活攬了過來，自研框架，UI庫，配套的基礎設施（構建，部署等）。第二件事情是把直播項目攬了過來，兩個人開發，運用自研的體系。（以為把專業做到位，卡住最優的項目，就可以有話語權）

我做的第二件錯的事情是組織內部培訓，指導某些人，盡自己最大的可能把知識輸出出來。（最後的結局是辭職之後，那幾個人直接把我微信刪除了）有時候想想，自己沒有功勞也有些苦勞吧，還不感恩。

我做的第三件錯的事情是幫其他業務些的人攔截不合理的需求，大家都不是超人，可以每天每周24小時的工作。人數就在那裡，怎麼調度都調度不來。（最後的結局是跳過了我，直接和一線的開發對接，反而覺得我這個角色不幹活，盡對著干）

我做的第四件錯的事情是攬過來了面試，其他HR，產品的技術培訓，踏踏實實的做一些事情，反而（BOSS覺得你是超人，這些都是你應該做的）

最尷尬的事情是我做了努力，被完爆。

首先你們要坐到一起。

如果按項目劃分區域，就很難保持團隊凝聚力。你作為公司的leader這一點還是可以爭取到的。（不過也要看公司給你的定位，有可能跟你自己的定位有區別，這樣就很尷尬了）

然後就是努力做到技術領導者，而不是管理者，這一點很重要(當然leader的定位也不是管理者)。

做法是，

1:你要對各個項目線有一定的了解，處於什麼階段，面臨什麼問題… 合理提出建議

2:讓他們給你彙報項目中有木有問題難點要求助的，解決他們在開發過程中的難點問題

3:定期抽時間review他們的代碼，給他們提供好的建議

4:為他們擋掉不合理的需求

5:可以定期進行技術分享，增強團隊氛圍，還有團建什麼的

6:……

重點不在於加人，而是先要提高開發效率，減少不必要的資源浪費。

如果把效率和資源整合都做好了，還缺人再考慮申請加人…

以上作法都建立在你可以通過技術產生成績，為公司帶來利益，然後才能服眾，才能確定自己的位置

切忌耍嘴炮

你作為前端負責人一定要凝聚前端這個團隊，而不是分散到各個小組，方法很多。

自己向上級溝通協調人力的事兒，盡量前端所有人向你彙報，不向你彙報你也控制不了。

各個組的需求來了你先權衡和調派人力，而不是需求直接提給前端一線員工。

你要有強勢的資本和理由，向上溝通

作為leader你的需求是什麼？做技術規劃？開發提升效率的基礎工具？組內學習？

把這些需求寫到小弟的KPI裡面，這點權利總有吧~

沒事聚聚會吃個飯聯絡下感情

順便討論討論KPI

既然當leader肯定會遇到普通程序員遇不到的問題，解決的好你就很快變成大leader，解決不好只能止步不前甚至回歸程序員。大公司里不是資源不足而是沒利用好，如果是創業小公司當leader 你可能既要寫代碼，又要跑業務，還要招人，說不定還兼職產品和設計，你肯定會羨慕手底下有幾個程序員的日子。

團隊管理各種問題的根源大概都在於失去主動權

首先，團隊每個人都需要有自己的態度和自律，端正態度，沒有什麼協作不了的。

過了『人』這一關，其次，才是真正的領導和協作。

人員不過關，就算你領導能力管理能力再牛B，就算你有權有勢，也無濟於事。

不過感覺題主情況好複雜.....

1、技術方案一定要想周全並在開發前拍板；

2、方案定好後，推進團隊強力高效執行

3、關注開發過程中項目：

3.1 項目時間節點管理

3.2跨部門溝通和資源協調，幫助成員順利專註開發。

3.3 核心代碼或文件一定要及時review或者自己擼。

3.4 高度對結果負責。

4、注意觀察團隊成員的特性，量才而用。及時調整團隊發展戰略。

5、團隊情緒管理。

這是一種按照職能水平拆分的管理結構，部門或公司不大不小的時候會這樣，其中最尷尬的就是你這個leader，因為你本身對各個垂直的業務沒有控制力，工作不好分配，目標管理不好做，績效更不好考核，有一些建議供你參考：

1. 首先明確你對團隊每個人每天做什麼必須要了解，包含時間節點如何。每個成員工作有變動必須要能夠做到向你彙報，你就是整個前端業務需求的介面人。技術方案你不一定你出，但是你必須審。

2. 建議不要自己寫業務代碼了。寫代碼的精力都用來review所有人每天提交的代碼，review的工作強度隨著你小組成員的能力增長而減少。

3. 每周五利益相關部門群發小組成員下周工作安排和時間節點。

4. 核心業務強推單元測試或集成測試，覆蓋核心功能。這點強推壓力很大，但是我只能告訴你好處也很大，人員流動，誇業務開發的培訓成本低很多。

5. 每周挑一個重點業務組內一起review，不局限於代碼也附帶業務背景講解，這個對降低人員流動的時間成本也很有幫助。

6. 一定要能向上級說清楚你有忙，開發的工作時間絕大部分不在於寫代碼。任何時候需要你backup的時候你要能說清楚自己手上有什麼工作有多重要，當然公司營收壓力下來也不是你能抗住的，但是你要能交代清楚你加入對其他工作的影響，不要把自己搞得太忙，一個人一天的精力有限，別覺得加班就能行，加班後半段多少人都是發獃連複製粘貼都能貼錯的，毫無效率可言，態度強硬的要求加人。不要輕易承諾你其實做不完的工作。

7. 前端的代碼風格，編譯部署流程，測試流程等等應該統一，你來定。如果都是自動化腳本，那麼腳本你必須寫，並且每個業務線繼承得來用。

當然，一切的前提是你上級支持你，實際上如果公司業務飛速發展過程中就是各種加需求壓任務，你全部精力用來review你組員的代碼，討論需求，討論確認技術方案，培養新員工，招人，技術預研，協調工作安排就很吃力。個人不太同意你還要負責業務代碼的編寫，你根本沒空。leader的職責是解決難點並且為所有小組成員加開發效率的buff

目前這種管理結構如果公司飛速發展，終有一天會裂變成業務線，你可能會面臨挑一個業務線去做的局面（那個時候公司使用垂直拆分的方式管理）。

你寫不寫代碼不影響你技術提高（有預研，review,技術方案討論，都是「寫代碼」的工作）。有苦惱一定要和上級說，管理就怕啥也不說忽然說拿到offer一個月走人的，的確覺得自己不適合做leader，找個自己認為是公司重點的業務線，帶1，2個人接著寫代碼就好了，掛個leader的頭銜對自己沒什麼幫助。

如果想向上，那麼掌握前端（精通到可以滿足公司未來半年到1年的發展需求）的基礎上，去了解整體方案，搞清楚後端和其他部門坐什麼怎麼做的，有條件學一些後端語言。一定要去了解公司的業務，需求背景，目的，期望的效果，上線後的實際數據，和產品經理和其他leader多吃吃飯，多溝通，為重點業務線的技術經理做準備。

要權。如果要不到。建議走。沒有權利。一切所謂團隊建設是浮雲。

我過去做測試組長時。曾面對過處境和答主一樣的情況。無法構建團隊。無法推動白盒測試。無法搭建tester轉型developer的渠道。還好走了。

為何我建議你走：因為從辦公室政治的角度。當前這樣的情況十分危險。

管理可以分業務維度和技術維度兩個方向。

業務維度以產品為導向，向來繁瑣除非你真正抽身做「管理」，或精力、記憶超乎常人，否則很難兼顧。

按樓主情形看是一個技術團隊、甚至只是技術團隊的一個前端子組，業務層面的需求、背景、壓力、計劃知道就行了，做不到面面俱到，所以業務維度適度放權是應該的，主要要把握的是作為技術團隊本身的「技術」這個維度。

技術維度可以主抓業務底層技術模型架構設計，輪子造的好可以讓業務維度行動更輕鬆，能有更高的技術提升、更高的影響力、更高的話語權。

技術維度的發展要留意團隊上下有沒有這方面基因。

一方面向上的，看彙報對象是否認可這件事，如果ta覺得「你服務好業務就行了，別的啥也別想，耽誤工作」，那趁早換工作吧，省的影響成長。

另一方面向下的，看組內有沒有人能擔得起這個事，有心無力會徒勞無功、有力無心會敷衍了事、有心有力過於自負會閉門造車或產生無謂的內耗。

大多數技術人員都是想在技術維度有所提升和作為的，但技術本身的價值體驗離不開業務場景，所以珍惜眼下的環境資源，總結分析、充分施展自己吧，心態不平穩、自我定位不準的話，換一個工作也未必有什麼作為。

另外推薦一篇我老大對《好的前端主管是如何帶隊的？》的回答：好的前端主管是如何帶隊的？ - 月影的回答

我們這邊基本上兩個人一條線，加上領導抓全局，當然，領導也寫代碼，然後分輕重緩急，哪裡很急，就調人過去幫，當然我們這邊做的事情都差不多，所以，調過去，沒有任何問題，如果事情做的不同，可以不忙的時候，開開交流會，讓技術流通起來，第一開闊眼界，第二，也能學到新東西，第三，互相幫忙的時候，知道怎麼入手

謝邀，很抱歉現在才回復，主要是最近少有上知乎。

各種觀點我看上面大家都回答得差不多了。這裡就龍珠自己如何處理的說幾句，希望有參考價值（主要從技術角度講，如何和需求方溝通這個可能要看公司情況所以先不提了）。龍珠前端組面臨的工作量也很大，有的實現難度大有的要的時間很急，同時也面臨需要做技術儲備和升級的問題。我們是從這樣幾個角度來處理的：

1. 方案選型盡量穩健和完善。我們選擇技術方案不追求新，關鍵要能符合業務場景，能被時間檢驗，一般我們都選擇被大公司在業務中大規模使用的方案。這樣可以減少很多試錯時間。

2. 在日常開發中做探索和實踐。很多好的idea我們會直接在項目開發中做，因此帶來的風險和維護成本通過靈活的構架和模塊間的隔離來控制。

3. 優先處理能提高效率的技術方向。一切矛盾歸根結底還是效率的問題，我們把提高效率當作是最重要的課題來突破。

4. 各個業務方向定好具體改善目標，在業務之餘努力去完成，每周核對進度調整計劃。

橫向靠影響力，縱向靠考核權

如何管好領導我還說不上。

你們的問題就在於級別設置問題，大家都平級，你能協調誰？項目管理，內部協調部門或組是高於其他各部門半格的，都是直接受老總或副總管理的，看企業規模。絕大多數企業都有這個毛病，都在扯皮中浪費了寶貴的效率！

提供建議，但是不知道是否可行。

招人 + 整合前端資源 + 把優化等工作也排入項目計劃中

業務是做不完的，也只有做不完的業務才能保證發的了工資，讓你們繼續有業務需求可做。所以不要基本上不要太糾結需求不斷，當然這個基本上也不是大部分寫代碼的人能去左右的事情

所以，當業務量增大，就需要去申請資源，增加人員編製來分解業務需求

整合前端資源，我覺得應該是你們最需要做的

根據你的表述，每個特性組有一個專門的前端，那麼帶來弊端就有：

1、針對每條業務只有特定的人員最了解，那麼這個人要離職的時候，交接的成本太高

2、可能出現其他特性組很忙，卻有那麼1-2個特性組需求沒那麼緊張。此時這個特性組的人其實是閑置的，雖然可通過借調的方式來使用，但是這個過程肯定是有成本的。我想任何一個產品經理或者業務方都不會願意釋放自己的資源。

所以，可以把前端資源整合起來，可通過拼小組方式去面向你們的特性組。原來的前端還是負責原來特性組需求，但是也要了解組內其他特性組的需求。這樣業務的熟悉度就不會堵在一個人身上。統一管理也就不需要存在為了借人存在的溝通成本以及借過來的人理解需求的成本。

雖然這個特性組是上面安排的，但是提出合理化建議應該不會被拒絕。

優化工作列入項目計劃，也許你們處於業務增長階段，你們的產品沒有太多的時間去關注所謂的性能，這個是可以理解的。正常情況下，除非影響業務需求的性能，否則可以選擇不去優化。

（往往開發腦子裡面想的優化，都會演變成重構）

我的建議是：

1、大的優化工作都是由產品經理或者業務方提出，這樣優化開始後的相關資源，如服務端，測試才會有排期跟著。

2、小的優化，直接落到每個小版本中。

3、如果選擇重構或者換新架構，那麼就需要有人犧牲自己的業餘時間或者抽業務量不大的時候，並且一旦選擇換新，就不能間斷。要先有人站出來，把換新工作的架構，基礎組件，工具庫，構建工具等要先做出來。當然換新工作是一個大工程，需要獲得領導的支持(業務方是不關心你這些的)。不建議私下偷偷的去弄。

其實我們團隊也有你這樣的問題，需求不斷，每周一個小版本，每月一個大版本，各種會場活動需求。

所以

工作上，我們準備嘗試上面說的整合資源，分組面向業務需求。

工程化上，選擇現在流行的組件化開發的方式，前期連續2周通過加班完成原先架構基礎部分向react的遷移。通用組件每個成員都會被分配到幾個去完成。然後選擇了一個非主線業務去去試水。

面對間斷性增長的業務量，我們選擇組件化開發，就是為了應對以後某個月的促銷，突然來的大量需求。我們還開始做一個可視化的頁面組裝平台，想著以後活動需求就由業務自己配置完成。工程化的建設就是節約成本，釋放生產力。

其實說這麼多，很多工作除了是自己的興趣，

最重要的是落到

業務需求

項目管理

工程化

業務特性組是有上面決定的，短時間來說無法更改，當然這個主管也在考慮這個問題。我們的工程化都是做的還不錯和一些前端新技術也都到應用和跟進，這次大部分都是我的主管自己早期建設的，其他團隊成員都忙於需求，很難有時間做些技術性的工作，最多也是了解，具體應用還需要有時間積累！我是最早的一批入職的前端，經歷整個項目的生命周期，業務可以說非常熟，所以面對其他問題或者需要協助時，知道團隊成員已經被業務壓的很死，很多事情都是自己親力親為，保證整個大組業務線不出問題。雖然需求和技術的月度規劃有做，但對於前端來說，要的快，機動性強，這就導致很多情況不能按原計划進行。目前情況是經常會有插入性緊急需求，臨時需求，比較突然的新業務等等，我們也不想接，但產品又說優先順序高，先做這些，其他暫停，一些計劃全打亂了，自己優化需求即使排了，都很難做，因為都是自己擠時間做，即使能做，也是斷斷續續。有時候在想，為什麼android和server團隊都有專門的框架組，性能專項組，可以不用做業務，H5為什麼就這麼難？是團隊還沒到那個時候？還是大家對前端的觀念沒有轉換過來？

個人觀點，減少部門溝通成本，擬定公共維護文檔。預先和產品協調項目排期，提前做好準備。進入開發階段，說實話，分攤到各個部分的工作量不是很大。溝通時間往往多於開發時間。公司通病，流程就是流程。就像爝大說的，部門之間關係一定要好，要郵件給郵件，要介面有介面，這才是幸福的日子。另外，前端本來就容易背鍋，作為leader,只有讓下屬知道，你可以為他們扛一下，這是很重要的。有耐心，會排期，敢擔當，會定位，懂溝通。。。。有問題，定位後，協調部門間解決，不要推脫，優先解決問題才是關鍵。

1 砍需求

2 招人