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

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

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

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

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

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

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

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

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

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

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

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

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

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

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