MVP 只写了 C 端，上线前炸出 6 个 P0 断链

一个 O2O 服务功能，产品方案和设计稿都只描述了「用户下单」的链路。开发照图实现，联调完毕，准备上线——然后 QA 走读了一遍服务人员侧，发现他们压根没法工作：看不到新订单通知、无法区分订单类型、无法更新服务状态、拿不到客户联系方式。同一时间，运营侧的计价配置入口也不存在。

6 个 P0 断裂点，全部是「从来没有人想到要做」，而不是「做了但有 bug」。

现象

功能本身的业务闭环是：用户下单 → 服务人员接单 → 执行服务 → 完成确认。但 MVP 交付物里：

• 用户支付成功后跳转的订单详情页，不展示任何服务方信息
• 服务人员的抢单列表里，新类型订单和普通订单外观无差异，无法识别
• 服务人员没有接收新订单的推送通知入口
• 接单后拿不到客户联系方式，无法主动沟通
• 取件、配送、送达等中间状态无法由服务人员主动更新
• 运营后台没有任何计价配置管理入口

结果是：用户下单成功，但整个服务链条在服务方这一侧完全断掉，功能根本无法上线。

根因

这类断链的根因不是代码 bug，而是需求视角的单角色盲区。

产品方案以「用户旅程」为主线，设计图覆盖了用户从发现服务到支付成功的每一个屏幕。但对于同一个业务事件，存在多个参与角色——用户是「发起方」，服务人员是「执行方」，运营是「配置方」。设计图里根本没有服务人员和运营的任何页面，开发自然也没有交付。

正解

在产品方案阶段，引入角色完整性检查，强制对每个参与角色逐一过一遍核心工作流是否被覆盖。

具体做法：列出本功能涉及的所有角色，对每个角色问三个问题：

1. 他怎么知道有任务要处理？（入口 / 通知）
2. 他能完成核心操作闭环吗？（执行路径）
3. 他的异常场景有出口吗？（错误 / 中断处理）

如果任意一个角色的核心闭环存在空白，就是 P0 断裂点，必须在 MVP 范围里覆盖，不允许带着这类断链上线。

以服务方为例，最小可用检查项：

服务方最小可用检查
✅ S1  能收到新订单推送通知
✅ S2  抢单列表能识别该类型订单
✅ S3  有接单操作入口
✅ S4  接单后能看到客户地址 + 联系电话
✅ S6  能更新服务中间状态（取件 / 配送 / 完成）
✅ S7  能确认服务完成

运营侧同理：

运营最小可用检查
✅ O1  有计价 / 参数配置入口
✅ O2  能在订单列表筛选到该类型订单
✅ O4  能对异常订单执行取消 / 退款

一句话外卖

MVP 的最小单位不是「C 端能用」，而是「所有角色的核心闭环都跑通」——哪怕每个闭环只有最基础的路径。