六天要拿出体验版：极短工期下先定砍什么，再定怎么验
一、极限工期不是例外，是必须预备的一种排期形态
据公开报道，有团队在假期接到紧急任务，要在几天内完成联调、再几天拿出供内部上会测试的体验版，报道给出的总工期约六天。天数、产品名与细节一律按公开报道处理，不是本篇判断的依据，我们也不对那个团队作任何评价。之所以值得写，是因为几乎所有做交付的人都遇到过同构的处境：客户或上级把一个已经定死的期限放在桌上，谈判空间接近于零。
多数团队在这种时刻的失败方式不是做不完，而是”默认全都要做”——范围不动，工期动，于是所有质量约束被均匀稀释，最后连一条完整的演示路径都保不住。我们的立场相反：极限工期不等于放弃工程约束，而是把约束前移，只保那几条绝对不能破的线，其余全部显式放弃。这要求动手之前先有一张裁剪表，而不是边做边砍。砍东西的决定在深夜赶工时做，砍掉的永远是没人记得的角落；在开工前第一小时做，砍掉的才是经过判断的部分。
二、先查四项前置条件，缺一就不接
接下一个极限排期之前，四项前置条件必须先确认，任何一项缺失都意味着风险无法闭合。
第一项，可演示范围冻结。必须白纸黑字写下”这次上会只演示哪几条路径”，冻结之后新增或改动任何一条都算破线，需要重新评估整个期限。范围冻结是极限工期唯一真正的杠杆：工期不可谈，范围是唯一可谈的变量。
第二项，数据与安全底线不动。工期再短，真实用户数据不进演示环境、生产凭据不落在个人机器、对外接口不绕过鉴权这三条不许让步。功能可以粗糙，安全没有灰度——出了安全事故，没有人会问它是不是赶工期间发生的。
第三项，回滚通道。体验版如果部署在与真实系统共享的环境里，必须确认能在十分钟内退回原状态；回滚不做演练就约等于没有。
第四项，上线后的值守安排。体验版被采用或被催促继续推进时，谁值守、故障找谁、什么时候补全，要在接排期时就写下来，而不是交付之后再问。值守缺位的赶工交付，等于把一个没人认领的系统放进生产环境。
三、三档裁剪表：把砍什么写成文档
裁剪只有写成三档才不会失控。第一档”必须真做”，是演示路径上直接暴露的环节，包括主流程、失败时的提示、以及评审人一定会点的那两三个按钮。第二档”可用假数据顶”，功能形态保留、数据是造的：报表先接固定样例，搜索先用预置词表，外部依赖先做挡板。假数据必须显式标记，字段命名里带上演示字样，防止它在后续开发中被当成真实通路继续盖楼。第三档”本次明确不做”，把历史数据迁移、多端同步、异常批量场景这类”大家都知道要做”的项目逐条列出并写明不做。
| 档位 | 判定标准 | 示例 | 文档要求 |
|---|---|---|---|
| 必须真做 | 演示路径与评审必点项 | 主流程、失败提示 | 逐条列路径，冻结后不许加 |
| 假数据顶 | 形态可见、可后接真源 | 样例报表、预置词表 | 标记为临时方案并登记 |
| 明确不做 | 本次交付不依赖它 | 历史迁移、多端同步 | 写明不做的理由与补齐时间 |
“明确不做”必须写进文档，理由有三：口头说”这个先不管”，评审人会默认它已经做了；不写下来，验收时它作为缺席者被追溯追问，全部火力对准执行层；不写理由和补齐时间，这三个字会在下一个版本变成”原来当时就没做”的账外债。裁剪表的本质是一份对预期差异的管理文件，让所有人在第一天就知道这次交付的边界长什么样。
四、体验版不是可上线版本，差别在这四处
极限工期最常见的次生事故，是体验版被直接当生产版推出去。两者的技术差别固定在四个地方：鉴权、限流、日志、数据落库。
体验版通常用固定账号或白名单进门，生产版需要完整的身份体系与权限边界；体验版不需要限流，因为它只面对会议室里几个人，生产版的第一批真实流量会击穿任何没做过并发验证的环节；体验版常常关掉或简化日志，出问题靠现场围观，生产版的排障完全依赖日志留痕；体验版的数据可能只在内存或临时库里，重启就丢，生产版要求落库、要求备份、要求考虑脏数据的清理。四处差别中任何一处，都是把体验版推上生产环境时要单独补的工程，没有”顺手就能补上”的余地。我们的做法是在体验版交付物里放一行固定声明：本版本缺少哪几项生产能力，逐项列出。这行字在风平浪静时没人看，在有人提议”先直接发出去”时是唯一的拦阻物。
五、上会评审只认四份证据
内部上会是极限工期的验收现场，评审该看的不是功能列表，是四份证据。
第一份，可复现路径。演示不能依赖特定机器、特定网络或特定操作顺序：给一台干净环境，让没参与开发的人按文档走一遍，走得通才算路径成立。赶工出来的演示常常是”作者限定”的，换个环境就断。第二份，已知缺陷表。极限工期一定带着一串已知缺陷，把它们列出来并标注影响面，远好过评审现场被人撞见一个——前一种情况是风险被管理，后一种情况是风险被发现，管理者的信用完全不同。第三份，数据真实性说明。哪些环节是真的在跑，哪些是假数据顶的，逐条对照裁剪表讲清楚，防止评审基于演示效果做出”已经接近可对外”的错误判断。第四份，失败时用户看到什么。演示永远展示成功路径，评审必须当场看一次故意失败：断网、错输入、超时，看系统给出的提示是体面的还是崩溃的。第四份证据是产品成熟度最诚实的读数。
六、排好还债窗口，学会给替代方案
赶工结束不等于结束。临时方案必须在当天登记为技术债，每一条带三个字段：债务内容、回收时限、责任人。没有登记的技术债不会自己消失，它会在下一次升级、下一次人员变动、下一次安全审计时连本带息地回来，而那时已经没有人记得它的本金是什么。还债窗口要排进正常的迭代容量，而不是”等不忙的时候”——做交付的人都知道那个时候不存在。
也要说什么时候应该拒绝排期。拒绝的信号是明确的：四项前置条件中有两项以上无法确认，或可演示范围冻结不了。但拒绝排期不等于拒绝任务，正确动作是给替代方案——分阶段交付的切法：按天给出可用的中间物，第一天一条主干路径，第三天加上失败分支，期限当天拿出评审版。把”做不到”换成”这样做明天就能看到东西”，大多数期限的来源压力其实是对不确定性的焦虑，能每天看到进展的期限要求，通常就不再要求六天后的全量奇迹。洹拓给客户的合同里有一条从这套流程里长出来的条款：工期压缩申请必须附裁剪表，没有裁剪表的压缩申请按默认全量处理——这一条把”先定砍什么”从团队自觉变成了流程义务。