做乙方交付项目时，瀑布模型该怎么控制范围和验收
乙方交付项目在瀑布模型下要控制范围和验收，关键不是多写文档，而是尽早把交付边界、非范围项和验收标准一次性说清，并在执行阶段用正式变更机制守住边界。文章指出，范围失控通常源于售前承诺模糊、需求只有功能名没有边界、非范围项未写明、验收标准不可判定。要真正控住项目，必须拆清业务、功能、数据、接口四类边界，把需求描述改写成可验收表述，同时把验收前移到需求确认、阶段成果确认和最终交付三个层次。执行中面对客户新增需求，不能直接估工开发，而应先区分是细化、偏差、缺陷还是新增，再决定是否走变更。最后文章还分析了客户需求不清、拿行业惯例压项目、用主观体验卡验收、乙方内部不敢坚持边界等常见难点，并给出应对思路。核心结论是：瀑布模型并不怕变更，怕的是变更不被看见、不被评估、不被确认。只要前置定义、过程确认、正式变更三件事做到位，乙方项目就能更稳地控制范围、推动验收和保障回款。
在乙方项目交付中，范围越清晰，后续返工和争议越少。项目一开始应该重点确认哪些内容，才能把工作边界、交付物和责任划分说明白？
用范围说明书和需求确认机制，把边界提前锁定
项目启动时就要把业务目标、交付物清单、功能边界、非功能要求、接口范围、验收标准和不包含内容写进范围说明书，并让甲方确认签字。对于容易产生歧义的需求，建议用原型、流程图、用例说明等方式补充解释，同时建立变更申请机制，任何新增需求都必须经过评估、审批和影响说明后再纳入计划。这样可以减少口头承诺带来的范围漂移，也方便后续按照约定进行验收。
在按阶段推进的交付项目中，每个阶段都会有不同的文档和成果物。怎样把这些阶段性产出和验收要求关联起来，避免到项目结尾才发现标准不一致？
把每个阶段的交付物写成可验收清单
瀑布模型强调阶段推进，所以每一阶段都应该有明确的交付物和确认动作。需求阶段对应需求规格说明书和需求确认记录，设计阶段对应概要设计、详细设计和评审结论，开发阶段对应代码、单元测试结果和版本说明，测试阶段对应测试用例、缺陷报告和测试总结。建议将这些内容整理成阶段验收清单，并定义通过条件、责任人和签字人，让每个环节都能单独确认，避免问题积累到项目末端。
做交付项目时，客户中途加需求很常见。遇到这种情况，项目经理应该如何处理，才能不打乱计划，也不影响原有验收口径？
通过变更控制把新增需求纳入统一管理
对于新增需求，不建议直接口头答应并同步推进，而是要进入变更流程。项目经理需要先判断变更内容是否影响范围、工期、成本、资源和验收标准，再形成变更评估说明，明确新增工作量、风险和对原计划的影响，交由双方确认后执行。如果变更未获批准，就应维持原合同范围和验收口径。这样既能保留客户沟通空间，也能守住项目边界，避免交付时出现“做了很多但不算验收范围”的情况。