规则型需求常常让产品经理在评审会上陷入尴尬——不是没想清楚，而是没把逻辑真正落地。本文揭秘「决策表」如何将模糊的业务规则转化为系统可执行的铁律，从根本上解决权限、状态等复杂条件的判断难题，让需求评审效率提升50%，彻底告别联调阶段的反复扯皮。
老实说，大部分规则型需求不是没想清楚
我先说个很真实的场景。
前阵子我在改一个“下载 Excel”的需求，评审会上，研发突然问我一句：“那如果用户有权限，但今天已经下过一次了，还能不能下？”
那一瞬间，我脑子里其实是有答案的。
但问题是——我发现我没法一句话说清楚。
你要是也干过产品，大概懂那种感觉：不是不会，是说着说着就开始补条件。
这类需求，后来我统一给它起了个名字：规则型需求。
不是业务复杂，也不是人不聪明。
而是这类需求有一个致命特征：你只要不用结构写，它一定会在评审或联调阶段翻车。
什么权限、状态、是否可操作、是否展示、是否生效……这些玩意儿，本质上都在问一件事：在某一组条件下，系统“必须”怎么做。
注意，是“必须”，不是“建议”。
很多产品经理以为自己缺的是「逻辑树」。
但我后来发现，真正缺的，其实是「决策表」。
逻辑树更像什么？
像你在脑子里过一遍：“嗯，好像要判断这个，还要判断那个。”
但真正能救命的，是决策表。
需求内容你肯定写过类似的：
登录用户，在有权限且不超额的情况下，可以下载数据。
这句话，看着没毛病，对吧？
但你把它丢给研发、测试，基本等于埋雷。
因为它至少会引出这些问题：
你会发现一个很尴尬的事：
这些问题你大概率都“心里有答案”，但没写。
这个时候，逻辑树确实有用。
它干的事情很单纯：
逼你不断问自己一句话：“这一步，还要不要再判断一下？”
于是你会拆成这样：
能不能下载？
├─ 登没登录？
│ ├─ 没登录 → 不行
│ └─ 登录了
│ ├─ 有没有下载权限？
│ │ ├─ 没有 → 不行
│ │ └─ 有
│ │ ├─ 今天是不是超额？
│ │ │ ├─ 是 → 不行
│ │ │ └─ 否 → 可以
到这里为止，你想清楚了。
但注意，只是想清楚。
重点来了。
如果你停在逻辑树这一步，其实还不够。
因为逻辑树有一个问题：它对你友好，对系统不友好。
系统不看“过程”，系统只认：输入是什么，输出必须是什么。
于是，我后来会强迫自己做一件事：把逻辑树压成一张决策表。
这张表一写出来，有几个变化特别明显：
你自己会突然发现：原来规则就这几条
一句行话：
决策表一出，需求基本就“收敛”了。
我用一句不太严谨、但很好记的话说：
再直白点：
所以你会发现一个现象：
需求越复杂，决策表越重要
而不是逻辑树越重要
有几个很现实的原因：
决策表天然能对齐研发思维
一行 = 一个 if / else
没什么翻译成本
它能强迫你给出“唯一答案”
不允许“看情况”“到时候再说”
测试特别喜欢
他们拿着表就能测，不用猜你在想什么
评审效率明显变高
争论点会集中在“规则对不对”，而不是“你刚才那句话什么意思”
很土，但特别好用。
只要我在需求里看到这些词：
我脑子里就会自动弹一句话：
“这玩意儿，不写决策表会出事。”
很多时候，不是你逻辑不严谨，也不是你不会画逻辑树。
而是你停在了“想明白”这一层，却没往前走到“写死规则”。
而决策表，恰恰是那个
把规则从“人话”，变成“系统话”的关键一步。
简单来说：
逻辑树帮你想清楚，决策表帮你少加班。
这话我现在是真信了。
本文由 @尤里卡高 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。