业务方说"配置化"，研发说要 2 周——PM 怎么判断这是真配置化还是伪配置化（其实要做个小产品）
该问题的正文、回答与评论。
【背景】 我做了 10 年技术 PM，主做 B 端 SaaS。最近一个季度，"配置化"这个词在需求评审会上出现的频率高到让我有点生理不适——业务方说"能不能配置化一下"，研发说"可以做但要 2 周"，我夹在中间既没法说"对，做"也没法说"对，不做"。
【现象】 具体案例：业务方提了一个"客户想自己配置告警规则"的需求，研发评估 2 周。我追问"配置什么"，业务方说"阈值、时间窗口、通知方式"——听起来就是 3 个字段的事，但研发说要做规则引擎。我再追问"是用户自己拖拽规则，还是从预设模板里选"，业务方说"最好都能"。这时候我意识到：这已经不是一个"配置化"需求，而是一个"规则产品"需求，但业务方的预算是按"配置化"算的。
【已尝试的排查与结果】
- 让研发把 2 周拆成"最小可配置 + 完整规则引擎"两段，业务方选了"最小可配置"。结果上线 2 周后业务方说"客户又加诉求了，得再加"——等于没拆干净，本质还是没对齐抽象层级。
- 直接拒绝"配置化"这个词，让业务方写清楚"客户到底要解决什么问题"。业务方写了一版，但里面混进了 4 个抽象层级不同的诉求（字段级 / 规则级 / 流程级 / 模型级），研发还是不知道做哪个。
- 翻过站内几篇"排期冲突 / 估时偏差"的帖子（如 #782、#564），但那些讲的是"算账"，没讲"怎么先判断这是不是同一类需求"。
【期望得到的答案形态】 我想要的不是"怎么和研发沟通"也不是"怎么和业务方沟通"，而是一份判断标准清单，最好能直接抄进评审会：
- 什么样的"配置化"是真配置化（字段级 / 枚举级 / 模板级），什么样的已经越界成"产品化"（规则级 / 流程级 / 模型级）？边界在哪？
- 用什么问句 / 模板，能在 30 分钟评审会上把"业务方口中的配置化"和"研发口中的产品化"对齐到同一个抽象层级？
- 当确实越界时，PM 用什么"降级话术"把"做小一点"变成业务方能接受的方案，而不是简单说"做不了"？
- 有没有 5~10 条 checkbox 式的"配置化 vs 产品化"边界判定清单，能直接贴进 PRD 模板？
期待有踩坑经验的同学给一份能直接抄进评审会的清单，最好附一个真实案例。谢谢。
结论先给：判断"真配置化 vs 伪配置化"最硬的判据不是字段数量，而是「测试用例数是否可穷举」。 配置化的本质是有限枚举、可穷举验证；产品化的本质是组合爆炸、不可穷举。这个判据来自测试侧，比 PM 的"问句对齐"更客观，因为你可以直接拿用例数去压研发估时。
一、核心判据：用例数公式
把业务方说的"配置项"列成一张表（每行 = 1 个可配置字段/枚举），然后问三个问题：
| 问题 | 回答 → 判定 | |---|---| | ① 配置项之间有没有 if/else / 嵌套 / 优先级？ | 无 → 真配置化；有 → 越界 | | ② 改了 A 配置项，B 配置项的行为会不会跟着变？ | 不会 → 真配置化；会 → 越界 | | ③ 让业务方给 3 个不同客户各自的期望配置方案，3 个方案之间结构是否一致（字段集合相同，只是值不同）？ | 一致 → 真配置化；结构不同（客户 A 有 3 个字段，客户 B 有 5 个字段且多 1 层嵌套）→ 产品化 |
量化公式（直接贴进 PRD）：
- 真配置化：用例数 ≤ 配置项数 × 5（每项覆盖正常 / 边界 / 异常 / 权限 / 并发）。10 个配置项 → ≤ 50 条用例，研发 2 周内可完成开发 + 测试。
- 伪配置化（产品化）：用例数需要"场景组合"，无法用"字段 × N 取值"覆盖，而是需要"客户画像 × 业务场景 × 条件分支"的笛卡尔积。3 个客户 × 4 个场景 × 3 个条件分支 = 36 条起步，且每加一个客户/场景用例数乘性增长。这时候 2 周不够，因为测试本身就要 1 周。
二、30 分钟评审会的对齐问句（按顺序问）
- "把你要配置的东西列成一张表，每行一个字段，告诉我字段名、取值范围、谁有权改。"（→ 得到配置项清单）
- "这些字段之间有没有'如果 A=1 则 B 必须=2'这种联动？"（→ 检测组合爆炸）
- "给我 3 个真实客户，每个客户期望的配置长什么样？我看看它们结构是不是一样的。"（→ 检测是否其实要做 N 个产品）
- "上线后，加一个新配置项的预估成本是多少？如果 > 1 天研发 + 0.5 天测试，说明你们不是在'配置'，是在'开发'。"（→ 暴露真实复杂度）
三、降级话术（不是"做不了"，而是"分阶段验证"）
当判定越界时，不要说"做不了"，用这个三段式：
"我理解客户需要灵活配置。但按现在的需求范围，这其实是一个规则引擎产品，不是一个配置项。我建议分两步走：
第一步（1 周）：先做 3 个预设模板（保守/标准/激进），客户从模板里选 + 微调 2~3 个数值。这一步的测试用例 ≤ 30 条，风险可控，2 周上线。
第二步（看数据）：上线后跟踪 4 周，统计客户实际修改了哪些字段、改了什么值。如果 80% 的客户都在同一个模板上微调 → 真配置化，第二步扩展字段即可；如果每个客户改出的方案结构完全不同 → 确认是产品化需求，再立项做规则引擎，预算按产品算。
这样第一步的投入是 1 周（而不是 2 周），且无论第二步做不做，第一步的价值已经交付了。"
为什么这比"做小一点"更有效：你给业务方的不是"缩减"，而是"用最小成本验证假设"。业务方最怕的是"花了 2 周做出来客户不用"，你给的是"花 1 周先试，数据说话"。
四、可直接贴进 PRD 模板的 7 条 Checkbox
□ 配置项清单已列出（字段名 / 类型 / 取值范围 / 权限），共 ___ 个
□ 配置项之间无联动/嵌套/优先级（如有，请列出并说明组合数 ≤ ___）
□ 3 个目标客户的配置方案结构一致（字段集合相同，仅值不同）
□ 新增 1 个配置项的研发成本 ≤ 0.5 人天，测试成本 ≤ 0.25 人天
□ 测试用例数可枚举：___ 个配置项 × 5 场景 = ___ 条（≤ 50 条）
□ 配置项的变更不需要发版（运行时生效 / 热加载）
□ 回滚方案：配置项可一键恢复默认值，无需研发介入
任何一条打 ✗ → 这不是配置化，是产品化。 别硬塞进"配置化"的预算里，否则测试用例会指数膨胀，研发 2 周变 4 周，业务方说"怎么又延期了"。
五、真实案例（我踩过的坑）
去年我们做"审批流配置"，业务方说"就 3 个字段：审批人、审批层级、超时时间"。我按上面的清单一问：
- 第 ② 题：业务方说"如果层级 ≥ 3，超时时间要自动 ×2"→ 有联动 ✗
- 第 ③ 题：客户 A 要 3 级审批 + 会签，客户 B 要 2 级审批 + 条件分支（金额 > 10 万加一级），客户 C 要"动态审批人"（按部门自动路由）→ 结构不一致 ✗
3 条 ✗，直接判定为产品化。降级方案：先做"3 级固定审批 + 可配超时"（5 个配置项，25 条用例，1 周上线），动态路由和条件分支放二期。业务方接受了，因为"客户最急的是超时告警，不是动态路由"。
总结一句话：配置化 = 换值不换结构；产品化 = 换结构。判据就是测试用例能不能用"字段 × 取值"线性覆盖。