数字化项目范围失控，通常不是需求本身太多，而是企业没有形成公开、可追溯的取舍规则。业务部门不断增加功能，管理层希望顺便解决相关问题，项目团队则在开发、返工和延期中消耗预算。要控制范围，关键不是压制需求，而是用“必做、可做、不做”三张清单，把有限资源优先投入到可验证的业务价值上。
先定义首期价值，再划分三张清单
立项时不能只写“建设平台”“提升效率”这类宽泛目标，而应明确首期对象、核心问题、交付结果和排除边界。例如，先覆盖一个部门或一条核心流程，让用户能够完成创建、审核、查询或异常追踪，并据此设置验收标准。
“必做”清单只保留不完成就无法验证首期价值的事项，包括核心流程、必要权限、关键数据责任、过程留痕、试运行和异常处理。判断标准是：不做它，首期目标是否无法实现？是否会导致核心流程中断、明显返工，或无法完成验收？
“可做”清单承接有价值但不影响首期闭环的需求，例如更多报表、其他部门推广、个性化提醒和更细的数据分析。它不是交付承诺，而是候选池，应记录价值假设、依赖条件、实施代价和后续触发条件。
“不做”清单则明确本期排除事项，并写清原因：不属于首期范围、缺少业务负责人、数据条件不足、需要另行立项，或投入与当前目标不匹配。明确拒绝并不等于否定需求，而是防止项目边界被反复解释。
三个阶段持续管控
立项阶段锁定三张清单、负责人、验收标准和变更审批人；实施阶段要求所有新增需求登记并评估对预算、工期、数据、组织和维护成本的影响。若要纳入新需求，就必须同步删减原范围、调整预算工期，或将其排入后续版本。
上线阶段不能只按系统演示验收，而要由真实用户验证业务流程、数据质量、权限责任和异常处理。验收记录还应区分已完成、部分完成、范围外事项及后续责任。
三张清单的价值，不在于让项目少做功能，而在于让每项投入都有依据。只要企业坚持“没有验收标准不开发，新增需求不评估不承诺”，数字化项目就能从需求竞赛转向以业务结果为核心的范围治理。