定制软件项目里最常见的场景是：功能都做出来了，甲方却说"这不是我要的"。问题往往不在开发，而在开工那一刻——需求是"能想象"的，却不是"能验收"的。
一、"需求写不清"为什么会变成真金白银
一句"要一个客户管理模块"，可以理解成 3 张表 5 个页面，也可以理解成带跟进记录、合同、回款、提醒、报表的一整套 CRM。两种做法的工期能差三倍。
风险在于：范围的定义权没有在开工前转移。开工后再定范围，等于把定价权交给了对方。
二、模糊需求 vs 可验收需求
| 模糊需求（不可验收） | 可验收需求 |
|---|---|
| 客户信息要能管理 | 新增/编辑/删除客户；字段 14 个（见字段表）；手机号唯一；删除为软删除，回收站保留 30 天 |
| 要有权限控制 | 角色 3 类：管理员、部门主管、普通员工；主管可见本部门数据；字段"成本价"仅管理员可见 |
| 报表要好看 | 首页 4 个指标卡 + 3 张图表；数据每 10 分钟刷新；支持导出 Excel |
| 要能用手机看 | 手机浏览器可打开；最小支持 375px 宽；核心 3 个页面在一屏内完成主要操作 |
三、把需求写成可验收的四个要素
- 谁用 —— 写清角色，不写"用户"。同一功能对不同角色就是不同需求
- 做什么 —— 动词开头的动作描述，一条只写一件事，能拆就别合
- 什么条件 —— 必填、唯一、上限、状态流转的前提条件
- 什么算完成 —— 可观察的结果：页面出现什么、数据变成什么、导出几个字段
四、一个对照示例
正例："业务员提交报销单后，部门主管在待办里能看到；主管点通过，状态变【已通过】并推送消息给财务；主管点驳回必须填写驳回原因（不少于 5 个字）。"——每一条都能当场演示、当场判定。
五、需求确认的三道关口
需求清单签字
按模块列出功能条目，逐条标注"本期做/下期做/不做"，双方签字确认
原型走查
把关键页面画出来点一遍，比文字描述少一半误解
变更单机制
开工后的任何新增，一律走变更单：写明工作量与工期影响，双方确认后再排期
这三道关口里，变更单机制是最容易被跳过、也最救命的一条。没有它，项目就会滑向"无限追加"。
六、常见问题
需求文档要写多少页才够？
不看页数看覆盖率。判断标准只有一条：把文档交给一个没参与过沟通的开发，他能不能据此把功能做出来并自测。能做到，就够。
甲方内部意见不统一怎么办？
必须指定唯一的需求确认人，并写进合同。多人并列拍板，等于没人拍板。
原型用什么画？
工具不重要。哪怕纸上画拍照也行——关键是让业务方在"页面"上而不是在"文字"上确认。
上一篇没有了