扫码阅读
手机扫码阅读

聊聊研发效能建设的痛点

62 2024-01-30

这是鼎叔的第八十九篇原创文章。行业大牛和刚毕业的小白,都可以进来聊聊。


前段时间参加了深圳敏捷之旅,和几位大咖深入交流,包括吴穹博士和乔梁帮主等,对于研发效能的一些痛点颇有共鸣,大咖们有几句看似悲观的犀利句子能启发出更本质的行动指南。

搞研发效能的痛苦,一是高层往往关心把业务快速打下来,打不下来就撤,而不是省钱和提效,二是让别人提高效能,远比教小孩提高学习成绩难啊,强扭的瓜不甜。提高研发效能的本质,就是带着团队明确度量、无限拆解、刻意练习、自建纪律


太阳下面没有新鲜事,解决新问题的思路都在人的本性里。

做效能,首先是要提升系统思考能力,找到根本原因。


一 做效能的工程师在企业里面挺卑微的,因为他要让其他团队提高效能,别人心情好可能听你聊聊,配合一下,心情不好就说业务太忙。


我在《无测试组织》第四章说过,质量管理/过程改进工程师,也是同样一类尴尬的角色,要求其他团队交付高质量产品,但是不能帮忙解决现实的痛点。如果我们用传统的监工权力强制执行,在敏捷组织中必将陷入被孤立的境地。如果一线Scrum流程中动不动把团队外的角色卷入审批,必然拖慢交付速度,且难以评价收益。

从我个人经验出发,质效工程师一定要尽可能融入到交付团队,帮scrum team把特定的工作给做了,共同为交付目标负责。带领效能建设团队的leader最好不是孤立leader,避免屁股决定脑袋的言行。比如,懂敏捷的业务测试leader来负责大型组织的效能建设更有机会成功,因为质量和效率的痛苦是双生关系,也是业务测试的压力来源,而大部分项目都有业务测试人员作为Scrum成员,他们作为被培训者更容易把改进纪律带进各个scrum团队。

二 战养分离。
人才培养,团队氛围和效能改进等工作类似“养兵”,面向长期目标;眼前业务交付目标就是“作战”。如果让一线团队leader做好战养兼顾,在业务压力之下就会变成以战为主。

我在《无测试组织》最后一章说过,现在的实体测试团队,未来会演变成专家赋能和交流型组织,即测试人员关注“战”,测试经理转型成“养”的的责任人。

三 工程师是二十一世纪的铁匠。

过去这么多年的中国软件研发产出如此繁荣,并不能说明工程师水平在进化,主要原因还是赚钱机会太多,公司的第一要务是堆人,抢下更多的市场,敏捷/效能更像是个锦上添花的东西。

实际上,一二十年前调研软件工程团队的十大痛点问题,在今天几乎一模一样,这也是《人月神话》理论的侧面证实。

这几年强调研发效能的声音更大了,主要原因也是市场分割得差不多了,开始要求经营效率了。

如果我们观察团队效能改革的优秀案例,会发现敏捷教练做的事,本质上和球队教练做的事类似,工程师就是今天的普通工种,教练要让他无限拆解迭代周期的工作流程,并在规定时间做规定动作,精确查看度量指标是否提升。

上图是示意图,真实的迭代拆解时间表要复杂个四五倍。

我在《刻意训练》的文章也分享了,提高交付效率,和羽毛球运动员提高成绩,是同一个道理,完全不依赖工程师的天赋,而是在优秀教练的指导下,反复拆解、练习、度量。

规定时间做规定动作,看似死板枯燥,其实是维护大型研发组织的一致性。团队可以负责自己独有的特性,但是否纳入大组织中需要谨慎评估,有一致的衡量标准。

有人会说,这种练习不是抹杀工程师的创造力么,而且也不符合团队自治的文化呀?

我的想法是,敏捷执行就是要克服工程师的懒散习惯,世界上所有领域都是一样的,比如音乐家,舞蹈,足球队,都是如此。野生玩家自由状态下出成果可以,出优秀成果难。

“刻意练习”的具体时间表、纪律是团队自己画出来的(自治),但是执行框架是由教练/Scrum master引导的。

光有创造力,没有集体的刻意练习,这个创造力大概率会在市场压力下失败。

反过来,大师级程序员的创造力是体现在高强度训练之中的闪现。

四 技术管理者只关注工程实践闭环就好,不用去操心需求精益环。除非…

学习了《持续交付2.0》的双环模型,我感觉它类似《系统思考-第五项修炼》给出的经典问题分析的环状结构。左边是“精益需求环”,解决做什么、谁来做、怎么做的问题,右边是“卓越工程环”,解决怎么按时交付高质量的版本。

左边才是业务交付慢的大头原因。

因为业产研的核心矛盾在左边环的低效,所以我也有冲动去拉通产品团队和技术一起提效,确实进展极慢,想犀利批评一下,很容易被业务产品团队反弹,甚至被带上“破坏精诚团结”的帽子。

技术管理者如果不能掌握利益分配权,不决策产品演进路线,还不如专注做好工程环的交付。至于双环提升的措施,给老板看看方案就好,不用强行去整体承担。

五 效能度量不要考核个人!不要考核个人!不要考核个人!

我在《无测试组织》第四章说过,研发度量如果用于个人绩效考核要非常谨慎,最好不要直接使用,而是作为绩效已有判断后的辅助证明。因为每个质效指标都有多种“作弊”方法,就跟经济改革一样,工程师都有很聪明的对策。

效能度量的最小单位是一线团队。那有同学就会问,管理者总要给出个人绩效高低呀。

我的答案是,个人绩效主要看三点,第一,OKR产出和预期的差距,第二,360度口碑(包括客户),第三所在职级专业能力的高要求和产出的差距。

六 业务团队只要知道哪个技术人员为它提供专职服务,满意度立马提升

初创团队天生就很敏捷,响应快,因为业务实现不够快就面临生死问题,这个时候业务伙伴一定是满意的。

随着公司成长到数百人以上规模,必然就会考虑敏捷化,“让大象起舞”。

从业务团队的角度,为什么技术团队大了很多,反而响应我的需求更慢了?

团队大了,必然会产生部门分割,多层管理损耗,沟通的损耗,复杂的资源申请流程,等等。

大的产研部门会引入“部落制”,整个部门分为多个部落,每个部落由数个Scrum团队组成,一起承接特定业务部门的需求。

敏捷化的本质就是把业务服务对接精准。确保每个业务方都精确地知道技术侧是谁在解决问题,该和谁沟通。

业务和技术的协作,既不能100%由业务侧控制,也不能100%由技术控制。如果业务完全主导,就会形成山头主义,技术架构优化就难以落地。推荐的协作方式是业务交付由Scrum Team/部落横向拉通(战),技术建设由专家团队纵向赋能和风险评审(养)。

七 效能大盘的高价值

如果面向大规模组织的技术管理者呈现效能指标,有一个基于北极星指标拆解下来的实时数据大盘是非常有价值的,这在《无测试组织》最后一章也有说明。

因为高级管理者距离一线Scrum比较远,他希望能随时查看整体团队数据,也希望看到高风险的团队指标。效能大盘就是非常好的桥梁,让高级管理者能既掌握全局,又按需(风险)下钻。

大盘的全自动化能力,保障了快速呈现、极低度量成本、可灵活调整的数据获取,让效能能透明化呈现。只要度量数据是围绕北极星指标,科学拆解的,就能长期稳定采集,并能看到趋势健康度。

另外,效能大盘不要只用于领导层偶尔看一看,因为leader很可能不经常看数据,导致风险处理被延误。在这种状态下,我们要在一线团队指定观察指标的责任人(有的公司称之为“效能教练”),按要求行动,充分把大盘的驱动价值发挥出来。

从鼎叔自己的经验来看,有了清晰的实时大盘建设思路,就能把面向大型组织的研发效能汇报成本大幅降低。相对于当年要花几十人天才能完成的效能月报,现在半人天就能输出初版(理论上从大盘到月报可以自动化转换),剩下的工作就是追加人工沟通、分析和总结:为什么部分业务的指标会明显下降或提升,并总结近期的优秀措施和风险。

打造效能大盘的第一个阶段,是把关键效能数据呈现出来;第二个阶段,是对指标进行准确下探、精确拆解和根据基线提示风险;第三个阶段,是通过专家规则建设和AI,预警团队风险和建议解决步骤。

八 持续交付落地可以卷入各个角色,其中一个角色是…HR

围绕持续交付值得教育的口号和纪律不少,想要深入人心,可以和HR合作进行文化建设,他们在这块是专业的,方法层出不穷。未来更深度的合作就是组织激励制度了。

原文链接: http://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247484490&idx=1&sn=1dfbe7375583754b5bf51edfd57edb53&chksm=c24fb128f538383e514afac8d1a53a879a78b5183427ed44e88738663fd2e27be47461a4b67f#rd

《无测试组织-测试团队的敏捷转型》主题探讨。从打造测试的组织敏捷,到敏捷测试技术的丰富实践,从一线团队的视角来聊聊我们是怎么做的。面向未来,拥抱敏捷原则,走向高效能组织。

81 篇文章
浏览 5349
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设 白皮书上线