支付产品的路线图怎么排：一张需求优先级决策框架

支付团队的路线图极难排。因为需求来自四个方向，且每个方向的"紧急"都有正当理由：

• 合规：「不接入这个资质，这个市场就停了」
• 通道：「不接这个本地支付方式，转化率上不去」
• 商户：「大客户说没有批量付款就不续约」
• 技术债：「对账系统再不改，迟早出事故」

排序框架：四维打分

我们对每个需求打四个维度的分（1-5 分），然后计算加权总分：

优先级 = 收入×0.35 + 风险×0.25 + (6−成本)×0.20 + 战略×0.20

关键：风险维度是一票否决

权重 25% 看起来不高，但有个附加规则：风险分 = 5 的需求，无论总分多少，必须排进当前季度。

什么算风险分 5 分？

• 监管明确要求且给了 deadline
• 存在资金损失可能且无缓解措施
• 核心链路单点故障

这条规则救过我们一次：一个「大客户定制报表」需求原本总分最高，但被「清算系统单点故障改造」插队。三个月后那个单点真的出过一次故障，因为已经改造过，只影响了 12 分钟。

反模式清单

我们踩过的坑，列出来供参考：

1. 被最大客户的诉求绑架。 一个客户贡献 30% 收入，他的需求会天然插队。解法：所有需求走同一套打分，包括大客户需求，但要额外计算「该需求的收入集中度风险」。

2. 把「技术债」当成不计分的杂活。 技术债必须像业务需求一样量化：不做的话，未来 6 个月预计产生多少次故障、多少人工成本。量化之后它自己会浮上来。

3. 按「人天最少」排。 会导致团队一直在做小需求，永远没时间做架构升级。

4. 路线图排满 100%。 我们强制留 20% buffer，用于插单和意外。这条纪律让团队的交付承诺可信度大幅提升。

让路线图活起来

路线图不是一年画一次然后贴墙上。我们的节奏：

• 每周：看需求池变动，处理插单
• 每两周：重算一次优先级分数
• 每季度：重排季度目标，砍掉没价值的 30%
• 每半年：回头验证——上个季度排在前面的需求，实际产生了预期价值吗？

最后那条最重要。我们有一个「承诺兑现复盘」：把半年前预测的收入影响和实际数据对比。连续三次高估某个类型需求的团队，会被要求降低该类需求的权重。

路线图的本质不是计划，而是一套公开的、可争论的取舍标准。

小结

好的优先级框架有三个特征：所有人看得懂、不同人对同一需求打出的分数不会差太多、以及它能让你对老板说"不"。