DevOps｜高效能敏捷交付组织：特性团队(FeatureTeam)+Scrum

这是《研发效能组织能力建设》的第三篇。特性团队和Scrum，这两个定义我们在之前的文章中都详细介绍了。这两个组织模式或者说管理实践，我都用过所以有些时候特别有感触。书本上纯粹的模式很容易理解，但是具体工作中运用这是非常考验团队和人的，尤其是涉及到考核和汇报的关系就会很复杂。本篇文章主要来唠唠我实际使用时的感受和理解。

特性团队定义

特性团队是一个长期稳定、跨职能跨组件、持续端到端交付用户价值的团队。

Scrum 定义

Scrum是一个用于开发和维护复杂产品的框架，是一个增量的、迭代的开发过程，目的是让开发人员像打橄榄球一样迅猛并充满激情，通过团队合作，提高工作效率。通过团队间的有效交互，为企业创造价值。

不确定性的世界

简单地总结下Scrum的合作模式是：PO负责计划、定义功能、验收产出，Scrum Master 负责流程，Team 负责实现。如果真这样去用，会不会有啥问题？对于日常的工作这样安排没有问题，但是对于非「按部就班」的事如何解决呢？放到产品代办列表中？PO去跟进？还是Scrum Master 去跟进？重视团队绩效而不是个人绩效，所有人都同一个系数还是各不相同？同一个系数，摸鱼的无所谓，拼命的的肯定受委屈。如果干多干少一个样干好干坏一个样以后有事谁还往前冲？定义是一方面，真的带团队做事情每天遇到「鸡毛蒜皮」「柴米油盐酱醋茶」的事情太多太多。我们不是在象牙塔里，我们要在复杂的世界中前行，所以这些非「按部就班」的事需要有人负责。这也就是特性团队提倡的要以一种「全职能」的团队去应对各种不确定。

各司其职+相互配合

为了追求效率最大化，各种分工越来越细，术业有专攻。每个人都在忙范围划定、能力所及的事，总感觉这不是一个「Team」，而是「迎面喊声兄弟借个火」的路人。可以说这是一个松散的，靠自愿、靠兴趣来驱动的组织。

人都是有惰性的，团队压力小还能相安无事。真想做出点事情，压力一大，工作任务多，需要每个人有更多承担的时候就会出现问题。不是说自组织么？不是说自领任务么？本质是Scrum 这种模式在人员素质高、工作压力不大，人员配置充足，分工合理的企业还能进行得下去，比如外企。因为很多外企在国内的部分都是成本中心，通常也不会有营收目标，你好我好大家好。但是对于很多还处在生死线上的企业是否合适？我自己感觉靠兴趣，靠影响力去驱动是不靠谱的。在公司里就要专业一些，职业一些。

PO，SM和Team 这三个「脑袋」驱动整个团队向前走，但有点问题就会非常内耗。能同时影响这三头「猪」的人是谁？如果是一只「鸡」还好，往往还是好几只「鸡」。这些「鸡」不在团队里，平时也不参加各种会议，只是偶尔听下汇报，但是却考核团队里的「猪」。这只「鸡」不在团队里却对团队效能影响很大。

Scrum 带来了流程，还带来了「各司其职、人尽其才」， 给我们带来一个按照规范流程做事情的组织；但三股碎麻无大用，要拧成绳才能提千斤鼎。对于公司也一样，公司的诉求也不是一个照本宣科的 scrum 团队，而是一个能拿结果、高效能的「特种部队」。

特种部队也得卷

西方发达国家依靠先发优势，掌握了大量先进的科学技术，即便是欧洲小国，也可以依靠一两样先进技术或者不错的产品赚大钱，过上富裕、安逸的生活。公司里面的人也不用那么拼命，按部就班的工作，很多人喝喝咖啡闲聊几句就是一天，只要公司里有一部分在努力工作，公司就能活的很好。

而我们不行，我们还处在产业链的低端，还在攀登科技高峰的途中，我们要想爬上金字塔的顶端，光靠「按部就班」的工作是活不下去的。所以造成了国内的公司和团队都很拼，都很「卷」。好像这一点说得有点远了，但的确在那里。

「卷」也不是一无所获。打工赚钱来的，谈钱不寒碜。「三个人干五个人的活拿四个人的钱」。如果没有更多的收获，我觉得不应该卷。实际上很多团队并不是在「卷」，而是「干耗」。加班很多却没有收获没有成果，这种「干耗」是应该抵制的。纯干耗不如早下班。

有价值有产出的团队

对于公司内的团队，底线就是要有价值有产出，在可预期的时间内拿到预期的效果；对于个人来说，经过一段时间能有所收获（知识、技能和收入）。而这所有的一切都需要产出的保障。而要做到这些，首先要选对一个有价值的方向，其次团队在这个方向上要做出有价值的产出。

这个「有价值的方向」公司会有一定的考虑，在团队创建之初其实公司是有预期的，虽然可能很笼统、概括。因为能在一个更高的维度看到存在的问题，有解决这些问题的诉求，也有一定的经验或者掌握了一些信息，所以才要成立相应的团队来解决。大方向是有的，但是还是要靠具体团队来落实。也就是说团队成立之初是有价值的。但是团队具体有多大价值，要靠团队来证明。那么一个高效能的团队就是证明其价值的有力保障。

高效能团队

一个对领域有深刻理解，同时能带领团队拿到结果的 FTO 是关键。这样的人只要授权他，同时给予资源就能取得很好的结果。

聚起一队「跨职能、持续闭环交付用户价值」的 FT Memeber是根本。各司其职、人尽其才的同时还要有主人翁意识(ownership)，能自驱，能补位。至于一些具体的流程、做法，相对反而不那么重要。团队正向运转起来，这些问题自然会迎刃而解。

所以，我心目中的高效能团队是一个可以持续完成一个个高优先级任务的「特种部队」，团队内部职能、职责清晰，同时尽可能地闭环。这样可以顺畅沟通，高效协同，持续地端到端交付用户价值。

期待&总结

成立一个高效能敏捷的团队不难，难的是我们有时候人为破坏它。一个团队从形成到高效能有一个form-storm-norm-perform 的过程，频繁的组织变更会让团队长期处于动荡，这也就是为什么特性团队要强调「长期、稳定」。FTO 对团队的产出至关重要。兵熊熊一个，将熊熊一窝。我见过很多特别优秀的FTO，也见过瞎整的FTO。向社会「输送一两个人才」「让一两个队员毕业」「把一两股寒气传给其他人」，不如向社会输送一个 FTO。当然对于做出成绩的 FTO，我们也要不加吝啬的给予掌声和奖励。希望各位都能找到自己心目中的「高效能团队」做出一番事情。

更多阅读

研发效能组织能力建设之特性团队FeatureTeam（上）

研发效能组织能力建设之Scrum管理框架核心精髓（中）

感谢点赞、转载

关注我，了解最新研发效能发展动向

欢迎进入「DevOps研发效能群」一起探讨