如何提高研发工程效能？

大小的小

创业团队一旦规模化，必然会面临体系化、流程化的问题。 以前自治高效的团队，可能随着团队人员的扩充， 新人的加入， 面临一些低效、互撕、管理成本增加等各种垢病。因此，能否高速实现研发流程标准化、体系化， 是衡量一个技术管理者管理水平的很重要的一项指标。那么， 如何提高研发的工程效能呢？

首先， 我们需要明白， 怎么样去衡量/考核工程效能。 如何度量研发效能呢? 一般我们会通过: 需求的响应周期、需求交付的吞吐率、持续交付和发布能力、交付的过程质量以及对外交付的结果质量来衡量。

下面一一说明每个维度的一些指标定义：

• 持续发布能力，它包括发布频率和发布前置时间，也就是从代码提交到功能上线花费的时间。
• 需求响应周期，它包括交付周期时间和开发周期时间，交付周期时间指的是从确认用户提出的需求开始，到需求上线所经历的平均时长。开发周期时间指的是从开发团队理解需求开始，到需求可以上线所经历的平均时长。
• 交付吞吐率，指的是单位时间内交付需求的数量；实际研发中，可以给出标准化的story/task定义，保证每个项目组的考核通用性。
• 交付过程质量，它包含两个细分的指标，分别是开发过程中bug的创建和修复时间分布，以及bug库存; 当然, 也可以加一些譬如reopen率这样的指标。
• 对外交付质量，它包含两个细分的指标，分别是单位时间的线上故障数，以及故障平均解决时长。
  

那么， 明确了如何去考核和衡量研发效能后， 该如何提升呢？

首先，从持续发布能力方面来讲， 一个研发团队的持续发布能力可能是反映研发体系够不够标准、工具和流程够不够完善的一项最重要的指标。因为从代码提交到功能上线， 这里面包含了相当多的基础设施的建设， 包括 ： 版本控制、问题跟踪、持续集成、持续部署这一整条流水线，也涉及到包括：开发、测试、运维等跨团队的流程配合的高效性。用什么样的流程和工具呢？我们可以利用gitlab+jenkins, 结合 jira+ confluence 来完成整个流程的贯穿。

当我们能够利用jira来管理每一项任务（无论它是story, task, bug）， 做到万事皆jira, 而且针对研发的jira任务与gitlab的每一次commit关联，无疑我们将开启流程统一的新局面；同时，我们可以配合：UnitTest、CodeReview的工具集、流程和规范， 来提升研发内的质量；通过一些自动化的集成测试框架，比如 Selenium 、JMeter等来提升产品整体的质量；在部署方面， 通过k8s及docker来达到快速发布或回滚的目的；在运维监控方面，通过Prometheus+ Grafana 这套系统去实现7*24小时的监控报警，提升整体服务的SLA。

其次，针对需求响应周期， 我认为主要是2个方面： 一是产品经理对于需求的管理；另一个是开发人员的能力（技术、业务和沟通能力）。这里我主要说明一下我对于需求管理的理解。有时候，研发高效体现在一次性把事情做对、做好的能力；如果需求总是在反复，需求不能真正带来商业价值或为商业目标服务，可能是研发低效（这时不一定是研发低产出）的重要原因。所以， 一定程度上， 我们也需要多花时间利用jira+confluence来做好需求管理， 针对每一个需求，产研要说清晰、弄明白。 以下是我认为的一个需求应该包括的内容或属性：

需求名称：一个关键词描述，不超15字需求描述：具体描述，业务的诉求或用户故事需求来源：来自市场？业务？市场？业务痛点：描述当前的现状，为何要实现该需求期望值：期望何时上线，如：本周、本月、下月、本Q，下Q…用户价值：一句话描述这个需求给用户带来的价值价值(Value)：用0~100的数值来计量成本(Cost):用人力成本（人天）来量化，如果特别大，无法评估，用较大的数字计量。ROI：Value/Cost， 需求的优先级，可以用这个字段来排序需求类型：新功能、优化…备注：疑惑、问题补充等附件：用于说明这个需求的图片或文件创建人：谁创建的这个需求，一般是PO处理状态：未开始、处理中、已完成、已关闭等优先级：A:重要&紧急，B:重要&不紧急，C:不重要&紧急 D：不重要&不紧急, X:待定负责人：谁负责去跟进这个需求的实现，可以是PO，也可以是Developer

需求明确， 目标清晰， 是高效的必要条件。

针对交付吞吐率，可能需要关注2个点。第一是标准，针对需求， 我们必须定义一个统一的单位，比如我们要求，必须将Jira里的point字段用起来；第2个点，主要是开发人员的能力问题，比如技术能力、遵守开发准则规范的能力、沟通需求了解业务的能力， 而这些能力，除了个人学习能力之外，还需要辅以培训、分享等活动来提升和普及。

针对交付过程质量， 可能需要更多的关注流程的控制，比如对于需求的修改、反复的控制，以及是否遵循敏捷的思路，Scrum框架实施程度等等。如何通过对DevOps这套流程体系的把控， 让测试工作贯穿到sprint的每一天，做到持续集成、持续测试，而不是临近sprint上线来进行集中爆发的测试，是我认为对于交付过程质量把控最重要的一点。

最后一点， 对外交付质量， 实际上如何减小线上BUG数的问题。 现代的质量管理观点认为：质量是规划出来的，而非检查出来的，更多的强调对于过程的管理，强调预防。如何降低线上BUG数呢？ 个人觉得， 以下几点是可以强调和加强的。一是对于代码质量的控制，可以加强UnitTest和CodeReview的力度，提高对于过程质量的控制；二是集成测试、自动化测试的加强，这样测试团队可以有更多的精力来进行场景测试，从而降低线上BUG出现的概率和数量。而从故障响应时间来讲， 个人认为规则大于一切， 可以通过设置任务处理优先级来提升故障的响应和处理时间，比如线上问题优先级最高，配合一些SLA的考核指标来提升对外交付质量。

Uifhjvv

以前自治高效的团队，可能随着团队人员的扩充， 新人的加入， 面临一些低效、互撕、管理成本增加等各种垢病。