芯片问题这么多，到底是谁的锅？透过问题单看芯片的质量管理

很多小公司或者小团队，都通过excel或者口头来沟通需求变更或者bug修改。带来的效果，就是大家都觉管理很乱，但是好像又没有谁能指出问题的根源。

本文介绍一下通过一些问题单的要素信息，可以分析出哪些芯片开发过程中的质量问题或者风险。

通过递进式的展示不通的问题单信息汇总，来由浅入深的展示问题单对于芯片研发质量的作用。

1、狂野型的统计方式

先来看一下最简单的问题单统计结果——只统计问题模块和问题数量。

我们以一组问题单数据统计示例展开聊聊，只统计这些信息够用不？

项目复盘时，只能知道模块发现了多少问题。但是，这全是开发的问题吗？设计人员首先回一个表情：我不信。

2、增加问题单发现的领域

把问题单按照提交的领域划分，从中可以看出，验证和设计各自的贡献情况。

模块C的设计人员一骑绝尘，居然发现的问题比验证都多。是不是验证可以靠边站了。哈哈。那么，我们给问题单再增加一些维度，再来深挖一下这个现象的真相。

某个模块验证提交的问题多，往往此模块收敛周期比较长，会成为项目交付的关键路径——拖延项目的交付周期。

3、增加问题来源的分类

问题单来源的主因：

1. 模块A是RTL缺陷。
2. 模块B是算法错误和RTL缺陷。
3. 模块C是需求和算法优化。

我们可以分析出一些初步的结论：

1. 模块B和C，虽然问题单一样多，但是B设计人员的出错率较高。
2. B模块的算法不够稳定，影响了整体收敛速度。
3. C模块的需求不稳定，影响了验证收敛速度。通常情况下，验证过程中需求问题，带来的影响比较大。这里算法的优化问题单，通常很大程度上是因为需求修改引入算法变更，算法需要一定时间的理解消化和测试。
4. 模块虽然有需求变更，可能是小修改，需求也比较明确。

4、细化缺陷类型

问题单，还可以继续细化问题类型。以设计方面的为例（设计表示很怨），还可以做如下细分：

1. 设计方案错误
2. 设计功能实现错误
3. 连线错误
4. 笔误

有了这些维度，可以更加全面的看到设计人员在哪些方面出现问题比较多。后续的质量活动更加有针对性——发现问题多的地方，是否还存在盲点？历代项目问题多的地方，但是发现问题少，是否验证不够充分？

5、从时间维度看问题单

通过复盘问题单爆发的时间过程，可以看到问题收敛耗时的主因。可以为下次项目提供借鉴意义。

可以看到第4周和第10周分别达到了问题单两个峰值。

通常情况下，第4周出现峰值，都是因为初步测试典型配置；后面还会有一个小高峰。但是第二个高峰基本上和第一个持平，这个也有异常。

因为案例中后期，需求变更比较多，对问题单也有贡献，对应的项目收敛周期拉长。这样来看，第二个高峰也比较合理了。项目收敛后面的小拖尾，很可能和需求变更有一点的关系。

6、不同项目的问题单分析

对于迭代开发的项目，问题单的借鉴意义会更大一些。

相同的人力、周期、需求和代码修改，问题单的增加和收敛曲线，往往也是相似。这也可以从另一个侧面来说明，制定的交付计划是否可行。

7、结束语

上述案例中的数据虽然比较粗糙，但是能有一定的代表性。问题单的数据分析，是客观的，一定程度上减少了主观因素。

通过设计合理的问题单信息，可以有效帮助项目复盘，从而改善下一次项目的质量管理。也能识别到团队自身存在的问题和长处。