研发效能 研发活动的降本与增效

CKL的思考 · 2022年08月04日 · 1792 次阅读

降本增效是最近几年一直在提的词,毕竟大环境不好,企业也需要做好过冬的准备。测试部门是理论上是个成本中心(做得好的,也有把测试部门做成利润中心的),在当下的大环境中,如何做好降本增效呢?最近在和朋友的沟通中聊到了这个话题,说说自己的观点。

01

降本和增效,看似是一体的。但其实是分来的,它们没有必然的联系,降本并不一定能增效,因为人员的流失而带来的工作交接等问题,短期内会一定会影响工作效率,长期来看,也会影响团队的情绪,带来一些负面影响。

增效,通常也意味着增本,因为你需要更高级的人才引进,也可以寻求团队成员自身的成长,但这些都会增加一些额外的成本,这些成本是你必须要付出的。比如你买了辆车,用于日常的出行,增效肯定是增效了。但同时也增加了生活成本。

所以,降本和增效,其实不是因果关系,这点有不少人没想清楚。把团队中工资最高的人开掉了,实现了降本,但如果因此而带来的是效率上的降低,那么这也不是团队所希望看到的。需要做出动态的平衡考量。

02

从团队来看,降本能做的事其实非常有限,最直接的办法就是减员(人力成本目前还是最高的成本),或者不再扩编。所以增效成了每个管理者优先考虑的事。个人认为,需要从三个方面来思考:解决真实痛点、提升技术能力及提高交付质量

03

在思考研发过程改进时,我们需要有更好的全局观,通过一定的度量手段(比如价值流分析)来发现整个流程中最核心的痛点和耗时点在哪里,从大局处着手。很多时候,单方面的细节优化,并不足以提升整体端到端的交付时间,那么意义其实就不是特别大。

(看图前先解析几个名词:LT:Lead Time 前置时间,PT:Process Time 处理时间,%C/A:the Percent Complete and Accurate 完整度与准确度百分比。有机会可以详细讲讲这个图怎么来的)

如上图,是一个比较完整的研发过程(每个团队略有不同,这不重要),从这里可以看出,开发拿到需求时,有 12 天的前置时间,是需要具体去分析为什么,是因为前面的活动花费的时间太长,还是迭代的容量太少,导致需要等几个迭代才能排上?再比如,用户验收测试的 %C/A 值只有 70%,说明功能完成与用户预期存在较大的差异,需要打开来看看是为什么,返工导致的成本可是很高的哟。在这种情况下,如果你只是去优化测试的效率提升,引入自动化等,其实对团队来说,提效的空间就很有限了。

04

提升团队整体的技术能力,也是一种有效的手段(和上面的图并不矛盾哈,因为有的团队确实是因为测试时间过长,影响上线时间的。每个团队需要独立来看)。个人会去三个角度来思考技术带来的提效。

自动化:这里的自动化包含各种类型,不论是接口自动化还是 UI 自动化,或者只是一些简单的造数工具、合规检查小工具等等,把标准化的、流程化的东西沉淀成脚本,把人力从重复的工作中释放出来,做更多有意义的事,来提升团队整体的效率。

人员能力建设:通过内部经验分享、新的测试理论、测试思维分享、代码能力提升这几个方面着手,提升团队成员的能力,可能需要花费更大的成本,但这个是值得的。好的理论和实践,可以快速提升团队的测试效率和质量。

复用思维:第一类是经验的复用:成功的经验是宝贵的,不能让它成为一次性的经验,在别的团队中成功的经验,需要被萃取,然后复用到其他团队中,让别的团队也快速受益。第二类是工具的复用,比如上文提到的自动化工程建设,就可以推广到更多的团队中去。

05

最后,还可以从交付质量上去做一些提效的事。最核心的点是明确 DOD(Definition of Done),每个环节的输出项验收标准是否完善,是否符合要求。返工是种很严重的浪费。需要去推动质量内建,让全员都有这种意识。尽可能一次把事情做对和做好,减少额外的成本浪费。质量的成本更多用于质量内建(质量预防为主)、测试更深更广进一步提升用户体验(而非大部分的时间耗在原本开发本身就可以自测做好的低级问题),需求基线的质量、开发编码的提测质量、测试质量都非常关键,所以做好这些关键点的评审是必要的质量成本(评审的目的正是如此,不是为了走个流程,更重要的是对工件质量的把关与准出)。

06

以上,个人从增效的角度谈了一些个人的看法。在这个 VUCA 的时代,不管是组织还是个人,都需要提高效率,然后空出更多的时间去思考那些不变与变化的东西。个人实现更多的自我价值,团队做更多有意义的事情,组织交付更多有价值的产物,实现共赢。

原文链接:https://mp.weixin.qq.com/s/SQR5HQHpU4-Hoe5OreHvzg

暂无回复。
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册