数字化项目失败，很少是技术做不出来，多数是范围失控、责任不清、验收标准含糊。这三件事都发生在写代码之前。
这篇讲从需求到复盘的几个关键动作。
需求阶段：把目标写成可验证的句子
「提升管理效率」不是目标，因为它无法验证。可验证的目标长这样：在什么范围内、让谁、能够做什么、达到什么程度。
比如：「车间主任能在每天早会前看到前一日各产线的完工数量与异常记录，数据延迟不超过 2 小时。」
这句话里包含了范围、使用者、具体行为和可测量的条件。它能直接变成验收标准。
写不出这样一句话，说明需求还没想清楚，这时候启动项目是危险的。
范围阶段：明确写下不做什么
需求文档通常只写做什么。把「本期不做什么」也写下来，是防止范围蔓延最有效的一招。
不做清单要具体到功能级别，并且写明原因：是留到二期，还是判断价值不足，还是依赖条件不具备。这份清单在项目中期会被反复翻出来，省掉大量争论。
责任阶段：每件事只能有一个人
项目里最危险的表述是「某某部门负责」。部门不会做决定，人才会。
至少这几个角色要落到具体的人：
- 业务负责人——对目标达成负责，有权决定范围取舍
- 关键用户——参与设计、试用、反馈，代表实际使用场景
- 技术负责人——对方案与交付质量负责
- 数据责任人——对口径与数据质量负责
第四个角色最常缺失，也是后期扯皮最多的地方。
执行阶段：短周期，可见进展
周期越长，偏离越远。建议以两到三周为一个节奏，每个节奏结束时有可以看到、可以试用的东西——哪怕只是一个页面、一张报表。
「可以试用」这个标准很重要。演示文档不算，必须是关键用户能自己点进去操作的东西。只有真实操作才会暴露设计问题。
验收阶段：按当初那句话验
验收争议基本都源于标准是在验收时才定的。如果需求阶段写了可验证的句子，验收就是照着念。
验收要覆盖三层：
- 功能——能不能做到当初写的那件事
- 数据——口径是否一致，历史数据是否可用
- 交接——文档、培训、权限、后续维护责任是否清楚
第三层经常被跳过，结果是项目组一撤，系统就没人会用、没人敢改。
复盘阶段：记下来，不然会重来
项目结束后一到两周做复盘，只回答三个问题：
- 哪些估计错了？错了多少？
- 哪些环节的等待超出预期？为什么？
- 下一个项目要换的做法是什么？
复盘结论要写进下一个项目的启动材料，不然它只是一次情绪释放。
自查清单
- 项目目标能不能写成一句可验证的话？
- 「本期不做什么」写下来了吗？
- 数据口径的责任人是谁？
- 最近一个节奏交付的东西，关键用户自己操作过吗？
- 上一个项目的复盘结论，这次用上了吗？