综合案例：OTC 衍生品交易系统

预计时间：35 分钟读完 + 30 分钟做练习 = 65 分钟。

一、第一性原理（Lesson 0001）

问题：OTC 衍生品交易系统的「第一性原理」是什么？它不是「用微服务」或「用 React」——而是：

• 交易指令的准确传递和执行
• 风险的实时监控和预警
• 交易数据的完整记录和对账

应用：当团队争论技术栈时——回到第一性原理。团队在「用 Java 还是 Go」上吵了 2 周——从第一性原理看，核心需求是「可靠的消息传递 + 低延迟的报价计算」——两种语言都能实现，吵 2 周的成本远高于选其中一种的成本。回到第一性原理 → 快速决策。

二、反转（Lesson 0002）

问题：不是问「怎么做才能成功」——而是问「怎么才能让这个系统彻底失败？」

应用：

• 失败原因 1：业务方和开发团队对需求的理解不一致
• 失败原因 2：上线时发现数据迁移不完整
• 失败原因 3：交易系统的延迟不满足要求
• 失败原因 4：监管要求变更导致要重做部分功能

提前识别的这些失败原因——成为项目初期的重点关注领域。

三、二阶效应（Lesson 0003）

问题：自建交易系统的一阶效应是「不再依赖外包」——二阶效应呢？

• 团队需要招募和培养金融工程人才（市场上很少）
• 内部团队对「交易系统的稳定性」缺乏经验——可能会有更多的生产事故
• 自建系统后——团队需要自己做 7×24 的运维和值班
• 监管要求的变更需要内部团队自己消化——外包时代外包消化的隐形成本暴露了

应用：这些二阶效应在项目一开始就应该纳入规划和资源估算——而不是上线后才「发现」。

四、系统思考（Lesson 0004）

问题：交易系统不是一个孤立的软件——它是一个更大的「交易生态系统」的一部分。

系统全景（部分）：

• 上游：行情数据源、交易指令录入、风控规则配置
• 核心：订单管理、风险管理、交易执行、清算对账
• 下游：财务系统上报、监管数据报送、客户报告

应用：从系统思考的角度看——最容易出问题的地方不是核心交易逻辑（团队会重点测试）——而是_边界_：比如行情数据源掉线了怎么办？财务系统格式变了怎么办？监管报送延迟了有什么后果？

五、贝叶斯思维（Lesson 0005）

问题：「12 个月上线」的先验概率是多少？

• 全行业同类系统的统计：首次自建的交易系统平均实际工期 = 预估 × 1.8-2.5
• 券商首次自建 + 团队经验不足 → 先验概率：12 个月上线 = 20%
• 随着项目进行，不断更新这个概率：前 3 个月的表现、团队的招聘进度、外包过渡的顺利程度——都在提供新证据

应用：与其争论「12 个月行不行」——不如建立一个「上调/下调概率的信号清单」，每 2 周根据新信号更新一次预期。

六、地图不是疆域（Lesson 0006）

问题：项目计划不是现实——架构图不是系统。

应用：

• 画架构图只用了 2 天——但实现它花了 8 个月——而且最终实现和架构图有 30% 的差异
• PM 的甘特图「3 个月完成风控模块」——实际做下来发现风控的规则引擎比想象中复杂得多——用了 5 个月
• 不要混淆「对计划的信心」和「对现实的信心」——地图不是疆域

七、能力圈（Lesson 0007）

问题：团队最大的能力圈边界在哪里？

• 团队擅长做：Web 应用、CRUD API、关系型数据库——圈内
• 团队不擅长做：低延迟交易引擎、复杂的金融衍生品定价模型——圈外
• 部分人做过：MQ 消息中间件、微服务治理——圈边缘

应用：

• 圈外的（定价模型）→ 聘请金融工程专家或者买第三方库
• 圈边缘的（MQ）→ 深入调研后再做技术选型——不能凭「感觉」选
• 圈内的（Web 前端）→ 快速迭代——这是团队的舒适区

八、根本原因分析（Lesson 0008）

问题：项目中期发现「测试总是延期」。表面原因是「测试排期太紧」。

5 Whys 分析：

• Why 测试排期太紧？→ 提测时间比计划晚了
• Why 提测晚了？→ 开发阶段发现的 Bug 比预期多
• Why Bug 多？→ 单元测试覆盖率不够 + 需求变更频繁

根本原因：需求的不稳定性 + 测试左移不够。修复措施：不是「给测试更多时间」——而是「在需求阶段引入更严格的评审 + 强制提高 UT 覆盖率」。

九、帕累托法则（Lesson 0009）

问题：哪些功能是真正关键的 20%？

• 20% 的关键功能：交易录入、订单路由、风险实时监控、交易对账
• 80% 的次要功能：报表生成、历史数据查询、管理后台、邮件通知

应用：

• V1 只做 20% 的关键功能——确保核心交易链路可用
• 次要功能在 V2/V3 逐步交付
• 这个分类本身也是风险管理的工具——关键时刻可以砍掉非核心功能来保证核心功能按时交付

十、奥卡姆剃刀（Lesson 0010）

问题：架构应该有多复杂？

• 团队最初提议：微服务（12 个服务）+ Event Sourcing + CQRS + Kubernetes
• 奥卡姆剃刀：「最简单的方案是什么？」——单体应用 + 消息队列 + PostgreSQL（= 3 个组件）
• 微服务确实「更先进」——但团队没有微服务运维经验——这会引入大量不必要的复杂性

应用：最终决定：单体应用 + 按模块分包，等系统稳定后再在必要时拆服务。这个决策至少节省了项目 4-6 个月的运维成本。

十一、康威定律（Lesson 0011）

问题：团队的沟通结构会影响系统架构。

• 团队分为「交易组」「风控组」「报表组」——每个组对应一个独立的功能模块
• 但交易组和风控组高度耦合（交易数据直接影响风控计算）——他们需要每天沟通
• 如果组织架构导致他们不沟通——系统架构也会跟着「不沟通」——产生两个孤立的模块

应用：调整团队结构：交易组和风控组合并为「核心交易组」——因为他们必须紧密协作。

十二、路径依赖（Lesson 0012）

问题：最初的技术选型会锁定未来 3-5 年的选择。

• 选了某个技术栈 → 后续的招聘、培训、维护都围绕它展开
• 选错了 → 转换成本极高

应用： - 数据库选型：选 PostgreSQL（开源、生态好、交易场景经过验证）——不要轻易选一个「看起来更合适」的冷门数据库 - 技术栈选型：Java/Spring Boot（人才市场充足）——不要因为「Go 性能更好」就选 Go（招人难、培训周期长） - 关键原则：在 OTC 交易系统这个场景下——生态 > 性能，团队过渡成本 > 技术先进性

十三、网络效应（Lesson 0013）

问题：交易系统本身不是一个网络效应的产品——但它依赖网络：

• 接入的客户越多 → 系统的价值越高（流动性越好）
• 接入的数据源越多 → 报价越精准

应用：在系统设计时，考虑「多客户接入」不是事后附加功能——而是核心架构能力。客户接入的 API 设计应该是一等公民——不是「后面再想」。

十四、反脆弱（Lesson 0014）

问题：交易系统必须在黑天鹅事件中变得更强大——而不是崩溃。

• 市场极端波动 → 交易量暴增 → 系统需要能承受峰值
• 某个数据源掉线 → 系统能自动切换到备用数据源
• 监管要求变更 → 系统不需要大规模重构就能适应

应用：在架构中设计「冗余」和「压力保护」： - 核心交易链路的每个环节都有降级方案（而非只有一个路径） - 定期做「混沌工程」实验：随机关闭一个组件，看看系统是否能自动恢复 - 监管规则引擎化——配置变更不需要改代码

十五、邓巴数（Lesson 0015）

问题：团队规模 15 人——正好在邓巴数分界线上。

• 15 人 → 勉强可以靠「聊天和信任」来协作——但已经需要一些流程
• 如果扩大到 20+ 人 → 沟通效率会急剧下降

应用：项目计划明确：如果团队必须扩大到 20+ 人——应该分拆为 2 个子团队——每个团队 8-10 人，有清晰的接口和沟通渠道。

十六、古德哈特定律（Lesson 0016）

问题：管理层用「代码行数」和「Sprint 完成率」来衡量团队绩效——然后发现这两个指标都在涨但项目延期了。

• 古德哈特定律：当「代码行数」成为考核指标——它就不再是有效的衡量标准了（开发会写大量的无用代码）
• 当「Sprint 完成率」成为考核指标——团队会把大任务拆成小任务来「提高完成率」——实际交付的完整功能没有增加

应用：选择那些「不易被游戏化」的指标——比如「生产事故数」「上线后缺陷数」「交易处理的延迟和正确性」——这些指标更能反映真实质量。

十七、帕金森定律（Lesson 0017）

问题：团队估算一个功能需要 3 周——但实际做下来只用了 2 周——第 3 周「打磨」了。

• 帕金森定律：工作膨胀填满可用时间——如果给了 3 周，即使 2 周能做完——也会被扩展到 3 周
• 但这不全是坏事：在复杂系统中，「打磨」确实会增加质量的——关键是要区分「真正需要的打磨」和「消磨时间的打磨」

应用：给合理但稍紧的估算——提前完成的任务明确「是真正完成了」而不是「可以多花时间打磨」。可以让团队在 Sprint Review 中展示完成的功能——而不是等到「完美」了再展示。

十八、布鲁克斯定律（Lesson 0018）

问题：项目第 8 个月发现进度落后了 3 个月——管理层提议加 5 个人。

应用：

• 拒绝不加分析地加人——先做「事前验尸」找出延期的真正原因
• 发现真正原因：需求变更太频繁 + 金融工程模块比预想的复杂（不是人不够）
• 解决方案：冻结需求变更 + 引入外部定价模型专家（而不是加 5 个通用开发）

十九、侯世达定律（Lesson 0019）

问题：不要说「12 个月上线」——

应用：

• 估算：12-18 个月（区间估算）
• 每个季度重新估算一次
• 管理层得到的是一个「不断校准的预期」——而不是一次性的「承诺」
• 当项目第 10 个月发现还需要 6 个月时——管理层不会觉得「又一次延期」——而是「我们的估算在动态校准中」

二十、事前验尸与预检清单（Lesson 0020）

问题：项目启动时做一次完整的事前验尸。

输出——前 5 个失败原因：

1. 需求不明确导致后期大量返工
2. 金融定价模块复杂度过高导致延期
3. 交易数据迁移丢失或不一致
4. 上线时监控和告警缺失导致事故无法及时发现
5. 内部团队经验不足导致运维问题

清单应用：

• 上线检查清单：迁移验证、监控配置、回滚演练、相关团队通知——每次上线前逐项确认
• 需求评审清单：验收标准、异常流程、性能要求——每次需求评审时使用
• 发布决策清单：是否已测试？是否已 Code Review？是否已更新文档？是否已知会运维？

二十一、这些模型的相互作用

二十二、测验（12 题）

开放思考题（无标准答案）

二十三、答题提示

展开提示

• Q1-2：第一性原理 + 奥卡姆剃刀 = 找到本质 + 保持简单
• Q3-4：康威（组织与架构对齐）+ 贝叶斯（动态更新信念）
• Q5-6：地图不是疆域（区分计划和现实）+ 能力圈边界（知道什么是圈外）
• Q7-8：帕累托（先做核心）+ 布鲁克斯（不加无谓的人）
• Q9-10：侯世达（区间估算）+ 古德哈特（选对指标）
• Q11-12：反转 + 事前验尸 → 预防失败的关键组合

二十四、本课行动清单

1. 选一个你正在做的项目——看看这个案例中的 20 个分析角度有多少可以移植过去。
2. 特别注意「模型的相互作用」——它们不是孤立的，组合使用效果更好。
3. 把你的分析和原始团队分享——讨论「如果我们在项目启动时就做了这些分析，会有什么不同？」

二十五、参考来源

• 本课综合案例的灵感来自真实券商自建 OTC 交易系统的经历——但这是一个经过简化和改编的案例
• 每一节对应的原始模型引用见 Lessons 0001-0020 的「参考来源」

下一步：看 Lesson 0022 · 综合案例：金融科技产品决策——本课程的最后一课。