准备做定制软件开发时，最容易被低估的是范围。很多项目一开始聊得很顺：做一个系统、提高效率、统一管理。真到开发时才发现，每个人理解的系统都不一样。
业务方想要看板，运营想要批量导入，财务想要导出，管理层想要报表，使用者只想少填字段。需求都合理，但第一版不可能全部做完。范围拆不清，后面就会变成不断加功能。
先写角色，不先写页面
页面是结果，角色才是起点。一个业务系统里，发起人、审核人、处理人、管理员和负责人看到的信息不一样，能做的动作也不一样。
如果角色没分清，页面设计会很快失控。今天给运营加按钮，明天给主管加筛选，后天又发现普通用户看到了不该看的数据。权限问题越晚发现，返工越大。
把流程写成状态变化
很多需求文档会写“提交申请”“审批通过”“完成处理”。这些词不够。更有用的是状态：草稿、待提交、待审核、已驳回、处理中、已完成、已取消。
状态写清楚后，谁能改状态、改完通知谁、哪些状态能统计、哪些状态能导出，都会跟着清楚。定制软件开发的很多复杂度，其实藏在状态里。
数据字段要拿样例说话
不要只说“客户信息”“订单信息”“项目资料”。最好拿一份现有表格或脱敏样例出来，看字段是什么、哪些必填、哪些可以为空、哪些字段会变化。
字段决定数据库，也决定页面和校验。字段越早确认，开发越稳。字段如果长期不稳定，第一版就要留出备注、附件或扩展字段，不要硬做死。
第一版只做一条主流程
第一版要能让真实用户跑完一条关键流程。录入、提交、处理、状态变化、结果查看、导出或统计，至少要形成完整链路。
复杂报表、自动化提醒、多端同步、精细权限、深度接口集成，可以放到第二版。不是不做，而是等核心流程跑起来后再做。
- 必须提前确认：角色、权限、状态、字段、接口、验收人。
- 适合第一版：高频流程、基础后台、必要导入导出、日志和备份。
- 适合后置：复杂 BI、低频功能、过细配置和不稳定想法。
验收不能只看页面
定制软件开发的验收，要用真实或脱敏数据跑一遍。换不同角色登录，看权限是否正确；提交错误数据，看提示是否能指导下一步；导出数据，看字段是否符合业务使用。
如果上线后还要靠人工在群里解释流程，说明系统还有没写清的地方。这些内容应该进 backlog，而不是靠临时沟通长期补。
准备资料清单
沟通前可以先准备：现有表格、流程截图、角色说明、老系统入口、接口文档、导出样例、常见异常、上线时间限制和验收负责人。资料不需要一次完美，但越真实越好。
范围拆清楚后，定制软件开发才会从“做一个系统”变成“先上线哪条流程”。这一步省不掉。
别把所有想法都放进第一版
很多定制软件项目会在早期把“以后可能要用”的功能一起写进范围。这样看起来完整，实际会拖慢上线。更好的做法，是把需求分成三层：必须支撑主流程的功能、上线后很快可能补的功能、暂时只记录不开发的想法。
这个分类不是为了砍需求，而是为了让每个功能都有理由。一个功能如果说不清使用频率、负责人、数据来源和验收方式，就先不要进入第一版。
接口和历史数据要单独评估
系统是否要接老系统、是否要迁移历史数据，会明显影响开发范围。老系统有 API、能导出、字段稳定，处理起来相对清楚；如果只能人工复制，或者数据格式经常变化，就要先设计过渡方案。
历史数据也一样。不是所有旧数据都值得迁移。可以先分清哪些数据上线当天必须可查，哪些只需要留存备查，哪些可以通过附件或归档方式处理。
沟通时可以直接带着问题来
如果你还没有完整文档，也可以先带着真实问题沟通：现在最耗时的一步是什么，哪些数据经常错，谁最痛苦，老板最想看什么结果，系统上线后谁每天使用。
这些问题比一份漂亮但空泛的功能列表更有价值。定制软件开发要落到真实流程里，先说清现实，再设计系统，后面才好验收。
