规则型需求常常让产品经理在评审会上陷入尴尬——不是没想清楚，而是没把逻辑真正落地。本文揭秘「决策表」如何将模糊的业务规则转化为系统可执行的铁律，从根本上解决权限、状态等复杂条件的判断难题，让需求评审效率提升50%，彻底告别联调阶段的反复扯皮。

老实说，大部分规则型需求不是没想清楚

是你没把「决策表」写出来

我先说个很真实的场景。

前阵子我在改一个“下载 Excel”的需求，评审会上，研发突然问我一句：“那如果用户有权限，但今天已经下过一次了，还能不能下？”

那一瞬间，我脑子里其实是有答案的。

但问题是——我发现我没法一句话说清楚。

你要是也干过产品，大概懂那种感觉：不是不会，是说着说着就开始补条件。

这类需求，后来我统一给它起了个名字：规则型需求。

规则型需求，最大的问题只有一个

不是业务复杂，也不是人不聪明。

而是这类需求有一个致命特征：你只要不用结构写，它一定会在评审或联调阶段翻车。

什么权限、状态、是否可操作、是否展示、是否生效……这些玩意儿，本质上都在问一件事：在某一组条件下，系统“必须”怎么做。

注意，是“必须”，不是“建议”。

说个反直觉的结论

很多产品经理以为自己缺的是「逻辑树」。

但我后来发现，真正缺的，其实是「决策表」。

逻辑树更像什么？

像你在脑子里过一遍：“嗯，好像要判断这个，还要判断那个。”

但真正能救命的，是决策表。

我们从一个烂大街的需求说起

需求内容你肯定写过类似的：

登录用户，在有权限且不超额的情况下，可以下载数据。

这句话，看着没毛病，对吧？

但你把它丢给研发、测试，基本等于埋雷。

因为它至少会引出这些问题：

• 游客算不算用户？
• “有权限”是指会员等级，还是功能点？
• 超额是今天？本月？还是 24 小时滚动？
• 超额了是直接禁，还是给个“升级套餐”的提示？

你会发现一个很尴尬的事：

这些问题你大概率都“心里有答案”，但没写。

逻辑树：说白了，是帮你“把脑子掏干净”

这个时候，逻辑树确实有用。

它干的事情很单纯：

逼你不断问自己一句话：“这一步，还要不要再判断一下？”

于是你会拆成这样：

能不能下载？

├─ 登没登录？

│ ├─ 没登录 → 不行

│ └─ 登录了

│ ├─ 有没有下载权限？

│ │ ├─ 没有 → 不行

│ │ └─ 有

│ │ ├─ 今天是不是超额？

│ │ │ ├─ 是 → 不行

│ │ │ └─ 否 → 可以

到这里为止，你想清楚了。

但注意，只是想清楚。

真正的分水岭：你有没有把它变成「决策表」

重点来了。

如果你停在逻辑树这一步，其实还不够。

因为逻辑树有一个问题：它对你友好，对系统不友好。

系统不看“过程”，系统只认：输入是什么，输出必须是什么。

于是，我后来会强迫自己做一件事：把逻辑树压成一张决策表。

这张表一写出来，有几个变化特别明显：

• 研发基本不再追问“那这种情况呢？”
• 测试可以直接一行一行写用例

你自己会突然发现：原来规则就这几条

一句行话：

决策表一出，需求基本就“收敛”了。

决策表和逻辑树，到底差在哪？

我用一句不太严谨、但很好记的话说：

• 逻辑树，是给人用的
• 决策表，是给系统用的

再直白点：

• 逻辑树解决的是：「我有没有漏想？」
• 决策表解决的是：「有没有任何扯皮空间？」

所以你会发现一个现象：

需求越复杂，决策表越重要

而不是逻辑树越重要

为什么我后来写 PRD，会刻意“偏爱”决策表

有几个很现实的原因：

决策表天然能对齐研发思维

一行 = 一个 if / else

没什么翻译成本

它能强迫你给出“唯一答案”

不允许“看情况”“到时候再说”

测试特别喜欢

他们拿着表就能测，不用猜你在想什么

评审效率明显变高

争论点会集中在“规则对不对”，而不是“你刚才那句话什么意思”

我现在判断要不要写决策表的土办法

很土，但特别好用。

只要我在需求里看到这些词：

• 是否
• 权限
• 状态
• 条件
• 能不能
• 是否展示 / 是否可点

我脑子里就会自动弹一句话：

“这玩意儿，不写决策表会出事。”

最后说一句实话

很多时候，不是你逻辑不严谨，也不是你不会画逻辑树。

而是你停在了“想明白”这一层，却没往前走到“写死规则”。

而决策表，恰恰是那个

把规则从“人话”，变成“系统话”的关键一步。

简单来说：

逻辑树帮你想清楚，决策表帮你少加班。

这话我现在是真信了。