Appearance
Process处理层——结构化分析
结构化的本质
什么是结构化分析？
把混乱的信息，用逻辑组织成清晰的结构。
为什么需要结构化？因为人脑处理零散信息的能力很有限。
心理学研究表明，人的工作记忆只能同时处理7±2个信息块。如果信息是散乱的，很快就会超出处理能力。
但如果信息被组织成结构，就能处理更多：一个结构包含多个信息，一个大结构包含多个子结构。
结构化分析 = 用逻辑的方式组织信息，让大脑能够高效处理。
逻辑的三大基本规律
结构化分析的基础，是逻辑的三大基本规律。
同一律：A是A
在同一个讨论中，概念必须保持一致。
违反同一律的例子：
"我们讨论的性能优化，你说的是前端加载速度，
他说的是后端接口响应时间，
结果讨论了半天，说的根本不是同一件事。"应用：在分析之前，先确保关键概念的定义是一致的。
矛盾律：A不能同时是非A
两个相互矛盾的命题，不能同时为真。
违反矛盾律的例子：
"这个方案可行"（命题A）
"这个方案有致命缺陷"（命题非A）
→ 这两个不能同时成立应用：检查你的分析是否自相矛盾。
排中律：A或非A，必居其一
对于同一个问题，必须有明确的立场。
违反排中律的例子：
"这个方案可能可行，也可能不可行。"
→ 这不是结论，是在逃避判断应用：分析要有明确的结论，不能永远模糊。
MECE：结构化的核心原则
MECE是结构化分析最重要的原则。
ME = Mutually Exclusive（相互独立）CE = Collectively Exhaustive（完全穷尽）
相互独立（ME）
分类之间不能重叠。
❌ 错误分类：
- 前端问题
- 性能问题
- 网络问题
→ 前端问题和性能问题有重叠（前端也可能有性能问题）
✅ 正确分类：
- 前端问题
- 后端问题
- 网络问题
- 数据问题
→ 互不重叠逻辑基础：矛盾律——一个原因不能同时属于两个互斥的类别。
完全穷尽（CE）
分类要覆盖所有可能性。
❌ 不完全的分类：
- 前端问题
- 后端问题
→ 网络问题呢？数据问题呢？
✅ 完全的分类：
- 前端问题
- 后端问题
- 网络问题
- 数据问题
- 其他问题
→ 覆盖了所有可能逻辑基础：排中律——原因要么属于A，要么属于非A，必在其中。
MECE为什么有效
如果你的分类是MECE的：
- 相互独立 → 一个原因不会被重复计算
- 完全穷尽 → 真正的原因一定在某一类中
这就确保了你的分析不会重复，也不会遗漏。金字塔原理：结构化表达
金字塔原理是结构化思维的具体应用。
核心思想：结论在上，理由在下，形成金字塔结构。
┌─────────────┐
│ 结论 │
└──────┬──────┘
│
┌──────────┼──────────┐
│ │ │
┌───┴───┐ ┌────┴────┐ ┌───┴───┐
│ 理由1 │ │ 理由2 │ │ 理由3 │
└───┬───┘ └────┬────┘ └───┬───┘
│ │ │
支撑 支撑 支撑金字塔的四个特点
1. 结论先行
先说结论，再说理由。
❌ "首先，我分析了A，然后看了B，接着考虑了C，最后我认为..."
✅ "我认为应该选方案A。理由是..."2. 以上统下
上一层是下一层的概括。
结论：我们应该用Vue
├── 理由1：团队更熟悉
├── 理由2：生态能满足需求
└── 理由3：学习成本更低3. 归类分组
同一层的内容要属于同一类。
❌ 混乱的分组：
- 技术优势
- 团队意见
- 性能数据
- 老板喜欢
✅ 清晰的分组：
技术维度
- 性能数据
- 技术优势
组织维度
- 团队意见
- 老板偏好4. 逻辑递进
同一组内的内容要有逻辑顺序。
常见的逻辑顺序：
- 时间顺序：先...再...最后...
- 空间顺序：前端→后端→数据库
- 重要性顺序：最重要→次重要→一般
- 因果顺序：因为...所以...问题分解树
复杂问题需要拆解。问题分解树是常用的方法。
分解的三个方向
按流程分解：
页面加载慢的原因？
按流程：
├── DNS解析阶段
├── 建立连接阶段
├── 服务器处理阶段
├── 数据传输阶段
└── 页面渲染阶段按要素分解：
项目延期的原因？
按要素：
├── 人：人员能力、协作问题
├── 事：需求变更、技术难题
├── 资源：时间不够、人手不足
└── 流程：评审不充分、沟通不畅按层级分解：
系统稳定性问题？
按层级：
├── 基础设施层
├── 服务层
├── 应用层
└── 接入层分解的检验
分解完成后，用MECE检验：
□ 各部分不重叠（ME）
□ 各部分加起来等于整体（CE）因果关系的逻辑验证
分析问题时，经常需要判断因果关系。
因果vs相关
相关：A和B经常一起出现
因果：A导致了B
示例：
"每次加班后就出Bug" → 相关
"因为加班太累导致Bug" → 因果（需要验证）相关不等于因果。
验证因果的方法
方法一：时间先后
原因必须在结果之前。
"代码提交在Bug出现之前" → 可能是因果
"代码提交在Bug出现之后" → 不是因果方法二：排除其他可能
如果A是B的原因，那么：
- 没有A时，B不应该出现
- 有A时，B应该出现（或概率增加）方法三：找到机制
A怎么导致B的？机制是什么？
"加班 → 疲劳 → 注意力下降 → 漏看边界条件 → Bug"
有机制的因果更可信。5个为什么：追问根因
5个为什么是追问根本原因的工具。
基本用法
问题：页面加载超过5秒
为什么1：为什么加载超过5秒？
→ 因为首屏图片太大（10MB）
为什么2：为什么图片这么大？
→ 因为没有做压缩
为什么3：为什么没有做压缩？
→ 因为不知道要压缩
为什么4：为什么不知道？
→ 因为没有前端规范要求
为什么5：为什么没有规范？
→ 因为团队没有制定前端开发规范
根本原因：缺少前端开发规范注意事项
1. 不一定正好5次
可能3次就够，也可能需要7次。关键是追到可以采取行动的层面。
2. 可能有多个分支
问题：上线后出现Bug
为什么：测试没发现
├── 为什么测试没发现？ → 测试用例不完善
└── 为什么代码会有Bug？ → 开发对边界条件理解有误
可能有多个根因3. 避免变成指责
❌ "为什么你没做好？"→ "因为我不够认真"
这是在找人，不是找原因。
✅ "为什么这个问题没被发现？"→ "因为流程没有包含这个检查"
这是在找系统性原因。检查点：结构化分析检验
markdown
□ 概念一致（同一律）
- 关键概念有明确定义
- 讨论中保持一致
□ 没有矛盾（矛盾律）
- 结论之间不自相矛盾
- 理由和结论不矛盾
□ 有明确结论（排中律）
- 不是模糊的"可能是这样可能是那样"
- 有明确的判断
□ 分类是MECE的
- 各分类不重叠
- 各分类覆盖了全部可能
□ 结构是金字塔的
- 结论在上
- 理由支撑结论
- 同层归类分组
□ 因果关系经过验证
- 时间先后正确
- 排除了其他可能
- 有合理的机制实例演示
场景：分析"为什么这次上线出了事故"
结构化分析过程：
markdown
## 第一步：用5个为什么追问
问题：上线后用户无法下单
为什么1：为什么无法下单？
→ 因为下单接口返回500错误
为什么2：为什么返回500？
→ 因为后端代码有一个空指针异常
为什么3：为什么有空指针异常？
→ 因为某个字段在新版本是null，但代码没有处理
为什么4：为什么没有处理？
→ 因为开发不知道这个字段可能是null
为什么5：为什么不知道？
→ 因为接口文档没有更新
根因1：接口文档不完善
## 第二步：检查是否有其他原因
为什么测试没发现？
→ 因为测试环境数据都有值，没测到null的情况
→ 因为没有边界条件测试用例
根因2：测试用例不完善
## 第三步：用MECE组织分析结果
上线事故原因分析
├── 开发阶段
│ └── 代码没有处理null → 接口文档不完善
│
├── 测试阶段
│ └── 没有发现问题 → 测试用例不完善
│
└── 上线阶段
└── 没有灰度 → 上线流程不规范
## 第四步：形成结论
结论：这次事故的根本原因是流程不完善，包括：
1. 接口文档更新不及时
2. 测试用例缺少边界条件
3. 上线缺少灰度环节
改进建议：
1. 建立接口文档review机制
2. 增加边界条件测试要求
3. 强制执行灰度上线本章小结
核心观点：
- 结构化分析 = 用逻辑组织信息
- 逻辑三大规律：同一律、矛盾律、排中律
- MECE是结构化的核心原则
实操工具：
- 金字塔原理：结论先行，以上统下
- 问题分解树：按流程/要素/层级分解
- 5个为什么：追问根本原因
因果验证：
- 时间先后
- 排除其他可能
- 找到机制
检查点：
□ 概念一致
□ 没有矛盾
□ 有明确结论
□ 分类是MECE的
□ 结构是金字塔的
□ 因果关系经过验证下一章，我们讲决策——如何在分析的基础上，做出可靠的决策。