写点什么

高效能敏捷交付团队反思:特性团队 (FeatureTeam)+Scrum

作者:laofo
  • 2022-10-18
    北京
  • 本文字数:2493 字

    阅读完需:约 1 分钟

高效能敏捷交付团队反思:特性团队(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 研发效能群」一起探讨

发布于: 刚刚阅读数: 3
用户头像

laofo

关注

日拱一卒,功不唐捐 2018-06-12 加入

公众号 scmroad, 主要关注领域 {研发效能、研发工具链、持续集成、交付、DevOps、效能度量、微服务治理、容器、云原生} 欢迎加入我们的圈子。vx:xueliuan

评论

发布
暂无评论
高效能敏捷交付团队反思:特性团队(FeatureTeam)+Scrum_DevOps_laofo_InfoQ写作社区