研发活动中的降本增效,研发降本增效的方法和措施

本文讲了研发活动中的降本增效,研发降本增效的方法和措施。

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

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的时代，不管是组织还是个人，都需要提高效率，然后空出更多的时间去思考那些不变与变化的东西。个人实现更多的自我价值，团队做更多有意义的事情，组织交付更多有价值的产物，实现共赢。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。