先记住一句
别先列几十个功能。先选出一条最影响经营、也最有条件改变的业务链路，把它完整跑通。
01．一期范围，不是一张功能清单。
“客户管理、审批、报表、库存都要”，这只是功能名称，还不是项目范围。真正可执行的范围，应该能说清一笔业务从哪里开始、经过谁、什么状态算结束。
比如“售后数字化”太大，但“客户报修后，客服在 10 分钟内受理，派到具体工程师，完工后由客户确认”就已经是一条可以设计、开发和验收的链路。
定一期时，至少回答四个问题
- 现在最容易出错的环节是哪一段？
- 这个问题一周大约发生多少次？
- 哪些角色必须参与，哪些可以二期再接？
- 上线后，原来哪张表、哪个群或哪步重复录入可以停掉？
02．真正天天用的人，要尽早参与。
老板决定要不要做，但一线员工决定系统最后能不能用起来。如果只听管理层讲目标，却没看客服怎么接电话、仓管怎么找货、工程师怎么在现场反馈，页面很容易看起来完整，用起来别扭。
不用召开很大的会。选一名熟悉实际工作的人，让他按真实方式走一遍，就能暴露很多隐藏规则：什么情况要加急，什么情况可以越过审批，谁有权改价格，什么数据不能让所有人看。
管理者关心
进度、异常、结果和责任是否看得见。
使用者关心
今天要做什么、怎么做、出错后怎么回退。
03．验收标准，要在开发前说。
“功能做了”不等于“业务能跑”。一个实用的验收标准，应该是一组真实操作：用测试账号登录，建一笔单，走完一次审批，模拟一个异常，再核对最后的数据和通知。
- 主链路能否从头到尾完成？
- 不同角色是否只看到该看的信息？
- 缺字段、重复提交、取消和退回时是否有明确提示？
- 需要导入的旧数据是否核对过数量和抽样结果？
当这些标准能写进一张清单，报价不再只是“做多少功能”，而是对一个明确结果负责。