06｜第一期到底做多大：目标、范围和责任如何约定？

第一期范围需要同时满足两件事：足够小，让团队有能力完成；足够完整，让一个真实任务能够走到有意义的结果。只减少页面数量，未必缩小了业务复杂度；删掉后续处理，则可能让系统永远停在演示。

范围工程的目的，是把业务期待变成可执行、可验证、有人负责的约定，并说明什么情况下需要重新谈判。

“支持询价、计算、展示”是一份功能清单。“接待能够把普通询价整理成条件完整、费用可解释、可交给调度复核的结果”，才是一项业务目标。

两种表达会产生不同设计。前者容易把展示报价视为完成；后者要求系统保留需求条件、当前版本、资源状态和待核实事项。因为调度能否继续工作，已经成为目标的一部分。

目标还需要成功标准。哪些字段必须齐全？费用与押金如何呈现？资源尚未确认时允许显示什么？客户改期后怎样让旧版本失效？这些标准应在实现前明确，后续才能通过任务验证，而不是在演示时临时决定“看起来可以”。

成功标准可以包含业务改善和不可突破的边界。前者如减少补问或返工，后者如不越权优惠、不把候选资源标为已安排。平均效率提高，不能抵消一次关键越界。两类标准应分别记录。

范围不只表示做哪些功能，还包括为谁、在什么条件下做。可以从用户、场景、数据、动作、环境和时间六个维度约定。

用户范围说明哪些岗位参与，是否包含外部客户。场景范围说明覆盖普通询价、特殊施工还是全部租赁。数据范围说明采用哪些价目、档期和历史资料。动作范围说明系统可以建议、创建草稿，还是能够提交正式业务动作。

环境范围说明入口、运行位置与必要集成。时间范围既包括验证周期，也包括业务上的有效期：价目在什么时间适用，资源状态何时需要重新核验，审批在何种变化后失效。

如果只写“支持智能报价”，这些边界都可能被不同人用不同方式理解。接待期待系统直接承诺，调度以为只是草稿，开发者默认历史价格有效，项目冲突就会在试用时集中出现。

表中的内容是范围写法示例，具体值应由目标企业确认。模板负责提醒遗漏，不能替代现场协商。

MVP 常译为最小可行产品，强调用有限投入获得有价值的用户反馈。端到端纵向切片则强调贯通任务链。两者可以结合，但不能只靠“页面少”来判断。

如果要验证接待与调度是否减少返工，最小范围必须包含一次交接。只生成报价，没有让调度读取并处理，就无法验证这个假设。反过来，为了验证这一点，暂时也不需要完整支付和结算系统。

因此，选择切片时可以从最高风险假设倒推。最不确定的是用户能否理解结果，就安排真实用户任务；最不确定的是数据能否及时取得，就先贯通对应接口；最不确定的是多种资源能否共同满足条件，就用代表情境验证组合判断。

较小范围应降低复杂度，同时保留决定项目价值的连接。用户输入、必要判断、业务输出和后续接手至少要对应起来。被推迟的功能，应明确说明是否影响当前验证结论。

“由业务负责”太宽泛。“调度负责人确认候选设备、操作员与运输组合是否可以安排”，才是一项可执行责任。同一个人也可能承担多种角色，但每个关键决定都要知道谁有权作出。

RACI 是一种常见的分工表达：R 表示执行，A 表示最终负责，C 表示需要协商，I 表示需要知会。使用时不必机械填满所有格子，重点是每项重要结果有明确的最终责任，而不是所有人都打勾。

还要区分发现风险和接受风险。测试人员可以发现某类样本不稳定，却未必有权决定带着这个限制继续试用；有权接受剩余风险的人，需要知道适用范围、潜在后果、缓解措施和退出条件。

这些约定还要落实到系统。若只有文档写着“主管审批”，任何用户仍能点击确认，责任设计就没有变成工程约束。界面、接口和权限需要共同支持同一规则。

没有停止条件，验证很容易变成不断追加时间。团队会把每次失败都解释为再优化一下，把范围不断扩张当作项目持续进展。

停止条件应对应关键假设和约束。例如需要的数据无法合法获得、关键动作无法避免重复执行、风险超出业务方可接受范围，或在约定预算内无法形成足够证据。触发后应明确下一步：补条件、修改方案、缩小范围或停止当前方向。

收窄也应有清楚含义。将自动执行调整为人工批准，将全部设备限定为一类，将多仓比较限定为两个仓库，都改变了覆盖范围。相应的目标和效果口径也要一起更新，不能继续引用原来更大范围的收益承诺。

有些限制可以在受控试用中接受，但必须可观察、可接管。若系统没有办法识别自己何时进入限制条件，就不能仅靠一句“复杂情况请人工处理”完成边界设计。

客户中途提出“再增加一种设备”，看起来只是多一行资料，却可能增加附件、运输与操作资质的规则。新增一个审批角色，也可能改变身份、界面、状态和验收。

处理变更时，应评估业务目标、数据与接口、权限、成本、测试和交接的影响，再由相应负责人决定是否进入本期。需要保留原约定、新变化、影响与决定，以便后续解释为何调整。

这并不意味着任何细节都要开正式评审会。小改动可以用简短记录处理，关键是变更程度与决策方式相匹配。影响外部承诺、资金、数据边界或重要状态的变化，需要更明确的授权与验证。

最终可以把第一期约定收在一页中：问题与基线、目标指标、六维范围、非目标、参与角色、关键假设、验收任务、预算与停止条件。每一项都指向实际工作，不写无法核验的口号。

第一期设计得好，团队会知道这轮完成后能够证明什么，也知道尚不能声称什么。下一篇进入这些承诺背后的基础条件：数据虽然存在，为什么仍可能不能被系统正确使用。

AI随心创的AI 工作流设计与试点支持可以从单一流程开始讨论输入、生成、校验、人工审核与交付。将本篇的一页范围约定作为沟通材料，更容易明确先验证哪项任务。