一、研发效能理想目标

二、研发效能度量指标

1、持续发布能力

1. 发布频率，单位时间内的有效发布次数。

2. 发布时长，从准备上线到上线完成的时间。

   2、需求响应周期

3. 交付周期，业务从提出需求开始到上线的平均时长，反应研发团队（产品、技术）对业务需求的响应速度。

4. 开发周期：从开发团队理解需求开始，到需求上线所经历的平均时长。反映技术团队的响应能力。

   3、交付吞吐率

5. 单位时间内交付需求的数量。

   4、交付过程质量

6. 缺陷总量。

7. 缺陷库存。

8. 缺陷修复时间。

   5、对外交付质量

9. 单位时间线上故障率。

10. 故障平均解决时长。

    三、研发效能管理

    研发效能管理本质上就是管「事」和「人」，更进一步是如何通过文化、技术层面的建设更好的进行管理。
    「事」和「人」就像MVC模式中的Model一样是数据，为了更好的管理，需要从多个维度进行查看，这就需要好用的工具来实现。
    管理离不开工具，在没有购买付费工具的情况下，我们目前采用飞书多维表格进行管理，类似的工具还包括vika、seatable，后续将持续寻找更好的工具。

    1、持续交付

    这个一个比较典型的持续交付活动过程。目前我们已经开始按照这个过程开展活动：每周需求排期、每日例会。
    
    具体开发过程中，每个需求都要采用「开发 -> 调试 -> 测试 -> 部署 -> 上线」的过程。期间相关研发专注于这个链条上的工作，不要去做其他事情。一个需求做好后在做其他需求。每天至少发布一个版本（哪怕很小的更新），通过频繁的「构建 -> 测试 -> 部署」可以快速的暴露问题、解决问题，增强团队信心，只有正确运行的代码才是真的。

    2、需求管理

    通常需求分为两大类：「业务需求、技术需求」，业务需求自不必多说，实际研发过程中会有很多来着技术层面的任务，比如搭建框架、环境部署、技术调研等等，为了实现需求与任务间的映射关系，为这种公共的技术任务建立一个「公共技术需求」就好。
    
    甘特图上展示的是每个需求的预计开始时间、预计完成时间，从当前日期观察，可以很容易发现延期需求，对于任务管理也是一样。日常例会可以以甘特图的方式进行需求跟踪。
    
    点击进度条能看到需求关联的任务，但无法自动跳转的任务描述上，电子表格还是不如项目管理系统方便。
    

    3、任务管理

    可以从「人」的维度看，每个人在负责哪些任务，这是之前所缺少的。
    

    4、缺陷

    

    5、风险

    

    6、 研发过程分析

    

    四、最佳实践

    1、任务排期

11. 做WBS（Work Breakdown Structure），尽可能提前列举出来所有任务，原则上每个任务执行时间不超过3天。

12. 确定任务之间的依赖关系（暂时不考虑任务开始、完成时间以及负责人）。

1. 确认任务负责人及开发时间。

从任务依赖关系上看「任务2」、「任务3」是没有依赖关系可以并行开发的。但在人员有限的情况下，可能就按照下面这个顺序进行开发。「任务2」、「任务3」由并行改为串行开发。

如果为了缩短开发时间，就需要补充人员，将串行开发模式调整为并行模式。

2、周会例程

1. 产品经理准备好需求列表，并提前与研发沟通清楚。
2. 检查每个人员所负责任务情况，共同决定下一周开发哪些需求。
3. 进行任务分解排期。
4. 复盘质量情况。

5. 其他信息同步。

   3、日会例程

   日会主持人提前准备好例会材料

6. 检查任务情况、是否延期、是否有风险。

7. 检查BUG处理情况，原则上当日发现BUG当日解决。
8. 检查线上系统性能情况。

9. 其他信息同步。

   4、提升专业能力

10. 周期性复盘线上质量问题，针对性学习相关知识、技能。

11. 周期性针对团队面临的技术问题进行复盘总结，制定改进措施及计划。
12. 坚持双周技术分享。

    五、研发效能度量示例

    之前设计的一些研发效能度量看板，飞书文档也有类似功能，seatable有vba的功能，可能统计起来更容易，后续在研究。
    各团队完成的需求数量，用于分析各团队产能。
    
    各团队需求平均完成时间，理想值小于14天。
    
    Bug缺陷趋势，Y轴上半部分，每日新增bug数量，下半部分，每日关闭bug数量。