质量阀评审那些事儿

各位PM、系统工程师、开发乃至测试们，当年或现在有没有被里程碑质量阀评审折磨得痛不欲生……

“几个不懂技术、不懂产品、不懂业务的，在那巴巴地问个不停，查什么文档，看什么evidence，是不是还得把现场录像给你啊，都是些理论派、务虚派，我们在前面冲锋陷阵，你们手叉着腰、指手画脚，不但不帮忙，反而来添堵……”是不是气不打一处来。

为什么我这么有感触？因为我曾经也被这么折磨过。不过呢，我最后还是成为了自己最讨厌的人。作为曾经的乙方项目经理和现在的甲方质量，来讲讲这个事儿。

质量阀评审，本质还是个评审，只不过是个大的评审，是针对这个里程碑该完成的事情的评审，并且具有一定的强制性，会影响到是否开阀，也就是项目能否进入下一个阶段，这也是为什么项目团队，尤其是Project Manager们深恶痛绝的原因。

在展开之前，我们先讨论下“评审”。

最简单的问题，为什么要评审？

评审的根因是“问题”不可避免，评审的目标也是找“问题”。而且，由于错误存在的时间越久，带来的影响越大，所以评审越早越好、越多越好。

那么，评审什么呢？

我们可以从项目管理、技术、文档、法规、流程符合性等不同层面进行，但实际的落脚点在“交付物”，就是对于前面这些东西，你都交付了什么，要查看的东西必须得可见，空口无凭，换句话就是，有没有什么Evidence啊，你怎么证明你做了呢，相应的质量保证工作做了没有（如内部评审和测试）……最常见的是文档，也可以是直接看代码、邮件附件、展示系统等等。

知道了Why和What，接下来是How，怎么评审？

我总结的是，Checklist和个人能力。Checklist是几乎每一个正式的、大的评审不可或缺的工具，可以对着条目一条条看；而个人能力是决定评审质量的关键因素，你得有经验和知识，你得知道正确的、完整的做事方式是什么，哪里最容易出问题，哪里是痛点和难点，哪里最容易投机取巧……否则也是Hold不住的。

其实，讲完了评审，里程碑质量阀评审也跳脱不出这个框架。

如果再针对性地看细节的话，可以看两个维度。

一、过几个？二、过什么？

一般来说，一个组织针对某类产品开发的阶段和产品的成熟度会设置n个里程碑，比如，CV&DV&PV、ABCD样件、需求&架构&设计&测试等，再针对相对重要的里程碑在其前后设置n-m个质量阀，再根据具体项目级别裁剪到n-m-k个，这n-m-k就是要经过评审才能过的阀，这个在裁剪那篇文章讲过一些，这里就不扩展了。

对于过什么，评审那个部分概要地讲了下，但还是不直观，这里再给出几个具体的问题感受一下。毕竟，评审的主要模式也是问答。

1. 项目整体立项背景是怎么样的？这次的交付目的是什么？开发Base是什么？变更范围多大？

2. 软件交付计划是什么？是否更新到最新状态？下一阶段交付什么成熟度的软件？是否有依赖其他项目或模块的？所有的里程碑都是经过align并且可行的？

3. 内部质量阀是否通过？

4. 当前有多少条开口项&任务&Bug？Due date什么时候？是否超期？是否有责任人？

5. 变更管理如何进行的？针对本次变更是否有CCB评审？

6. 配置管理的模式是怎么样的？配置项如何定义的？每个配置项是否经过评审？当前是否打了基线？

7. 风险管理如何进行的？什么级别的风险？是否有解决不了的？解决不了的风险的上升机制是什么？

8. 目标市场是什么？出口限制是否澄清？区域认证是否需要？还有什么法规风险？

9. 功能安全和信息安全相关活动是否进行？是否得到审批？

10. Feature Plan里承诺哪些功能？

11. 所有的客户需求是否都澄清？是否有不清楚的或拒绝的需求及如何进行澄清和达成一致的？不清楚的需求会给交付目标带来什么风险？共有多少条客户需求？是否有需求报告？实现了多少？是否评审？是否打基线？客户原始需求文档如何管理？

12. 系统&软件需求是否进行分析拆解？是否包含功能需求、性能需求、接口需求、诊断需求等？如何进行相应的追溯？

13. 系统&软件架构设计是否完成并被评审？系统架构是否包含系统框图、功能分配、接口定义等？软件架构是否包含模块划分、动态行为设计、接口信号、任务调度、内存划分、休眠唤醒策略等？如何进行相应的追溯？

14. 软件详细设计是怎么进行的？

15. 是否有测试计划？测试是否均完成？如何确保都完成并都经过了评审？多少条测试用例？系统测试、系统集成测试、软件需求测试、软件集成测试、软件单元测试和静态代码分析的详细做法是怎样的？复用分析是怎么做的？Fail项的分析如何进行的？是否通知到客户？

16. 如何保证任务下发时的输入完整性和准确性，如软件集成？

17. 是否可以找一条有完成V链路的需求？

……

在一系列问题后，一般会根据满足的程度用绿色、黄色及红色来定义质量水平，进而可基于此做出开阀与否的决定。

以上随机列了一些评审可能会问到的问题，不会很完整，实际项目中，基于产品类型和项目特点，公司流程的成熟度（大型公司的成熟产品，质量保证的很多工作都会融入到开发流程里，质量阀评审检查的点会少很多，比如，只是查一下职能部门签字等）以及评审者的经验，会有不同的侧重点，问题也会千奇百怪。

当然，更实际的是，怎么审还要看评审者和被评审者的地位差异，比如，质量有没有签字放行权，公司高层是否重视质量，某个领导对本项目是否会有特别考虑……或者弱势甲方对强势乙方的评审，现场可能会出现的是什么呢？来不及，改不了，保密，加钱……你能奈我何？

所以说，这些事儿里有技术、有知识、有逻辑，还有商业和政治。