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

三五年後我大概率走上管理，之前該做什麼準備呢？

老闆提拔我帶前端小組，我內心慌慌該怎麼應對？

真有 35 歲天花板麼，我要不要堅持走前端這條路？

技術編碼做好多年，現在轉型管理是對的選擇麼？

公司業務發展太快，我怎麼才能帶好 3 人到 50 人？

我老闆懂不懂管理，我想看看別人公司怎麼做的？...

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

• 5 人團隊 | 竹隱 - 如何從 7 年技術架構走向業務管理
• 10 人團隊 | 志遙 - 如何在小型前端團隊的管理中踩坑
• 20 人團隊 | Scott - 如何在中小前端團隊中完成管理轉型
• 40 人團隊 | 芋頭 - 如何帶領前端架構團隊突破價值困局
• 50 人團隊 | 堂主 - 如何推動與影響中型前端團隊的成長

本文是第五場講師 - 堂主的講稿文字版，來看看他是如何講的

如何推動與影響中型前端團隊的成長 & 暨最近一年多新團隊的管理工作覆盤

○ 前言

本文根據 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