Phase 4.1 建立业务对话能力
目标：不只是"执行技术需求的工程师"，而是能在需求阶段就识别风险、提出方案、推动决策的技术伙伴。
一、为什么业务对话能力是稀缺的
大多数工程师接到需求的反应是：
"好，我来实现。"
少数工程师会问：
"等等，这个需求背后要解决的问题是什么？"
在金融系统中，后者的价值远高于前者。原因：
- 金融需求复杂且细节多：业务方不一定能把所有边界情况都想清楚
- 错误的代价高：金融 bug 是真实资金损失，发现越早成本越低
- 技术方案影响业务结果：选择同步还是异步，直接决定资金到账时间
二、需求评审中的有效提问
提问的三个层次
第一层（差）：确认实现细节
"这个字段是 int 还是 long？"
第二层（好）：理解业务规则
"如果账户余额刚好等于委托金额，允许下单吗？还是必须 > 委托金额？"
第三层（优）：识别业务意图和边界
"这个限额是按账户算还是按实际控制人算？如果一个人控制多个账户，是分别计算还是合并计算？"
金融需求评审必问清单
在接到任何金融系统需求时，逐一确认：
关于数据精度
- 价格和金额字段用几位小数？四舍五入规则是什么？（HALF_UP 还是 HALF_EVEN？）
- 是否有最小变动单位（tick size）？不符合 tick 的报价怎么处理：拒绝还是向下取整？
关于并发和时序
- 同一账户的多笔订单可以并发处理吗？还是必须串行？
- 如果成交回报乱序到达（Part 2 先于 Part 1 到达），怎么处理？
- 如果消息队列重复投递（at-least-once），系统如何保证幂等？
关于边界条件
- 零数量/零金额的操作是否合法？
- 节假日怎么处理？（结算日跨越节假日如何计算？）
- 跨时区场景：下单时区和结算时区不一致时，"今日"指哪个时区？
- 账户被冻结期间收到成交回报，怎么处理？
关于失败场景
- 风控检查超时（而非拒绝），订单应该通过还是拒绝？
- 向交易所发送订单失败，是立即告知客户还是重试？重试几次？
- 成交回报收到了但持仓更新失败，怎么保证一致性？
关于监管合规
- 这笔操作需要审计日志吗？
- 是否需要向监管机构上报？报告时限是什么？
- 数据留存多少年？
三、用业务语言描述技术方案
工程师常犯的错误：用技术语言解释技术决策，业务方听不懂，也不知道怎么决策。
错误示范
"我们用 Kafka 做异步解耦，通过 Event Sourcing 保证审计链完整性， 同时用 Redis 缓存热路径数据降低 p99 延迟。"
业务方内心：??
正确示范
"成交后持仓更新我们做了两层： 一层是毫秒级的内存更新，让风控实时看到最新持仓； 另一层是写入数据库，保证即使服务器重启，数据也不会丢失。 这样做既快又安全，代价是极端情况下两层可能有短暂的 1 秒以内的不一致， 你们的业务可以接受吗？"
转换技巧：
- 从业务影响出发，而非技术实现
- 量化"快多少"/"安全到什么程度"
- 明确说出权衡和代价，让业务方参与决策
四、识别需求中的业务逻辑漏洞
金融系统的需求文档常常存在遗漏，工程师需要主动发现。
案例 1：分红再投资
需求：账户收到股票分红后，自动买入同一只股票。
工程师应该追问：
- 分红的资金到账时间是几点？是否在交易时间内？
- 如果分红到账时，该股票已经涨停无法买入，怎么办？等次日？还是取消自动买入？
- 分红金额不足一手（A 股 100 股）时，余额如何处理？
- 如果当日已经有其他订单冻结了部分资金，分红金额够用吗？
- 跨市场：港股分红是港币，自动买入用港币还是换汇？
案例 2：日亏损限额
需求：账户日亏损超过 100 万元时，禁止当日继续下单。
工程师应该追问：
- "亏损"指已实现盈亏，还是包含浮动亏损？
- 浮动亏损随行情变化，下午 2 点触发了限额，2 点 30 行情回升，是否解禁？
- 判断亏损的基准是"今日开仓成本"还是"昨收市值"？
- 已经在途的订单（OPEN 状态）如何处理？立即撤单？还是让其自然成交？
- 100 万是所有账户合并算，还是每个子账户单独算？
案例 3：T+1 限制下的卖出
需求：A 股买入当天不能卖出（T+1 限制）。
工程师应该追问：
- 今天买入 100 股，昨天已持有 50 股，今天可以卖出多少？
- 只能卖昨天的 50 股？还是 150 股全部？
- ETF 申购得到的份额，当天能卖吗？（实际上可以，规则不同）
- 通过大宗交易买入的股票，T+1 规则适用吗？
- 如果持仓快照在盘前不准确，导致误判，怎么补救？
五、主动参与业务决策
从"被动接需求"到"主动参与决策"需要做以下事情：
1. 理解业务目标，不只是功能清单
每个需求背后都有业务目标，理解目标比理解功能更重要：
功能需求：新增"持仓预警"功能，当持仓亏损超过 10% 时发送提醒
业务目标：降低客户大额亏损的流失率
基于业务目标，工程师可以补充：
✓ 预警阈值是否应该可配置（不同客户风险偏好不同）？
✓ 预警后如果客户没有操作，是否需要升级提醒（电话/短信/APP 推送）？
✓ 浮亏 vs 实现亏损：日内高频波动会导致反复预警，是否需要冷却时间？
2. 评估需求的 ROI
有时候工程师比业务方更清楚某个功能的实现成本，要敢于提出来：
业务方：能不能做一个"智能止损"，根据波动率自动调整止损价格？
工程师评估：
技术复杂度：需要实时计算各种证券的历史波动率，维护动态止损单，
处理订单状态的复杂状态机，约 2-3 个月工作量
主动提出替代方案：
"我们先做一个简单的固定比例止损（如 -10% 触发），2 周可以上线。
收集用户使用数据后，再决定是否需要复杂的动态止损。
这样可以更快验证用户需求，避免做了没人用。"
3. 提前识别合规风险
这是最体现"懂金融"的能力：
案例：业务方提出允许用户授权他人代为操作账户
工程师应该识别：
× 这可能涉及"代客理财"资质（需要基金管理牌照）
× 被授权人是否需要经过 KYC？
× 操作日志如何归属？合规报告中是用授权人还是账户主人？
主动建议：
"这个功能建议在上线前确认法务意见，
因为代为操作他人账户在某些情况下可能触及监管红线，
历史上有平台因为这个被处罚过。"
六、技术评审中的主动贡献
不只是在自己负责的模块发声，还要对整体方案提出建设性意见。
数据流图的必要性
每次技术评审前，先画出数据流图：
用户下单 → API 网关 → 风控服务 → OMS → FIX 网关 → 交易所
↓ ↓ ↓
审计日志 持仓缓存 订单 DB
在图上标出：
- 哪些地方可能出现延迟瓶颈？
- 哪些地方如果失败会导致数据不一致？
- 哪些地方需要特别的幂等保护？
识别单点故障
方案中有单点 → 主动提出：
"这个 FIX 网关如果宕机，是所有交易都中断吗？我们是否需要主备切换？
考虑到交易时间是确定的（9:30-15:00），宕机恢复的 RTO 要求是多少？"
提出可观测性需求
业务方通常不会主动要求监控，但工程师应该主动加上：
"这个功能上线后，我建议加上以下监控：
1. 风控检查的平均延迟和 P99 延迟（告警阈值：P99 > 100ms）
2. 订单拒绝率（分原因统计）
3. 成交回报处理延迟
这样出现问题时我们能快速定位，也方便评估上线效果。"
七、实战练习：需求评审模拟
练习 1：接到如下需求，写出你的追问清单。
需求：实现"条件单"功能。用户可以设置：当某只股票价格突破某个价格时，自动下一笔买单。
参考追问方向（自己先想，再对照）：
参考答案
- 价格判断：是成交价突破，还是最新报价（Bid/Ask）突破？两者差别可以达到几个 tick
- 延迟要求：触发条件满足到下单的延迟要求是多少？（价格转瞬即逝）
- 触发后的订单类型：是市价单（保证成交）还是限价单（可能又没成交）？
- 条件单是否支持撤销？在触发过程中用户撤销怎么处理？
- 同一账户多个条件单同时触发，资金不够怎么办？先触发的先执行？
- 系统重启后条件单是否还有效？（需要持久化存储）
- 盘前/盘后时间触发条件，在开盘时才下单？还是忽略？
- 是否支持重复触发？（比如价格每次突破都触发，还是只触发一次）
练习 2：用业务语言描述以下技术决策。
技术决策：成交后持仓更新使用乐观锁（版本号），并发冲突时重试最多 3 次，超过后进入死信队列人工处理。
要求：用 3 句话向业务方解释这个方案的含义和影响。
本节小结
业务对话能力不是一夜之间能建立的，它来自：
- 积累提问习惯：每次接需求，先问"为什么"和"如果...怎么办"
- 主动理解业务流程：不只读技术文档，也读业务流程手册和合规手册
- 翻译能力：在技术语言和业务语言之间自如切换
- 勇于发声：发现潜在问题时不要沉默，哪怕可能是自己想错了
核心原则：你对业务的理解越深，你提出的技术方案就越准确，你的价值就越不可替代。