业务部门准备定制开发，先把这五个实施问题说清楚

业务部门提出定制开发需求时，常会先列出页面、按钮和功能清单，例如客户档案、任务提醒、统计报表或移动端审批。这些内容有助于表达设想，但还不足以支持设计与开发。真正影响项目能否落地的，是业务问题是否明确、流程规则是否完整、数据是否可用、系统边界是否清楚，以及验收是否有共同标准。

在进入原型和技术方案前，业务部门负责人可以组织使用岗位、流程管理者和信息化人员，围绕以下五个问题形成书面结论。它不必是一份篇幅很长的文档，但需要让参与者对“为什么做、做什么、不做什么、怎样算完成”有一致理解。

一、这次建设具体要解决什么问题

“建设客户管理系统”是项目名称，不是问题定义。需求应落到具体岗位和工作场景：谁在什么时点遇到什么阻碍，目前怎样处理，阻碍会造成哪些可观察的后果。比如信息分散在多个表格、跟进记录无法交接、审批状态难以查询，这些描述比“提高效率”更便于分析。

还应区分根因与表象。若问题来自职责不清、业务口径频繁变化或基础资料长期缺失，仅增加软件功能通常无法解决。业务部门需要先确认哪些问题通过管理调整处理，哪些问题确实需要系统承接。这样可以避免把所有期待都装进首期范围。

二、流程在正常和异常情况下怎样运行

功能清单说明系统有什么，流程说明人员怎样使用。梳理时应从触发条件开始，依次写清参与岗位、处理节点、状态变化、时间要求和结束条件。对客户管理场景，还要考虑客户归属变化、重复客户、人员离职交接、资料退回和逾期未处理等情况。

异常分支不能等到测试阶段再补。网络中断、接口不可用、必填资料缺失、审批人不在岗、重复提交等问题，都会影响实际操作。业务部门应明确系统是阻止提交、暂存待办、允许授权人员处理，还是通过提醒转入人工流程。规则越早确认，设计返工越少。

三、数据从哪里来，由谁维护

页面上的每个关键字段都应能回答三个问题：来源是什么，口径是什么，谁负责维护。数据可能由用户录入，也可能来自现有客户、合同、订单或组织系统。若来自接口，需要确认唯一标识、同步方向、更新频率、失败处理和历史数据范围；若由人工维护，需要明确必填条件、修改权限和纠错方式。

历史数据迁移也应单独评估。表格数量多不代表数据可直接导入，重复记录、字段含义不一致、缺失值和无效状态都需要处理。业务部门应参与确定清理规则与抽查方法，不能把业务口径完全交给开发人员猜测。涉及联系人、交易条件等敏感内容时，还要明确最小使用范围和保留要求。

四、本期系统边界和协作边界在哪里

定制开发容易出现范围不断扩大的情况，原因往往不是需求多，而是边界未被明确。首期范围应列出包含的岗位、流程、终端和报表，也要列出暂不包含的内容。对于与现有系统重叠的能力，需要确定由哪个系统作为数据来源，哪个系统负责执行，避免同一信息在多处维护。

协作边界同样重要。业务部门负责确认规则、提供资料和安排验收人员；信息化人员负责账号、网络、接口和安全要求；开发团队负责方案实现、测试修复与交付说明。若关键接口由第三方系统提供，应提前确认对接方式和协调责任，不能把外部依赖默认为随时可用。

五、怎样判断系统达到可用状态

验收不宜只检查页面能否打开、按钮能否点击。更有效的方法是按真实业务路径编写场景：给定用户角色、前置数据和操作步骤，说明期望状态、权限结果、通知结果与数据写入结果。正常流程、退回修改、重复提交、无权限访问、接口失败和数据缺失都应有对应场景。

验收材料还应说明问题如何分级、由谁确认修复，以及哪些差异属于缺陷、哪些属于新增需求。新增需求需要进入变更流程，评估对范围、设计和排期的影响，而不是在验收现场口头追加。对于上线后才能观察的使用问题，可以建立反馈清单，但不能用尚未发生的效果数字代替交付标准。

把五个问题整理成可执行的需求基线

以上内容可以沉淀为一份简洁的需求基线：业务问题与目标、角色和流程图、关键规则、数据字典、接口清单、权限矩阵、范围说明和验收场景。每项内容标明确认人和版本，发生变化时记录原因与影响。原型设计和技术方案都应以这份基线为依据。

业务部门负责人不需要代替产品经理编写技术文档，但需要对业务规则作出明确选择。定制开发的价值不在于功能数量，而在于把组织已经确认的流程、数据和责任稳定地落到系统中。先把五个问题说清楚，能够让设计讨论更聚焦，也让后续开发、验收与运营有据可查。

项目检查表

作者：云迈科技项目顾问团队
审核：企业数字化方案顾问