05 软件工程综合实践：定义一个真实工程问题

TL;DR：本篇用一个完整案例串起全专栏方法——为“交付周期变长”定义一个可操作的问题。流程：5W2H 检查完整性 → MECE 分解定位瓶颈 → 问题陈述卡（不预设方案）→ 利益相关者地图与边界声明 → 可证伪条件。最终产出是一页“问题定义记录”，让未参与者能理解一致、能指出薄弱点、能据此启动因果分析和决策流程。

概念解释

为什么要专门练习“定义问题”

大多数团队的瓶颈不在分析能力，而在问题定义——看到“交付变慢”就冲向“加人/催评审/上工具”，不检查到底慢在哪、是不是真正的问题、谁受影响。本篇把 5W2H、MECE、问题陈述卡和利益相关者地图串成一个端到端流程，产出一个可被审阅的问题定义。

与其他专栏综合实践的衔接

软件工程综合实践：做一次可复盘的技术选型（决策与权衡专栏）串起“决策前”的全流程。本篇串起“决策前更前面”的一步——在选方案之前，先把问题定义清楚。两篇合起来构成“定义问题→选择方案”的完整前端。

目录

案例与系统边界

某团队首次提交到生产的中位周期由 4 天增至 12 天。朴素反应：“加人/催评审”。按本专栏方法，先定义问题：5W2H 检查完整性 → MECE 分解定位瓶颈 → 写不预设方案的问题陈述 → 画利益相关者地图和边界。

串起全流程

串联逻辑：5W2H（①）检查完整 → MECE（②）定位瓶颈 → 陈述卡（③）不预设方案 → 利益相关者（④）补人 → 边界（⑤）定范围 → 可证伪（⑥）留修正钩子。如果 ② 发现瓶颈不在评审而在测试，③ 的问题陈述需要修正——这就是“问题定义可被修正”的实际运作。

一页问题定义记录

验收标准

问题定义是否到位，看四件事：

1. 多人一致理解：未参与者读完理解与参与者一致。
2. 不预设方案：问题陈述让多个方案可以竞争。
3. 边界和利益相关者完整：三类角色都列出、边界外有触发条件。
4. 可证伪：写了什么证据出现时修正定义。

满足四条才算“定义到位”；只满足“写了文档”，仍属“看到现象就冲向方案”。

适用边界

• 不是所有问题都需要完整定义流程：简单 bug 直接修。完整定义留给跨团队、多方案竞争或反复出现的问题。
• 定义不替代分析：定义清楚后，根因仍需 因果分析与根因分析，方案仍需 决策矩阵与权衡：在多目标下显式取舍。
• 定义可被修正：随着分析深入，可能发现瓶颈不在预想的地方——修正陈述而非捍卫原定义。

关联笔记

• 问题定义总览：从现象到问题陈述（三层结构与五条判断标准）
• 5W2H：检查完整性的工具（检查描述完整性）
• MECE：互斥穷尽的分解原则（检查分解完整性）
• 问题陈述：把现象转化为可操作的定义（问题陈述卡模板）
• 利益相关者与边界：谁受影响、谁有事实、谁能决策（利益相关者地图）
• 软件工程综合实践：验证一次改进是否有效（因果与证据专栏综合实践，本篇是其上游）

参考资料

• What is Problem Solving? — ASQ
• 5W2H — AHRQ Digital Healthcare Research
• The Minto Pyramid Principle — Barbara Minto
• Are You Solving the Right Problems? — MIT Sloan Management Review
• Systems Thinking — SEBoK