产品规划怎么做？规划需求清单和版本节奏先排

产品规划指的是把一堆想要的东西排成「这一版做什么、下一版做什么」的那张时间表。关键在需求清单和版本节奏这两步先排，否则第一版就会被塞满，最后什么都做不完。

产品规划最难的不是排期，是把「这个也要」那一项从第一版里删掉。我见过的新团队，十个里有八个在第一版上栽跟头，不是能力不够，是不敢删。

2025 年我参与过一个刚组队的产品，六个人，第一版需求清单列了四十七条。三个月后上线的只有十九条，剩下二十八条既没做也没人说不做，一直挂在看板上，团队每天看着它们开会。

需求清单先列全，再砍掉八成

需求清单的第一步是「先列全」。所有提需求的人一人一句，全都写进去，一条也不许删。这一步的意义不是收集，是让所有人看到总量有多大。不列全，大家永远觉得「就这么点事」。列完之后砍，我用的砍法是问四句：没有它用户能不能完成核心动作、没有它这一版能不能发、没有它数据能不能算出结果、没有它三个月后补行不行。四个问题里有三个答「能」，这条就挪到下一版。

拿童装那个品类规划来说。它的爆款规划里先摆数据：2022 年 6 月，裤子占类目销售额 14.93%、裙子 14.09%、套装 13.47%、T 恤 12.03%，四类加起来超过一半；连身衣 4.87%、家居服 4.87%、内衣裤 4.30%，都是零头。到了 7 月，套装升到 14.93%，裤子掉到 11.38%。

这组数就是砍需求的依据。第一版只做占销售额前四的品类，连身衣、演出服、亲子装这些先别碰。不是它们不该做，是它们加起来不到 4%，占的是团队的档期，换回来的是零头。

产品侧的清单也一样。你列的四十条里，真正影响核心动作的通常不超过八条。我一般会让团队把清单按「不做这一版的后果」排一遍，后果能拖的那批，第一版一律不进。

有个非常实用的做法：给每条需求写一个「删掉它的代价」。写不出代价的，说明它也许多余。这个动作我做了三年，最常出现的结果是，四成需求条目根本写不出代价。

还有一个常被忽略的细节：清单里要区分「功能」和「体验优化」。功能是用户能不能做到，体验是做得顺不顺。第一版里功能优先，体验可以放到后面。这两类混在一张表里排序，体验项往往因为做起来快挤掉功能项，最后上线的产品什么都能点，什么都别扭。清单还要标「谁提的」，不是为了论资排辈，是为了在删的时候知道找谁确认。销售提的和用户提的同一条需求，删的时候要说的话完全不一样。

另一个容易漏的维度：有些需求是「补漏」，有些是「增值」。补漏是缺了就出问题，比如支付失败没有提示；增值是有了更好，比如多一种排序方式。第一版先补齐漏，增值往后放。这两类搞混，团队会把时间花在做加法上，而底座还是漏的。

图源：《jellybaby童装电商爆款产品规划方案》（第9页 · 原文）

需求清单排序，用三条硬标尺

排序别用感觉，用三个可以打分的标尺：影响的人数、影响的程度、做的成本。每条需求三个数，前两个取 1 到 5 分，成本取工天。三列排完，优先级基本自己浮出来了。

我用的具体算式是：优先级分 = 人数分 × 程度分 ÷ 工天。一条影响 5 分人群、程度 4 分、要 3 个工天的需求得 6.7 分；一条影响 2 分人群、程度 5 分、要 10 个工天的需求得 1 分。这个算式不完美，但它能把「声音大」和「值得做」分开。

竞品参照放在排序之后，不要放在排序之前。先按自己的用户数据排完，再去看竞品做了什么，这时候竞品是你的校正项，不是你的起点。先看竞品再排序，排出来的是一份抄来的清单。

用户调研的数据要落到具体行为上。「用户希望更方便」不是需求，「用户在第三步填写表单时平均停留 40 秒、跳出最多」才是需求。前者你没法排，后者你能算出影响多少人和多久。

我自己踩过的坑是把「老板说要」自动排到最前。后来改了规矩：领导提的需求也要走同一套三个数，唯一的不同是可以把「影响程度」这一列由他来定。这样既尊重了判断，也没让清单失去结构。

打分这件事最怕一次性定终身。我建议每次排期都重打一遍，因为人群量会变、成本会变、竞品也会变。上个月排第一位的东西，这个月可能已经不值得做了。重打一遍只要两个小时，比做错一版便宜太多。同类需求还要先合并：「支持多地址」「支持默认地址」「地址簿可编辑」其实是同一个地址模块，合并成一条，工天立刻少一截。

想把这一套真跑一遍的话，运营动脉上有可下载的完整方案和配套表格，照着填比从白纸开始靠谱。

图源：《欧赛斯曲江海洋极地公园零售终端产品规划（汇报稿）》（第6页 · 原文）

版本节奏规划，一版只干一件事

版本节奏规划的核心不是「多久发一版」，是「这一版的主目标是什么」。我建议一版只立一个主目标，其余全是配套。一版里塞三个主目标，结果一定是三个都没达标。

节奏上我按 4 到 6 周一版排。短于 4 周，测不完一轮；长于 6 周，中间的需求会堆到爆。新团队第一版可以放宽到 8 周，因为要同时搭基础框架。

每版留一条「机动槽」。我一般把总工天的 15% 留出来不分配，专门接临时插进来的事。不留这条，任何一次插单都会把后面的计划推倒，推一次，整个团队对排期的信任就掉一格。

版本之间要有「冷却期」，一周左右。上线后第一周不开新需求，只看数据、修 bug。没有冷却期，团队永远在开发，没有人在看产品上线的真实表现。

童装那个规划里还有一层可以参考：它把类目按月份拆开看占比变化，6 月和 7 月的数据是不一样的，套装从 13.47% 涨到 14.93%，裤子从 14.93% 掉到 11.38%。这说明同一个产品在不同周期里的优先级会变。版本节奏里要有一次固定的「重排」，不是一次排完管一年。

我给的节奏模板是这样的：第 1 周定需求清单和排序，第 2 到 4 周开发，第 5 周内测加修 bug，第 6 周上线加冷却。一套走完，再开下一版。

还有一件小事但影响很大：每版发出去之前，先定好这一版要观察的两三个指标，指标多了没人看。上线后这两三个数不对，下一版就围绕它排；数对了，说明这一版的目标达成了，可以安心换一个新目标。版本节奏最忌讳的是「随叫随发的补丁」，补丁发多了版本边界就没了，团队会一直处在救火状态。我的规矩是：紧急问题当天修，非紧急问题等下一个版本窗口。

图源：《欧赛斯曲江海洋极地公园零售终端产品规划（汇报稿）》（第2页 · 原文）

资源盘点不盘点，排期全是空话

资源盘点要盘到人天，不能盘到人。六个人不等于六个人天，还要扣掉会议、请假、支持和其他项目。我一般按人月算完再乘 0.7，这个 0.7 是我用了几年都觉得稳的折扣系数。算下来，六个人的团队一个 4 周的版本，实际可用大概 84 个人天，不是 120 个。

盘完要做一次「满负荷检查」。把清单里的工天加起来，除以可用人天。结果超过 1，就说明这一版注定延期；超过 1.2，基本可以肯定到最后会砍功能赶上线，质量会掉一档。排期排到 1.2，等于提前预定了延期。

还有一项常被漏掉的资源：验收的人。开发完了谁验收、验收要多久，也必须写进排期。不写，上线前那三天就会变成「谁有空谁点两下」，然后带着问题发出去。这一块一般要留出两到三个人天，看功能数量。

资源盘点还要算上「知识成本」。新团队用不熟的技术栈，同样一个功能要多花三到五成时间。这不是团队不行，是学习曲线。第一版如果用了新框架，排期就该多留那一截，别到时候把工期压到加班上。反过来，团队里有人做过类似项目的那一块能省一半工天，盘点时要把「熟不熟」标出来。

图源：《欧赛斯曲江海洋极地公园零售终端产品规划（汇报稿）》（第3页 · 原文）

里程碑和验收标准要成对出现

里程碑只写日期不够，还要写「那天必须交出什么」。我写的格式是：日期加一件可以拿出来看的东西。比如「11 月 20 日，可点击的完整下单单流程」，而不是「11 月 20 日，完成第二阶段」。

验收标准要能判真假。「体验流畅」判不了，「从进入首页到下单成功不超过 5 步、每步加载不超过 2 秒」能判。写不出可判标准的验收项，说明这条需求本身还没想清楚。

里程碑之间留缓冲，不要等间隔。前紧后松，把缓冲压在倒数第二个里程碑之前，最后一个里程碑前面留足时间做验收和修复。新人团队最容易犯的错是把缓冲全放在最后，结果最后一周成了「救火周」。

我个人的经验是：一个版本里里程碑不要超过四个。超过四个，每个里程碑都变成例行汇报，没人再认真看。四个以内，每个都有分量。

验收标准还有个写法上的讲究：写「通过条件」而不是「期望效果」。期望效果是产品上线后才知道的，通过条件是交付当天就能判断的。把这两者混在一起，验收会永远卡在「效果还没出来」上。

图源：《欧赛斯曲江海洋极地公园零售终端产品规划（汇报稿）》（第10页 · 原文）

顺带提一句验收样本。新团队常犯的错是验收只点一遍正常流程，异常见了绕开。我的要求是每条验收至少要跑一遍异常：填错、断网、重复提交、中途退出。这四类各点一次，二十分钟，能挡掉上线后最常见的一半问题。

风险项和复盘机制，写完才叫规划完

风险项要写成「如果某事发生，我们就怎么做」，不是「注意某某风险」。前者有预案，后者只是一句口头提醒。没有写动作的风险项，等于没写。我一般列三到五条风险，每条配一个触发条件和一句应对。比如「如果第三方接口在开发第三周还没通，就把该功能从本版移出，只上线本地流程」。有这句，第三周真的没通，团队不用开会吵，直接照做。外部依赖也算风险，设计资源、法务审核、接口对接，全是别人的档期，一处卡住全版后挪。

图源：《jellybaby童装电商爆款产品规划方案》（第4页 · 原文）

复盘机制要在规划的时候定好，不是版本结束后才想起来。我的做法是每版结束后一周内做一次 60 分钟的复盘，只谈三件事：哪些需求判断错了、哪一步拖了、下次改什么。复盘结论要落到清单的下一版里，不能只写在文档里。

我见过太多团队复盘写得很好，下一版照样把同样的需求又列一遍。复盘真正的作用是给下一版的需求清单去重，不是写一份好看的总结。所以复盘的第一页应该是一张表：上一版砍掉的需求，这一版做没做，为什么。

新团队的三个具体动作

新团队最常见的问题不是没规划，是规划了没人守。我建议第一件事：把需求清单贴在一面看得见的墙上，用纸条，不用文档。纸条能撕，能挪，能当面挪给人看，文档做不到。

第二件事：给每一版写一句话的主目标，写在群里置顶。团队每天散会前读一遍，能读出来，说明还清楚；读不出来，就说明这版又塞歪了。

第三件事：每一版结束做一次「删了什么」的公示。把砍掉的需求列出来，写清砍的理由和计划补上的版本。敢公示自己砍了什么，团队才敢相信排期。

我带的第一个新团队，第一次公示「砍了什么」的时候很紧张，怕有人说我们不做实事。结果公示贴出去，运营那边反而说「早知道这几条要往后放，我们的活动就不按原来的时间排了」。信息一透明，配合就顺了。

产品规划这件事做到最后，拼的不是谁想得全，是谁敢删得干净。需求清单列得越长，越说明没想清楚哪一条是命门。一份好的产品规划，第一版永远比你想做的更少，但每一版都能按时发出去。

你可以先做一件事：把手上那份需求清单打印出来，拿笔给每条写「删掉它的代价」。写不出来的当场划掉。这一轮下来，你会发现清单短了一半。

图源：《欧赛斯曲江海洋极地公园零售终端产品规划（汇报稿）》（第8页 · 原文）

下一步是给剩下的每一条打三个数，人数、程度、工天，算完排一遍。排完如果第一版还有二十条以上，再砍一轮。放心，砍掉的不会消失，它们会排在第二版、第三版，只要清单在，一条都跑不了。

记住：需求清单和版本节奏这两步排完，产品规划就不再是一张愿望单，而是一份能兑现的承诺。