先说我自己的破事。 2018 年我在一家做 CRM 的 SaaS 公司，团队 6 个研发、2 个前端、1 个测试，双周迭代。 老板有一天在群里丢了一句：“竞品有语音审批，我们也上。” 我当时用 RICE 算了一下：Reach 按 30 天活跃销售 4200 人，Impact 给 1，Confidence 我给了 0.8，Effort 6 人日，分数 (420010.8)/6=560。 另一个需求是把客户列表加载从 4.2 秒降到 1.5 秒，Reach 还是 4200，Impact 给 3，Conf 1，Effort 12 人日，分数 1050。 按理说性能优先。但老板插队，语音审批上了。 3 个月后看埋点，使用次数 117 次，使用率 0.7%，而且多数是销售在电梯里没信号时误触。 那天晚上我把 RICE 表格删了，不是模型没用，是我把 Confidence 当成了政治分。
1. 四个模型放一起看，别跪着用
RICE 由 Intercom 的 Sean McBride 在 2016 年推广，公式是 Reach×Impact×Confidence÷Effort。 它适合需求多、有埋点、有用户分群的团队。 但 Reach 如果按 UV 算，很容易漏掉低频高价值场景。 KANO 是狩野纪昭 1984 年提出的，问卷一般用正反两问、5 级量表，算 Better 和 Worse 系数。 我在教育项目发了 212 份家长问卷，Better 最高的是“错题本自动生成”，0.62；但实际愿意付钱的只有 11 人。 ICE 更粗，Impact、Confidence、Ease 各 1-10 分，适合早期没数据时快速筛。 WSJF 在 SAFe 里常见，Cost of Delay 除以 Job Duration，适合 50 人以上、有明确 PI 规划的大团队。 我的独立观点：这些模型都是过滤器，不是决策机。真正难的是决定“不做”。
2. 我现在用的土办法：100 人日预算制
把每个月研发产能当预算。 假设团队 8 个研发，每人每月 18 个有效人日，总产能 144 人日，留 15% 给线上 bug 和会议，实际可排 122 人日。 我会切成三块：核心指标 70 人日，战略探索 25 人日，老板/突发 27 人日。 每个需求必须写四件事：假设、北极星指标、护栏指标、止损线。 比如“客户列表加载优化”：假设加载时间从 4.2 秒降到 1.5 秒，销售日活提升 5%；北极星是“销售人均跟进客户数”；护栏是“列表接口错误率不超过 0.3%”；止损线是上线 14 天若日活提升低于 1%，就回滚或停止后续优化。 这样老板插队时，我不是说“不行”，而是说“可以，从战略探索里扣 6 人日”。 这比吵“这个需求重要还是那个重要”有用，因为它把注意力变成了可花的钱。
3. 具体步骤，能直接抄
1）建需求池，字段至少 14 个：需求名、提出人、日期、目标用户、场景、频率、证据链接、Reach、Impact、Confidence、Effort、战略权重、RICE、状态。 2）每周一重算，RICE 公式不变，但 Confidence 改成证据等级：A 级=有埋点+5 个用户访谈+10 条客服工单，算 1；B 级=3 个访谈+5 条工单，算 0.8；C 级=纯直觉，算 0.5。 3）战略权重乘数 0.5-2，由业务负责人定，但必须写理由。 4）排期会只开 30 分钟，只看 RICE 前 20 和后 5，后 5 直接归档。 5）每两周复盘，上线 30 天看是否达到预设指标，算“决策命中率”。 我待过的小团队，第一年命中率 18%，第二年 34%，大厂有数据中台的可能到 45%。 注意，命中率不是越高越好，太低说明拍脑袋，太高说明你只做保守需求，没有探索。
4. 不同场景，别拿一把锤子敲所有钉子
C 端高频产品，RICE 里 Reach 用周活，Impact 按留存、收入、分享区分。 B 端 SaaS，Reach 要拆成“管理员数”和“最终用户数”，因为买单的人和使用的人经常不是一拨。 平台型产品，先看合规和稳定性，再谈增长。 早期 0-1 项目，ICE 比 RICE 好用，因为没数据，Confidence 全是假的。 硬件或供应链产品，WSJF 更合适，因为延迟成本很高。 最后一句个人观点：产品经理不是写文档的，是组织注意力的套利者。 你省下来的每个 6 人日，都应该投到能验证假设的地方。 别追求模型漂亮，追求少做废需求。
