- 按阶段下钻
我们经常看到的现象是，如果产研部门被业务部门抱怨说交付速度太慢，产研部门的管理者头脑中的第一反应很可能是：再多招聘一些开发人员吧！从约束理论的角度来看，交付管道中至少会存在一个约束因素，限制了全局流动效率的潜能。但这个约束具体是在哪个阶段，很可能与我们预想的完全不同。
在下面这个案例中，部门碰到的问题就是交付周期较长。于是，把交付周期按照阶段下钻之后形成了一张柱形图。从图中可以看到，需求的平均开发周期在 5 天左右，其实并不算很长，但开发前有一个等待周期也接近 5 天，另外还有多个阶段的平均耗时接近甚至高于开发周期。比如测试阶段耗时超过 9 天，方案及 PRD 阶段耗时接近 6 天。在精益理论中，我们可以把活动分为三类：增值的活动（如写代码等）、非增值但必要的活动（如测试等）、浪费（如等待、缺陷导致的返工）。我们要最大化增值的活动，优化非增值但必要的活动，消除不必要的浪费。那么在这个案例中，我们就找到了改进的大致方向，再结合其他指标进一步进行问题排查，应该就可以得出有针对性的优化策略了。
- 按聚合维度下钻
研发效能度量平台在采集到各研发工具产出的效能数据之后，一般会进行自下而上的聚合，比如按照产品、部门、团队、项目、应用等不同的维度聚合，这样就可以提供更高层级的视图进行展示和分析。而我们在分析效能问题时，更多是自上而下进行的，比如先看到整个公司的效能情况、各个部门的横向对比，然后再进行逐层下钻，一直到子部门、团队层级，甚至下钻到数据明细，从而从宏观到微观进行问题根因分析。
在下面这个案例中，首先可以看到左上角的聚合数据报表，它展示了在所选时间范围内（周/月/季），所选部门与其同级部门的交付周期的横向比较，并且可以进行上一周期和本周期的对比。从这个宏观数据出发，我们可以进一步下钻分析，比如下钻到所选部门的下一级部门、下两级部门、下三级部门的数据图表，最终钻取到具体的明细数据。然后可以按照交付周期的长短对所选范围内的需求进行排序，并查看这些需求的交付过程和状态流转的细节，针对性分析影响效率的问题所在，寻求改善的抓手。
- 对在制品进行下钻
我们在做效能度量分析的时候，经常会按照固定周期（比如月度或季度）来统计效能数据、出具效能报告。但当每次看到效能报告中统计数据的时候，往往这个周期已经过去了。当我们根据上个周期的数据分析决定采取一些改进措施的时候，需要在下一个周期结束时才能进行效果验证，那么这就带来了一种延迟反馈。
其实，我们也可以采取一些更积极的、更及时的分析和干预方法。比如前文中提到的流负载（或在制品）指标就是一种先导性指标，流负载过高一定会导致后续的交付效率下降、交付周期变长，所以识别到这类问题就要进行及时干预。那么如何干预呢？可以使用一种称为滞留时长报告（Aging Report）的下钻分析方法。
工作项在交付管道中的停滞，会浪费交付过程中的宝贵时间。滞留时长报告显示了在交付管道中，没有完成的工作分别在当前状态滞留了多长时间。在下面这个案例中，我们首先可以看到左下角的流负载报表，它展示了在所选时间范围内（周/月/季），所选部门人均的在制品数量，并且可以进行上一周期和本周期的对比。从这个宏观数据出发，我们可以进一步下钻分析，比如下钻到所选部门的下一级部门、下两级部门、下三级部门的数据图表，最终钻取到具体的明细数据。这样我们就可以看到这些在制品的详细情况，它们目前分别处于什么样的阶段，在当前阶段已经滞留了多长时间。如果做得更好一些，可以计算出来工作项在每个阶段平均的滞留时长作为参考值，如果发现有些工作项滞留超过了平均时长，就需要特别进行，进一步分析是什么因素导致的阻塞，然后迅速采取行动，想办法恢复工作项的流动。
