从需求到验收：企业软件定制开发全流程时间表与关键交付物

定制软件最贵的成本从来不是人力，而是“以为已经对齐了”。甲方以为买的是一个能跑起来的系统，乙方以为接的是一份会不断生长的需求清单。一个 60—90 天的项目，失控往往不是发生在第 60 天，而是从第 7 天就已经埋下伏笔：需求只用语音聊了半小时，没有人把它写成一页能被验收的条目。

所以下面这份时间表建议核对。不谈交付物的排期，都是让人安心的说法。

一、第 1—15 天 需求与方案：把“我要一个系统”拆成可验收的条目

核心交付物：《需求规格说明书》《原型交互稿》《需求确认单》

• 每个功能点都必须配一条验收标准，能明确判定通过或不通过。写不出验收标准的功能，基本等于没想清楚。
• 需求确认单要签字冻结，之后的变化一律通过变更单处理，按工时计价。这么做并不只是为了约束甲方，更是为了让双方都看见“加一个功能，等于少三天工期”。
• 我的经验是：需求阶段每多投入 1 天，后期平均省下 3 天返工。想省掉这 15 天的项目，通常要在上线前补回 30 天。

二、第 16—30 天 设计与技术方案：这一步决定后面 60 天的返工率

核心交付物：UI 设计稿（含移动端）、数据库 ER 图、接口文档、技术架构说明

• 数据库结构一旦上线再改，成本会指数级上升：一处字段变更，可能牵连报表、接口和历史数据迁移。
• 务必要在第 30 天前把接口文档审阅。接口文档是判断一个团队工程素养成本最低的方式：字段命名混乱、没有错误码约定的，后期联调一定痛苦。
• 涉及第三方对接（支付、短信、ERP、硬件）的，这一阶段就要拿到对方技术文档，并完成连通性验证，千万别拖到开发后期才发现对不上。

三、第 31—70 天 开发与联调：用“能演示的进度”代替“口头的进度”

核心交付物：每两周的可运行版本、测试环境地址、缺陷清单（Bug List）、周报

• 不接受“整体完成 90%”这种表述，只接受“哪些功能现在点开就能用”。
• 每两周演示一次，用接近真实的数据跑通主流程。演示不通过的部分，优先级高于任何新功能。
• 每周看一次缺陷清单的“新增/关闭”曲线。缺陷只增不减的项目，一定会在验收期集中暴露出来。

四、第 71—90 天 测试、验收与交付：验收不只是签字，更是资产交割

核心交付物：测试报告、验收清单、源码与部署文档、数据库脚本、账号权限清单、培训记录

• 验收清单必须在开发前就写好，验收时逐条打勾，不再引入新需求。
• 源码、部署文档、第三方组件清单（含授权方式）是三项必须交付的内容。拿不到源码和部署文档，等于把未来的迭代权交给供应商。