“不知道用户有什么用？那就扫走吧。”
第一次听这句话的时候，很多人以为是一句调侃。但等你在需求评审会上见过“会员体系必须上”“签到闭环一定要做”“个性化推荐这版就要接进来”这类需求，而对方又答不出用户是谁、场景是什么、验证指标是什么时，你就会明白：这句话其实是研发团队最高效的资源保护手段。
不是说产品不努力，也不是说业务不需要增长。而是大多数团队真正的问题，从来不是技术做不出来，而是启动了太多“做完之后不知道谁会来用”的功能。真正消费研发资源的，不是需求的数量，而是所有人在一个价值未经验证的需求上投入的时间。更麻烦的是，这类需求一旦上线，还要承担后续的维护成本、客服成本、性能成本，再想“扫走”就难了。
这篇文章不讨论怎么怼产品经理，也不讨论怎么逃避工作。我会从一个技术人的视角，给出判断需求用户价值的方法、可落地的评估工具、开发前的最小验证方案，以及一套让“不做这件事”也能被团队接受的操作流程。读完之后，你可以带着 RICE 打分脚本、埋点验证代码和特性开关配置回到项目里，用工程手段把低价值需求挡在开发流程之外。
1. 这篇文章真正要解决的问题
先讲清楚一个容易被忽略的成本结构。一个功能的价值不是“上线就完了”，它从需求提出开始，就消耗着团队时间。需求评审、技术方案、开发、联调、测试、上线、灰度、回归、埋点分析、问题答疑，每一步都是人力成本。如果这十个步骤做完，用户完全不买账，这部分成本就全部沉没。而且它挤占了原本可以做其他验证的时间，这就是机会成本。
伪需求不是“坏需求”。它的提出方通常有真实诉求，只是那个诉求没有被正确地描述和验证。比如：
- 竞品做了“连续签到”，我们不做就感觉落后。
- 老板在某次物料会上说了一句“这个功能可以想一下”。
- 运营同学观察到 3 个用户反馈，要求做一个覆盖所有用户的复杂配置功能。
这些需求如果直接进入开发队列，几乎没有风险提示。因为需求本身不过是一场会议里的一句话，真正投入的是团队大量的人日。所以技术人必须参与需求治理，不是替团队做产品决策，而是在需求进入开发之前，确保它有明确的用户、场景和验证路径。
这套方法的核心结论是：如果需求说不上来给谁用、解决什么冲突、上线后用什么指标证明价值，那么它就应该被“扫走”。“扫走”不等于永久删除，而是把它移到一个“验证区”：不安排开发，只安排最少量的验证动作。验证通过了，再回到排期；验证不过，就自然淘汰。这是所有方法里成本最低的一种处理方式。
本文适合技术负责人、后端/客户端/前端工程师、项目 Owner 阅读。你不需要是产品专家，只需要把下面几件事当成工程任务来做。
2. 先用三个维度识别“伪需求”
看一个需求是不是伪需求，不需要复杂的分析模型，先问三个问题：
- 用户是谁？
- 用户带着什么任务来？
- 完成这个任务后，会发生什么可观测的变化？
如果一个需求连第一个问题都回答不了，或者只能用“所有用户”来概括，那它大概率不是一个好需求。真实需求是从具体人群切入的。例如“新注册用户在 24 小时内更容易流失”比“用户需要更好的体验”更容易指导设计。
第二个问题背后是场景。用户不是平白无故用你的功能，他一定是在某个场景里遇到了阻碍。没有场景支撑的功能，即使做出来，也没有触发入口，用户根本不会想起来。
第三个问题决定怎么验证。可观测变化可以是按钮点击率、停留时长、复购率、客服工单数量，也可以是一个流程的完成率。如果上线前说不出来指标，上线后就是靠感觉评判，这样的需求风险极高。
可以用表格对比真需求和伪需求：
| 维度 | 真需求 | 伪需求 |
|---|---|---|
| 用户画像 | 能说出具体人群和规模 | 用“所有用户”“提升体验”带过 |
| 使用场景 | 在什么时机、什么页面、什么任务下使用 | 只有功能描述，没有场景 |
| 当前方案 | 用户现在怎么做，缺什么 | 不关心现状 |
| 验证指标 | 上线后看什么数据，阈值多少 | 用“感觉”“趋势”决定 |
| 不做的影响 | 能说清楚损失什么 | 想不出来不影响什么 |
伪需求有几个高频信号。第一是“竞品有，所以我们要有”，这类需求容易出现在监控栏目里。第二是“领导提的”，这类需求不是不能做，而是需要先把它转化成业务目标和验证指标。第三是“为少数用户反复提出的需求”，当个别用户的声音被放大成全量需求时，需要用概率和成本来衡量。第四是“内部自嗨型”，功能设计出来是为了满足团队内部的控制感，而不是用户的真实任务。
3. 需求价值评估：RICE 打分法落地
识别伪需求只是第一层，接下来要对需求做排序。研发资源有限，不可能同时做所有还说得过去的需求。RICE 是一个非常实用的优先级模型。
RICE 四个字母的含义：
- Reach（触达范围）：一定周期内会受该功能影响的用户数量。不是注册总量，而是真正会用到这个功能的用户数。
- Impact（影响力）：功能完成后，对单个用户产生的影响程度。通常用 0.5（微小）、1（中等）、2（大）、3（巨大）来打分。
- Confidence（信心）：你有多大把握上述估计是对的。0.5 表示很没底，1 表示正常，1.5 表示有数据支撑。
- Effort（工作量）：团队完成该功能需要投入的人月或人日。
公式：RICE Score = (Reach × Impact × Confidence) / Effort
RICE 分数用来排序，不用来直接决定做不做。如果两个需求分数差异很大，高分的先做；如果分数接近，再讨论战略方向。
3.1 用 Python 脚本计算 RICE 分数
下面是一个最小脚本，把需求整理成字典，批量计算。
# 文件：rice_score.py # 用途：按 RICE 模型对需求批量打分排序 def rice_score(name, reach, impact, confidence, effort): score = (reach * impact * confidence) / effort print(f"需求：{name}") print(f" Reach={reach}, Impact={impact}, Confidence={confidence}, Effort={effort}") print(f" RICE 得分：{score:.2f}") return score # 需求数据，按实际情况修改 requirements = [ {"name": "订单导出", "reach": 8000, "impact": 3, "confidence": 0.8, "effort": 8}, {"name": "会员等级体系", "reach": 2000, "impact": 2, "confidence": 0.4, "effort": 40}, {"name": "消息中心", "reach": 5000, "impact": 1, "confidence": 0.6, "effort": 15}, ] req_scores = [] for req in requirements: score = rice_score(**req) req_scores.append((req["name"], score)) req_scores.sort(key=lambda item: item[1], reverse=True) print("\n排序结果：") for name, score in req_scores: print(f"{name}: {score}")运行：
python3 rice_score.py预期输出中，订单导出分数最高，会员等级体系因为 confidence 低、effort 大，排在后面。这个例子想说明：一个投入很大且置信度不高的需求，除非有强烈的战略理由，否则就应该被“扫走”。
3.2 给打分设边界
RICE 不是完美的。最大的问题是 confidence 容易被人为抬升。需求方为了让需求排上，会把 confidence 填成 1.5，把 reach 填成全网用户数。所以在团队使用 RICE 时，建议增加一条约定：Reach 必须写清楚数据来源，Confidence 低于 0.6 的默认进入验证区，而不是开发队列。这样一来，打分过程本身就会逼着需求方补齐数据。
4. 需求评审前，技术人先做这三件事
需求评审会不是用来临时讨论的。如果所有争议都在评审会上才暴露，会议一定开得又臭又长，最后变成谁的嗓门大听谁的。更合理的做法是在评审前把信息补全。
第一件事：要求需求方补充“需求背景说明书”。内容至少包括：用户是谁、要解决什么问题、如果不做会怎样、上线后用什么指标衡量。不需要写成文档大师，三五行的 PRD 补充也可以。关键是让人在开会前就能判断需求成色。
第二件事：查一下现有数据。新需求往往不是完全无中生有的。如果还没有埋点，可以看工单、客服记录、搜索词、后台日志。举个例子，如果一个需求是“用户想导出订单”，可以先看搜索词里有多少人搜“订单导出”，客服一周被问几次。这些数据比主观判断更可靠，判断成本也更低。
第三件事：确认“不做会怎样”的答案。问这个问题不是抬杠，而是强迫需求方思考功能的关键性。如果需求方犹豫了半天，说不出来什么影响，那这个需求大概率可以被推迟。相反，如果它能说清楚“不做会导致每日 100 个用户流失”，这个需求就值得认真对待。
下面给一个可以直接粘贴到 PRD 里的需求评估模板：
| 项目 | 内容要求 |
|---|---|
| 背景 | 一句话说明为什么要做 |
| 用户 | 具体人群、规模、数据来源 |
| 场景 | 什么时候、哪里、怎么做这件事 |
| 当前方案 | 用户现在怎么解决这个问题 |
| 预期收益 | 最多可量化的 3 个指标 |
| 不做的影响 | 明确写，想不出来就写“暂不确定” |
| 验证方式 | 上线后如何判断成功 |
模板不是为了增加文档工作量，而是让每个需求都有自己的“证据链”。没有证据链的需求，默认不进入开发。
5. 如何在开发前做最小验证
即使需求通过了前两关，也不意味着直接进入开发。特别是当工作量较大、置信度不高的时候，先用最小代价验证用户的真实反应。验证的目标不是“做出来”，而是回答“用户是否需要”。
5.1 观察现有行为：前端埋点
如果功能还没有开发，但页面结构允许，可以先做一个引导点击入口，用埋点统计用户点击意愿。下面是一个前端点击采集的简化示例：
<!-- 页面中的一个功能入口 --> <button id="order-export-entry">// 文件：track.js document.getElementById('order-export-entry').addEventListener('click', function () { fetch('/api/track', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ event: 'order_export_click', page: window.location.pathname, ts: Date.now() }) }).catch(function (err) { console.error('埋点上报失败', err); }); });后端接收的简化实现，使用 Flask：
# 文件：app.py from flask import Flask, request app = Flask(__name__) @app.route("/api/track", methods=["POST"]) def track(): data = request.get_json() # 正常项目中这里应该写入消息队列或日志系统 print("收到埋点事件:", data) return {"code": 0, "message": "ok"} if __name__ == "__main__": app.run(port=5000)这段代码的作用不是做数据分析，而是验证“用户有没有点击”。如果入口放出去一周，曝光量很大但点击率非常低，说明用户对这个功能可能并不那么感兴趣，需求就要回到验证区了。
5.2 用占位页验证需求意愿
更轻量的方式是在 App 或 Web 端放一个“敬请期待”的占位页，配合按钮文案，观察用户的点击和预约行为。预约人数超过阈值，再决定开发；低于阈值，直接放弃。这个方案的优点是不写复杂的业务逻辑，成本极低。缺点是有可能被用户认为是吊胃口，所以只适合验证单个高价值功能，不宜频繁使用。
5.3 给验证设一个“时间盒”
验证不能无限期。团队要事先约定验证周期和通过指标。例如：两周内点击量超过 1000 次，预约转化率超过 5%，则进入设计阶段；否则扫走。时间盒的好处是让验证成为排期的一部分，而不是可做可不做的额外任务。
6. 特性开关：让“扫走”这件事可回滚
很多团队不敢拒绝需求，还有一个原因：担心判断错误。如果功能做出来上线后效果不好，再回滚很麻烦，于是只能硬着头皮维护。这种心理恰恰会让伪需求越积越多。
工程上解决这个问题的方式是特性开关（Feature Flag）。在功能开发时，就把开关埋进去。每次发布都不用强制用户看到新功能，而是按配置决定是否开启，以及按用户比例灰度放量。如果数据表现不好，一键关闭，而不是连夜下线版本。
下面是一个轻量配置示例：
# 文件：feature_flags.yaml features: member_level: enabled: false rollout_percent: 0 order_export: enabled: true rollout_percent: 100 notify_center: enabled: true rollout_percent: 10配合一个简单的 Python 读取模块：
# 文件：flag_reader.py import yaml with open("feature_flags.yaml", "r", encoding="utf-8") as f: config = yaml.safe_load(f) def is_enabled(feature, user_id=None): flag = config["features"].get(feature) if not flag: return False if not flag.get("enabled", False): return False percent = flag.get("rollout_percent", 100) if percent >= 100: return True if user_id is None: return False # 按 user_id 哈希做简易灰度 hash_val = sum(user_id.encode("utf-8")) % 100 return hash_val < percent if __name__ == "__main__": print("member_level:", is_enabled("member_level", "user_1001")) print("order_export:", is_enabled("order_export", "user_1002")) print("notify_center:", is_enabled("notify_center", "user_1003"))运行前先安装依赖：
pip install pyyaml python3 flag_reader.py实际生产项目里，建议把开关配置放到配置中心或专门的特性开关平台，而不是每次改文件重新部署。这里用 YAML + Python 只是为了理解原理。引入特性开关后，“扫走”一个功能就变成改一个配置项的事，这比代码回滚安全得多，也更适合灰度验证。
7. 拒绝一个需求，不等于吵架：更体面的处理方式
经常有同学问：如果需求真的很伪，但产品经理就是坚持要做，怎么办？这里要区分两种“拒绝”。一种是不负责任的丢回去，另一种是带着替代方案说不。
负责任的做法是四个步骤：
- 表示理解需求背后的动机。不否定对方的业务判断，而是问“你担心的是哪一类用户流失”。
- 拿出数据或验证方案。哪怕只是把 RICE 打分表打开，也能让讨论从情绪转向事实。
- 提出一个更小范围的验证动作。不开发能力，而是放一个占位入口或做定向访谈，用一周时间看数据。
- 重新约定时间点。约定两周后回到评审会，根据验证结果决定是排期还是永久扫走。
落到具体沟通场景，可以这样说：
- “这个功能我可以排，但按我们之前的定义，它的 confidence 只有 0.4。我建议先给 2000 个用户开一个入口，看看点击率，两周后回来对数据，行不行？”
- “如果今天必须先上线一个能力，我更倾向于先做订单导出，因为它每个月的工单量能直接反映需求，会员体系可以放到下一轮。”
这样做有两个好处：一是你没有拒绝对方的目标，只是调整了实现路径；二是你为团队争取到了数据决策的依据，避免拍板上线。
更底层的心法是：技术人不要只在接需求时出现，要在需求定义阶段就出现。你能贡献的不只是工时评估，还有如何验证用户价值的方法。当你能说出“这个功能我们不急着开发，但我们需要这样一个验证方案”时，你在评审会上的话语权会完全不同。
8. 常见问题与排查思路
在推行这套方法时，会遇到各种现实阻力。这里把常见问题整理成表格。
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 文件里写了评估模板，但产品不填 | 模板增加了需求方工作量，没有形成流程约束 | 检查模板是否太长，字段是否重复 | 精简模板，保留用户、场景、指标、不做的影响，纳入 PRD 必填项 |
| 需求方说“老板定的，必须做” | 需求没有与业务目标建立联系 | 询问老板关心的业务指标是什么 | 把需求映射到指标，设置最简单的验证实验，给出时间盒 |
| RICE 打分总是被夸大 | Reach 和 Confidence 取值没有依据 | 要求每个字段写数据来源 | 规定 Reach 必须从埋点/工单/搜索词中获取，Confidence 低于 0.6 默认进验证区 |
| 埋点数据迟迟没有增长 | 入口曝光低或埋点事件未生效 | 检查页面曝光和 Network 请求 | 前端本地联调，确认事件上报；增加曝光事件 |
| 特性开关关闭后流量仍有进入 | 客户端缓存了旧配置 | 查看配置刷新机制 | 接入配置中心动态刷新，或强制生效时间 |
| 需求被扫走后，需求方情绪抵触 | 把“扫走”理解成了否定方向 | 回顾沟通步骤 | 提供替代验证方案，约定回归时间 |
这套排查思路的核心是先看数据和配置，而不是陷入口头争论。需求治理本身也是一种工程问题，要有日志、有指标、有回滚。
9. 最佳实践：把需求治理融入研发流程
最后分享几条在实际项目中验证过有效的做法。
第一，把需求评估模板内建到 PRD 模板中。如果公司用 Jira、TAPD 或飞书项目，把“用户、场景、预期指标、不做的影响”设置成必填字段。字段不填，流程不允许进入评审。这是用流程约束替代个人自觉，比“提醒大家写清楚”可靠得多。
第二，在迭代排期之外，单独列一批“验证任务”。这些任务可能只是加一个埋点、做一次访谈、写一条数据查询，看起来不像开发，但它们的作用是降低下一个开发决策的风险。验证任务和开发任务一样计入工作量，不能让团队白干活。
第三，建立“需求验证区”或“需求池”。被扫走的需求不用直接删掉，而是放进一个专门的空间，记录扫走时间、原因、验证期限。两周或一个月后回看，如果没有人再提起，也没有数据证明需要复活，再真正删除。这样做既保留了信息，也让“扫走”变得可追溯。
第四，定期做一次需求复盘。每季度把过去三个月上线功能的真实数据拉出来，对比当初评估时的预估。哪些需求低估了工作量，哪些需求高估了用户量，逐条追原因。这个复盘不是追责，而是校准团队的判断能力。
第五，把需求评审看成代码评审的“上游事件”。代码评审是检查代码能不能合入，需求评审是检查需求能不能进入开发。很多代码问题来自需求定义不清，想在代码层面补救是低效的。技术人越早参与到用户价值和验证方案的设计中，团队浪费的资源就越少。
真正值得记住的判断是：需求被“扫走”不是它的终点，而是它需要重新证明自己的开始。愿意把有限研发资源投入到已经验证过的价值上，才是对用户和团队更负责的方式。下次再遇到一个“不知道用户有什么用”的需求时，不必纠结，把它扫走，补上验证动作，用数据说话。
