工程质量改进方法论：PDCA、六西格玛、FMEA 实战指南

软件开发中经常遇到这样的问题：Bug 修了又出现，流程改了又乱，质量提升总是昙花一现。这些问题的根源往往不是技术能力不足，而是缺乏系统化的改进方法。

本文整理了工程管理中常用的质量改进方法论，包括 PDCA、5W1H、FMEA、六西格玛等。这些方法论虽然起源于制造业，但其核心思想同样适用于软件工程。

PDCA 循环：持续改进的基础框架

PDCA（Plan-Do-Check-Act）又称戴明环，是最基础的持续改进方法。它的核心思想是：改进不是一次性的，而是循环往复的过程。

常见误区

• 计划阶段敷衍：没有明确的目标和衡量标准，导致后续无法评估效果
• 跳过检查阶段：执行完就结束，不验证效果，改进变成形式主义
• 不进入下一轮循环：一次改进后停止，没有持续优化

5W1H 分析法：问题定义的利器

5W1H 是问题分析的基础工具，通过六个问题全面定义问题边界。

常见误区

• 停留在表面：只回答 What，不深入分析 Why
• 遗漏关键问题：忽略 When 和 Where，导致无法复现问题

FMEA：故障模式与影响分析

FMEA（Failure Modes and Effects Analysis）是一种预防性的风险分析方法，核心是在问题发生前识别潜在故障点。

FMEA 的核心是计算风险优先数（RPN）：

RPN = 严重性(S) × 发生频率(O) × 检测难度(D)

每个维度用 1-10 打分，RPN 越高，优先级越高。

常见误区

• 只关注高 RPN：低 RPN 的问题积累多了也会造成严重影响
• 评分标准不统一：不同人对同一问题打分差异大，需要团队对齐标准

六西格玛：数据驱动的质量改进

六西格玛的目标是将缺陷率控制在百万分之 3.4 以内。它的核心方法是 DMAIC：

常见误区

• 认为只适用于制造业：六西格玛的数据驱动思想完全适用于软件质量管理
• 忽视 Control 阶段：改进后不建立监控，问题很快复发

RCA：根本原因分析

RCA（Root Cause Analysis）的核心是「5 个为什么」——连续追问为什么，直到找到根本原因。

示例：线上服务宕机

1. 为什么宕机？→ 内存溢出
2. 为什么内存溢出？→ 对象没有被回收
3. 为什么没被回收？→ 存在内存泄漏
4. 为什么有内存泄漏？→ 连接池没有正确关闭
5. 为什么没正确关闭？→ 异常处理代码遗漏了 finally 块

根本原因：代码 review 不严格，异常处理规范缺失。

常见误区

• 停在表面原因：只问 1-2 个为什么就停止
• 归咎于人：根本原因应该指向流程和系统，而不是个人

方法论选择指南

总结

质量改进方法论的核心思想是相通的：

• 数据驱动：用数据说话，而不是凭感觉
• 根因分析：解决根本问题，而不是表面症状
• 持续改进：改进是循环往复的过程，不是一次性的
• 预防优于修复：在问题发生前识别风险

选择哪种方法论不重要，重要的是真正执行。一个被认真执行的简单方法，比一个被束之高阁的复杂方法有效得多。