项目中途新增页面或功能怎么办？变更评估与确认流程

“顺便加一个页面”“这个字段再接个接口”听起来很小，真正影响可能包括原型、设计、开发、测试、文案、权限和上线。没有变更机制，项目会不断膨胀，最后双方都觉得自己吃亏。

成熟合作不靠拒绝变化，而是让每次变化有记录、有影响评估、有授权。

01 先区分三类情况

原需求已经明确但交付遗漏，属于修正；已交付功能与确认规则不一致，可能是Bug；原确认范围没有的新页面、逻辑或方向，则是新增。

不要只看工作量大小。一个两小时的新增仍是新增，一个需要两天修复的错误仍应按责任处理。

需求变更评估表

02 变更请求先写清，再评估

用简短模板记录背景、目标、用户、预期结果和截止时间，避免口头需求在传递中变形。

供应商应说明理解和假设，客户确认后再估算。信息不全时先做小范围分析，不要直接承诺。

03 提供至少一个缩小方案

不是每个新需求都要完整实现。可以先做一个角色、一个流程或一个平台，验证后再扩展。

把“必须本期上线”和“可以下一版本”分开，保护关键路径。

04 变更单与原合同共同生效

记录新增内容、不包含项、费用、付款、交付、验收和新时间表。对原范围的替换也要说明哪些内容被取消。

群聊确认可以作为沟通，但重要变更最好形成正式文档或邮件，便于后续验收。

05 小变更也要累计管理

零散小需求单个不大，累计可能占用大量时间。可以设一定的变更额度，超出后集中评估或进入维护包。

项目经理维护变更日志，让所有人知道总预算和周期为何变化。

06 项目结束后复盘变更来源

若大量变更来自前期需求遗漏，应改进发现和原型；若来自业务变化，应调整合同和迭代模式；若来自多人反馈冲突，应改善决策机制。

不要把所有变化都归为“客户不专业”或“供应商估算不准”。

常见问题

客户新增需求可以直接拒绝吗？

可以基于资源、风险和合同拒绝，也可以提供后置或替代方案。重点是清楚说明原因和影响。

很小的改动也要收费吗？

可设置包含额度或维护范围。是否收费不是唯一问题，至少要记录并控制累计影响。

Bug和新增功能怎么判断？

对照已确认需求、原型、设计和验收标准。与确认内容不一致通常是缺陷；增加新行为通常是新增。

变更会不会影响原上线日期？

可能。应明确关键路径、可并行工作和是否用增加资源换时间，不能默认原日期不变。

需求变更由谁批准？

双方都应指定有权确认范围、费用和周期的人，避免普通参与者口头承诺。