什么是特性团队 / 功能团队(FeatureTeam)

最近一直在思考如何做团队组织能力建设和如何进行决策、执行产品研发策略。因为自己一直在研发效能领域，所以来谈谈什么是特性团队(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是怎么运行的，这样你读起来更能有体感。