DESIGN METHOD
权衡分析
TRADE-OFF ANALYSIS把“既要又要”的冲突转成明确优先级、边界和补偿。
什么时候该用，什么时候别用？
- 设计目标互相冲突
- 争论来自不同人优化不同指标
- 方案没有绝对赢家
- 所谓冲突可通过补信息或创新解除
- 用权衡掩盖未满足的硬门槛
权衡分析的具体操作步骤
按顺序完成；每一步都要留下可以复查的文字或证据。
- 01
列出冲突属性
将双方都写成有价值的目标，不把一方污名化。
提升 A 为什么会损害 B？
- 02
区分门槛与优化项
先设不可低于的底线，再讨论剩余空间的优先级。
哪些最低要求绝不能交换？
- 03
按场景选择位置
说明目标用户、使用频率、故障影响与生命周期。
在哪个场景更偏向哪一边？
- 04
设计补偿与复查
对牺牲项增加监控、冗余、文档或退出条件。
怎样控制被牺牲一侧的风险？
跟着一个例子完整走一遍
原始问题
新系统应追求开发速度还是架构扩展性？
- 1
硬门槛：数据合规和核心接口测试不能牺牲。
- 2
首批仅 3 个客户，需求仍快速变化，当前更偏向简单与速度。
- 3
领域边界和数据导出接口先稳定，内部实现保留替换空间。
- 4
当客户超过 20 个或出现第二种部署模式时复查架构。
得到的结论
团队没有抽象讨论“长期主义”，而是在当前场景选择位置并保留演进触发点。
复制后直接填写
第一次不用追求完美，先把空白处填出来，再根据证据修改。
冲突属性：A【】 vs B【】
硬门槛：【】
当前场景与优先方向：【】
接受的代价：【】
补偿机制：【】
复查触发条件：【】看似在用，其实容易用错
- 所有目标都标为最高优先级
- 只写选择，不写被牺牲的代价
- 没有随规模变化的复查条件