一次让我印象深刻的审核对话
几年前的一次软件企业审核现场，我旁听了一位审核员和项目经理的对话：
> 审核员：”你们的设计输出有哪些记录？
> 项目经理：”有产品需求规格说明书、概要设计文档、详细设计文档、评审记录……都在SVN里。
> 审核员翻了翻文档目录：”有文档有评审，好，符合。
我在旁边没说话。因为我刚看过这家企业的 Git 仓库——主分支上每天十几个提交、没有MR审查、没有自动化测试覆盖、版本号混乱、代码注释和需求描述对不上。
文档都写了，代码是乱的。但那位审核员只看了文档，没看代码。
这件事让我一直在想一个问题：ISO 9001 8.3.5 的”设计输出”，真的只是文档吗？
8.3.5 到底在要求什么
再读一遍标准原文。8.3.5 要求设计输出应：
> a) 满足输入要求；
> b) 满足后续产品和服务提供过程的需要；
> c) 包括或引用监视和测量的要求，适当时，包括验收准则；
> d) 规定产品和服务特性，这些特性对于预期目的、安全和正常提供是必需的。
标准没说输出必须是 Word 文档。它要求的是”满足输入要求”和”规定特性”。对于软件产品，代码本身就是设计输出最核心的载体。
需求规格说明书写得再厚，代码没实现，等于没做。设计文档画得再漂亮，代码里没有对应逻辑，都是废纸。
但多数审核员看不懂代码，所以天然绕开了这个”最高质量的设计输出”，退而求其次只看文档。这一绕，就把真正的质量风险绕过去了。
一个真实案例：KCP 落地前后
我在中兴网信负责研发质量管控时，面对的是这样一组数据：
- 需求变更随意，一个版本迭代中间改三次，没有追溯
- 版本发布靠人工”拍脑袋”，上线后故障频发
- 年度客户满意度只有 84%
后来我们做了三件事：
第一件事：建需求变更审批流程。
三级变更审批——紧急、一般、重大，各有不同的审批链路和准入准出标准。变更前必须关联需求 ID，变更后更新追溯矩阵。半年后，需求变更合规率从 82% 升到 98%。
核心做法不是加文档，而是把变更写进流程和工具里——需求管理系统里改字段，不经过审批流程连改都改不了。
第二件事：卡版本发布节点。
每个版本发布前必须走完五个步骤：
- 系统测试全部通过
- 遗留问题逐条评估
- 回滚预案就位
- 版本基线锁定
- 发布审批签字
一年后，现场版本故障率从 12% 降到 3%。
第三件事：输出质量度量看板。
每个季度出一份《自研产品质量度量看板》，不是给老板看的装饰品，而是每项指标都对应一个改进动作。谁的数据拖后腿，谁在下个季度认领改进。
三年后，用户满意度从 84% 升到 96%。
这些改善没有靠”多写文档”实现，靠的是在研发流程的关键节点设卡，用工具和数据说话。
审核8.3.5的实操建议
我不要求审核员学会写代码，但建议多问几个问题：
1. 问代码评审
“你们的代码评审是怎么做的？走形式还是真的有人逐行看？”
没有代码评审的系统，如同没有质检的产线。MR/PR¹ 的记录数量、reviewer 人数、通过率¹MR（Merge Request，合并请求，GitLab 平台叫法）和 PR（Pull Request，拉取请求，GitHub 平台叫法）是同一个概念，指开发提交代码后发起同行审查的机制。 的记录数量、reviewer 人数、通过率——这些数据比一份”设计评审报告”更能反映真实质量。
2. 问测试覆盖
“你们的单元测试覆盖率是多少？集成测试是谁做的？”
8.3.5(b) 要求的”满足后续服务提供过程的需要”，测试覆盖是最直接的证据。覆盖率低于 60% 还号称做了充分测试的，基本在撒谎。
3. 问版本基线
“你们怎么保证发布的版本和测试的版本是同一个？”
没有基线管理，文档写得再规范也没用。版本号规范、变更记录、回滚机制——这三样缺一个，发布就是碰运气。
4. 问需求追溯
“每个代码提交关联了需求 ID 吗？”
需求变来变去，代码改来改去，但没有可追溯的记录，所谓的”满足输入要求”就是一句空话。
结语
我不是否定文档的价值。文档在体系审核中有不可替代的作用——它是沟通的载体、培训的素材、审计的证据。
但我要说的是：对于软件企业，代码是最高质量的设计输出。8.3.5 的审核不能只看文件夹，要去 Git 仓库看一眼。
了解研发流程、看懂评审记录、追踪变更闭环——这些能力决定了做的是”符合性审核”还是”深度诊断型审核”。
懂软件研发的审核员，和不了解的审核员，面对同一家企业，看到的完全是两个世界。
