最近一直在思考如何做團隊組織能力建設和如何進行決策、執行產品研發策略。因為自己一直在研發效能領域，所以來談談什麼是特性團隊(FeatureTeam), 怎麼創建特性團隊以及在日常工作中如何結合 Scrum 帶領團隊快速向用戶交付產品價值。內容稍多，準備分三篇來完成，本篇主要介紹特性團隊/功能團隊（FeatureTeam）。

為什麼需要特性團隊？ 

其實，我在帶領團隊完成工作的時候經常遇到下面的問題？

• 傳統的按照職能組織的團隊之間，跨職能的協調和依賴管理複雜，不利於跨職能、跨層級的溝通

• 多種職能之間依賴嚴重，各種等待時間不利於價值流的快速流動和承諾最終的交付時間

• 每個職能都在專註自己的事情，對用戶價值整體交付缺乏關注

• 各職能團隊之間目標難以對齊

• 每個人都對自己的事情負責，無人對最終的結果負責

   

同時，跨職能團隊之間還有一個最重要的問題就是難以應對高度不確定的問題，跨職能的溝通是巨大的阻礙。我們經常會被易變、不確定、複雜、模糊的問題整得焦頭爛額。也正是在這樣的背景下，特定團隊誕生了，我們期望通過建立一個穩定、端到端解決問題的團隊來幫我們解決這些事情。特性團隊提高了我們應對高度不確定問題的應變能力，讓我們慢慢接近最後的「正確答案」，讓我們在某種程度上具有了「可預見性」。

什麼是特性團隊？

• 定義：特性團隊是一個長期穩定、跨職能跨組件、持續端到端交付用戶價值的團隊。

• 特點：

• 長期、穩定：這不是一個臨時拼湊接私活的裝修隊，而是需要長期一起工作解決各種問題的「特種部隊」。我們一般不超過兩個披薩12個人。

• 跨職能、跨組件：一專多能T型人才；所有信息團隊內部共享。開誠布公，不搞信息差。既然我們要一起去打硬仗，那麼我們之間都是可以把後背互相託付的人。上到開飛機飛船下到開坦克潛艇樣樣精通，前後端通吃，產品運營運維一起抓。

• 端到端的交付：我們是一支可以交付用戶價值的團隊，從了解用戶、梳理需求到最後價值交付我們都可以做，需求來了拉出去就能幹。這就是我們要說的救人斬首可以做，經濟建設也能行。

• 核心價值

• 最大化響應速度

• 最大程度減少外部、內部依賴

• 最大程度降低溝通成本

• 好處

• 團隊內可以做到端到端，所以減少了等待，交付速度快

• 減少了團隊之間依賴，計劃更容易更有保障

• 責任範圍的擴大，各種不同領域的專家在一個團隊，增加了個人成長的機會

• 團隊內部快速溝通、快速響應用戶的訴求

• 長期穩定的合作，成員歸屬感增強

• 團隊成員直接面對用戶，更加深刻了解自己工作的業務，同時感受到自己工作的價值

• 團隊成長快，FT 運轉一段時間，團隊每個人產出都有提升

• FT對每個人都要求很高，每個人都有全局視角，有把事搞定的能力，快速學習的能力

• 以用戶為中心的功能特性驅動團隊運轉

   

• 問題

• FT 對團隊每個人要求都很高，要有不斷學習的能力，自我驅動和主動承擔，但不是每個成員都能適應

• 各個FT都會針對自己的團隊非常實際的做出決定，在技術棧選擇、規範性遵從上一般不是很注重，

• 各個FT之間交集很少，重複造輪子在所難免

• 長時間在一個 FT 中工作，部分隊員可能會對本 FT 做的事情失去興趣

• 工作邊界並不是很清晰，中間模糊地帶需要更多地發揮積極主動性

• 長期高強度的端到端用戶價值的交付，讓我們把注意力全部集中在事上，對人的關懷度降低

• 難以完全閉環。對於專業性很強、難以短時間掌握的職能，還是需要專業的小夥伴來支持，比如運維、DBA、設計師

   

    當然這些問題都是可解的，我在下篇文章中會詳細介紹。

什麼時候採用特性團隊組織方式？

• 在開發新的產品、新的業務

• 進入新的市場

• 業務發展初期，需要快速打開局面

• 用戶數快速增長、需要快速響應

   

什麼地方適合特性團隊？

• 創業

• 內部創業

• 內部新業務

   

特性團隊裡邊的人員構成？

特性團隊里正常情況下只有兩種角色，FTO，FT隊員

FTO：團隊的「CEO」，能決策、會執行、要負責

• 搭班子：負責整個FT的搭建、對外協調，對內溝通，對整個團隊負責、對結果負責

• 定戰略：整體把握業務的方向，勇於做決策並對結果負責；在有限資源、時間、範圍內取捨，推動特定問題的解決

• 帶隊伍：負責團隊的管理、躬身入局、敢於當先

   

FT隊員 

複合型人才，跨職能跨組件端到端的解決問題，主人翁精神(Ownership)，自驅力

特性團隊帶來的成本

• 全能型人才帶來對每個人各方面要求都很高，人力成本是有所上升的。就像特種部隊一樣，想培養出一個能征善戰的特種部隊也是非常不容易的。

• 完全閉環的 FT，人員利用率未必是最高的。因為很多是跨職能跨組件，每個人要互相備份，每個人要掌握的知識和技能也多，這就需要付出更多的精力。比如A模塊是小王寫的，這個時候小李要去解決個問題，這個時候肯定比小王自己去修效率要下降。同時前後端通吃的複合型人才寫前端的時候也未必有一個更專業的前端寫的溜寫的好，找個前端來也許更快更好。

單FT負責整個產品

當一個FT 可以負責整個產品的時候我們一般採用上面的模式。

• FTO一般由產品經理擔任

• FT 負責一個完整的產品, FTO 就是 Scrum PO(Product Owner)

• FTO視情況決定是否需要設置 Scrum Master

• FTO視情況決定是否需要設置研發 Leader

多FT負責整個產品

當產品規模較大，單一FT已經無法支撐所有「以用戶為中心的功能」，而因業務又需要同時支撐時，我們通常會建立多個FT來支撐。

多FT的模式和單FT還是有很大不同的。

• 團隊內不再是全能型的人才(太貴了），轉而由各個職能團隊支持，比如前端、後端、移動端、產品、QA、運維、設計師(UI,交互等）、運營、PMO等

• FTO一般由產品經理擔任，也可單獨指定

• FTO 不是產品經理擔任時，FT中需要有PO(Product Owner)

• FTO負責本FT團隊的產出，依然對最後的結果負責

• FTO不再負責人才培養，轉而移交到職能部門，但對人員有考核權，且權重高於職能線(FTO是拿結果的）；

• FTO視情況決定是否需要設置單獨的產品/前端/後端/QA/移動端等負責人；設置後各負責人需要虛線彙報FTO，FTO對職能負責人有考核權，且權重高於職能線

• FTO不再負責項目協同，轉而移交到PMO，PMO對FTO實線/虛線彙報；虛線彙報時，FTO對PMO有考核權，且權重高於職能線

• 對於如此大的產品，FT成員要支撐端到端的功能產出，對整個產品需要了解，學習成本高，學習曲線長

• 各FT共用相同的源碼庫，需要更精細的分支管理和更好的協作，同時對代碼質量要求更高，要有準入標準等

• 各FT的技術棧選擇需要達成共識，可由技術委員會或者架構部來協調和確認

• 各FT的基礎設施、支撐平台也會由單獨的研發效能團隊來負責

文章小結

特性團隊也不是銀彈，但是的確幫我們解決了很多的問題，比如高效溝通、快速響應、以及降低內外依賴等，尤其是在以用戶為中心的功能快速交付上讓我們更加從容地應對不確定的問題，當然特性團隊也存在它自己的問題比如單FT成本高、隊員長期做一件事失去興趣、人文關懷欠缺，多FT的學習成本和基礎設施建設等。我下篇文章會結合 Scrum 來說一下單FT是怎麼運行的，這樣你讀起來會更能有體感。

參考資料

Feature Team 快速響應團隊擺脫冗長研發體制 //zhuanlan.zhihu.com/p/101314842

當談論Feature Team時我們在談些什麼 //zhuanlan.zhihu.com/p/90452177

互聯網公司研發效能/工程效率團隊建設和規劃

研發效能團隊規模、職能劃分和優劣勢分析概述

研發效能之產品運營

研發效能之技術治理