软件系统定制开发原型什么时候做？从第一版到开发确认的安排

能讲清核心业务，就可以开始第一版

原型启动前，至少应初步了解业务目标、主要角色、典型流程和首期边界。否则，设计人员只能根据零散功能名称猜测页面，后续容易反复调整。

以一个假设的设备维修系统为例，企业希望把员工报修、部门确认、维修调度、处理记录和结果验收串起来。

开始前可以先说明：谁提出报修，谁决定维修安排，现有设备资料在哪里，哪些步骤首期必须纳入，系统最终需要留下什么记录。

这些信息不必整理成厚重文档。现有表单、流程草图、脱敏样例和访谈记录，都可以成为第一版的输入。遇到尚未达成一致的内容，应明确标记，不能在页面上悄悄替企业作决定。

此时适合先做流程草图和简单页面草图，用较低成本验证理解。颜色、图标和视觉效果可以后续完善，不应阻碍核心业务讨论。

第一轮先走通流程，再补页面细节

第一版原型完成后，评审重点应放在“事情怎样办完”，而不只是逐页检查有没有缺少按钮。

沿用维修示例，可以拿一条模拟报修记录，从员工提交开始，一直走到维修结束和结果确认，观察每一步由谁操作、状态如何变化、信息传给谁。

正常流程走通后，还要补充例外：重复报修是否合并，缺少备件怎样暂停，维修人员能否转派，提交人撤销申请后哪些记录保留。

这些问题可能改变页面结构、数据关系和权限。因此，先讨论完整流程，再细化字段、提示和交互，通常比逐个页面孤立确认更容易发现遗漏。

原型逐步深入时，也要明确字段含义、必填条件、计算口径和操作后果。无法直接画在页面上的规则，可以附在说明中，不能默认开发人员会自行理解。

原型不一定必须做成可以点击的演示。简单流程可以用静态草图确认；涉及多角色切换、复杂状态和操作反馈时，再增加交互表达。

技术与数据验证要同步，不必等原型全部完成

原型与技术方案并不是严格排队的关系。界面讨论暴露出的约束，应及时进入技术评估；技术验证发现的问题，也可能需要反过来调整流程和原型。

例如，维修系统要读取设备台账、查询备件库存。如果现有平台能提供哪些字段、什么时候更新都没有确认，原型中的“实时库存”就只能算待验证设想。

历史数据也可能影响设计。旧设备编码重复、资料缺失或组织归属不一致，需要先评估处理方式，再决定新系统怎样展示、关联和迁移。

并发、权限、安全和部署条件同样不能只靠页面判断。原型能表达“谁看见什么”，但权限是否真正生效、接口能否稳定调用、数据怎样备份，需要方案与测试提供证据。

对于影响较大的未知项，可以提前安排小范围技术验证。关键在于区分界面原型与技术验证：前者帮助确认使用方式，后者验证某项技术假设，两者不能互相替代。

相关结果应进入风险、依赖和待确认记录，避免原型评审通过后，才发现核心条件无法满足。

一轮评审，应该由谁确认什么

原型不是只交给一位负责人看过，就完成全部确认。完整软件系统涉及多个角色，评审需要覆盖实际使用、规则决策、系统协作和后续维护。

项目应先明确原型的编制和维护负责人，再约定各方的确认职责。业务负责人重点确认目标、范围和处理规则；实际使用人员核对操作是否符合现场工作；技术人员判断接口、数据和环境条件；测试人员帮助识别可验证的结果与遗漏场景。

企业可以安排一位能够协调跨部门分歧的负责人汇总意见，但不宜用“领导已经看过”代替关键岗位的核验。

评审也不必从第一页念到最后一页。可以围绕典型场景组织：报修如何提交、维修怎样转派、异常如何关闭，每轮解决一组有明确边界的问题。

结束后应留下确认记录，注明原型版本、确认范围、修改项、待定事项和负责人。尚未解决的问题，应说明影响哪些功能，以及何时需要作出决定。

这样，原型评审才从“大家觉得差不多”转变为能够推动下一阶段的工作结果。

什么时候可以把原型交给开发

对于准备开发的功能，判断条件不是画了多少页，而是关键行为能否被清楚说明，并转化为实现任务和测试条件。

至少需要核对：主流程和重要异常是否明确，角色权限是否清楚，关键字段和数据关系是否一致，接口与外部依赖是否具备实施条件，预期结果能否验证。

以维修转派为例，不能只确认一个“转派”按钮，还要说明谁能转派、允许在哪些状态操作、原负责人是否保留记录，以及相关人员如何收到通知。

原型不能单独承担全部需求。业务规则、数据定义、接口约定和验收条件，应与对应页面或流程建立关联。只有页面，没有这些说明，仍可能存在较大的理解空间。

如果部分模块已经明确，且模块边界、共享数据及主要依赖已有安排，可以分批进入开发。不必为了等到全部页面完善而暂停所有工作。

但涉及共同数据模型、统一权限或核心接口的问题，应优先确认和验证。不能因为某个页面已经画好，就忽略它对其他模块的影响。

确认后的原型，仍然需要版本管理

原型确认意味着形成当前批次的共同基准，不意味着企业此后不能提出调整。

开发中发现新情况时，应记录变更原因，判断它影响哪些流程、数据、权限、接口和测试，并评估工作量、费用与工期，再决定如何安排。新增一项审批，看似只改一页，实际可能影响多个角色和状态。

原型、需求说明和开发任务应保持版本对应，避免设计人员改了页面，开发人员仍按旧图实现，测试人员又拿另一版作为依据。

开发联调和测试试运行阶段，可以继续借助原型核对业务理解，但实际验收还需要约定的规则、测试结果、性能与安全要求，以及交付资料，不能只比较界面是否相似。

在项目计划中，调研、原型、技术与数据方案、开发测试、验收上线及培训交接，应分别明确责任、输入、输出和确认点。具体安排可以迭代，但交接关系不能模糊。

因此，原型最合适的安排不是某一个固定日期，而是在业务已有基础时尽早开始，在对应开发前确认关键内容，并在后续变化中持续维护一致性。