研发能力从哪几个方面衡量
研发能力从以下5方面衡量：1、持续发布能力；2、需求响应周期；3、交付吞吐率；4、交付过程质量；5、对外交付质量。其中，持续发布能力具体包含两个细分指标，分别是发布频率和发布前置时间。需求响应周期包括交付周期时间和开发周期时间。
1、持续发布能力
具体包含两个细分指标，分别是：
- 发布频率。 团队对外响应的速度不会大于其交付频率，发布频率约束团队对外响应和价值的流动速度。它的衡量标准是单位时间内的有效发布次数。
- 发布前置时间（也被称为变更前置时间），也就是从代码提交到功能上线花费的时间，它体现了团队发布的基本能力。如果时间开销很大，就不合适加大发版频率。
2、需求响应周期
具体包含两个细分的指标，分别是：
- 交付周期时间。指的是从确认用户提出的需求开始，到需求上线所经历的平均时长。它反映团队（包含业务、开发、运营等职能）对客户问题或业务机会的响应速度；
- 开发周期时间。指的是从开发团队理解需求开始，到需求可以上线所经历的平均时长。它反映技术团队的响应能力。
区分交付周期和开发周期，是为了解耦并明确问题，以做出针对性的改进。其中，交付周期是最终的目标和检验标准。
3、交付吞吐率
指的是单位时间内交付需求的数量。关于这一点，常见的问题是，个数能准确反映交付效率吗？这是个问题。所以，我们更多强调单个团队的需求吞吐率的前后对比，统计意义上它足以反映趋势和问题。
4、交付过程质量
它包含两个细分的指标，分别是：
- 开发过程中缺陷的创建和修复时间分布。我们希望缺陷能够持续和及时地被发现，并且在发现后尽快修复；
- 缺陷库存。我们希望在整个开发过程中控制缺陷库存量，让产品始终处于接近可发布状态，奠定持续交付的基础。
交付过程质量的核心是内建质量，也就是全过程和全时段的质量。而非依赖特定的阶段，如测试阶段；或特定的时段，如项目后期。内建质量是持续交付的基础，关于其具体度量方法，下文会给出详细实例。
5、对外交付质量
它包含两个细分的指标，分别是：
- 单位时间的故障（线上问题）数；
- 故障平均解决时长。
这两者共同决定了系统的可用性。
这里可能会存在两个误区
误区1：交付的质量就是产出的方案、代码的数量和质量
这样衡量交付价值，就很少有人愿意建设公共设施了(因为质量好不好很难量化，建设公共设施初期的耗时往往明显大于直接完成业务需求)，也很少有人愿意使用公共设施(因为用别人的，不如自己建，还能拿个结果)。而对于技术团队，长期创造价值的能力，离不开公共设施的完备和对公共设施的使用。
误区2：交付的质量就是业务KPI中指标的增量
有很多功能并不带来直接的增量，或者比较难以衡量，但可能带来公司的竞争壁垒，如产品的体验。这样衡量交付价值，带来的问题就是，大家都只关注短平快的增量功能(比如营销)，最终产品的竞争力下降。
不完全是技术方案、代码的数量和质量，也不完全是KPI指标的增量。交付价值就是按照用户的需要，对用户提供的整个产品、服务的数量和质量。这个定义几乎是不证自明的。
