谈「效」风生 | 如何找到现有研发体系的「内耗问题」？

#第3期：如何找到现有研发体系的「内耗问题」？#

在上一期《谈到提升效能，我们应该如何下手？》我们聊到开始做研发效能的四个要点：评估现有流程、引入自动化工具、建立度量指标、持续改进。本期就围绕「评估现有研发体系」这个话题，来看看下面两位研发朋友是如何理解相关问题的。

受访者 A：某云厂商 资深技术专家 李工

受访者 B：某通信企业 架构工程师 孙工

无论是什么样的科技企业，研发体系都存在很多问题。两位嘉宾在工作中都对自己所在的研发体系进行过改进工作。那么，评估研发体系要做些什么？

A：当我们开始做评估时，就已经说明研发体系出了大问题，或者说体系已经跟不上业务发展的速度。评估就是一个诊断过程，找到系统的问题是关键，最终目的是为了实现效能“提速”，如何准确地找到问题是关键所在。

简单说一下“找问题”的方法，我们可以从“成本”的角度去分析整个体系。比如，一般来说，随着产品和业务的不断升级迭代，研发团队成员也随之增多，代码规模也应按一定比例增长。实际上我们发现并非如此，反而到了一定阶段，增长速度呈现放缓趋势，这是人员成本扩大的问题。

在不同研发环节上增加相应人员，会造成各个环节之间的沟通成本增加，比如，产品与研发之间、研发与测试之间、功能测试与系统测试之间，都会产生很高的沟通成本，导致研发时间损耗。在研发体系中找到这些“成本问题”，并且解决“成本问题”的核心就是降低体系中的内耗，这也是评估工作的主要方向。

B：周工用”内耗“来解释体系问题很贴切。衡量体系中的内耗，需要建立相应的指标来监控问题的严重性。建立指标，是开始改进体系时首先要做的事，也是未来持续要做的事。

在此不详细说度量指标，只说一下构建指标时我们的一个思路，每个指标下面对应了很多数据，最后我们要做的是对数据进行分析。所以我们既要保证指标是有效的，也要保证数据分析是合理的。

我们常见反映质效关系的指标包括：需求完成数和平均完成时长、人均提交代码量、代码缺陷发现量、缺陷平均修复时长、代码规约扫描、构建次数、发布成功率等等。

以上可能是基础性指标，此外还有更多的延伸指标。我们需要仔细思考我们所找的问题会藏在哪里，再去定指标。例如，团队成员、需求、代码的关系，团队成员有新有老、需求有大有小，代码有多有少，如何定义经验水平、如何定义需求颗粒度，提交的代码缺陷等级与缺陷数量的关系如何。

比如说：两个研发人员提交代码，都出现5个缺陷，第一个人出现了5个之前我们没遇到的缺陷，第二个人出现的是5个我们之前多次出现修改的缺陷，这是人员的能力差异，从指标上可以准确反映。

发现体系中的「内耗问题」之后，接下来要做些什么？

A：我们刨根问底把这些问题找出来，并不急于修正优化。尤其是要重新构建一套提升研发效能的体系时，这些问题将作为一个“参照物”来完善效能的实践，为以后打造平台做准备。

我们知道了内部问题在哪里，问题的严重程度如何。这时开始实践DevOps或DevSecOps来提升研发效能，就不再是停留于理论阶段了，在DevOps或DevSecOps模型下全局切入，从问题入手，“自下而上”地解决问题，再持续改进，从而持续为业务创造价值。

B：接下来不管是做DevOps还是DevSecOps，我们都需要设计新的流程，之前所找到的「内耗问题」，也是我们技术价值流中流动性过慢的问题，从而导致研发非常低效。

构建新的流程，目的是减少需求从代码生产到部署上线的时间，同时提高质量、安全性、可靠性，建立从开发到运维再到安全三者之间更快速、更平滑的流程，从而持续交付高价值。

这就要讲到“如何最大程度优化工作流”的事了。简单说我们通过使工作可视化、限制在制品数、减小批量大小、减少交接次数、持续识别和改善约束点、消除价值流中的困境和浪费，持续地优化全局目标，实践这些方法论上程序来设计改进我们的流程。

再提一点，提升研发效能也是一个组织性问题，我们找到问题、构建新的体系的同时，也要在组织层面推动。推行和管理研发效能的人，很大程度上不是研发人员，有的甚至会导致多个团队之间产生矛盾，所以一开始也需要从组织架构进行改变，来支撑研发效能的提升。

本期两位嘉宾分享的内容涉及的知识点比较广，简单总结如下：

1. 评估研发体系，需要找到造成现有体系流动性过慢的「内耗问题」。

2. 通过构建度量指标，并对指标进行科学的数据分析，来深度挖掘体系内存在的「内耗问题」。

3. 挖掘到「内耗问题」后，可以准备实践DevOps或DevSecOps，根据「流动原则」设计优化新的工作流。

4. 组织架构也需要随之变化，来支撑研发效能的提升工作。