TL;DR：问题定义是七阶段闭环里最容易被跳过的阶段——团队看到现象就冲向方案，不检查"我们解决的到底是不是真正的问题”。问题定义的核心是把模糊的现象转化为可操作的问题陈述：明确目标（想要什么）、现状（当前在哪）、差距（差什么）、边界（不解决什么）。
2026-08-26
TL;DR：5W2H 用七个问题检查一个问题描述或行动计划是否完整，但它只能暴露缺口、不能发现根因或比较方案。5W2H 最常见误用是把它当成根因分析工具——它的 是“为何重要或为何这样做”，不等同于 5 Whys 的连续追问。
2026-08-26
TL;DR：MECE（Mutually Exclusive, Collectively Exhaustive）是麦肯锡提出的分解原则：每个层级的子项不重叠、合起来覆盖全部。MECE 不是一个工具而是一个检查标准——它告诉你分解是否合格，但不告诉你怎么分解。
2026-08-26
TL;DR：问题陈述是把模糊现象转化为可操作定义的产物。一份合格的问题陈述包含四个要素：目标状态、当前状态、量化差距、不预设方案。最常见的问题是“把方案藏在问题里”——“我们需要增加 Redis”不是问题陈述，是方案。“如何将读延迟从 200ms 降到 50ms 且不增加超卖风险”才是问题陈述。
2026-08-26
TL;DR：边界不是客观世界中等待被圈出的盒子，而是观察者为某个决策做的判断——把它视为事实会漏掉被外部化的成本。利益相关者地图回答三个问题：谁受影响、谁掌握事实、谁有权决策。这三个角色经常不是同一群人。定义问题时最常犯的边界错误是“把依赖团队和用户当作外部”，导致局部方案把成本转移到了边界外。
2026-08-26
TL;DR：本篇用一个完整案例串起全专栏方法——为“交付周期变长”定义一个可操作的问题。流程：5W2H 检查完整性 → MECE 分解定位瓶颈 → 问题陈述卡（不预设方案）→ 利益相关者地图与边界声明 → 可证伪条件。最终产出是一页“问题定义记录”，让未参与者能理解一致、能指出薄弱点、能据此启动因果分析和决策流程。
2026-08-26