研发效率是在现代企业都关注的，注意是因为靠谱的工程师是有限的，而且软件工程师的人力成本较高，时间成本更高。在大多数情况下，软件工程是一个团队活动，通过协作实现突破。好的想法从不匮乏，但高速执行却不那么容易。高效团队会习惯于更高的标准。当研发速度停滞时，人们会创造性地寻找重建高速产出的方法，但是如果长时间停滞，也会造成人员的流失。
如何提升研发效率呢？或者说，研发速度是否可控呢？
速度是位移和时间的函数，很多时候，位移方向的目标更容易被忽视。然而，项目失败的最常见原因是团队构建了错误的东西。“绕树三匝，何枝可依。”，实际上，方向错了，停止就是进步。
确定方向本身就是很困难的事，例如预测产品或市场匹配度等。通常需要关注客户的声音，成功不是提供一个特性，而是学习如何解决客户的问题。理想情况下，我们希望倾听客户的意见，满足他们的需求，同时只发布他们最感兴趣的那20% 。
即使那些所谓具具远见的创新者，也很难预测客户到底需要什么。由于在选择方向时需要一些猜测，因此系统的灵活性和可扩展性就变得至关重要。灵活性可能表现为开放性，最大限度地提高试验的速度，减少对给定计划的承诺，快速发展的产品，以及在决策中区分可逆和不可逆的功能特性。尽管，可扩展性使犯错的代价比想象的要低，而“time to market”则肯定是昂贵的。
有很多人尝试直接观察软件团队的研发效率，但众所周知，这样的测量是非常困难的。为了弥补这一缺陷，企业会使用员工参与度来调查与研发效率相关的问题。这样的调查往往局限于对员工参与度和与公司目标一致性的高层次衡量，这也是OKR模式的辅助手段。利用这些调查来决定是否实现了高速迭代，询问工程师实际花费了多少时间来设计和编写代码，工具是否充分，过程是否有效，以及技术债务的影响等。
在着手进行这类问题的调查之前，一般会承诺根据调查结果采取行动，以便这些行动对目前的调查和今后对这类调查的答复产生积极影响。
可扩展性可以通过自治团队来改进，这些团队围绕着有良好边界的特定责任区形成高度的内部凝聚力。团队所负责的服务彼此公开API; 在理想情况下，不存在跨团队沟通，因为与业务逻辑交互所需的全部都是API，而业务逻辑是业务团队的责任。
服务的实现细节通常是不共享的，并且不存在对远程服务所依赖的数据存储进行私有访问。即使服务需要不前向兼容，API的新旧版本仍然通常会在重叠的一段时间内可用，因此业务可以在旧版本被弃用之前进行迁移。
服务的拥有者可以按照团队自己的速度发展并发布变更，独立于可能发生的其他变更，并在时间上与其脱钩。这就是所谓的“无许可创新”。然而，确定责任领域之间的接口是具有挑战性的，这些接口会不可避免地随着时间的推移而演变，完美的自治永远是虚幻的。
一组软件服务不断进化，就像一个鲜活的生命。发布新的接口，整个服务可能分离或合并，单个服务可能经历重大的重新设计或被弃用。理想情况下，内部团队拥有高度的自治，在组织结构上与“高内聚、低耦合”的软件设计原则相一致。
基于康威定律，这些团队提供的服务应该是独立的。理想条件下，不需要对所依赖的服务进行任何更改，任何团队就可以实现80% 的任务。在剩下的20% 中，通过特定的接口实现。
在符合研发路线图的情况下，服务拥有者会同意那些有意义的变更，但是在路线图上的优先级较低。这时，业务方可能会提供一个“援助团队”来实现所请求的更改。援助团队由来自业务团队的开发人员组成，这些工程师临时加入拥有服务的团队。设计、测试、编码和发布都需要服务拥有者的逐步批准; 当完成更改后，援助人员将返回到他们原来的团队。这个方式的一个附加价值是交叉授粉，在团队之间缺乏沟通的情况下尤其有效。
产品开发的敏捷方法可以迭代和速度之间做平衡。
即使在需求快速变化的世界里，团队井然有序的积压工作也是可以的，只要最新版本用于sprint即可。团队明确承诺从待办列表中完成一系列任务，而作为回报，则是团队获得了一个不可中断的受保护时间窗口，这是一个尽可能快速工作的冲刺。在完成这个不间断、无波动的幸福周期之后，sprint 的成果将展示团队履行的承诺。
在下一个 sprint 计划会议继续之前，团队将进行回顾。这是一个内省会议，其中团队评估其达到的速度，并确定在随后的sprint中提高速度的方法。一个诚实的回顾，建立在信任和自我意识的基础之上，可以找出在进入下一个sprint之前如何“提高研发效率”。
专注是实现高效研发的必要条件。
团队希望专注于解决客户的问题，高速实现所责任的业务逻辑。他们不希望不能控制自己的团队。可靠的基础架构和基础设施是无许可创新的助推器，更是是软件架构转变的推动者。勿在浮沙筑高台，不为繁华易匠心。
一个高效团队注重培养一种文化，这种文化鼓励团队成员高效交付成果。这是一种自我强化，具有高效文化的团队往往能够吸引到高手。重要的是，要假定团队成员是有才华的，与使命保持一致，并且希望高效工作。文化中对研发效率产生积极影响的方面包括: 多样性和包容性教程、谦逊、信任、乐于学习、愿意带着“紧迫感和重点”前进、自主性以及集体承诺取得成果的意愿等等。
为了实现高效研发，有必要投资那些使工程师能够高速工作的系统，并最大限度地将他们的时间花费在自己的文凭领域。显而易见，出发点是构建、集成和部署代码的工具和过程，以及那些在代码发布后用来运营的工具和过程，确保代码满足可用性、可靠性、性能和安全性的要求。
虽然基于服务的体系结构可能带来自治性的好处，但跨服务边界的故障可能更难排查。如果日志采集、传输、监控、报警和问题跟踪在各个服务之间都是通用的，那么就会很有帮助。可观测性的能力应能够进行分布式跟踪，便于精确检测关键信号和指标，并逐步细化排出空间，从而精确找到问题的根本原因。
为了提高创新速度，需要积极寻求降低实验成本，以便能够做更多的实验。高实验率可以促进更频繁纠错。但实际上，高比率的实验可以被看作是大量丢弃的想法、文档垃圾、死代码和失败，造成资源的大量浪费。
成功的团队拥抱失败，是指做出的大多数错误选择是容易逆转的。失败，如果处理得当，可能是一个成长的机会。错误并不是必要的罪恶，是做新事物的必然结果，可以被看作是有价值的。
但是，我们客观地认识到了自己的错误么？！
尽管大家都觉得软件工程越来越重要，但是太多的软件项目最终还是偏离了目标，并且超出了预算。有效的交付需要对所要的东西有一个完美的视野，同时要朝着那个视野坚定地前进，对所有的干扰视而不见，这可能是一个长期存在的误区。提高研发效率的一个更可靠路径是优化研发速度，提倡高效文化，开放的实验和学习，自治而敏捷的组织，不忘初心。
