FDE 项目需求不断增加，怎样管理范围变更而不拖垮试点

先判断要求为什么出现。原定“缺订单号时提醒补充”，系统却编了订单号，这是修复；把提醒文案改得更容易理解，是体验改善；增加创建退款的能力，是新业务动作。三者不能用同一套“有空就做”的处理方式。

记录里写触发场景和失败表现，避免只写“更智能”“更好用”。如果一个要求说不清谁用、什么时候用、期待怎样的结果，先补证据。用当前试点记录验证它是不是普遍问题，不以会议上声音最大的人决定优先级。

示例中的决定不是通用答案。它说明本期可以保留需求的部分价值，同时把尚未准备好的执行动作明确排除。另一家企业若已有可靠支付接口和授权机制，可以作出不同决定。重要的是依据和边界可复核。

一个简单打分表可以帮助比较，但不能替代关键依赖的确认。支付接口未授权、规则无人负责等阻塞项，不能靠其他维度得高分抵消。

本期接入适合影响清楚、资源和责任到位的要求。选择接入后，将测试、运维说明和排除项一起更新。替换意味着用新增项交换原有工作，写出哪项被移出，不能让团队同时承担全部目标。

延期不等于忽略。记录需要满足的条件，例如规则负责人确认、数据接入完成或积累足够失败样本。下次讨论有条件可检查，而不是重复争论“重要不重要”。

对小修复可以按日汇总，对权限变化或新业务对象单独做决定。流程的轻重应与影响匹配，避免为了管理需求建立一套比试点还复杂的审批系统。

Palantir 关于生产责任的文章强调工程团队对部署后行为的责任。本文的范围变更方法借用这一关注点：新增功能产生的告警、异常和维护工作，应在上线前有人接住。原文不提供本文这张变更表。

比如新增邮件发送，验收应包含收件人错误、重复发送、内容版本变化和撤销请求；运维说明应写清如何暂停发送。如果只在页面增加按钮，却没有相应记录和恢复路径，工作量会在上线后回到团队身上。

范围文档保留版本。每次修改能回答谁提出、依据是什么、谁确认、增加了哪些检查。口头讨论可以快速，最终决定需要落到可追踪记录。

原要求是“让助手支持销售”。与提出者核对后发现，当前最需要的是根据产品资料整理询价信息，并交给销售确认。于是本期变更可以写成：支持提取商品、数量、交货地区和期望日期；缺失时列出待补字段；不计算最终报价，也不发送承诺。

验收增加不同商品称呼、缺数量、含多个交货地址和资料冲突的案例。报价系统暂不接入，价格权限也不开放。输出必须包含原始请求位置，销售可以回到证据确认，避免看着一份流畅摘要反而漏掉客户限制。

若下一阶段要自动报价，再单独评估价格来源、折扣权限和报价有效期。这种分期能让同一个需求逐步展开，又不把未确认条件藏在“先做个简单版本”里面。

决定之后还要通知真正受影响的人：操作人员知道本期能用到哪里，维护者知道新增错误类型，验收者知道哪些情况需要重测。一个需求被接入，意味着这些工作一起进入范围，而不是开发人员口头答应就结束。

整理最近一周新增要求，按修复、体验改善和新能力分组。为涉及新对象或权限的要求补齐影响表，选出本期必须完成的核心任务，并把排除项放进演示说明和交付记录。

这套方法适合时间有限、需求仍在变化的 FDE 试点。紧急生产故障先止损和修复，再补变更记录；不能让范围管理阻碍必要处置。新领域和复杂组织可能需要更完整的采购或变更制度，本文表格只解决项目层面的沟通。