精准排查故障响应慢的项目

从收到缺陷报告或线上事故警报开始，到问题解决，需要多长时间？迟迟无法解决的故障会损害用户使用体验，公司的业务也可能因此蒙受损失。

DevInsight 提供事故/缺陷密度和响应时间的跨项目对比，帮助研发团队筛选出问题多、修复难度大的项目，进一步结合项目属性和历史趋势分析原因。

下钻定位难以修复的故障

研发团队需要在故障修复上投入多少工作量？这一指标说明了代码的可维护性。

DevInsight 用箱线图直观展示修复工作量的分布。图中的异常点代表缺陷/事故的需要需要大量编码工作，可能反映该缺陷波及面较广，建议补充注释和测试，拆分复杂函数；图中的箱体则代表该项目中故障修复的普遍工作量，如果箱体偏高，可能反映该项目未能达到高内聚低耦合，常常导致联动修改。

度量“救火”负荷，为新特性开发争取宝贵时间

研发团队在故障修复上投入的工作量，在总工作量中占比多少？这一指标说明了研发人力成本在不同类型事务上的分布情况。

如果占比偏高，则团队可能正在“焦油坑”中挣扎——大量时间被紧急的事故/缺陷挤占，团队成员忙着救火，新特性新功能的交付只能一再拖延。

研发团队可以针对修复工作量占比异常偏高的项目进行复盘，并采取“质量改进月”等实践，帮助研发团队减轻技术债包袱，轻装上阵。

‍