项目做了一半，客户说再加个小功能怎么办？

问题：一个“小”功能，值不值得接？

你正在按计划推进一个项目，突然客户或老板说：“很简单，就加一个导出Excel的功能，估一下两天够不够？”

听起来确实不大。但做过项目的人都知道，这种“小功能”往往是范围蔓延的起点。最坏的情况是：你接受了，团队加班做完，测试发现数据格式不对、权限没顾上、后续维护成本高，最后交付延期，质量打折，客户还不满意。

拒绝呢？又怕得罪客户，或者显得自己没能力。

这是小团队项目经理的典型困境。我们没有大公司的流程和商务团队来挡，也没有资源做详尽的影响分析。但正因为小，我们必须快速决策，把能量用在刀刃上。

我的判断原则：先问四个问题

我在往日时光和山禾网络带项目时，也反复遇到类似情况。后来我总结了一套非常简单的决策框架，不需要复杂工具，一个记事本或一张纸就能完成。每次遇到追加需求，我会先问自己四个问题：

1. 这个功能对当前项目目标是否必要？ 如果它是合同或需求文档里明确承诺的一部分，那不算“追加”，是必须补的漏洞。如果完全超出原始范围，则进入下一步。
2. 如果接受，对现有排期的冲击有多大？ 不是问“开发需要多少天”，而是问“这个功能会挤压其他任务的工期吗？会推迟关键里程碑吗？” 如果会，需要明确推迟什么。
3. 接受这个功能后，测试和回归的成本是多少？ 小团队常常只算开发，忽略测试。一个导出功能可能涉及多个数据字段、权限、边界条件，测试时间可能比开发还长。
4. 拒绝的代价是什么？ 客户会生气吗？会威胁下一期合作吗？还是说这只是个“最好有”的请求，没有也不影响核心使用？

这四个问题不需要完美答案，但能帮你快速定位风险等级。

一个具体案例（假设场景）

假设我们正在为客户开发一个内部CRM系统，核心功能是客户管理和跟进记录。项目进行到第三周，客户说：“能不能加个功能，把客户列表导出成Excel？”

看起来很简单。但实际影响：

• 导出字段需要和客户确认（原来只展示部分字段，导出要不要全字段？）
• 权限问题：不是所有角色都能导出，需要加角色判断
• 数据量：如果客户有上万条记录，导出需要分页或异步处理
• 测试：至少需要测试空数据、超大数据、权限拦截

综合评估下来，开发和测试至少需要3-4天，而项目原计划还有2周，这个功能会挤掉原来计划中的报表优化和用户培训。如果接受，必须和客户协商：要么推迟交付日期，要么砍掉一个同等规模的其他功能。

决策框架：接受、协商还是拒绝？

基于上述四个问题，我把结果映射到三个选项：

1. 接受

条件：功能小且必要（不接项目无法交付），且有明确的时间余量，测试成本低。 行动：立即调整排期，通知团队，并记录变更。

2. 协商

条件：功能有价值，但会明显影响排期或质量。 行动：向客户解释影响，并给出两个选项：

• 选项A：接受新增功能，但交付日期推迟X天
• 选项B：保持原日期，但取消或替换某个已有功能，保持总工作量不变
• 选项C：将这个功能放在二期，先完成当前约定范围

关键：不要只说“不行”，要说“如果要增加这个功能，我们需要牺牲什么”。把选择权还给客户，让他们理解trade-off。

3. 拒绝

条件：功能与核心目标无关，且风险高（如会引入大量技术债务或安全隐患），或者客户只是随口一提，不接受也不影响满意度。 行动：礼貌解释为什么不做，并给出替代方案（比如用已有功能代替，或者手动导出方案）。

实际执行中的检查清单

为了不让现场决策太随意，我后来做了一个简单的检查清单，在项目开始前就和团队对齐：

• 这个需求是否超出原始范围？
• 如果接受，需要调整哪些已有任务的排期？
• 测试和回归的最短时间是多少？
• 是否有替代方案（比如用现有功能+手动操作）？
• 这个功能的可逆性如何？如果后期发现不对，能容易去掉吗？
• 客户愿意为这个功能支付额外成本吗？

最后一个问题很关键。如果客户愿意追加预算，那说明这个功能对他们确实重要，也给了团队缓冲。如果不愿意，那大概率是“顺口一提”。

写在最后

小团队做项目，最怕的不是需求多，而是“每一个看起来都不大”的需求累积成不可控的负担。与其每次都凭感觉决定，不如提前建立一套简单的决策习惯。

这套框架不一定完美，但至少能让你在客户、老板和团队之间有一个清晰的立场。下次再遇到“再加个小功能”的请求，不妨先停一停，问自己四个问题，然后有底气地选择接受、协商或拒绝。

PaxLee