狭义的的研发效率管理

这里只是在软件工程中，比较常用，且比较狭义的研发效率管理。

关于研发效率：

• 首先，我们怎么定义并评估衡量研发效率：
  工程纬度：人均bug数？平均漏洞，坏味道？代码重复（技术债务）。提测成功率，编译成功率。这些流程中，每个环节都可以统计。（流程效率？）
  整体纬度：在更大的维度上，发版速度？上线速度，ab流量利用率？需求变化数。（业务维度？）
  为此，我们通过一些
  （上面更多是细节的改进和监控，在外界条件与环境不变的情况下，从细节提升效率）

• 但是整体，评估并研发效率主要的服务对象，还是需要提升我们的业务指标。所以从大层面上，我们在方案，设计，选型上进行权衡。比如有个一次性的活动，有个非常特殊的场景，非常大概率只会执行一次，我们是否需要设计一个通用的，更复杂的技术方案来应对？或者直接hack一个方案？【在这个场景，maybe直接hack一个能够在效率上最高】同理，如果有一个需求实现起来特别复杂，而稍微修改一下成为另一个需求能达到与我们目标期望基本一致的效果，也许我们应该修改这个需求。
  （这里更需要选择合适的技术，合适的体系，框架，才能从大层面保证效率，更多的是通过修改外界的环境与变量，需求，等等）

• 沟通问题？比如沟通双方的知识理解范围，与议题的范围不匹配。会导致艰难的教育过程。

• 当分析研发效率的时候，其实就是，直接原因，间接原因，根本原因。
  直接原因：一些代码设计问题？人的问题？
  间接原因：流程管理？
  根本原因：成本（代码质量，甚至人工成本）与完成效率有部分权衡关联关系