两周交付一个行业系统：范围冻结、里程碑与验收

两周能交付的东西，是已有底座加行业配置、少量定制和部署上线，不是从零开发一套完整平台。这句话在签约前跟客户说清楚，比后面任何项目管理技巧都管用；没说清楚，第 10 天多半在吵架。

先把“两周交付”的边界划出来

很多人把两周交付理解成两周写完所有代码，然后失败。能不能交付，取决于底座有没有。

所以承诺给客户的是交付：两周后你能登录、能走完主流程、能看到真实数据、能拿到部署文档。边缘功能没做完不叫违约，这一点也要写在纸上。

报价也要按这 10 个工作日算。一个人做，10 个工作日就是 10 人天，单人无驻场的项目里，扣掉沟通、部署、验收，真正写代码的时间不到一半。按人天报价时，把部署、培训、文档、30 天在线值守都算进去，别用“顺手就做了”把成本送掉。从零开发、复杂资金系统、强合规行业都不适用两周交付，硬套只会延期；实际工期要按团队人数、客户配合度和第三方依赖重新估，后面的 D1 到 D10 是一种排法，不是唯一排法。

D0：签约前要拿到的六样东西

两周的工期，真正决定成败的是签约前那几天。我一般要拿到六样东西才敢报“两周”。

服务器和网络：几核几 G、什么系统、有没有公网 IP、能不能装 Docker 和中间件、数据库版本是多少。域名和备案：主体是谁、有没有备案、能不能加子域名、解析在哪家。第三方账号：支付、短信、地图、对象存储、电子发票，有没有测试账号，要不要资质，回调地址能不能被公网访问；多商户和连锁的还要确认收单分账模式：总部商户号加分账接口，还是各门店特约商户号；逐户进件（给每家门店向支付渠道提交材料、开收款商户号）要几天，进件天数计入排期。

还有三样更容易漏。真实数据样本，脱敏后给 100–500 行先看结构，字段有多脏要看全量的空值率、枚举值分布和最长字段统计，别拿 500 行下结论；对接人名单和决策人，谁能确认范围、谁能签字验收、谁负责服务器；合同和付款节点，定金什么时候到、验收后几天付、尾款挂在哪。

六样缺一样，D1 就会变成等资料。等资料不占你的工作日，但占客户感知里的工期，最后还是会算到你头上。

范围冻结：把“想要”变成“这次要”

签约后第一件事是开一次 90 分钟的范围会，产出三张表，IDE 可以先放着。会前从底座能力清单克隆一份预填草案，会上只做勾选、增删和定级——90 分钟从零写不出三张表，客户配合再好也不行。

第一张是必须有（Must）：没有它业务就跑不起来。多商户系统里大概是商户入驻、商品发布、下单支付、订单履约、结算查询这几条。第二张是这次要有（Should）：影响体验，但有替代方案，比如批量导入、消息通知、简单报表。第三张是以后再说（Later）：客户提了，但不影响这次上线，比如复杂营销、多级分销、BI 大屏、APP 原生端。

规则很简单：Must 不超过 15 条，Should 不超过 10 条，Later 全部写进后续版本、不写进本次合同。一条的定义要卡死：一次演示里能当场判定过不过的最小业务动作，清单行固定五列——编号、名称、级别、验收判定句、演示脚本步骤；15 条只对行数生效，拆行走变更单。任何新增需求，必须从 Should 或 Later 里换出来，或者走变更单。清单定稿编号 v1.0，每条带 F001 式编号，变更单引用编号（“以 F007 换 F012”），群内确认回版本号。

范围会开完，让客户在功能清单上签字——这一步是让双方对“做完了”有同一个定义。签字清单分两部分：Must 进验收门槛；Should 进一页《本次不交付声明》，逐条标“已完成 / 顺延到 vX.X”，验收时对照着勾——这样后面那句判定才立得住：清单里标 Must 且没按清单运行，是 bug；Should 没做完按声明顺延，不是违约。

10 个工作日怎么排

以白牌成品加一个流程定制加部署为例。

D8 排在 D9 前面是有原因的：先演示，再上生产。很多项目反过来做，客户在真实数据上第一次看到问题，信任直接就崩了，后面不管修得多快他都不放心。

这张表只排了一个流程定制。签了两个流程，第二个单独插一天，从 D7 的核对和 D8 的内部验收里各挤半天——20% 的 buffer 就是从这两处省出来的，两个流程一起上就没有了，所以那一档叫“能，紧”；再往上就要破两周。

甲方那 10 天不是等着

两周交付里，乙方满打满算只有 10 个工作日，甲方那边也有固定的动作，只是很多人没提前说。D1 提供资料和账号，D3 确认品牌、字段和流程配置，D5 安排业务人员试第一版，D8 组织演示并当场定问题级别，D9 提供生产环境和上线窗口，D10 参加验收、接过账号和文档。每个动作半天到一天，压在最后就会变成“你们先做，做完我们再看”。排期表要发给客户，并且写一句：甲方资料或确认每延迟一个工作日，交付节点顺延一个工作日。顺延要能自动生效，条款得落成相对日期：里程碑从乙方收到资料之次日起算第 N 个工作日，收到当天邮件回执，回执日期就是起算凭证——里程碑别写日历日期，写了顺延就要重新签。这句话的作用是让双方对时间有同一个预期；配合的客户不会反感它。

还有一个容易忽略的角色：客户的 IT 或网管。服务器权限、端口、备份策略、白名单都在他手里。D1 就要把他拉进群，不要等到 D9 才发现他出差了。

四件事最容易被低估

数据。客户给的数据通常躺在 Excel 里，字段名不一致、手机号带空格、金额存成文本、有重复记录、必填项缺失。导入脚本写完只是开始，真正要核的是总量对不对、金额合计对不对、关联关系对不对、权限归属对不对、失败了能不能重跑。这块在排期表里占 D6、D7 两天，别塞进 D9。

第三方对接。支付、短信、地图、电子发票、对象存储，任何一个的回调、鉴权、白名单、证书都能卡掉一天。签约前就要确认有没有测试账号、要不要备案或资质、回调地址公网能不能访问、有没有 IP 白名单。

权限。客户演示时最爱问的两句话是“这个店长能不能只看自己门店”“代理商能不能看下级”。这类需求如果在演示现场才提出来，往往要动数据模型。角色和数据范围得在范围会上就列清楚。

部署环境。客户的服务器可能是 2 核 4G、Windows Server、没装 Docker、数据库版本很老。签约前把环境信息拿到手，必要时把“服务器由我方代购或指定配置”写进合同，否则 D9 那天你会在现场装系统。

这四件事有个共同点：都不在代码里，但都会在 D9 那天一起爆发。排期时把它们当成开发任务，不要当成杂事。

里程碑是给客户定心的

不要只告诉客户“第 10 天交付”。设四个他能直接判断的节点：D2 能登录，环境通了、主流程能点；D5 能演示，核心流程走通，客户开始提反馈；D8 可提验收，问题清单收敛、变更确认；D10 能上线，生产部署、备份、培训、交接。

每到一个节点，发一条短消息加一张截图或者一段录屏，不要等客户来问。交付期的沉默，客户会读成“他是不是做不出来”。

延期时，先给方案再给原因

两周的项目也会延期，原因通常是数据比想象脏、第三方审核比想象慢、客户中途换了对接人。原因要说，但不要只说原因。

发现要延期，第一时间给三个选项：砍掉哪些 Should 保 D10，增加多少费用换一个人并行，或者整体顺延几天并重新排里程碑。每个选项写清对上线的影响，让客户选。客户最怕的是不知道会延到什么时候。

不要用“再给我两天”拖三次。第一次是意外，第二次是管理问题——第二次就该停止口头拖延，把三个选项直接摆出来。

延期确认后，把新的里程碑发到群里，双方回一句确认。口头答应的新日期，过两周就没人记得。

变更控制只需要一句话

本次范围内的，免费改；范围外的，要么用同等工作量换，要么加钱加时间。

落下来是四件小事：变更单要写清改什么、为什么改、影响哪些功能、增加几天、增加多少钱；客户没确认就不开工；口头需求一律转成文字发到群里，等对方回一个“确认”；紧急 bug 先修，但先修 bug 不等于免费加功能。

没有这套控制，两周的项目会拖成两个月，最后双方都不满意，而且说不清是谁的问题。

上线后的 30 天，才是口碑

验收签字不等于项目结束。上线第一周问题最密集，客户对系统的信任也最脆弱。

我的做法是：第一周每天固定时间同步一次问题，P0 两小时内响应，P1 当天给方案，P2 排进版本；第二周隔天同步；第三周开始走工单。P0、P1、P2 的口径提前写死：P0 是主流程不可用或产生错误数据且无替代方案，P1 是有替代方案但影响日常使用，P2 是体验问题；P0 的两小时指工作日 9:00–21:00，凌晨的顺延到早上，这条不写，值班表没法排。第 31 天起转付费维保或按次计费，报价单上单独列一行“含 30 天在线值守”，别让它看起来是送的。

这 30 天里最容易吵架的是“这是 bug 还是新需求”。判断口径在合同里：清单里标 Must 且系统没按它运行，是 bug；清单里没有、或者客户想改流程，是新需求。新需求走变更单，不要因为怕得罪人先做了再说，做完再要钱更难。

30 天结束做一次回访，顺便核对三件事：备份有没有在跑、告警有没有接到人（错误日志关键字和磁盘水位要告到客户指定的群，负责人署名）、账号和密钥有没有移交。这三件事在验收时都签过字，一个月后最容易松掉。

尾款挂在验收签字，或者验收合格之日起 30 日内，别挂“售后期满”——期满从哪天起算会被争；更不要挂在“用得好”，那个连可争的日期都没有。

验收标准在 D1 就写下来

验收要能逐条判定，避免“我觉得还不行”这种无法反驳也无法满足的意见。清单里至少有这几项：功能清单逐条勾选且 Must 全部通过；关键报表的数字和来源一致（以功能清单所列报表为准，报表名写进每条的验收判定句）；权限矩阵按角色逐项测试，谁能看什么、能做什么；性能给出口径，比如“在线用户 50、峰值并发 20 下，登录、下单、报表三类接口 P95 小于 3 秒，接口清单见附件”，而不是写“系统要快”；能在干净环境按文档部署成功；至少一次培训录屏加一份操作手册；30 天内 bug 免费修，新需求另计。

验收单上还要补一句：以上项目通过后，买方应在 3 个工作日内签署验收，逾期未提出书面异议视为通过。这句话是为了不让尾款无限期挂着，但它只在两个前提都成立时才有用：条款在签约时就写进合同，而且你发出验收通知这件事本身是有记录的（邮件、盖章的验收申请单）。否则 3 个工作日从哪天开始算都说不清。真走到诉讼，法院也未必按这一条判；它的实际作用是让对方知道，拖着不验收对他没有好处。

系列：上一篇 一个人做行业软件，先接单再做产品 ｜ 下一篇 国内项目验收为什么总卡住 ｜ 相关 私有化部署的最小交付包，拔掉网线还能装起来才算