3. 质量保证实践：流程审计与过程监控
流程审计和过程监控，这两个词听起来挺正式。说白了，就是去看看大家是不是真的按规矩干活，以及干得怎么样。我见过很多团队，流程文档写得漂漂亮亮，墙上贴满流程图，但实际做起来完全是另一回事。
为什么会这样？因为没人去盯。流程不审计，等于废纸一张。今天我就聊聊，我在实战中是怎么做这件事的。
3.1 流程审计：不是找茬，是找盲区
我刚开始做质量保证那会儿，总觉得审计就是挑毛病。后来发现，团队其实很愿意改进，只是他们不知道自己的盲区在哪。审计的真正价值，是帮团队看到那些「不知道自己不知道」的问题。
我个人的习惯：每次审计前，先搞清楚三个东西——
- 这个流程的核心目标是什么？(不是为了流程而流程)
- 谁在执行？谁在依赖输出？
- 最近有没有发生过偏差或事故？
审计的四个步骤
- 制定审计计划：选流程、定范围、排优先级。不是所有流程都要审，先审那些风险高、变更频繁的。
- 准备检查清单：根据流程文档，列出关键节点和产出物。不要空手去问话。
- 现场访谈+抽样：找执行者聊，看实际记录，比对是否符合文档。我一般抽最近3个月的样本。
- 出具审计报告：发现的问题分等级——严重、一般、观察项。必须给出建议，不能只列问题。
小技巧：审计时别只坐办公室看文件。去生产现场、去测试机房、去代码检视会议旁观一会。纸上流程和实际流程之间，往往差着一整个沟通黑洞。
3.2 过程监控：用数据说话，别靠感觉
审计是间歇性的，过程监控是持续性的。我个人更看重监控，因为它能提前预警。
我遇到过的一个案例：一家硬件厂商，以前靠每周开会汇报进度，结果总是到了节点前才发现延期。后来我帮他们搭了一套监控面板，每天自动抓取关键指标——代码提交频率、测试通过率、缺陷引入率。不到两周，团队就发现了代码合并的瓶颈，直接改了分支策略。
过程监控不是把所有数据堆在Dashboard上，而是选对指标。我一般关注三类：
| 指标类型 | 例子 | 监控频率 |
|---|---|---|
| 交付效率 | 需求平均交付周期、构建时间 | 每日 |
| 质量水平 | 缺陷密度、回归通过率 | 每次发布前 |
| 过程合规 | 评审参与率、变更审批时长 | 每周 |
3.3 流程审计与过程监控的关系
这两件事不是二选一，而是互补的。流程审计发现问题根源，过程监控防止问题复发。下面这张图是我常用的框架：
3.4 实战中的常见坑
避坑指南（我曾经踩过的）：
1. 审计前没对齐标准，结果审出来一堆不是问题的问题。
2. 监控指标太多，团队看着仪表盘眼花缭乱，反而忽略了真正的异常。
3. 光审不改——审计报告写完，没人跟踪整改，下次审计同样问题又出现。
1. 审计前没对齐标准，结果审出来一堆不是问题的问题。
2. 监控指标太多，团队看着仪表盘眼花缭乱，反而忽略了真正的异常。
3. 光审不改——审计报告写完，没人跟踪整改，下次审计同样问题又出现。
一个实际工具配置示例
我常用一个脚本来自动化收集过程监控数据。比如检查构建频率和测试通过率：
#!/bin/bash
# 过程监控数据采集示例
# 输出CSV格式：日期,构建次数,通过率,平均时长(min)
echo "date,builds,pass_rate,avg_duration"
# 假设有构建日志文件 /var/log/builds.log
awk '$1 ~ /^[0-9]{4}-/ {date=$1; builds[$1]++; if($5=="PASS") pass[$1]++; total_time[$1]+=$6}
END {for(d in builds) printf "%s,%d,%.2f,%.1f\n", d, builds[d], (pass[d]/builds[d])*100, total_time[d]/builds[d]}' /var/log/builds.log
这个脚本跑完，数据直接导入到监控面板，一旦通过率低于90%，系统会自动发邮件提醒。嗯，这比人工盯报表靠谱多了。
3.5 你该从今天开始做什么
- 挑一个你负责的流程，看看它最近的执行记录。如果发现有偏差，别骂人，先问为什么。
- 选两个过程指标，搭个最简单的监控：一个关于效率，一个关于质量。用Excel也行。
- 下个审计周期，试试把审计发现项按「源头—现象—根因」三层分解。你会发现很多问题根源是一样的。
一句话总结：流程审计让你看到「纸面」和「地面」的差距，过程监控帮你保持两者一直对齐。缺一个，质量保证就是空谈。
我记得有一次，一个团队花了一个月做流程文档，但从来没人去审。后来我一查，实际做法和文档差了十万八千里。这就是典型的「两张皮」。流程审计和过程监控，就是专门治这个病的。