为了准确的评估产品在市场、用户侧的落地效果，企业往往会为产品建立相对完善的问题收集处理机制。发布后问题（有的时候也称为线上问题）是软件产品质量的一个重要度量项。通过对发布后问题的收集、分析，一方面可以更清晰的了解产品发布后的质量表现，另一个方面也可以促进企业前后端组织的协同和工作流程的优化。
一般来说，我们会从发布后问题的数量上来看待一个产品发布后的质量表现，但这并不客观且无法横向对比几个产品的质量表现。比如说A产品交付给了十家客户1月份总共出现了20个发布后问题；B产品交付给了100家客户，1月份总共出现了50个发布后问题。很显然，我们是不能用发布后问题的数量这个指标来说A的产品质量要好于B产品，因为单位客户情况下B产品的发布后问题数量明显小于A产品。但这就能说明B产品质量好于A产品吗？也不一定。比如：A产品的研发复杂度也许更高，在售后服务体系一致的情况下质量问题跟复杂度成正比；B产品交付过程中保障措施更完备、服务很到位使得问题暴露的几率大大降低。
因此，我们引入了“发布后问题密度”这个指标。这个指标的计算方式为：
发布后问题密度 = 发布后问题数量/产品规模
这个公式不难理解，难的是要搞清楚什么是产品规模，以及产品规模怎么核算。在讨论如何定义和核算产品规模之前，我们需要理解一个概念，即无论怎么定义以及核算产品规模都无法精准的算出发布后问题密度，而且这个精准度的提升也会导致整个度量成本的大幅提升。减少发布后问题的产生，是多方面单位产出的保障，同样的产品，多方面单位投入的规模越大，出现问题的几率越低（注意，这是几率事件，不要拿极端情况来说）。我们把产品从设计到研发，从研发到发布、交付到客户使用各个环节的投入加到一起作为产品规模，不仅仅是人的投入，也包含“物”的投入。比如有的客户为了系统更稳健采购了硬负载，为了系统安全采购了大量网安设备。按照上面说的公式，我们可以得到一个单位投入下发布后问题数量作为问题密度。这种算法是否可信可靠呢？显然不靠谱，因为核算太复杂了。“发布后问题密度”指标看上去很美好，但可操作性很低。
有朋友会问，我只比较某个产品这个月比上个月发布后的质量，是不是就不需要“发布后问题密度”这个指标了，直接看问题数量是不是就行了？我只能说除非你的销售数量一直不变并且你的产品已经处于基本的运维期了。
回归本质，发布后问题的收集和分析并不是为了做产品间的质量对比，而是为了推进产品质量优化以及改进工作流程。那么发布后问题的哪些指标更有价值呢？比如问题响应时长、处理时长、验证时长、生命周期时长。指标之外，对发布后问题的分析、复盘、解决措施固化到工作流程比度量本身更为重要。
我们关于问题生命周期的几个定义可供参考：
问题生命周期：问题从提出到关闭的整个周期。用于度量产研-交付团队对于问题的整体处理效率。如果大量问题生命周期过长，则说明从交付到产研的协作中可能存在效率问题。
问题响应时长：问题从记录到开始解决的时长。
问题解决时长：问题从开始解决到提交验证的时长。用于度量产研团队问题处理效率，如果问题解决时长很高，则说明可能存在效能问题或人力不足等问题。
问题验证时长：问题从提交验证到关闭。用于度量问题验证效率。
源自公众号 爱测未来