Conduct a premortem analysis t…

# 社区团购小程序项目 · 事前验尸分析（Pre-mortem）

> 假设：8周后项目失败。倒推死因，提前布防。以下按“高概率死因→预防措施→监控信号”结构展开。

一、技术死因分析

1. 团购高峰期系统崩溃

• 死因：开团/秒杀场景并发激增，未做压测与限流
• 预防：核心链路（下单、支付、库存）单独压测；库存扣减用Redis预扣+异步落库；设置排队/限流兜底
• 信号：压测QPS低于预估峰值的2倍即预警

2. 库存超卖/数据不一致

• 死因：并发下单未做原子扣减，退款与发货状态机混乱
• 预防：库存操作统一走幂等设计；订单状态机文档化，全员评审

3. 微信生态合规踩坑

• 死因：小程序审核被拒（类目资质、虚拟支付限制）、分享裂变被判定诱导
• 预防：开发首周即核对微信平台类目资质要求（食品、生鲜需相关许可）；裂变玩法预留合规备选方案

二、业务死因分析

4. 团长招募不及预期（最大业务风险）

• 死因：只做了工具没做供给侧，上线无团长无单量
• 预防：开发期同步启动团长冷启动（目标区域、招募话术、首批种子团长）；预算切一块做团长激励
• 信号：上线前种子团长数量为0即红色警报

5. 供应链掉链子

• 死因：爆品团成了，但履约/售后崩盘，口碑翻车
• 预防：首月只上经过验证的少量SKU；与供应商明确履约SLA和退换货责任

三、团队与工期死因分析

6. 5人小队的关键人依赖

• 死因：后端或前端单人请假/离职，进度冻结
• 预防：核心模块代码交叉Review；文档强制同步；每周识别“单点风险”

7. 需求蔓延吃掉工期

• 死因：8周工期被砍成“4周开发+4周返工”
• 预防：第1周冻结MVP范围（建议：团长端+用户下单+支付+基础后台，先不做积分、分销等花活）；变更走评审，砍需求不砍质量

8. 20万预算错配

• 死因：全砸在开发，测试/运维/推广为零
• 预防：粗略配比参考——开发人力占大头，但务必预留测试设备/云资源、上线后运营费用；提前列预算红线清单

四、行动清单（本周就做）

• [ ] 输出MVP功能清单并全员签字冻结
• [ ] 确认微信类目资质与所需证照
• [ ] 启动团长招募与供应链摸底（与开发并行）
• [ ] 每周五跑一次“风险信号看板”（进度、压测、招募数据）
• [ ] 定义“上线最低标准”：压测达标+种子团长到位+核心链路冒烟通过

> 核心结论：这个项目最可能的死法不是技术，而是“有产品没生意”——技术风险靠工程手段可控，业务冷启动必须与开发并行启动。