关于devops:什么是特性团队-功能团队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 是怎么运行的，这样你读起来更能有体感。

参考资料

Feature Team 疾速响应团队解脱简短研发体制

当议论 Feature Team 时咱们在谈些什么

互联网公司研发效力 / 工程效率团队建设和布局

研发效力团队规模、职能划分和优劣势剖析概述

研发效力之产品经营

研发效力之技术治理