第2章 需求来源与分类：优先级权重的基础
2.1 四大需求来源的识别框架
需求并非凭空产生，它们总是来自特定渠道。在实际产品工作中，需求的来源可以归纳为四类：用户反馈、业务目标、技术债务、合规需求。每一类需求在优先级标注时拥有不同的“权重”倾向，必须结合来源特性才能做出合理的排序。
讲师提醒：不要机械地按来源给需求打标签，而是先判断需求背后的驱动因子——是用户痛苦、商业机会、系统风险，还是法律红线？驱动因子的紧急程度决定了初始权重。
2.2 需求来源特征对比
| 需求来源 | 典型触发场景 | 默认优先级权重 | 响应周期 | 验收核心标准 |
|---|---|---|---|---|
| 用户反馈 | 客诉、NPS低分、体验地图痛点 | 中～高（视影响面） | 2～4周 | 用户满意度提升≥10% |
| 业务目标 | OKR拆解、营收增长、市场份额 | 高（与OKR对齐） | 按季度/月度节奏 | 关键指标达成率≥90% |
| 技术债务 | 代码耦合、性能瓶颈、未重构模块 | 中（技术风险优先） | 持续迭代中穿插 | 故障率下降、维护效率提升 |
| 合规需求 | 法规更新、安全审计、数据保护 | 极高（不可妥协） | 按监管截止日期 | 完全通过合规审查 |
2.3 优先级权重的差异化规则
同一个需求如果来源不同，权重计算方式截然不同。以“增加用户信息导出功能”为例：
- 用户反馈来源：权重取决于投诉量 + 功能使用频率，通常为P2～P3。
- 业务目标来源：若该功能是续费转化漏斗的关键卡点，权重可升至P1。
- 技术债务来源：旧导出模块耦合严重，长期维护成本高，权重为P2（技术健康类）。
- 合规需求来源：若新法规要求用户必须能在30天内自助导出全部数据，则权重为P0（必做）。
关键法则：合规需求与技术债务中的“安全/数据漏洞”享有最高优先级覆盖权；业务目标中的“季度核心指标”次之；用户反馈中的“高频共性痛点”再次之。其他可通过量化评分（见第4章）进行二次矫正。
2.4 需求来源与优先级权重关系图
2.5 场景案例：多来源冲突时的优先级调整
某电商APP后台同时收到三个需求：
- 需求A（用户反馈）：购物车商品数量上限从100提升至500——中痛点。
- 需求B（业务目标）：新增“大促拼团”功能——季度GMV目标驱动。
- 需求C（技术债务）：订单查询接口响应慢，影响运营效率——技术缺陷。
在优先级权衡中：如果合规或安全无影响，则B（业务目标）应排第一，C（技术债务）次之，A（用户反馈）最后。但若C影响了线上稳定性，则C需提升至P1，与B并列甚至更高。
常见误区：不要在所有需求上一视同仁地使用“用户反馈优先”策略。技术债务和合规需求往往被低估，导致后期翻修成本远超预期。每个来源都应设置一个“基础权重系数”，再结合其他维度（影响面、紧急度、实现成本）做最终排序。
2.6 交付物模板概要
在本章结束后，你应能在PRD的“需求来源”字段中清晰标注来源分类，并在优先级评分中体现该来源的默认权重系数。具体模板如下：
| 需求编号 | 需求标题 | 来源分类 | 默认权重系数 | 调整后优先级 | 备注 |
|---|---|---|---|---|---|
| REQ-021 | 用户信息导出 | 合规需求 | 1.8（极高） | P0 | 数据保护法要求 |
| REQ-022 | 首页推荐算法优化 | 业务目标 | 1.5（高） | P1 | Q2核心指标 |
| REQ-023 | 列表加载速度优化 | 技术债务 | 1.2（中） | P2 | 影响QPS |
2.7 验收标准
- 能够快速识别每个需求所属的来源分类，并在PRD模板中填写准确。
- 能够根据来源默认权重系数，结合紧急度与影响面进行优先级初判。
- 能够应对多来源冲突场景，正确做出调整决策。