研发效率是在现代企业都关注的，注意是因为靠谱的工程师是有限的，而且软件工程师的人力成本较高，时间成本更高。在大多数情况下，软件工程是一个团队活动，通过协作实现突破。好的想法从不匮乏，但高速执行却不那么容易。高效团队会习惯于更高的标准。当研发速度停滞时，人们会创造性地寻找重建高速产出的方法，但是如果长时间停滞，也会造成人员的流失。

如何提升研发效率呢？或者说，研发速度是否可控呢？

高效的目标——方向

速度是位移和时间的函数，很多时候，位移方向的目标更容易被忽视。然而，项目失败的最常见原因是团队构建了错误的东西。“绕树三匝，何枝可依。”，实际上，方向错了，停止就是进步。

确定方向本身就是很困难的事，例如预测产品或市场匹配度等。通常需要关注客户的声音，成功不是提供一个特性，而是学习如何解决客户的问题。理想情况下，我们希望倾听客户的意见，满足他们的需求，同时只发布他们最感兴趣的那20% 。

即使那些所谓具具远见的创新者，也很难预测客户到底需要什么。由于在选择方向时需要一些猜测，因此系统的灵活性和可扩展性就变得至关重要。灵活性可能表现为开放性，最大限度地提高试验的速度，减少对给定计划的承诺，快速发展的产品，以及在决策中区分可逆和不可逆的功能特性。尽管，可扩展性使犯错的代价比想象的要低，而“time to market”则肯定是昂贵的。

高效的感知——度量

有很多人尝试直接观察软件团队的研发效率，但众所周知，这样的测量是非常困难的。为了弥补这一缺陷，企业会使用员工参与度来调查与研发效率相关的问题。这样的调查往往局限于对员工参与度和与公司目标一致性的高层次衡量，这也是OKR模式的辅助手段。利用这些调查来决定是否实现了高速迭代，询问工程师实际花费了多少时间来设计和编写代码，工具是否充分，过程是否有效，以及技术债务的影响等。

在着手进行这类问题的调查之前，一般会承诺根据调查结果采取行动，以便这些行动对目前的调查和今后对这类调查的答复产生积极影响。

高效的组织——自治

可扩展性可以通过自治团队来改进，这些团队围绕着有良好边界的特定责任区形成高度的内部凝聚力。团队所负责的服务彼此公开API; 在理想情况下，不存在跨团队沟通，因为与业务逻辑交互所需的全部都是API，而业务逻辑是业务团队的责任。

服务的实现细节通常是不共享的，并且不存在对远程服务所依赖的数据存储进行私有访问。即使服务需要不前向兼容，API的新旧版本仍然通常会在重叠的一段时间内可用，因此业务可以在旧版本被弃用之前进行迁移。

服务的拥有者可以按照团队自己的速度发展并发布变更，独立于可能发生的其他变更，并在时间上与其脱钩。这就是所谓的“无许可创新”。然而，确定责任领域之间的接口是具有挑战性的，这些接口会不可避免地随着时间的推移而演变，完美的自治永远是虚幻的。

一组软件服务不断进化，就像一个鲜活的生命。发布新的接口，整个服务可能分离或合并，单个服务可能经历重大的重新设计或被弃用。理想情况下，内部团队拥有高度的自治，在组织结构上与“高内聚、低耦合”的软件设计原则相一致。

基于康威定律，这些团队提供的服务应该是独立的。理想条件下，不需要对所依赖的服务进行任何更改，任何团队就可以实现80% 的任务。在剩下的20% 中，通过特定的接口实现。

在符合研发路线图的情况下，服务拥有者会同意那些有意义的变更，但是在路线图上的优先级较低。这时，业务方可能会提供一个“援助团队”来实现所请求的更改。援助团队由来自业务团队的开发人员组成，这些工程师临时加入拥有服务的团队。设计、测试、编码和发布都需要服务拥有者的逐步批准; 当完成更改后，援助人员将返回到他们原来的团队。这个方式的一个附加价值是交叉授粉，在团队之间缺乏沟通的情况下尤其有效。

高效的方式——敏捷

产品开发的敏捷方法可以迭代和速度之间做平衡。

即使在需求快速变化的世界里，团队井然有序的积压工作也是可以的，只要最新版本用于sprint即可。团队明确承诺从待办列表中完成一系列任务，而作为回报，则是团队获得了一个不可中断的受保护时间窗口，这是一个尽可能快速工作的冲刺。在完成这个不间断、无波动的幸福%E