决策框架
为什么需要决策框架
技术决策直接影响项目成败。没有框架的决策往往缺乏客观依据、难以说服团队、无法复盘。
决策框架的价值：
- 多维度评估，避免片面
- 量化对比，减少主观性
- 记录依据，可追溯优化
- 逻辑清晰，易于沟通
评估矩阵方法
通过多维度量化对比方案，核心步骤：确定维度 → 设置权重 → 评分 → 计算加权总分。
实战案例：React vs Vue 选型
场景：中型电商项目，团队 5 人。
| 维度 | 权重 | React | Vue |
|---|---|---|---|
| 团队熟悉度 | 25% | 4 | 3 |
| 生态丰富度 | 20% | 5 | 4 |
| 学习曲线 | 15% | 3 | 5 |
| TypeScript | 10% | 5 | 4 |
| 加权总分 | 100% | 4.15 | 3.95 |
决策：选择 React
- 团队熟悉度是最大权重维度
- 生态和 TypeScript 支持更好
- 虽然学习曲线陡，但可以带新人
权衡取舍方法
决策的本质是在约束条件下做取舍。原则：明确优先级、识别约束、评估代价、寻找平衡点。
实战案例：内部系统性能 vs 开发效率
场景：内部管理系统，50 人使用，1 周内上线，2 个前端。
| 方案 | 优点 | 缺点 | 适用性 |
|---|---|---|---|
| A. 极致优化 | 体验好 | 多 2 周，复杂度高 | ❌ 时间不允许 |
| B. 快速开发 | 1 周上线，易维护 | 首屏慢 1-2s | ✅ 符合约束 |
决策：选择方案 B
- 内部系统容忍度高，数据量小
- 时间紧迫，可后续优化
- 取舍：牺牲极致性能，换取快速上线
风险评估方法
识别风险 → 评估影响 → 制定预案。
实战案例：微前端架构改造
风险矩阵
| 风险 | 概率 | 影响 | 等级 | 应对 |
|---|---|---|---|---|
| 性能下降 | 高 | 中 | 🔴 高 | 预加载、缓存策略 |
| 团队学习成本 | 中 | 中 | 🟡 中 | 培训、文档 |
| 子应用冲突 | 低 | 高 | 🟡 中 | 沙箱隔离 |
决策：分阶段实施
- 先改造 1 个非核心模块验证
- 建立性能监控
- 准备回滚方案
完整决策流程
1. 明确目标
定义清晰的目标和约束条件。
好的目标：
- 具体：提升首屏加载速度到 2s 内
- 可衡量：错误率降低到 0.1%
- 有时限：3 个月内完成
2. 列出选项
至少 3 个方案，包括"不做"。
3. 评估对比
使用评估矩阵，关键维度：效果、成本、风险、可行性。
4. 做出决策
综合评估，记录依据。不追求完美，追求最合适。
5. 执行验证
制定计划、设置指标、定期检查、根据反馈调整。
实战案例：是否引入微前端
背景
5 个前端项目，技术栈不统一（React、Vue、Angular），维护成本高。
目标：统一入口，降低维护成本，支持独立部署。 约束：3 个月内完成，不影响现有业务。
方案对比
| 方案 | 优点 | 缺点 | 周期 |
|---|---|---|---|
| A. 全部重写 | 技术栈统一 | 风险大 | 6 个月 |
| B. 微前端 | 保留代码，独立部署 | 学习成本 | 3 个月 |
| C. iframe | 实现简单 | 体验差 | 1 个月 |
| D. 保持现状 | 无风险 | 问题依旧 | - |
评估矩阵
| 维度 | 权重 | A.重写 | B.微前端 | C.iframe | D.现状 |
|---|---|---|---|---|---|
| 开发成本 | 25% | 1 | 3 | 5 | 5 |
| 时间周期 | 20% | 1 | 4 | 5 | 5 |
| 用户体验 | 20% | 5 | 4 | 2 | 3 |
| 技术风险 | 15% | 2 | 3 | 4 | 5 |
| 总分 | 100% | 2.65 | 3.75 | 3.75 | 3.85 |
决策
选择方案 B（微前端）
理由：
- 在时间约束内可完成
- 保留现有代码，风险可控
- 支持独立开发部署
- 学习成本可通过培训解决
执行计划
阶段 1（1 个月）：技术验证
- 选 1 个非核心模块试点
- 团队培训
- 建立开发规范
阶段 2（1.5 个月）：核心模块改造
- 改造 2-3 个核心模块
- 性能监控和优化
- 完善文档
阶段 3（0.5 个月）：全面推广
- 剩余模块接入
- 上线验证
- 复盘总结
验证指标：
- 性能：LCP < 2.5s
- 稳定性：错误率 < 0.1%
- 效率：开发效率不降低
决策复盘
决策后要复盘，持续优化。
复盘框架
1. 回顾目标
- 当初的目标是什么？
- 是否达成？
2. 分析过程
- 决策依据是否充分？
- 评估是否全面？
- 有没有遗漏的因素？
3. 评估结果
- 实际效果如何？
- 与预期的差距？
- 出现了哪些意外？
4. 总结经验
- 做对了什么？
- 做错了什么？
- 下次如何改进？
复盘案例：微前端改造
目标回顾：
- ✅ 统一入口（已完成）
- ✅ 独立部署（已实现）
- ⚠️ 降低维护成本（部分达成，通信复杂度增加）
过程分析：
- ✅ 评估维度全面
- ❌ 低估了通信复杂度
- ❌ 性能优化投入不足
结果评估：
- 性能：LCP 2.8s（未达标）
- 稳定性：错误率 0.05%（达标）
- 效率：开发效率降低 10%（可接受）
经验总结：
- 做对：分阶段实施，风险可控
- 做错：性能优化准备不足
- 改进：下次要提前做性能预研
常见决策陷阱
1. 锚定效应
被第一印象影响，忽略其他信息。
案例：听说 Vite 快，就直接选 Vite，没考虑生态和团队熟悉度。
避免：先列出所有维度，再评估。
2. 确认偏误
只看支持自己观点的信息，忽略反对的。
案例：想用新技术，只看优点，忽略风险。
避免：主动寻找反对意见，做魔鬼代言人。
3. 沉没成本
因为已经投入，不愿放弃错误决策。
案例：重构已经做了 2 个月，发现方向错了，但不愿停止。
避免：关注未来收益，不看过去投入。
4. 过度自信
高估自己的判断能力。
案例：觉得自己经验丰富，不做详细评估。
避免：用数据说话，多听团队意见。
不同场景的决策策略
小决策（组件选择）
- 快速决策，不要过度分析
- 可以试错，成本低
中决策（技术选型）
- 使用评估矩阵
- 考虑 5-8 个维度
- 团队讨论，达成共识
大决策（架构重构）
- 完整的决策流程
- 详细的风险分析
- 制定执行计划和验证指标
- 定期复盘
提升决策能力
- 多实践：每次决策都用框架
- 多复盘：记录决策过程和结果
- 多学习：看别人怎么做决策
- 多思考：为什么这样决策？有没有更好的方法？
面试准备
准备 3-5 个决策案例：
- 技术选型（React vs Vue）
- 架构设计（微前端、SSR）
- 性能优化（权衡取舍）
- 重构决策（风险控制）
每个案例准备：
- 背景和目标
- 评估过程
- 决策理由
- 执行效果
- 经验教训
记住：好的决策不是选最好的方案，而是在约束条件下选最合适的方案。