第一屆搞管理|堂主 - 如何推動與影響中型前端團隊的成長

前端早早聊發表於2020-01-23

image.png

前端早早聊大會目標成為用得上,聽得懂,抄得走的前端大會,計劃 2020 年辦 12 期,第一期 2020 年 1 月 11 日在杭州夢想小鎮舉辦,報名 450 人,到場 230 人,話題聚焦在 「前端轉管理」,來探討大家常遇到的問題:

三五年後我大概率走上管理,之前該做什麼準備呢?
老闆提拔我帶前端小組,我內心慌慌該怎麼應對?
真有 35 歲天花板麼,我要不要堅持走前端這條路?
技術編碼做好多年,現在轉型管理是對的選擇麼?
公司業務發展太快,我怎麼才能帶好 3 人到 50 人?
我老闆懂不懂管理,我想看看別人公司怎麼做的?
...

會議的五位講師工作經驗從 5 到 15 年不等,帶的團隊從 5 到 50 人不等,這些問題他們是如何處理的呢,一路怎麼走來的呢?這 5 場乾貨的分享一定會帶給大家完全不同的觀察視角:

正文開始

本文是第五場講師 - 堂主的講稿文字版,來看看他是如何講的,觀看視訊請掃碼文末二維碼,回覆 “早早聊第一期” 即可獲得其他 4 篇文章、錄播視訊及 PPT 地址

**今天下午跟大家聊的這個話題 - **__如何推動與影響中型前端團隊的成長 & 暨最近一年多新團隊的管理工作覆盤:

○ 前言

本文根據 2020.01.11 日,杭州第一屆 “前端早早聊” 的管理專場分享內容整理而來。因為現場裝置原因,導致沒能提供視訊的錄播,故以文字版進行沉澱,也能略微彌補現場時間原因一些未能說到的遺憾。

本文的標題是《如何推動與影響中型前端團隊的成長》,一是契合大會所有分享都以 “如何” 為切入的要求,另外副標題我增加了 “暨最近一年多新團隊的管理工作覆盤”,這是因為我本身到政採雲,一定意義上屬於 “空降”。最近一年多工作上所做的事情,都是將這裡的前端進行聚合和打造,幫助團隊成長,更好的支撐業務的現在和未來。所以,本次分享也算作是對過去一年多,在團隊管理工作方面的實踐,和基於實踐的階段性沉澱總結。

另外還是非常感謝@Scott,感謝活動的組織者和參與者,感謝這一期的話題。業界關於技術管理,尤其是前端領域的技術、團隊管理的經驗沉澱少之又少,希望本次這些個人角度沉澱的文字,能為一些同學帶來一些啟動,產生一些改變。

○ 介紹

堂主,本名馬翀,2006 年開始搗鼓前端。畢業前的 2011 年,先是在淘寶前端團隊實習了整一年,2012 年畢業後即加入淘寶(花名@堂主),直到 2016 年加入蘑菇街(蘑菇街時期花名@明淳),在蘑菇街做了 2 年的 TL。2018 年 8 月 ~ 至今,在政採雲負責前端團隊的工作(花名又改回了@堂主)。

政採雲前端團隊目前有 50 多人,平均年齡不到 28 歲,妥妥的青年軍。團隊名字是 ZooTeam,團隊站點也是 zoo.team。Z 是政採雲拼音首字母,oo 是無窮的符號(♾),結合 Zoo有生物圈的含義,希望後續政採雲的前端團隊,不論是人才梯隊,還是技術體系,都能各面兼備,逐漸成長為一個生態。

下面是我的微信二維碼,有想進一步交流的同學,歡迎掃描加我微信。

第一屆搞管理|堂主 - 如何推動與影響中型前端團隊的成長

○ 一些似曾相識的

首先,我們來看一些日常工作中時常看到的情景(基本上都是從脈脈客戶端“職言”匿名社群找到的 Case)

  • 同學 A:“… 哎,天天寫業務程式碼,感覺沒啥技術含量,也沒什麼沉澱,成長太慢。架構那邊做的東西倒是蠻有趣的,看上去很吊,但參與不進去。再這樣下去感覺要廢…”
  • 同學 B:“ … 天天在公司寫內部工具,感覺沒啥提升,也沒多少時間去學習,前輩們有啥建議嗎,這樣下去感覺要廢了…”
  • 同學 C:“ … 獨自負責過很複雜的前端專案,一般基礎面試題和專案經歷沒有太大問題。但對一些框架的原理、原始碼、工具研究較少,技術棧較陳舊,對 React、Vue 瞭解較少,導致水平一直在阿里 P6 級,無法突破到技術專家的評級(P7)…”
  • 同學 D:“ … 每次做專案總是那幾個對接合作的人出狀況,總不能按時保質給到下游所需。找他吧總是再等等,然後又沒下文。反饋吧也不解決問題,下次還是如此,最後還得我們下游加班加點給他們兜底。真 TM 不想幹了…”
  • 同學 E:“ … 推動個事太難了,就這麼點東西,各種拉會溝通。解決個問題誰都不接,各種打太極推諉;出了問題先甩鍋。心累…”
  • 同學 F:“ …這次績效考評,主管給了我 3.25,說我層級較高,但產出結果和其他更低層級同學相比,沒有明顯區別。我也在賣力的幹活啊,總說需要多一些想法,結果不夠。問題是他也不說啥叫想法、怎麼個結果產出才是 OK 的,主管 SB…”

這些的背後,是一個組織的發展遇到了困難。團隊的任何問題,歸根到底都是管理問題

○ 如何理解 “管理”

對 “管理” 的理解

對於如何理解 “管理”,不同的管理者可能會有 N 種不同的回答。我對這個問題的理解是:管理,就是靠別人拿結果

不論是實線的 TeamLeader,還是虛線的小組長,或者專案 PM、技術小組的 Owner,其工作的內容都不是他一人能搞定的,都需要靠其他人的產出來集體落成結果。

管理,就是靠別人拿結果。在不確定性中尋找確定性,通過成就他人成就自己,基於資料闡明一切改變。管理者是帶來改變的人,管理者就是要靠影響他人,帶來正向的改變

那一些同學可能會問:我應該轉管理嗎?什麼時候應該考慮這件事呢?對這個問題,我的理解是:當你要推動改變的事,你一個人搞不定時,就要去追求團隊的力量了(管理)。

管理不見得必須是實線的方式(如最常見的 TeamLeader)。日常中的業務介面人、虛線小組的組長、虛擬團隊的 Owner,其工作範疇都會涉及定目標、出方案、整合資源、跟過程落地。這個過程本身就是在基於驅動一個群體去拿到結果,自然也是在做“管理”相關的事,在鍛鍊自身的管理能力。

在進行管理相關實操重點的交流之前,我覺得有必要和大家分享一些巨集觀的視角。

對內的視角

第一屆搞管理|堂主 - 如何推動與影響中型前端團隊的成長

對內,面向團隊,我個人關注的優先順序是 **人 → 事 → 文化 → 影響力。**這也是後面關於實操部分的分享順序。另外還需要抓牢治理結構(即必要的制度、流程)和管理工具。

關於治理結構,我的建議是,團隊成員平均意識和能力越是偏向於一般般和強執行的,越需要強化 —— 即越需要明確清晰的制度和流程。反之團隊成員越是偏向於自驅和專家的,則越需要強化價值觀,文化驅動,儘量降低強硬的流程制度對人的直觀約束感。

關於管理工具,制度流程是管理工具,績效、晉升是管理工具,調薪、股權、獎項也是管理工具。合理的使用管理工具,重視 “找平”,而不是 “一體均衡”。積極的管理工具,需要向團隊倡導的方向去傾斜。

對外的視角

第一屆搞管理|堂主 - 如何推動與影響中型前端團隊的成長

作為一個管理者,無慾無私幾乎是不存在的,將團隊視為自身的 “勢力範圍” 也是生物的本性。但不論願不願意承認,管理者都要直面的現實是:你的團隊,同時也是你直屬老闆的團隊,更是公司創始人的團隊,亦是大股東、投資人的團隊。個人發展,離不開團隊的發展,更離不開公司業務的發展、所處行業賽道的發展。與其在存量的盤子裡過多的關注 “誰的手是不是伸的太長”,不如推動一起把盤子做大,在增量空間裡獲得更大的自主權和收益。

處理不好這些層層遞進的關係,就很容易出現部門牆,導致團隊的內耗,甚至是內鬥。看過擁抱變化組織架構調整,上位的同時,也有淡出的背影;也看過那些個人、團隊 KPI 完成甚至超額完成,但最後公司的目標完不成,公司裁員甚至是倒閉。背後,都能從上面這張圖裡找到原因。

第一屆搞管理|堂主 - 如何推動與影響中型前端團隊的成長

正視 求同存異,重視 信任關係

○ 人

人對了,事就成功了一半。

人:選篩

梯隊建設,正確的盤人、選人是關鍵的第一步。

第一屆搞管理|堂主 - 如何推動與影響中型前端團隊的成長

內部選拔

內部選拔,我一般的優先順序可見上圖。其中,價值觀和利他精神是我最看重的 2 個點。來到政採雲後,整個團隊的梯隊搭建過程中,最開始抓的部分就是 TL 儲備和抓核心員工成長。其中組長(後續 TL)的選育物件,我沒有采用常見的搬來嫡系老部隊、社招空降的策略,而是完全的“本土化”培養。

篩選過程中,一方面是創造足夠的橫、縱建設空間讓重點被觀察員工去參與,同時也是在過程裡觀察,哪些同學願意花更多的個人時間去參與討論,幫助同學解決問題,主動的多往前走一步多承擔。同時結合這些同學的業務熟練度、技術能力等,最後選擇出組長一級的培育物件,作為後面 TL 的儲備人才。

皮實、要性也很重要,選育過程中要求的維度和壓力都是逐漸增加的,也會有苛刻的時候。本身這也是一種雙向的考察,一是物件能否逐漸適應我的節奏和管理風格,同時也是看選育物件能否擔得起來,是能衝出去,還是老樣子被動的待命。

外部招聘

外部招聘,我的策略是面向本地中短期內長不出的 “物種” 、或能長出來但數量不滿足團隊未來那個時期的需求去招聘。如果某種特質、某個方向的人才,我們團隊未來半年到一年是能長出來的,那我會優先本地培養。所以,能看到現階段社招的側重點是 2 年內經驗的優質高潛,和具備經驗的技術專家。

外部招聘儘量避免缺人時急躁胡亂招,能幹活就行。記得我們前面提到的吧,管理就是靠別人拿結果。你團隊同學的能力,決定了你的管理結果。招聘,應優先面向能為團隊帶來積極改變的候選物件。

人:育用

用人長,補人短。關注團隊成員的輸入與輸出。

第一屆搞管理|堂主 - 如何推動與影響中型前端團隊的成長

育人

育人,是為員工提供 “輸入” 的渠道,通過做事用人幫助員工在認知、能力維度上得以成長。我個人的經驗,是要在過程中能為員工提供認知的升級,在負責的維度,和事的複雜度上要逐漸的比之前更上一個臺階,叫有潛力的員工承擔他能力 120% 的事情,反推員工突破自己。每一年都根據員工的特點,思考其後續的階梯式成長計劃。具體粒度看組織的梯隊層級和你所處的位置。比如我會重點側重 TL 長這一層,兼顧組長和團隊核心;TL 這一層重點在團隊內組長和核心,兼顧高潛;以此類推。

很多同學在剛開始承擔管理工作時,會擔心自己務虛的佔比增加,編碼參與減少,專業能力下降。這都是因為增加了輸出,但他能認知到的有效輸入不足的體現。

用人

在用人這一塊,是為員工提供 “輸出” 空間。把他個人的優勢長處,通過做事、推動事,輻射到更大的範圍,影響其他人,幫助業務拿到更多結果。這部分管理者要幫助團隊同學撐起必要的空間,優秀的管理者是擴大增量空間,一般管理者是爭取存量空間。一般的策略,都是為同學爭取能夠主導的方向,如承擔業務的前端 PM,做跨職能的建設,在過程中軟化、優化、強化合作關係和信任關係,並通過影響力建設為員工提供結果放大器,叫更多的人瞭解並認同其過程和產出。

不論是育人,還是用人,都要考慮物件的訴求,和輸入、輸出空間的匹配度。

人:換血

換血是團隊成長的必經之路,不論是主動的淘汰不合適人員,還是被動的接受優秀員工的流失,其本質都是雙向的匹配問題。

第一屆搞管理|堂主 - 如何推動與影響中型前端團隊的成長

主動淘汰

關於主動汰劣,首先要和大家分享的一點,是要求前置,過程跟足。也就是說績效的重點是在平時的績效管理,而非最後的績效考核。績效考核是在最後的結果,績效管理的重點是在平時的過程。在考核週期的開始,就將要求擺明,目標和考核標準儘量都公開透明,陽謀至上。過程中做好階段性 Review,我的方式是一般每隔 1 個半月左右(看考核週期,我們公司是半年一個考核週期),會和我直接的下屬進行一次過程的階段性 Review,對稱 Aciton 是否是沿著既定目標在前進,進度是否有問題,過程中是否有方向偏差和其他問題。儘量避免過程中缺少溝通,最後來個一次定生死,給員工個 Surprise。

績效結果,只要不是系統自動打分,由人來評判,成員績效結果就一定會受到管理者個人主觀意願因素的影響,無非是多和少的區別。管理者人正的,這個因素會少一些;管理者人不正的,這個因素就會大一些。我個人的建議是,立場要站穩,對公不對私。標準前置化,績效看產出結果,尤其是對應的業務結果。合適的前置目標和過程跟進,合適的考評標準宣導,會讓絕大部分的團隊成員,對自己和團隊內他人績效結果的預測,八九不離十。

如果決定要淘汰,一定要站穩立場:淘汰一個人不是他對你無用,而是他不再是業務、團隊後續發展希望匹配的物件。心要慈,刀要快。強留、老好人心態氾濫,對各方都不見得是好的。如業務未來的發展,需要 80 分的團隊匹配,他可能很努力,但確實能力和潛力的問題,再使勁最後也只能 70 分(且中長期來看沒有突破性成長的可能),面向團隊基本水平,他再努力也不夠。最後他對接的業務受到阻力,團隊成長變慢,他自己的職業自信心也會受損。

主動淘汰,刀要快,心也要慈。這個圈子很小的,經常的我們會看到有管理者被投訴在績效結果中夾私報復,或者任人唯親,或者借績效之名職場騷擾等拿自己職業信譽開玩笑的“新聞”。只想說,做人留一線,日後好相見,這個圈子比我們的主觀認知要小得多。

被動流失

團隊核心離職,可惜性流失,是大家都不希望看到的事情。但,人和企業的合作,是雙向匹配的,這種情況在所難免,這裡只提幾點重要的。

關鍵崗位必須有 Backup,團隊 TL,業務介面人,技術建設 Owner,都是關鍵崗位。如我團隊的 TL 、組長們,自這個團隊的組建、分線、分梯隊開始,就第一時間和大家明確過他們都有自己的 Backup,且會要求各組內同步建立下面的 Backup 機制。

系統性坍塌,是指一個人的離職會導致一批人的離職,比較常見的是某 Leader 離職後帶走大批核心,導致對應業務支撐能力系統性受損。能力性坍塌,是指離開了某個人,某項能力就玩不轉了,如團隊某關鍵建設基於 A 技術,結果負責的同學離職後,團隊剩下的人誰也不會 A,導致這塊變成無人能維護,出了問題也無人能解決。每年的人才盤點中,除了要盤點團隊梯隊、核心的階段性潛力,更要考慮在崗的可替代成本和流失成本。

熟人場,很重要,也最容易被忽視。離職從想法變成行動,有相當一部分原因,是因為離職同學之前關係很好的同事(有些也是其生活中的朋友)都已經離職了,他周圍不再是他最熟悉的人。這背後體現的,是熟人場帶來的團隊融入度和主觀認同感。團隊的組織架構調整,TL 調整,和關鍵核心的離職,都需要考慮對應的影響面。

人:結果

績效與晉升,都需要對結果負責。

第一屆搞管理|堂主 - 如何推動與影響中型前端團隊的成長

績效

正如前面所說,我們要儘量做 “績效管理” 而非僅僅 “績效考評”。績效的工作,90% 在日常中的過程跟進,不要本末倒置放在最後的結果溝通時。因為前面內容這部分已有涉及,我只重點分享我對績效結果認定的一些原則。績效結果我沿用了阿里系的 3.xx 數字,有些公司是 ABCD 等... 這個不重要,大家能找到參考點就行:

  • 3.25(不滿足期望):代表的是無年終、無加薪、無晉升。有些公司還會針對這部分員工納入 Pro 改進流程,改進不到位就淘汰;有些公司是連續兩次 3.25 解除合同。針對業績不滿足期望,一定是其工作有重大人為過失(如因個人疏忽直接導致線上 P0/P1/P2 等重大故障),或是明確不滿足團隊現階段的用人標準。
  • 3.5-(部分不滿足):這部分我的標準是,有 80 分的能力,卻只拿到了 70 分的結果。可能是因為合作態度問題,可能是因為自己跟進不力,總之未能發揮該有的水平,浪費了天賦。
  • 3.5(滿足期望):良好完成自己分內工作,屬於得努力踮踮腳甚至跳一跳才 OK 的結果,但也沒明確的亮點,只是做到了分內事。
  • 3.5+(部分超出):有亮點,除了完成分內事,還帶來積極正向的改變,有明確的對外的影響和推動結果。
  • 3.75(超出期望):不止是亮點,更有驚喜。通過個人努力和推動,帶來了突破性的變化。

晉升

晉升是一個結果而非目標。簡單說,晉升的前提,是能像下一個層級那樣思考問題,並在做下一個層級做的事並拿到結果。

績效好不等於能晉升,前者是拿到了突破性結果,但不代表一定能勝任下一層級的綜合要求。管理者也不應該將晉升等同於排隊,晉升需要對結果及直接顯著的貢獻負責。

對於晉升提名通過者,管理者需要進行必要的晉升輔導,如演示稿、陳述內容結構優化的輔導等,必要時還可以組織幾場模擬面試,幫助參加晉升面試的同學找找感覺。程式設計師很多人都是會做不會說,必要的輔導還是需要的。

這裡特別強調一下晉升後新的目標的設定。部分流失是出現在晉升後,晉升成功就提離職不是玩笑,是確實存在的區域性現象。晉升後,前期的持續努力得到了階段性滿足,新的目標感缺失(有些是晉升後待遇變化低於預期),會加大誘發離職的風險。

層級&要求

對於人,核心重點是明確層級標準和產出結構,結合不同的策略提升組織的整體能力。這其中要求組織上下都能明確不同層級的定位,明確考評標準,面向梯隊的分層,制定對應的階梯式成長計劃,提供足夠的輸入和輸出空間,對結果的評定也當是站得住的(有業務落地並帶來明確變化)。

第一屆搞管理|堂主 - 如何推動與影響中型前端團隊的成長

我個人對研發 P8 以下的關鍵性要求及定位見上圖。因為大部分團隊的構成,都是工程師 ~ 技術專家這個範疇(P4~P7),所以上圖也是面向這個範圍,高階技術專家以上的部分暫未列入。

工程師到高階工程師的階段,在做好分內事,從獨立執行到能做出亮點。資深工程師到技術專家,是要能由對內轉變為對外,能影響到其他人,從影響團隊到成就團隊,從影響業務到成就業務。高階專家、總監等再往上,是維度的升級,影響到部門之間、業務之間,乃至影響到事業部之間、企業之間、行業之間,以此類推。你看,馬總這些年考慮的,都變成全人類的事了。

第一屆搞管理|堂主 - 如何推動與影響中型前端團隊的成長

考評維度的單一,是管理者的大忌。考評什麼,就會得到什麼。維度單一會導致團隊能力單一,核心人員的輸入、輸出空間不足,誘發流失。考評維度單一,也會客觀上造成面向 “履約率” 的“計件式”結果核定,面向層級分配工作量(層級高的多分配幾個業務模組),造成團隊寒心、失心,嚴重的會導致團隊核心離散。

上圖是我在蘑菇街時期,同時也是在政採雲時期的一套通用的團隊能力建設結構。政採雲時期的現階段,比較蘑菇街時期,在內容上會增益一些。基本的四縱五橫九線結構,每一條內又有不同的專項化成長突破方向。每一條線內的點,和每一個不同線之間的交叉點,線本身,線構成的面,都是不同維度、不同 Level 的空間和結果,也都是不同的考核點。每一個考核點,也都分能力成長,和業務收益等不同結果。最後在正常的業務支撐考評之外,再結合這些圍繞業務、為業務帶來更多可能性的成長建設方向,看同學是在做點的事,還是推動線、面的事,看結果是做了能力的建設,還是建設已經能給業務帶來直接的積極變化。

更豐富的維度,更深層的要求,增加維度和複雜度,創造足夠的 120% 空間,管理者可以有更多推動改變的事情去做。

第一屆搞管理|堂主 - 如何推動與影響中型前端團隊的成長

崗位能力模型也是一項需要花點心思去做的事。不同業務階段、不同團隊構成,崗位能力模型也不會盡然相同。花點時間思考團隊現階段需要的能力,按照團隊實際情況設定不同的段位及要求標準,做做團隊的能力摸底,大方向上是能掌握團隊現階段的長處和短板的。基於此可制定下一階段的內部培訓計劃、招聘計劃等。上圖是我團隊一個崗位能力模型,內部有個小系統可供團隊同學每個季度自我評測一次,並提供主管角度的評測。一是為同學明確能力結構要求和定位長短板,同時也為對稱上下級之間能力認識上的偏差。

第一屆搞管理|堂主 - 如何推動與影響中型前端團隊的成長

人的方面,管理者需要基於以上的標準,區分出團隊的梯隊構成,並對梯隊現狀有一個瞭解。上圖是一年半前和現在的對比。政採雲前端團隊的梯隊結構,能看到由之前較為明顯的金字塔式,轉變為現在的紡錘式。相比前者,後者的結構更為健康。

○ 事

站在未來看今天,提前籌備

事:建設

業務支撐、技術基建,都是建設。

第一屆搞管理|堂主 - 如何推動與影響中型前端團隊的成長

業務支撐

優質高效的支撐業務,是活在當下。做完既定的業務工作,幫助業務達成既定的業績目標,是拿工資該做到的最基本的事。但做完絕不意味著結果 OK。好的業務支撐,在做完的基礎上,還要能做好。深入業務,對業務預期的把握和影響,面向業務支撐的流程、協作等優化,驅動業務乃至正向的影響到業務的產品架構,技術的方式優化支撐業務的基礎模式,用更具效率、更優體驗的方式為業務帶來更多可能性,都是需要考量和衡量的點。

技術建設

必要的技術建設,是為了幫助業務和團隊活好未來。尤其是對於前端職能來說,太多的前端團隊僅是面向最上層的 “使用者介面層” 進行開發,基建也僅是一套三方的開源元件庫 + 一套本地腳手架環境,技術範疇很薄,業務影響不深。這也導致普遍的在研發體系的對話中,前端的話語權偏低,處於堆人力的資源型工種,經常被 “資源瓶頸” 的問題懟。

出蠻力的堆人、加班,頂多能帶來 40% 的人效提升(看你是 996 還是 997)。希望於數倍的人效提升,需要在業務支撐結構,和麵向業務的技術基礎建設上找答案。

體系結構

管理者需要帶動團隊,推動業務方、協作方,優化隊伍支撐業務的基本結構,變出蠻力的做事方式,為更聰明高效的方式。相比較一線大廠已經在 Serverless、FaaS、微前端、 AI 機器學習 UI 自動轉 Code 的方向上發力,一般的中小型企業的前端團隊很難具備這樣的基礎。面向一般中小企業的前端團隊,在大廠新一代解決方案還未成熟產品化之前的現階段,因地制宜的優化團隊的支撐結構,是更接地氣的。下圖是我團隊過去一年形成的現階段基本策略,僅供參考:

第一屆搞管理|堂主 - 如何推動與影響中型前端團隊的成長

第一屆搞管理|堂主 - 如何推動與影響中型前端團隊的成長

過去一年面向業務迭代的生命週期,政採雲前端團隊所做的基建相關(點選檢視大圖):

第一屆搞管理|堂主 - 如何推動與影響中型前端團隊的成長

業務支撐結構,和技術體系的搭建,管理者要能站在未來看今天。從現階段的業務情況出發,推演半年、一年、兩年後的業務發展趨勢,從趨勢推演未來,站在未來看今天。假設現在你的團隊支撐的是 500 億的業務,一年半後業務體量變成 2000 億,那時候你的團隊應該以什麼方式去支撐?需要什麼樣的人才結構和底層系統?多推演,想明白這些,優先面向解決高頻業務問題的方向去推動建設。

事:視角

前端在研發體系中話語權偏低的現狀,從前端這個職能出現那一刻就存在了。不排除個別研發團隊,因其業務模式的原因,對前端的依賴較深,前端的話語權相對偏高。絕大部分的研發團隊中,前端的工作,在其他研發眼中,往往是 “技術含量低”、“很薄的一層” 等情況。這個現狀的背後,看看下圖就知道了:

第一屆搞管理|堂主 - 如何推動與影響中型前端團隊的成長

橫、縱,2 個維度。先說右邊的 “縱”,參考網路應用系統的分層體系,前端的傳統工作範疇,都是集中在 “使用者介面層”,很少能往下深入,深入到閘道器 ~ 基礎設施層。後端則不同。從這個角度看,前端確實很 “薄”。現在良性的一面是,Node 能力為前端提供了向下滲透的服務端能力。一些團隊也基於 Node 橫向擴充套件自身的工程化能力,和向業務縱深去擴充前端的系統化能力。

我們再看左邊的 “橫”。只有很少的前端團隊,能較完善的去建設和發展技術體系。對於有了較完善體系的前端團隊而言,其技術體系也更多是侷限於前端自身的職能範疇,沒能較好的互動滲透到業務側,更多是在自嗨,業務的感知力是很弱的。將技術帶來的工程收益,轉變為業務收益;將部門內的技術影響,轉變為業務影響;將技術場景,升級到業務場景;將團隊的基礎能力,變為業務能力。跳出前端,圍繞並深入業務,這是每一個正在推動團隊體系建設的 Leader 要更多想想的事。

○ 文化

所謂文化、價值觀,就是日常的言行

一家公司,最重要的資產和產品,是不斷成長的人,和不斷成長的團隊。而文化,是組織發展的核心引擎。

團隊共識

團隊共識,有助於幫助團隊找到做事的態度和節奏。我的個人經驗是,先從團隊不希望擁抱的那些問題出發。我們團隊的核心成員,曾經聚在一起用了很多時間,羅列出日常中那些反感的行為,並歸類總結,反推出團隊集體認同的方向、觀點,和希望擁抱的行為,落實為我們的團隊共識。

第一屆搞管理|堂主 - 如何推動與影響中型前端團隊的成長

第一屆搞管理|堂主 - 如何推動與影響中型前端團隊的成長

價值觀

價值觀是公司級別的文化要求,價值觀必須要落地到考評中,且重點在標準的解讀。如下標準供參考:

第一屆搞管理|堂主 - 如何推動與影響中型前端團隊的成長

組織發展維度

下列是政採雲前端團隊最近 1 年多時間,在組織發展維度進行的建設項,供參考:

第一屆搞管理|堂主 - 如何推動與影響中型前端團隊的成長

○ 影響力

對內和對外,影響力都是放大器。

第一屆搞管理|堂主 - 如何推動與影響中型前端團隊的成長

影響力是放大器。對於團隊管理者,不能忽視影響力的塑造。塑造影響力,核心抓手是利他性輸出。對內的業務支撐優質高效,共建性推動(幫別人拿結果,做大盤子),跨部門的裸心會、吐槽會(增進理解,擴大共識),沉澱分享、定向培訓、內部論壇輸出等都是有利的方式。對外需要重視品牌化運營,把團隊影響力按照做產品的方式去打磨,制定好輸出的策略、路徑、節奏,找準可相互共利的 “借風” 渠道。

○ 資料指標

管理者推動改變,資料說明改變。

一般的團隊資料指標,可以參考如下結構:

第一屆搞管理|堂主 - 如何推動與影響中型前端團隊的成長

資料指標的設計,需要在某專項建設的前期即設計好並進行採集,並在整個推動週期和落地後持續收集,這樣可以得到一個相對完整的變化曲線,用以作證工作的成效。資料不見得一定是精準的,但資料一定要能說明趨勢直觀化結構,準確反饋

○ 最後,一些建議

管理者是推動改變的人,從最初的執行,到開始承擔對改變負責,到逐漸適應,一路上的心路歷程和風景各不相同。管理者是火車頭,肩上負擔著業務、團隊方向,及身後一群人未來一個階段的得失。套用一篇講企業發展文章的話,“朝哪個方向走,判斷的核心是深刻理解市場、業務的趨勢。這其中,要對技術的未來做判斷,對產品的未來做判斷,相對而言,大部分人都能看到技術的發展趨勢,困難的是判斷未來的產品形態”。運作一個團隊,和運營一家企業,異曲同工。管理者,其自身也是創業者

管理者同時也要面對結構性挑戰與週期性挑戰,只有活得久才能迎接更大的空間挑戰。結構性挑戰,是在不同的業務及團隊階段,團隊需要發展和落實的結構效能力、體系效能力。人才體系、文化體系、組織架構、技術體系、業務體系,管理者首先要儘量成長為體系性選手,具備搭建體系的能力,否則會壓低團隊的天花板。週期性挑戰,亦是在不同的業務及團隊階段,管理者需要側重面對的核心問題也是在變化中。草莽期解決無到有,資源壓力;快速發展期要快速搭建技術體系和優化梯隊;技術體系相對完備時要跳出前端的事業,橫向推動和打通,和業務產生更多互動;平臺期需要幫助業務和團隊在新的曲線破局... 每個管理者必須要務實、要花足夠的精力提高自己推動改變的能力。

最後,分享一些在之前的團隊管理過程中,看到、思考過的點,作為這次交流結束前的引申參考,和大家交流:

管理者是第一 HR

TeamLeader 的工作範疇,絕不僅僅是分析需求、拆解需求、下派需求、跟進執行過程。團隊的組織建設、文化養成、環境塑造、人員培養、招聘策略等等... 都是管理者的職責範疇,HR 是輔助你更好的完成這些工作的。

視人為人

說起來容易做起來難,視人為人,真的能做到嗎?有多少企業和團隊,還是在拿人當資源,當工具。相當多的管理問題甚至是管理事故,都是出在視人不為人上。

灰度思維

灰度思維的對立面,是 “二元論” 思維。二元論的認知,會讓他對很多事情、人際關係的理解,侷限在非好即壞、非敵即友、非 A 派即 B 派、要麼是幫我要麼是整我的角度。實際工作中的人際關係,絕非是二元論這般簡單,都是動態的灰度。是放大共同利益,求同存異,做大盤子,還是侷限於自己部門內樹牆,列位自己品味。

輸入與輸出

在輸出中得到自我認同感與成就感,往往是源於你的能力超出團隊和業務一大截。但如果在崗位上,一慣性的在做輸出的推動,缺乏有效輸入(成長),你可能要考慮下是不是離業務太遠了,或者認知維度上侷限性過低了,喪失了對更多輸入維度的感知。

60 分與 80 分

一般情況下,一個平均分是 80 分的團隊,來了一個 60 分的人,大家都會認同這個 60 分的人是個問題。但我這裡需要指出企業中常見的另一個場景,為了提升企業或者團隊的能力,優化結構,在平均分 60 多分下,招來一個 80 分的人,這個 80 分的人是不是個問題?表明上看,招聘到更牛逼的人對團隊發展是好的,但如果落地輔導做的不到位,會導致這個 80 分的人看誰都不順眼,看誰都覺得垃圾,導致信任關係危機,帶來更多問題。

場景與方案

《莊子·列寇傳》有一則寓言,“朱評漫學屠龍於支離益,單千金之家,三年技成而無所用其巧”。 講的是一個人散盡家資學習屠龍之技,學成卻發現世界上本沒有龍。對於研發同學,同樣會存在從方案出發找場景的問題,如想學習 Node 不知道如何學習,照著書中的例子學,最後發現都忘了效果很不好。沒有一個作家是看小說看成的,也沒有一個語言學家是看字典看成的,同理技術專家也不會是通過看技術書籍養成的。我的建議是,管理者要在不同的維度組織空間,從問題場景出發組織同學產出技術方案,並在落地過程中學習掌握新技術,更有成效。

信任關係

重視信任關係,無論是對下,還是平級,還是向上管理。信任關係會影響事倍功半還是事半功倍,也會影響資源和機會的配比。

Backup

最後再強調一次,任何關鍵崗位,一定要有 Backup 儲備,避免系統性或能力性坍塌。

○ 招聘資訊

簡歷自薦推薦,請傳送至 ZooTeam@cai-inc.com

第一屆搞管理|堂主 - 如何推動與影響中型前端團隊的成長

近兩年 Scott 觀察到前端行業已經完全進入競爭的深水區,各大小公司的前端 TL 剛剛上任,初帶團隊,針對前端工程師這個群體,應該怎麼管人理事,搭臺拿結果,幫帶有成長,就成立了這個全國的前端技術主管學習交流群,在人的選用育留上互相學習成長,入群的門坎是你有實線或者虛線在帶團隊,請加 Scott 微信: codingdreamer 邀請入群,同時,未來的前端早早聊大會行程動態、資料下載請掃碼下方的公眾號:

2.png

1.png

相關文章