FAQ
企业软件开发要不要先做原型？
💡 直接回答
结论：企业软件开发通常适合先做原型，但深度应由业务风险决定。稳定的小改动可用标注稿，跨角色流程需呈现状态和异常；接口、性能等未知问题另做技术验证。确认时应留下页面编号、规则说明、样例与未决项，不能把能点击的演示当成功能已实现。
企业软件开发通常适合先做原型，把业务人员脑中的操作过程变成能共同查看的页面和规则。原型做到什么程度，要看哪些误解会影响实施：已成熟系统的一处字段调整，可以先用现有页面标注；跨岗位审批、多状态单据或首次建设的业务，则宜先呈现核心任务怎样完成。原型确认也不等于软件验收通过。
按尚未解决的问题选择原型深度
- 位置和字段已明确：用线框稿或页面标注说明新增字段、必填条件、提示及受影响位置，不必把所有旧页面重画。
- 角色和步骤有分歧：制作可走查的关键页面，串起发起、处理、退回和结束，标出不同角色能看什么、能操作什么。
- 交互需要比较：为复杂筛选、批量录入或移动作业准备少量代表页面，用脱敏样例比较方案，再决定是否细化视觉。
- 疑问属于技术可行性：接口是否开放、设备能否连接、响应能否达到约定目标，应另做技术验证；模拟页面不能提供这些证据。
用一张状态卡把画面背后的规则补齐
示例：采购申请原型不能只有“提交”和“审批”两个按钮。可为这条流程附一张状态卡：申请编号、发起角色、必填字段、当前状态、允许动作、动作后的状态、通知对象及异常提示。申请人提交后能否修改，审批人退回后由谁补充，审批期间申请人撤回会发生什么，都应在对应页面或说明中找到答案。示例用于说明材料组织方式，并非已完成的项目记录。
页面旁还应注明数据来自哪里、金额或数量怎样计算、哪些字段只读；不在本期的动作明确标注。每个关键页面用固定编号关联需求条目，确认版保存版本、日期和确认人，避免聊天截图与设计工具里的稿件各自生效。完整需求文档的组成可参考APP需求文档要素，不必把文档全文塞进原型。
让实际使用者走一遍正常与退回路径
- 请业务使用者按一份脱敏样例完成提交，再由处理人说明接收什么、如何决定及何时结束，记录需要口头补充的规则。
- 换成字段缺失、无操作权限或申请被退回的样例，核对页面提示、可执行动作和后续责任人是否清楚。
- 把发现的问题登记到页面编号下，写明决定、负责人和关闭依据；修订后重走受影响路径，再固定本阶段版本。
如果双方仍无法确定审批规则或数据口径，应保留待确认标记，先补业务决定；不要用精美视觉掩盖未决事项。接口验证未完成也不能因原型演示顺畅就承诺联调已可行。原型走查提供评审输入，正式实施范围再按需求基线确认。涉及企业管理系统定制时，优先画清高风险任务，普通查询页可按已确认组件规则展开。
说明：本文为通用软件原型与需求协作建议，原型深度、技术验证、实施范围和验收依据以双方确认的需求说明与合同为准。
