开发前风险预演 · 2026-07-30

重庆环卫拼团用餐方案
Pre-Mortem

假设方案上线后失败，从结果倒推支付、订单、关团、退款和通知中真正需要提前解决的问题。

结论：方向可行，有条件通过

复用现有菜单、点餐入口和正式订单，但必须增加“拼团活动 + 报名聚合层”。补齐关键决策后再进入原型和技术设计。

暂不直接排期开发

先说清楚：什么能复用，什么必须新增

继续复用

现有履约能力

  • 餐厅、档口、菜品、菜谱和餐次
  • 手机端选餐入口与购物车
  • 成团后的正式消费订单
  • 取餐、核销、订单查询
  • 满足适用条件的取消和退款能力
必须新增

正式订单前的报名聚合层

  • 拼团活动及完整规则
  • 报名人与报名菜品快照
  • 唯一性、并发锁和幂等处理
  • 定时关团及正式订单转换
  • 通知记录、失败补偿和重试

这不是第二套订单系统。 拼团活动与报名记录只负责正式消费订单形成前的意向聚合；成团后的备餐、取餐、结算和售后仍走现有系统。

Tigers：会真正阻塞上线的问题

1. 支付与成团口径未确定

Launch-Blocking

报名不付款会造成成团后不支付、备餐人数失真；报名即付款则必须处理未成团批量退款；余额冻结体验最好，但若现有账务没有冻结能力，改造量最大。

行动：先确认报名、成团、扣款、退款四个时点，以及报名人数是否必须已经付款。

2. 当前下单会立即形成正式订单

Launch-Blocking

现有订餐提交在校验菜品和时间后直接创建正式订单，与“先报名、截止后成团”的流程不同。直接套用会让未成团报名进入订单和备餐统计。

行动：增加独立报名层，正式消费订单只接收已成团且满足结算条件的数据。

3. 截止时存在并发和重复执行

Launch-Blocking

最后报名、用户取消、定时关团和人工操作可能同时发生，导致重复成团、人数越界、重复生成订单或重复退款。

行动：建立活动状态机，使用数据库事务、条件更新和唯一业务号保证关团、转单、退款可安全重试。

4. “最低人数”的统计粒度不清

Launch-Blocking

需要明确按人、份、订单、菜品还是套餐成团；一人买多份、不同员工选不同菜品时，统计结论完全不同。

行动：首期限定一场活动对应一个固定套餐，按去重员工数判断成团。

5. 未成团和订单退款是两类业务

Launch-Blocking

未成团可能发生在正式订单形成前，不能默认直接走现有退款订单；成团后取消还涉及报名截止、备餐开始和退款截止。

行动：分开定义撤销报名、未成团释放或退款、正式订单取消退款三类动作。

Elephants：团队还没有充分讨论的问题

  • 成团后食堂能否人工撤销，谁承担退款和通知？
  • 截止后能否加人、换菜、减少份数？
  • 一名员工能否代多人报名，代报如何计数？
  • 未取餐是否退款，是否记录爽约？
  • 多种账户或微信支付并存时如何原路退款？
  • 后厨按人数还是按菜品份数备餐？
  • 菜单变价、下架或库存变化后如何处理快照？
  • 同一餐次存在多场拼团时如何避免重复报名？

Paper Tigers：首期不必过度建设

不建第二套正式订单

活动与报名只做聚合，成团后的履约继续复用消费订单。

不引入团长角色

食堂管理员发起、员工报名已经能够完成试点闭环。

不做复杂跨域拼团

首期不支持跨餐厅、跨餐次、多菜单混拼和高频实时推送。

建议的首期范围

单一场景
一个餐厅、一个日期、一个餐段。
固定套餐
避免多菜品分别成团的复杂统计。
按员工数
按去重员工人数判断是否成团。
一次关团
系统自动且只执行一次成团判定。
截止前撤销
截止后不允许员工自行修改报名。
成团后转单
满足条件后生成或关联正式订单。
结果页必达
通知只做提醒，不作为唯一结果通道。
后台可追踪
人数、份数、转单和退款异常可查询。

进入开发前的行动清单

动作建议责任方完成条件
确认支付与结算模式产品、客户、财务写清报名、成团、扣款、退款四个时点
确认成团统计粒度产品、客户、食堂运营明确按人、份或套餐，以及重复报名规则
输出状态机和异常矩阵产品、后端、测试覆盖报名、取消、关团、转单、退款、通知失败
确认数据模型后端、DBA明确活动、报名、报名项、任务记录和唯一键
验证订单退款边界后端、测试、财务选定支付方式后完成真实测试环境闭环
小范围试运行项目、食堂运营一个餐厅、一个餐段、一个固定套餐运行一周
最终建议：先完成“报名 → 临界人数 → 并发关团 → 正式订单 → 取消/退款 → 后厨统计”的真实测试环境验证，再决定是否支持多套餐、代报名、顺延和多支付渠道。

原始方案：拼团用餐方案｜客户评审版