FreeWheel容力：如何打造更高質效的技術團隊

1

編者按

技術團隊的管理包羅萬象。但歸結到底，無非在於二字：道、術。

聽過很多人講二者間的關聯，卻大多未全然說透。道與術的關係本質上就是一個指導思想與具體手段的關係，是心法與招式的關係。從技術角度來看，管理中的「道理」、「心法」或可界定為技術定位、技術與業務的融合、企業文化、技術與哲學等；「方法」和「招式」，則就如技術團隊組織架構、產品開發流程、制度規範的建立、架構設計等。

怎樣將「心法」與「招式」融合在一套特殊的理念和決策之下，或是困惑多數技術管理者的一道難關。帶著對如何打造頂尖技術團隊、如何在技術、文化以及技術人成長間搭建更優橋樑、如何培養團隊榮譽感及價值感等問題，InfoQ 專訪了 FreeWheel 高級副總裁容力及其所領導的技術團隊管理者（技術副總裁黨政法、技術副總裁王強），了解在這樣一支跨國團隊協同合作的環境背景下，作為 300+ 人團隊的總負責人，他是如何塑造高效敏捷的行動力、團隊方向感、追逐感、凝聚力，以使龐大（甚至是跨國界、跨時區）的隊伍能擁有更好的創新力和生命力。

曾在知乎上看過一個提問：「互聯網公司，如何管理一個 8-10 人的技術團隊？」，下列的跟評有著林林總總各式不同的看法，其中一人大致列了三條最簡單也最複雜的見解，即了解人、了解事和了解業務。所以，我們和 FreeWheel 技術團隊的交談也從這幾點開始。

2

萬丈高樓平地起——「合理擴張」與「Hire the Best」

公司高速發展的時候非常需要適時的管理。從剛剛成立擴展到幾百人的規模，這是每個公司發展需要經歷的一個很大的檻。有些企業瘋狂式的增長，是對現實性的考慮模糊。我（FreeWheel 高級副總裁容力，以下均以第一人稱「我」代之）觀察到過去太多大公司人員的迅猛增長，並非是由公司的效益或業務需求所驅動的，而是取決於領導層的話語權。

FreeWheel 在 2007 年剛剛成立時只有 10 個人左右，2015 年 3 月我加入時已上升至 150 餘人，而截至目前，FreeWheel 又擴增了一倍，達到 300 餘人規模。經歷十餘年的發展，整個創業和探索的過程非常曲折和艱辛。但一直以來，團隊的擴建都是由業務所驅動的（FreeWheel 每年保持大約 70% 的營收增長率），因此這決定著更為良性的增長動因和態勢。

人員持續擴張的背後，「Hire the Best」是在招賢納士時秉持的最重要的基準。何謂 Best，如何定義？表層意義上來說，Best 就是頂尖的，具體分析主要體現在兩個方面：一個是在校招中，學歷與畢業院校的卓越性，另一個更重要的是在技術上的紮實積澱和積累，放在不同的招聘環境下具有不同的側重點。但同時，Hire the Best 的難點在於，你不能只看他現在會什麼，而是要預測他將來是否能更快地學到更多。技術人的學習能力，其個人長期的潛質和潛力應該在面試環節得到更多的加分。

我個人有一個理念，不管是在應聘還是在招聘的時候，都會秉承一個非常淺顯的道理：我們看待一個人適合不適合這家公司就看三點，第一，是這個人能為公司帶來什麼價值；第二，公司能帶給他什麼，雙方是互利的過程，僅僅看這個人給公司帶來什麼，不看公司帶給他什麼，這個交易也談不成；第三，這個人能夠在公司做多久。我們是對人才的投資，工作也是他生命中貢獻時間和青春很重要的一部分，所以是否能夠長期在一家企業效力很重要。因行業而異，因公司而定。

3

擁有良好工程師基因團隊的三點練就要素

管理人員必須要從技術第一線提拔而來

如何從一線的工程師轉成技術管理者，對個人和工程師團隊文化來說都是非常重要的一環。我非常看重的的一點是，技術公司的管理人員一定需要從技術第一線提拔而來，這樣才能讓公司保持工程師團隊文化，而且這種文化才具有與生俱來的某種技術特性。

我當時來 FreeWheel 就跟一線管理人員說，如果你的技術能力不能讓你在團隊里服眾的話，那你還能給團隊帶來什麼。在我的定義和 FreeWheel 的文化中，轉變為團隊領導的人必須要在他的團隊里具有最頂尖的技術水平。我們一般會以 10 人左右的團隊為一個評價標準，如果他是技術大拿，只要他說了別人就覺得有信心，願意按照他說的去做，那麼他才能成為一個合格的團隊領導者。很多矽谷的互聯網公司也是這樣，並不是按級別的高低來選擇最適合的管理者。

培育一種開放的文化：信息和思維雙維度

我曾在微軟和雅虎工作了將近十年，從最早的編程開始做起，到做一線的技術管理，再到管理 100 人、300 人的團隊，這種鍛煉是一步一步做起來的。十多年裡，從一線的管理逐漸轉變到管理更大的團隊，我也有了更紮實的體會。關於如何建設團隊；如何做長期的規劃；對於一個團隊，以至於一個比較大的團隊組織，怎樣獲得長期且穩定發展；如何在良性競爭中勝出等問題，微軟和雅虎都為我提供了很好的學習平台，所以在加入 FreeWheel 之後，可以很自然地將這些理念和思路應用在具體的技術管理場景中。

在雅虎期間，我能感覺到那種矽谷的沸騰的氛圍，而且在矽谷不同公司之間的交流也非常頻繁。在矽谷，不管是大公司還是小公司，大家就像是在一起創業的大家庭，時間長了就形成了一種工程師文化，說的簡單點是自由、平等、開放。這種工程師文化會讓每個人都持續保持進取的態度，很少有人抱怨，心態也會更加開放。

都說技術老大的角色決定了一家公司技術團隊建設的模式，FreeWheel 聯合創始人兼 CTO Diane 在工程師開放文化的構建上起了非常關鍵的帶頭作用，我們的開放主要體現為在信息維度的充分共享和在思維維度的創造激發。整個公司發展中，技術層面和商業模式層面的信息，可以在領導層和員工之間做到充分的溝通和共享，使得全員在任務處理上能更好地把握整體方向、理清事情的優先順序，做對公司最重要的事情。另外，大家做事情都是本著平等開放的原則，不會因為說話的人不同，就對他提出的問題或者方案有不同的態度，不因人廢言，更不因言廢人。這樣做的目的就是要激發大家的積極性，充分發揮每一位員工的創造力。

對 Engineering Excellence 的追求

追求 Engineering Excellence，是近期 FreeWheel 整個工程師團隊的最大變化。在公司整體度過了生存期的挑戰並進入到加速生長期時，我們要關注的事情，不再是到處救火，而是要追求卓越， 要打造一個可以在未來幾年裡，支撐業務發展的優秀技術平台。 在這個新的目標下，FreeWheel 工程師團隊也發生了不少變化，包括對 Full Life Cycle Engineer 理念的倡導，對 CI/CD(持續集成 / 持續交付) 等高效開發流程的探索和精進等。

4

敏捷開發模式在工程師團隊的實踐與落地

敏捷開發模式跟傳統的開發差別之一是對變化的擁抱。傳統的開發相對會拒絕變化，即計劃制定好之後不希望有任何變化，有變化會對開發流程造成很大的影響。敏捷文化是擁抱變化，當有問題發生的時候需要會主動做調整，當然這對團隊的組織和行為方式也帶來了很大挑戰。這裡，FreeWheel 有一些比較好的實踐經驗可以分享。

第一是團隊的組織。FreeWheel 一開始按照敏捷開發的原則將團隊組織成 Scrum，在這種管理方式下，所有相關人員（主要是測試人員、開發人員，和在美國的產品團隊）會形成一個比較緊密的團隊，消除相互間的壁壘。所有人從一開始就會融入到產品的設計、開發、測試里去，通過快速反饋和及時溝通，能最迅速地解決項目過程中各種問題。

第二是團隊的管理。敏捷開發與傳統模式相比，最顯著的特點就是人和流程的關係有很大不同。傳統開發中會制定一個固定的流程和周密的計劃，人被添在了這個流程和計劃中。敏捷開發的變化多、迭代快，如果套用一種管理模式並強加給團隊，往往會帶來生產力的倒退。所以管理的方式應該是給團隊更大的自主性，注重引導而非控制。一個公司往往會有很多個敏捷團隊，我們最終是讓各個團隊用他們的聰明才智解決問題，但同時各個團隊之間又可以互通有無、取長補短。有的時候你會是第一個踩坑的人，但這個踩坑的過程是有價值的，得到的經驗教訓可以跟大家分享。

第三是做事的方式。當把任務拆分的更細時，反饋就能更及時。如果有一大塊的東西擋在你的工作流里，會對你的敏捷性造成障礙。所以我們一開始就會對所做的事情進行拆分，把任務拆分得更細，使得任務更容易被排期。同時在技術上實現 CI/CD，對產品持續不斷地做測試，並且把它集成到研發流程中。當工程師做了某些改動後，整個系統會立刻產生結果評價，告知你做的是對還是錯，然後大家基於這個結果再看如何繼續推進。

SAFE（Scaled Agile Framework）模式的嘗試

與此同時，上面提到的「Hire the Best」理念也會對團隊建設和管理帶來一定挑戰。如果團隊人員的水平和能力呈現為梯隊型，自然而然管理會相對容易；但如果大家都處於較為平均的基線範圍內，就會面臨更多協調、平衡及取捨方面的工作。最近 FreeWheel 正在嘗試 SAFE，即將團隊都分成不同的 squad，一個 squad 即為對產品有貢獻的垂直的功能性團隊，需要挑選並重組在前端、後端、資料庫方面具有差異化優勢的小組成員。但將優秀的成員都放在一起做一件事很容易有人做的多，有人做的少，有人滿意，有人不滿意，這就跟項目管理、軟技能訓練等相關。

通過實行敏捷模式，工程師團隊的整體趨勢會越來越扁平化，但是扁平化主要還是發生在一個模塊內部。比如，目前 FreeWheel 中國的工程師主要被劃分為五個分支技術團隊——AdServing、Forecasting、Reporting、UI 和 OPS，其中，AdServing 模塊內部被大概分成了 6、7 個小型團隊；Forecasting 被分成 3 個小型團隊。其他四大模塊情況也類似。在團隊組織上，部分小型團隊成員可以直接彙報給一線研發經理，例如，UI（負責核心業務系統的研發與測試）模塊的 80 人團隊（北京分部）大概有 6 個研發經理，他們各自領導著十人左右的團隊。因此，分支技術團隊總負責人和普通工程師之間只有一級，向上的溝通和彙報會更加通暢。而且，負責管理的同事有更多的機會直接與小型業務開發團隊進行協作，第一手掌握他們真實的想法、他們的困難和反饋意見，以便縮短做決策的時間周期。

對 Full Life Cycle Engineer 理念的倡導

對於 Full Life Cycle Engineer，現在業界有兩種聲音，一種是 Full Stack（全棧）Engineer，指能夠掌握前端、能寫 Web，能寫後端伺服器，還能開發 mobile 程序等，要掌握不同的技術。這種聲音存在一定的爭議。另外一種方向是 Full Life Cycle Engineer。比如寫 C++ 的就不需要掌握 web，但要能對使用 C++ 開發軟體的整個生命周期熟稔於心：當新的功能要求提交出來時能用 C++ 對它進行設計，寫完之後能夠用相關的工具測試並將服務進行發布，後續還需要支持服務的運維。舉個很簡單的例子，測試、運維的環節常常被技術管理者忽略，隨之而來的問題便是產品質量不可控、BUG 一堆、發布成功率低、運維人為事故頻發。但對 Full Life Cycle Engineer 理念的倡導可以有效減少此類問題的發生。

因此，FreeWheel 非常倡導 Full Life Cycle Engineer，其直接優勢在於可以消除上下游間明顯的界限。比如一開始設計的時候就會將測試的實施方案、後期發布、運維上的問題一併考慮進去，而不是執行一半之後再去想怎麼「填坑」。這是敏捷模式下最為可行的方式，如果整個軟體交付過程中還要上下游切換，溝通成本就會很高，整個團隊不可能敏捷起來。

最快速的定位技術問題出現的根源

研發團隊之間的協作非常重要，協作和溝通的效率在很多時候都是解決複雜技術問題時的必備條件。開發過程中，如果我們在上線環節亦或開發測試環境中發現了一個具體的技術問題，不同的研發團隊負責人或該領域的資深專家會組成一個臨時小團隊，不斷地調研，分析和研究後認定問題根源並劃定應該由哪個團隊、哪個工程師具體跟進和解決。解決方案落地且開始執行後，大家還會回過頭來進一步驗證，確定目前的解決方案是否有其他風險存在。

輪崗制的跨地域協作

對 FreeWheel 而言，最大的挑戰之一是跨地域、跨時區的溝通與協作。FreeWheel 除了在美國、中國、法國有研發機構以外，在歐、美、亞洲的多個國家也會有自己的辦公室。這些國家的團隊規模及成熟度較高，但都存在較大的時差。

相比通過電話、電子郵件進行跨時區的交流，我們會儘可能地採用很多其他的方式優化跨時區、跨地域的合作和溝通。比如北京的各模塊的研發團隊會持續派輪崗人員，去美國等地不同的實驗室和不同部門，與產品經理在一起緊密地合作一到三個月。這樣做的好處之一就是當產品經理面對更多的客戶、分析客戶需求的時候能得到研發團隊第一手的支持，比如從技術角度看業務設計是否合理、能否實現、實現難度大小等。

另外，美國的產品經理會每個季度飛到北京來與這裡的同事工作 1-2 周的時間商議未來 3-4 個月的研發及項目規劃。這類協同工作的目的都是儘可能地減少跨時區、跨地域溝通的難度和障礙。如果團隊之間沒有很好的溝通，做完以後發現有很多問題，但由於一開始沒有識別出來，最後就會演化得愈發嚴重。

5

讓每個人感覺到自己的價值所在

人才培養更關注個體，團隊建設更關注集體。團隊一方面要做事，另一方面要育人，人才是團隊的核心資產。在團隊中可能只是很微小的一粒存在，你也必須要給所有技術人以存在感和價值感，讓他們能看到自己的付出能改變產品、改變公司，甚至改變整個行業的走向。

保持團隊的方向感，讓團隊成員知道自己在做什麼，將來又要做什麼，能感覺到自己的價值所在

在 FreeWheel，不論每個同事的職務或工作職責如何，技術管理層都會首先注重幫助所有人在公司找准自己的定位，也會幫助他們分析清楚自己的長處和短板，並有針對性地制定相應的工作計劃及提高個人能力和適應職業發展的規劃，幫助所有人找到他對公司的價值所在。這樣做一方面會讓每一位同事在工作上形成滿足感，另外一方面也保證了他做出的貢獻和體現的價值能被公司所認可，因而能有更好的職業發展機遇。

保持團隊的進步感，讓團隊成員感覺到自己每隔一段時間都能學到新的東西，從而值得為之付出努力

對工程師來說，發揮價值的地方仍在於與產品的強聯繫。我們非常提倡讓技術人深入到第一線工作中，讓大家去直面解答客戶的問題。在 FreeWheel，銷售和客戶服務團隊是直接做售前、售後服務的人，每個季度聚集到北京參加 PI Planning（Program Increment Planning），制定下一季的產品計劃，從而去打破技術人員、產品經理、銷售這一套人員固定模式上的隔閡，讓工程師團隊能感覺到自己做的東西所發生的變化、對用戶所產生的影響，直接參与到用戶的意見反饋環節中去。

另外，隨著業務的發展和體量的增大，FreeWheel 也正在實行大規模的技術重構工作。當每天的工作中都有可能面臨到新的技術挑戰時，就能更好地保持團隊的進步感。

以 UI 模塊團隊為例，從 2007 年到目前，前端技術框架經歷了多次演變，去年開始 UI 團隊 (同時也包括其他團隊) 都在推行微服務化 SOA 架構。後端的業務邏輯會通過 Golang 服務封裝成一個一個不同粒度的微服務，這樣我們整個前端的框架會更多專註在業務交互上，跟核心業務邏輯直接相關的實現都會封裝在底層的微服務框架上。但對於像 Go（包括我們前端目前正在使用的 React.js 框架）都是比較新的技術框架，會在技術細節方面面臨更多的挑戰，很難通過參考別人的經驗就能獲得有意義或有幫助的答案。所以我們更多是依賴於自己的研發團隊，深入地具體分析某一些技術問題產生的原因：為什麼在我們這樣的產品環境下會發生；能不能做一些實驗，嘗試找到一些解決辦法；論證我們的解決辦法，確保不會帶來其他的衍生問題；對我們的系統穩定性、可靠性是否造成影響等。

很多的問題都是挑戰，而克服挑戰、解決問題的過程才能讓大家感受到每天的進步以及明天未知的新奇。

保證團隊成員的歸屬感和自豪感，這樣的團隊才有凝聚力

FreeWheel 常常說我們的企業文化是 Proudly Unique、Deeply Caring，還有 Purposeful，雖然是幾個形容詞，但是在日常工作中會遇到很多事情，大家會經常在一起談解決問題的方法，遇到矛盾的時候又怎麼解決，這會讓所有人感覺與他人連同在一起，是有意義的存在。

另外，企業的定位和願景同樣會對技術人的價值感形成帶來很大的影響。我入職前，跟 FreeWheel 的 Co-CEO 進行了一輪電話面試，談公司的發展前景時，他用十年前蘋果和諾基亞做了類比的例子，並說：「雖然在公司規模上，我們在業界和主要的競爭對手相比非常弱小，但是如果把競爭對手比作諾基亞（那個時候），那我們就應該是蘋果。」舉這個例子的目的在於說明，即使目前的你尚且弱小，但只要你的產品有非常清晰的、適合市場發展的戰略，也一定能夠打敗當時佔領市場 80% 份額的巨無霸。

在這樣的目標之下，我們也相信，優秀的工程師會逐漸認知到企業和自身的使命，認知到他在做的這項技術的前景與價值。

今日薦文

點擊展開全文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！