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