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