P2 场景交付

P2 是我们的主力服务：把一个具体的业务场景，做成能在生产环境跑、并且真的有人在用的系统。

周期 3–8 周，按项目报价，诊断后书面给出。

一、交付物（五项）

二、验收标准：三条缺一不可

这是 P2 与普通外包最本质的区别。

第一条：功能层 —— 约定清单全部跑通

合同里列出的每个功能点，在测试环境验证通过。这一条所有服务商都会做。

第二条：采用层 —— 业务人员真的在用

这条是我们坚持加的，也是同行普遍不写的。

具体指标在合同里约定，例如：

• 至少 3 名业务人员连续使用 14 天
• 核心功能日活达到约定的次数
• 关键流程线上化率达到约定比例

为什么必须有这条：因为"上线了"和"用起来了"是两件事。很多项目验收单签了、系统上线了，业务人员还在用微信和 Excel 干活——这不是交付成功，这是交付失败但没人承认。

第三条：交接层 —— 客户能独立接手

你指定的对接人，在不问我们的情况下，能完成：

• 日常操作（增删改查、导出报表）
• 简单配置变更（改字段、改流程、改权限）
• 常见问题的初步排查

三条都过，才算交付完成。 只过第一条，那是外包；三条都过，才是 FDE。

三、报价是怎么来的

报价由基础交付量与五个影响变量构成。这五项会在诊断阶段逐条量出来，然后给出书面报价。

为什么是这五项：同样是"交付一套系统"，单系统单角色与多系统多角色的工作量可以差三倍以上。这五项就是差异的来源。

诊断阶段我们会按这五项逐条估算，给出一个区间而不是一个数字——因为有些工作量要到动手才知道。

四、付款节奏

每个阶段不通过验收，不进入下一阶段。 已完成的阶段按合同结算，未开始的不收费。

五、交付流程

注意：采用阶段在"上线"之后还有 30 天。这 30 天不是可选项。

六、不含什么

七、常见的四种失败原因，以及我们的对策

这一节国内同行基本不写。但我们踩过这些坑，知道它们有多常见。

失败原因一：需求在做的时候变了

表现：做着做着，老板有了新想法，或者业务部门提出"能不能再加一个功能"。

我们的对策：Frame 定界阶段把"不做什么"写进文档，客户签字。变更走流程——小变更消化，大变更签补充协议。不是不让变，是让变化有代价、有记录。

失败原因二：数据根本不能用

表现：客户说"数据都在系统里"，实际打开一看，字段缺失、重复、格式混乱、关键信息在 Excel 和微信里。

我们的对策：P0 诊断阶段就要样本数据看。如果数据不可用，我们会在诊断阶段就说清楚，而不是做到一半才发现。

失败原因三：业务人员抵触

表现：系统上线了，但业务人员不用，或者表面用、实际还是私下用微信和 Excel。

我们的对策：① 设计阶段就让业务人员参与，不是做完再通知；② 采用阶段盯使用数据，发现抵触立刻查原因；③ 如果抵触来自"觉得是来监视自己的"，需要客户管理层出面说明。

失败原因四：客户侧没人对接

表现：签约时说"全力配合"，实际推进时找不到人，一个问题等一周。

我们的对策：合同里写明必须指定一名项目对接人（大致占其三分之一工时）。如果客户不能保证这一点，我们会建议不做——因为大概率会烂尾。

八、什么时候不建议做 P2

九、和 P4 怎么配合

如果你的团队有能力接手，我们建议 P2 + P4 一起做：

• P2 把系统做出来
• P4 把能力交给你的人，我们退出

这样你的总投入比"P2 + 长期 P3 托管"低，而且不被锁定。

详见 P3 托管 / P4 能力转移。