陷阱二：需求“镀金”——产品经理/客户不断加功能，如何守住边界
说实话，这个陷阱我见得最多。
项目做着做着，产品经理跑过来说：“哎呀，加个小功能，就一个按钮。”客户那边也来一句：“我觉得再加个报表导出挺好的，你们开发顺手就做了吧。”
嗯，听起来都很简单。但等你真做了，会发现这根本不是“顺手”的事。
这就是典型的需求镀金。说白了，就是在原始需求之外，不断往上堆砌功能。表面上看是“锦上添花”，实际上是在给项目埋雷。
为什么需求镀金这么可怕？
我经历过一个项目，本来计划三个月上线一个后台管理系统。结果产品经理每周都来加功能，今天加个数据看板，明天加个消息推送。最后呢？项目延期了两个月，核心功能反而漏洞百出。
为什么会这样？因为每个新功能都有三个成本：
- 开发成本：写代码、联调、测试，这些都要时间
- 维护成本：功能上线后，bug修复、版本升级，都是长期负担
- 认知成本：用户面对一堆功能，反而不知道核心功能在哪
你想想看，一个本来很清爽的App，被塞了十几个“顺手加的功能”，用户打开后一脸懵。这到底是帮用户，还是害用户？
如何识别需求镀金？
我个人习惯用三个问题来过滤：
- 这个功能解决了谁的什么问题？ —— 如果说不清楚，大概率是伪需求
- 没有这个功能，用户会死吗？ —— 当然不是真死，而是说用户的核心流程会不会断
- 这个功能可以放到二期吗？ —— 如果放二期也没问题，那就别挤在一期里
我在项目中遇到过一位客户，非要加一个“历史数据对比”功能。我问了他三个问题，结果发现这个功能只有他自己偶尔用，而且现有报表已经能满足了。最后我们达成一致：先上线，后续再优化。你看，边界就是这么守住的。
守住边界的四个实操方法
光识别还不够，你得有方法去守住。我总结了四个，都是实战中磨出来的：
| 方法 | 具体做法 | 我的经验 |
|---|---|---|
| 1. 明确需求优先级 | 用MoSCoW法（Must have, Should have, Could have, Won't have）给需求分级 | 我习惯在项目启动会上就把Must和Won't列清楚，白纸黑字签字确认 |
| 2. 建立变更流程 | 任何新增需求都要走变更申请，评估影响后再决定 | 有一次客户想加功能，我让他填变更单，他填到一半自己放弃了——因为评估后要延期两周 |
| 3. 用原型说话 | 把新功能做成低保真原型，让客户和产品经理“看到”而不是“想到” | 很多功能画出来之后，对方自己都觉得没必要了 |
| 4. 设定“功能冻结期” | 在开发中期设定一个时间点，之后只修bug不加功能 | 这个做法救过我很多次，尤其是项目快交付的时候 |
核心原则： 需求边界不是靠“拒绝”来守的，而是靠“共识”来守的。让所有人明白：加功能是有代价的，而这个代价需要大家一起承担。
避坑指南
我曾经接手过一个项目，需求文档里写了30多个功能，但上线后用户只用了其中5个。剩下的25个，全是镀金功能。浪费了团队三个月的时间。
从那以后，我给自己定了一条规矩：每个功能都要回答“用户真的需要吗？” 而不是“这个功能很酷吧？”
💡 小技巧： 下次产品经理或客户来加功能时，你可以这样说：
“这个功能我记下了。我们先把当前的核心功能做完，如果还有余力，我们再考虑加进去。您看行吗？”
—— 既没有拒绝，也没有承诺，给自己留了回旋余地。
嗯，守住边界这件事，说白了就是敢于说“不”。但这个“不”不是硬怼，而是用数据和逻辑让对方自己放弃。你想想看，如果每个需求都照单全收，那项目永远做不完，质量也永远上不去。
最后说一句：好的产品不是功能多，而是功能精。 少即是多，这个道理在需求分析里同样适用。