软件定制开发不是“需求开会—程序员编码—客户验收”三段式。稳妥的流程应让每个阶段都有输入、产物、确认人和未决问题，后续发现偏差时才能定位从哪里开始变化。
| 阶段 | 输入 | 产物 | 确认人 |
|---|---|---|---|
| 1. 问题澄清 | 现有流程、表格、单据、系统截图 | 现状流程、目标流程、问题清单、范围说明 | 业务负责人 |
| 2. 原型确认 | 一期范围、核心流程、角色与状态 | 确认原型、需求版本、待决项 | 业务负责人、关键岗位 |
| 3. 数据与权限设计 | 确认原型、数据样例、角色范围 | 字段表、主数据规则、权限矩阵、迁移说明 | 业务负责人、技术或系统管理员 |
| 4. 开发联调 | 字段表、权限矩阵、接口约定 | 可测试版本、联调结果、已知问题、日志位置 | 项目组、技术或系统管理员 |
| 5. 真实试运行 | 可测试版本、实际单据 | 按缺陷、规则争议、培训问题分类的问题清单 | 关键岗位、业务负责人 |
| 6. 上线准备 | 问题清单、初始化数据、账号与权限 | 上线清单、培训与支持安排、回退方案 | 业务负责人、技术或系统管理员 |
| 7. 验收交接 | 合同、需求基线、验收用例 | 验收记录、未关闭事项、交接资料 | 业务负责人、技术或系统管理员 |
1. 问题澄清：先定义要改变的业务结果
调研不从功能菜单开始，而从现有业务走法开始。业务人员带着表格、单据和系统截图说明谁在什么条件下做什么、数据流向哪里、异常如何处理。项目组据此确认一期目标、涉及岗位、系统边界和范围外事项。
这一阶段的产物可以是现状流程、目标流程、问题清单和范围说明。未确定的规则要显式记录，不能藏在会议纪要的一句“后续再议”里。
2. 原型确认：把角色和状态放进页面
原型要覆盖核心流程，而不只是首页效果。每个页面标出使用角色、字段来源、可执行动作和状态变化；审批、驳回、撤回、作废等分支也要能走通。
确认原型时同步维护需求版本。页面调整若改变数据结构、接口或权限，应评估影响后再纳入，避免把“改个按钮”当作没有成本的变化。
3. 数据与权限设计：在开发前消除口径冲突
字段表应说明名称、类型、是否必填、取值规则、来源和负责人。客户、商品、订单、组织、员工等主数据要确定唯一标识及主系统；历史数据是否迁移、由谁清洗也要写清。
权限矩阵需要覆盖菜单、数据范围、字段和动作。管理员、部门负责人、普通员工、离职人员和外部协作方的边界若不明确，页面完成后再补权限通常会引发结构性返工。
4. 开发联调：按可验证链路交付版本
迭代计划应围绕业务闭环拆分，例如从客户创建到订单审批，而不是分别汇报“前端完成多少、后端完成多少”。每次交付都附已完成功能、测试入口、已知问题和下一步依赖。
涉及 ERP、CRM、钉钉或财务软件时，联调需要固定接口字段、触发时机、数据方向、失败重试和日志位置。接口返回成功后，还要核对目标系统是否生成正确业务记录。
5. 真实试运行：让实际岗位发现流程问题
内部测试解决代码缺陷，试运行则验证业务能否照常完成。选择实际使用岗位，按日常单据走一遍新增、修改、审批、导出和异常处理，记录卡点属于缺陷、规则争议还是培训问题。
试运行期间应限制随意新增范围。影响主流程的问题优先处理，体验优化和新想法进入后续清单，防止项目一直停留在“还差一点”。
6. 上线准备：数据、账号和回退方案同时就绪
上线清单应覆盖生产环境、域名或证书、账号与权限、初始化数据、备份、监控、通知、培训和支持联系人。旧系统何时停止录入、新旧数据如何衔接，也要通知到实际岗位。
关键流程需要预设回退或人工补录方式。出现接口失败、数据导入错误或权限遗漏时，业务人员应知道由谁判断、在哪里登记、如何恢复。
7. 验收交接：按证据关闭范围
验收以合同、需求基线和用例为依据，保留输入数据、预期结果、实际结果和问题状态。未关闭事项单列影响、处理方式和完成条件，避免以“先签字再慢慢改”掩盖边界。
交接物根据合同核对源码或构建物、部署说明、数据库与配置、操作手册、接口文档、日志入口、备份恢复和运维责任。流程到这里的结果不是一张签字单，而是一套客户能够继续使用和管理的系统资料。
