一句话：切片不是偷工减料，是把风险分期。先交一个小的、能跑的、能量化的东西，比交一个大的、说不清的强十倍。
「7 大系统一起上」是客户最初的要求，切成四层后才可执行：P0 数据地基（订单↔经销商 ID 对照表、出厂价红线 PV/KW/K1、尺寸数据源）→ P1 引擎（型号 96.6%/厚度 95.2% 已验证，尺寸 29% 是瓶颈）→ P2 拆单与 BOM→ P3 派单。关键判断：P0 不做完，P1 做出来也是废的。
排期上留 30% 缓冲的真实依据：生产 400 单里 97% 无尺寸，规格缺失直接推翻了乐观工期。延伸：基础 16 · 数据库存东西 讲这批数据为什么缺。
需求诊断做完，客户紧接着就是一句话：「这几个系统一起上，才算完整。」7 个模块、报价、拆单、派单、报表、库存、权限——听起来都对，都该做。
但你心里清楚：同时上=同时炸。出了 bug 你不知道是哪一块引起的，数据错了你不知道回滚哪一段，客户一线停工了没人能立刻顶上。这不是能力问题，是结构问题。
| 客户的心理 | 没说出口的真话 | 如果照做 |
|---|---|---|
| 「一起上才完整」 | 他怕的是你做完一个就跑路，或者中途加价 | 你为了留住他全接下来，工期拉成三个月，中途任何一环卡住都收不到尾款 |
| 「先做核心功能就行」 | 他自己也没分清哪个是核心 | 你猜一个做三个月，做完他说「这才是我想要的」 |
| 「反正都要做」 | 他要的是结果，不是顺序 | 你按他的顺序做，一半功能依赖还没建好的地基，全是空转 |
「最小可交付」最容易被做成空话——什么都能砍一点，结果砍出一个不能用的东西。要有能判定的条件，不是感觉。下面四条全部满足才算 MVP，缺一条就说明还得再切。
| 标准 | 怎么判定 | 为什么是它 |
|---|---|---|
| 能不能在 14 天内上线 | 把工作量拆到「周」而不是「月」——超过两周的切片不是切片，是分期付款 | 时间是最硬的约束。14 天内能做完，你才有底气面对客户的进度质疑 |
| 上线当天就能被一线用起来 | 一线人员不需要培训、不需要换账号、不需要先做一遍数据准备就能上手 | 如果上线第一天没人能用，它就进不了真实业务，永远只能停在「演示挺好」 |
| 出问题能在 1 小时内回滚 | 上线前必须实测过一次回滚，不是「理论上能」而是「真的退过」 | 不能回滚的功能，等于把客户的日常经营押在一段还没跑稳的代码上 |
| 不依赖还没建好的数据源 | 逐条列出这个切片读哪些表/接口，逐个确认已存在且有真实数据 | 这一条最容易被忽略。依赖没建好的地基，等于上线即空转 |
客户是门窗/卫浴经销商，真实业务流是四步：订单 → BOM → 玻璃图纸 → 报价。客户要求用真实数据校验，拿出来的校验规模是：33,176 笔真实订单、387 个经销商、2,799 个型号。
这套数据一跑，结论就出来了——不是「7 个系统一起上」，而是「四层，按依赖顺序上」。
| 层 | 做什么 | 为什么是这个顺序 |
|---|---|---|
| P0 数据地基 | 建订单↔经销商 ID 对照表；建出厂价红线（PV / KW / K1 三档）；打通尺寸数据源 | 没有这三样，后面全是空算。这是所有功能的地基 |
| P1 引擎 | 型号匹配与厚度匹配引擎 | 已经验证可用：型号匹配 96.6%、厚度匹配 95.2%。这是最快见效的部分 |
| P2 拆单与 BOM | 把订单自动拆成生产工单 | 依赖 P1 的匹配结果，也依赖 P0 的价格档位。必须等前面两层落地 |
| P3 派单 | 对接供应商 / 黑湖小工单 | 排在最后。因为它是外部系统对接，不确定性最大，放在地基跑稳之后才接 |
| 校验项 | 真实覆盖率 | 卡在哪一层 |
|---|---|---|
| 型号匹配 | 96.6% | P1 已验证可用 |
| 厚度匹配 | 95.2% | P1 已验证可用 |
| 尺寸数据 | 29% | 🔴 瓶颈，在 P0 要打通的数据源 |
| 订单↔经销商对应 | 0% | 🔴 完全缺失，是 P0 的第一件事 |
排期最常见的死法是说「大概两个月」。这句话说出来你就输了——两个月之后客户一定会问「进度到哪了」，而你答不上来。
可估算的做法是不按功能拍脑袋，按可数的单位估。这三个维度能覆盖绝大多数工作量：
| 估算维度 | 怎么数 | 参考量级 |
|---|---|---|
| 接口数 | 需要新写或改造的对接点，一个算一个 | 含外部系统对接要额外加权，对接方不受你控制 |
| 页面数 | 一线/后台各自的操作页，含列表、详情、表单 | 列表页和表单页的复杂度差很多，别按一个价算 |
| 数据字段数 | 要新补齐或清洗的字段，一个算一个 | 字段数是隐藏工作量的大头，见下面的真实教训 |
数完之后换算成周，而不是报月。给人报「3 周」比报「1 个月」更可控，因为三周之后你真的能拿东西给人看。一个月之后你只能说「快了」。
这张表是防扯皮的关键。它把「砍需求」从一句情绪化的争论，变成一张有理由、有复查时间的清单。左边这些需求不是不做，是不在这一期做。
| 被砍掉的需求 | 砍的理由 | 什么时候再考虑 |
|---|---|---|
| 移动端App | 一线现在的核心动作在电脑端；先让电脑端跑通，避免同时维护两端交互 | 电脑端稳定运行满1 个月，且一线明确提出手机端需求 |
| 供应商协同门户 | 涉及外部方账号体系和权限，属于外部依赖，不该由第一期承担 | P3 派单跑通、且已有明确合作方愿意配合 |
| 自定义报表中心 | 各角色报表需求差异大，需求会无限扩张；先用固定几张报表满足验证 | 固定报表已验证够用，且客户愿意为自定义付费 |
| 多组织/多门店权限体系 | 本期只服务一家经销商体系，权限模型按单组织设计即可 | 确认要接入第二家体系时 |
| 历史数据全量迁移 | 成本高、对本期价值低；新系统只跑增量，旧数据可查即可 | 客户明确要求查三年以上历史数据时 |
| 坑 | 表现 / 对策 |
|---|---|
| 需求蔓延 | 上线后客户「顺便再加一个小功能」。对策：新需求一律单独评估、单独排期、单独报价。算谁的变更要写清楚——谁提的、影响哪一层、延几天、多少钱，一次性讲明白，不要在开发过程中零散地做「人情加单」 |
| 用「先做着看」掩盖没想清楚 | 需求没想透就先动手，做一半发现不对，推倒重来。产出：所有功能开工前必须能一句话说清「它解决什么问题、谁用、怎么算成功」。说不清就不许开工 |
| 把 P0 估成一周，结果做了两周 | 数据地基最容易被低估，因为它的「工作量」大部分是等客户给数据、反复对字段，而这些时间不算在你写代码的时间里。对策：估算时把等待客户的时间单独列一行，不算进开发工期，但要写进交付承诺的日历 |
| 切片切在错误的位置 | 把最花哨、最好演示的功能放第一期。后果：演示很惊艳，一线不用。对策：第一期要选一线每天都要用、且当前最痛的那一步 |
| 层与层之间留了「后面再说」 | P1 用临时假数据跑通，客户验收时看到的是演示效果，上线才发现没法用真数据跑。对策：每一层验收都必须用真实生产数据 |
我先明确一个立场：切片不是砍需求，是把风险分期。一次上全套看起来省事，实际上是把所有风险堆在同一个时间点爆掉——出了 bug 分不清是哪块引起的，数据错了不知道回滚哪一段，客户一线停工了没人能顶上。最后往往是双方都受损。
德莉玛这个项目就很典型。客户是门窗/卫浴经销商，业务流是订单 → BOM → 玻璃图纸 → 报价，要求用33,176 笔真实订单、387 个经销商、2,799 个型号做校验。客户一开始的想法也是「几个模块一起上」。但跑完校验我就知道这条路走不通——型号匹配 96.6%、厚度匹配 95.2% 都还行，可尺寸只有 29%、订单↔经销商对应是 0%。
所以我把方案改成了四层，按依赖顺序上：P0 数据地基（订单↔经销商 ID 对照表、出厂价红线 PV/KW/K1 三档、打通尺寸数据源）→ P1 引擎（型号与厚度匹配）→ P2 拆单与 BOM → P3 派单（对接供应商/黑湖小工单）。这里最关键的判断是：P0 不做完，P1 做出来也是废的。因为尺寸和客户匹配是残缺的，引擎算得再准也只是在错的基础上算得更快，而且它不会报错——它会给出一张看起来完全正常的报价单，这比直接报错危险得多。
另外两件我会坚持做的事：一是每一层验收都必须用真实生产数据，临时假数据演示得再漂亮，上线就会发现跑不通；二是写清「不做什么」清单，把砍掉的需求连同理由和复查时间一起让客户签字。P1 也不作废——它已经验证过了，等P0 的数据补齐就能直接产出正确结果。这就是分层的好处：每一层都在为下一层铺路，客户两周就能看到东西，而不是等三个月才知道方向对不对。