迭代开发里的“需求变更”，到底怎么管钱和流程？

做IT研发外包，尤其是现在流行的敏捷迭代模式，最头疼的一件事，恐怕就是“需求变更”了。

甲方觉得：“咱们不是说好做迭代吗？那我这会儿有个新想法，或者发现之前想的不对，想改改，不是很正常吗？”

乙方（外包公司）觉得：“大哥，需求文档都签了，代码都写一半了，你现在说要改架构？这得加钱、加时间啊！”

结果就是，扯皮。无休止的会议，伤感情的邮件，最后往往是项目延期，或者乙方含泪买单，双方都憋着一肚子火。

作为一个在行业里摸爬滚打多年，看过无数合同纠纷的人，我得说句公道话：需求变更本身不是魔鬼，失控的变更才是。

要在合同里把这事儿定好，不能光靠“信任”，得靠“机制”。今天咱们就抛开那些虚头巴脑的理论，用大白话聊聊，怎么在合同里规定迭代开发的需求变更流程和费用调整，才能既保证项目能跑起来，又能让双方都觉得公平。

一、 先搞清楚，咱们在吵什么？

很多时候，矛盾的根源在于双方对“变更”的定义都不一样。

有些甲方认为，迭代嘛，不就是边做边改吗？我付了包月的钱，你就得听我的，我想怎么改就怎么改。

有些乙方呢，为了拿项目，前期嘴上答应得天花乱坠，说“没问题，我们很灵活”，结果一遇到真要改东西，脸就拉下来了，恨不得每个改动都收一笔巨款。

所以，合同的第一步，就是要定义清楚什么是“变更”。

在敏捷开发里，我们通常会有一个“产品待办列表”（Product Backlog）。这个列表里的东西，优先级是动态调整的。如果在迭代（Sprint）开始前，或者在迭代的梳理会上，我们调整了优先级，把下一个迭代要做的功能换了，这通常不叫变更，这是敏捷的正常操作。

真正的“变更”，通常指以下几种情况：

• 迭代进行中插入新需求： 这个迭代本来要做A、B、C三个功能，代码都写上了，你突然说要加个D功能，或者把A功能换成A'功能。这绝对是变更。
• 颠覆性的修改： 比如，原型已经确认了，UI都切图了，你突然说“我觉得整个页面的布局应该反过来”。这种属于返工，是大变更。
• 技术栈或架构的调整： 比如合同里写明用MySQL，你中途非要换成Oracle，或者原本设计的单体架构，你非要改成微服务。这牵一发动全身，必须算变更。

把这些情况在合同的“名词定义”或者“范围管理”章节里写清楚，后面谈钱、谈流程才有依据。

二、 流程怎么走？不能“口头通知”

很多项目之所以乱，就是因为变更流程太随意。甲方负责人在微信上发一句“小王啊，这个地方我想加个功能”，乙方的项目经理回一句“好的”，这事儿就算定了？

绝对不行。等到月底结算，或者项目验收时，这就是一笔糊涂账。

一个规范的变更流程，应该像这样，白纸黑字写在合同附件里：

1. 提出与记录 (Request)

任何变更，必须由甲方指定的接口人，通过书面形式（比如邮件、项目管理工具里的特定表单）提出。口头说的，一律不认。

申请里要写清楚：

• 为什么要改？（背景和目的）
• 改成什么样？（具体描述）
• 期望什么时候上线？（时间要求）

2. 影响评估 (Assessment)

这是最关键的一步，也是最容易扯皮的一步。乙方收到变更请求后，不能光说“行”或“不行”，得拿出数据。

乙方需要评估这个变更会带来什么影响，包括但不限于：

• 工作量： 需要多少人天（Man-day）？
• 技术风险： 会不会影响现有功能？
• 时间成本： 原本的里程碑要不要推迟？推迟几天？
• 依赖项： 是不是需要第三方配合？

这里有个小技巧，可以在合同里约定一个“评估阈值”。比如，如果预估工作量小于2人天，可以简化评估流程；如果大于5人天，必须出具详细的评估报告。

3. 报价与审批 (Quotation & Approval)

乙方根据评估结果，给出明确的报价和工期调整方案。这里要引入我们下一个大话题——费用调整。

甲方收到报价后，需要内部决策，然后书面确认“接受变更”或者“放弃变更”。如果甲方在合同约定的时间内（比如3个工作日）没有回复，乙方有权视为变更取消，按原计划进行。

4. 执行与记录 (Execution & Record)

一旦甲方确认，乙方就要更新项目计划，把变更内容加进去，相关的费用和工期变更也要记录在案。所有的沟通记录、确认邮件，都要作为合同的一部分存档。

这个流程听起来有点繁琐，但其实是保护双方。对甲方来说，避免了乙方漫天要价；对乙方来说，避免了无休止的“免费劳动”。

三、 钱怎么算？这才是核心

流程走完了，最终还是要落到钱上。费用调整是变更管理里最敏感的部分，也是最能体现专业性的地方。

常见的计费模式有以下几种，合同里最好选一种，或者组合使用。

模式一：按人天单价结算 (Time & Materials)

这是最常见，也最“公平”的方式。

公式： 变更费用 = 变更评估工作量（人天） × 合同约定的人天单价

优点： 简单明了，做了多少活，收多少钱。

缺点： 如果乙方效率低，磨洋工，活干得越久，收的钱越多，甲方会吃亏。

怎么用好它？

可以在合同里约定一个“人天单价”的上限和下限，或者要求乙方在报价时提供详细的工作量拆解（比如：前端开发0.5人天，后端开发1人天，测试0.5人天）。这样，甲方可以审查其合理性。

模式二：按功能点或模块一口价 (Fixed Price for Change)

对于一些边界清晰、相对独立的变更，可以采用一口价。

比如，甲方想在现有系统里加一个“导出Excel”的功能。乙方评估后说：“这个功能我们很熟，不用重新设计，直接做就行，报价8000元，3天搞定。”

优点： 甲方预算可控，乙方如果效率高，还能多赚点。

缺点： 评估难度大。如果一开始没说清楚细节，后面很容易因为“这个导出要不要带图表”、“筛选条件是不是要多级联动”这种细节吵起来。

模式三：打包的“变更预算包” (Change Budget)

这是一种比较高级，也更体现合作精神的玩法。特别适合那种初期需求确实不太明确，但又想控制总成本的项目。

玩法是这样的：

双方在合同总价之外，单独设立一笔“变更预算金”，比如合同总价的10%-15%。

• 在项目过程中，所有的小变更，都从这个预算包里扣钱（可以按人天或者一口价）。
• 这个包里的钱用完了，如果还想改，就得额外加钱了。
• 如果项目做完了，这个包里的钱没用完，可以按约定返还给甲方，或者折算成后续的运维服务。

好处： 甲方不用为每个小改动都走一遍复杂的财务审批流程，乙方也有了一个明确的“变更额度”，做起来更有底气。

关于工期的调整

注意，变更不仅仅是钱的问题，还有时间。合同里必须写明：

• 变更导致的工期延长，是否影响最终的交付节点？
• 如果因为甲方的变更导致项目延期，乙方是否免责？
• 延期的计算单位是什么？按天？按小时？

我见过最坑的一种合同是：只规定了变更要加钱，没规定变更可以延期。结果乙方为了赶甲方临时加的需求，不得不压缩测试时间，最后上线一堆Bug，双方互相指责，项目烂尾。

四、 几个能让你少踩坑的“潜规则”

合同写得再好，执行的人不对，也是白搭。这里有几个实战中总结出来的经验，不一定都写在合同里，但一定要在项目启动时双方达成共识。

1. 设立一个“变更控制委员会”（CCB）

听起来很高大上，其实很简单。就是双方各派几个有决定权的人（比如甲方的产品总监，乙方的项目经理），组成一个小组。

凡是涉及到费用超过X元，或者工期影响超过Y天的变更，必须经过这个小组开会讨论通过，不能由下面的人随意决定。这能有效避免“拍脑袋”决策。

2. 善用“待定”（Icebox）列表

敏捷开发里，不是所有好点子都要立刻做。当甲方提出一个新想法，乙方评估后发现工作量很大，或者会严重影响当前迭代目标时，可以建议：“这个想法很好，但我们建议把它放进产品待办列表的‘待定’区，等下个迭代或者更合适的时候再做。”

这既尊重了甲方的想法，又保护了当前迭代的稳定性，避免了频繁的“计划外变更”。

3. 区分“Bug”和“新需求”

这也是扯皮高发区。甲方觉得“这个功能不好用，我想换个样子”，这到底是Bug修复，还是新需求变更？

• Bug： 指的是系统没按预定的设计工作。比如点了按钮没反应，数据算错了。这种通常属于乙方的责任，应该免费修复。
• 新需求/优化： 指的是系统按设计工作了，但甲方想要更好的体验或新功能。比如按钮能用，但甲方觉得颜色不好看，想换个颜色。这应该算变更。

合同里最好对“Bug”和“需求变更”有一个明确的界定标准，比如参考《软件需求规格说明书》（SRS）。

4. 拒绝“顺手做一下”

“小王，这个功能能不能顺手帮我加一下？不费劲吧？”

这是乙方工程师最怕听到的话。很多时候，“顺手做一下”背后隐藏着复杂的逻辑和潜在的风险。

作为乙方，一定要守住底线，哪怕是再小的变更，也要走流程，至少要在邮件里确认一下。这不仅是为公司收钱，也是为了保护自己，避免无休止的“免费加班”。

作为甲方，也要理解，专业的乙方不是不愿意“顺手”，而是“顺手”的背后，可能需要修改代码、测试、部署，这些都是成本。

五、 一个简单的合同条款范本思路

说了这么多，我们把这些思路浓缩成一份合同条款的结构，你可以直接拿去和法务或者PMO讨论。

《项目研发外包合同 - 需求变更管理细则》

1. 变更定义
本合同所指的需求变更，是指在迭代开发过程中，超出双方书面确认的《迭代计划书》或《产品需求文档》范围的功能增减、逻辑调整、UI/UX修改和技术架构变更。

2. 变更流程
2.1 甲方通过[指定邮箱/项目管理工具]提交书面变更申请。
2.2 乙方在[24/48]小时内进行初步响应，并在[3]个工作日内提供包含工作量、工期影响和报价的正式评估报告。
2.3 甲方在收到评估报告后[3]个工作日内书面确认。逾期未确认视为放弃变更。
2.4 双方签署《变更确认单》后，乙方方可执行变更。

3. 费用调整标准
3.1 变更费用计算方式（请二选一或组合）：
A. 按人天结算：单价为人民币 [XXXX] 元/人天，以实际投入工时为准。
B. 一口价：根据评估报告确定的固定金额 [XXXX] 元。
3.2 变更预算：本项目预留合同总额的 [X]% 作为变更预算金，用于支付小额变更。超出部分由甲方另行支付。

4. 工期调整
因甲方变更导致项目延期的，交付日期相应顺延，乙方不承担延期责任。延期天数 = 评估影响的工作日。

5. 优先级
当变更需求与原计划需求冲突时，以双方书面确认的优先级为准。

……

写在最后

其实，聊了这么多流程、表格、钱，最核心的一点，还是“透明”和“尊重”。

好的外包关系，不是甲方和乙方的对立，而是一个战壕里的战友。甲方要理解乙方的开发成本和时间压力，乙方也要体谅甲方在市场变化下的业务焦虑。

合同里的这些条款，不是为了在出事时用来打官司的，而是为了在项目顺利时，大家都能有一个清晰的预期，知道边界在哪里，遇到问题该找谁，怎么解决最高效。

把丑话说在前面，把规矩立在事前，这样，当需求变更真的来临时，你们才能心平气和地喝杯咖啡，而不是拍着桌子吵架。

企业培训/咨询