怎样划定第一版系统的最小有效边界

客制系统最常见的范围问题，不只是「做太多」，也包括「每个地方都做了一点，却没有一段流程真正能用」。

例如，第一版同时出现客户资料、库存、订单、佣金和报表五个页面，但员工仍要在聊天工具和表格之间补齐每一步。功能看起来很多，业务却没有一段可以完整迁移到新系统。

一个更有用的第一版，应该完成一条有明确起点和终点的业务切片。

从问题写起，不要从页面写起

不要先说「我们需要一个客户管理页面」。先描述当前发生的事情：

客户从不同代理分享的链接进入，成交过程中可能由多人参与。月底结算时，团队无法可靠追溯客户最初来源和各人的贡献，佣金常要人工争议。

这样的描述包含受影响的人、发生问题的时点和业务后果。它比页面清单更能帮助团队决定系统应该管到哪里。

一条有效边界需要六个要素

可以用下面这张表定义第一版：

要素	要回答的问题
触发事件	什么事情发生后，流程开始？
输入	系统必须收到哪些资料？
参与角色	谁读取、修改、确认或批准？
核心规则	哪些决定必须保持一致？
结束状态	做到什么，才算这次流程完成？
可见证据	用什么记录证明流程正确运行？

以上述客户归属问题为例，边界可能是：客户通过可识别链接提交咨询；系统保存来源和后续参与者；负责人确认成交；财务在结算前查看完整记录。第一版不一定需要同时处理房源发布、完整会计或工资。

区分「必须有」、「稍后有」和「不在系统里」

为每项需求选择一个位置：

必须有

没有它，核心流程就无法完成，或结果无法被信任。例如，来源链接、客户记录、参与者登记、成交确认和追溯记录。

稍后有

有价值，但可以在第一版运行后，依据真实使用决定怎样实现。例如，高级绩效分析、自动分配线索、复杂佣金模拟。

不在系统里

继续由人或现有工具处理更合理。例如，少量特殊争议由负责人审核，而不是一开始就把每种争议写成自动规则。

把项目缩小，并不是把「稍后有」偷偷删除，而是清楚记录它为什么暂缓、需要什么证据才重新评估。

为边界写出可验证的验收情境

功能名称很难验收，业务情境比较容易。可以使用「给定—当—那么」的写法：

给定一名客户通过代理 A 的专属链接提交咨询，当员工 B 接手跟进并最终确认成交，那么系统应保留最初来源、后续参与者、确认人和时间，供获授权的财务人员查看。

再补上失败和权限情境：

• 没有权限的人不能修改来源记录；
• 修改关键归属必须留下原值、修改人、时间和原因；
• 重复客户进入时，系统要提示，而不是静默建立两个身份；
• 无法判断归属时，进入人工复核，不自动分配佣金。

这些情境同时帮助设计、开发、测试和业务验收。

第一版也需要完整的运营安排

软件做完不等于流程已经落地。范围还应该说明：

• 旧资料是否迁移，迁移到什么日期；
• 谁培训员工；
• 上线后问题由谁记录和判断优先级；
• 系统不可用时，临时怎样继续工作；
• 哪些指标用来判断这段流程是否改善。

如果没有这些安排，技术边界很清楚，运营边界仍然是空的。

用一页纸确认第一版

一个可以执行的第一版说明，不必很长，但至少应包含：

1. 要解决的一个业务问题；
2. 流程的起点和终点；
3. 参与角色和权限；
4. 必须执行的核心规则；
5. 暂缓与排除的内容；
6. 三到五个关键验收情境；
7. 上线后观察的结果。

当这七项能够被业务负责人和实施团队用相同方式复述，第一版的边界才算真正形成。

---

本文提供通用的系统范围方法。实际边界仍应依据企业流程、风险和可用资源决定。