3

DevOps|高效能敏捷交付组织:特性团队(FeatureTeam)+Scrum - laofo(公众号scmroad)

 1 year ago
source link: https://www.cnblogs.com/laofo/p/16804525.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

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,我们也要不加吝啬的给予掌声和奖励。希望各位都能找到自己心目中的「高效能团队」做出一番事情。

感谢点赞、转载
关注我,了解最新研发效能发展动向
欢迎进入「DevOps研发效能群」一起探讨

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK