定制软件报价之前，把需求写成一次真实操作

先做一个小而完整的尝试

• 写清使用角色和起点。

• 逐步描述输入与选择。

• 指出最耗时的重复动作。

• 列出异常情况。

• 定义最后能检查的结果。

容易忽略的地方

先确认必须解决的问题，别把所有听起来有用的功能都放进首期。截图和样本可以去掉个人信息后再用于评审。

做完以后，看什么

用一条典型流程作为评审样例，逐项核对页面、权限、数据和完成标志，再讨论范围与费用。

验收时别漏掉边界

把需求换成一个脱敏操作样本：谁收到什么资料，从哪里开始，经过哪些判断，最后交出什么结果。让供应方照样本演示，并问缺字段、重复提交和审批退回时怎样处理。只讲“要一个管理系统”无法比较报价，因为双方可能想的是完全不同的流程。

把下一步写到纸上

用确认过的操作列出本次必做、可延后和不在范围内的事项，再讨论工期与报价。接口、历史数据导入、部署和培训分别注明是否包含。会议后由双方核对这份范围，新的想法另行评估，不默认为已经包含在原承诺中。

继续了解

需求评审开会前，准备一个脱敏业务样本

产品演示别只看大屏：让供应方走完一项任务

机构数字化先做哪一步？从最频繁的重复工作开始