PRD 评审别再各说各话：一份从 12 个金融项目里长出来的对齐清单
2019 年冬天的投产前夜，我被业务方拦在会议室里翻规则卡，第 17 张卡上发现字段解释已经和上次评审会说的不一样。那次投产延期 3 周。从那之后我把 PRD 评审当项目来管，做了 12 年 PM，整理出这份从 12 个金融项目里长出来的对齐清单：术语对齐表、规则分级、决策权分清、结论分两栏、纪要 24 小时出。
PRD 评审别再各说各话：一份从 12 个金融项目里长出来的对齐清单
投产前夜那 17 个冲突
2019 年冬天，我带的第一个核心系统改造项目要投产。
PRD 已经开了 4 次评审，业务、研发、测试都签了字。投产前两天的回归测试，业务方的资深运营陈老师把我拦在会议室里，一张一张翻规则卡，翻到第 17 张的时候她停了下来。
"这个字段的解释，和上周评审会上说的不一样。"
我拿过来一对，确实不一样。我当时心里咯噔一下。翻回去再查，最早一版 PRD 写的字段口径，到第三版评审的时候被改了一行，研发没注意，运营也没注意。但业务方的对外说明已经按第三版的口径发给了 50 多家分行。
那天的投产延期了 3 周。延期本身不复杂，复杂的是怎么把改了 3 版、开了 4 次评审、签了 4 次字的 PRD 里，漏掉的那一行捞出来。
后来我把这个案例在团队里讲过好多次。不是讲我怎么延期，是讲一个更让我后怕的事：当时的会议纪要我自己都翻不出来，因为评审开完没人出纪要。
这件事之后，我开始把 PRD 评审当项目来管。这套做法陪着我和团队走过了后面 11 个项目，从核心系统到外围系统，从监管报送项目到内部数据治理项目。下面这套清单就是从这些项目里长出来的。
金融项目的 PRD 评审为什么特别难
金融项目的 PRD 评审，参会的人比互联网项目多一层。
常规三方是产品、研发、测试。金融项目里业务方的角色拆得更细，至少有业务经办、业务复核、合规审查这三层，有时候还要拉上运营和分行的人。每多一层，对齐的难度不是加法，是几何级数。
业务规则和合规规则的耦合也是。互联网产品改一个字段，影响的是用户体验。金融产品改一个字段，影响的是对外报送口径、对账逻辑、监管报表。一条改动从 PRD 走到上线，背后可能挂着 6 张表和 2 份监管文件。
第三个特点是投产窗口很贵。互联网产品可以灰度，金融产品不能随便灰度，要灰度就得在小范围试点，对监管报送口径的影响还得提前演练。很多项目一年只有 3 到 4 个窗口能用，错过了就要等下个季度。
这三个特点叠在一起，PRD 评审一旦漏掉一个点，后面的返工成本比别的项目高一两个量级。
三方各说各话的三个根因
我后来把几次翻车的情况拆开看，发现 PRD 评审各说各话的根因基本就三类。
第一类是术语不一致。业务说"金额"，研发理解的可能是账户余额，测试理解的可能是交易金额。同一份 PRD 里，"金额"出现过 30 多次，每次指向的字段不一样。这种不一致不是 PRD 没写清楚，是业务和技术的视角不一样，不主动对齐就一定会漏。
第二类是优先级标准不统一。业务方觉得重要的，研发排不上；研发觉得重要的，业务方觉得不影响核心。会议上吵的是谁的需求更重要，背后其实是优先级标准没对齐。常见的现象是会上"达成共识"，会后才发现各方对"重要"的定义差了一个维度。
第三类是决策权没分清。一个字段的取值范围，业务说可以放宽，研发说不能动，合规说必须按监管文件来。这时候谁能拍板？很多人以为是我这个 PM，其实不是。PM 能做的是把分歧摆到桌面上，让有决策权的人拍板。如果决策权没在评审前分清，评审就是讨论会，不是决策会。
五条对齐规则
针对这三个根因，我后来固定下来五条规则。每条都是从具体翻车里长出来的。
规则一：评审前先发术语对齐表
评审会议开始前 24 小时，先发一份术语对齐表。表格里每个术语的"业务口径"和"技术口径"分开写。
业务口径写业务方的标准说法，技术口径写对应到数据库里的字段名和取值范围。两边对不上的，评审时单独讨论；对得上的，评审时不用再解释。
这条规则的好处是会上不用再花时间对齐"我们说的是同一件事吗"。会前的术语表把这件事做完了，评审会上直接讨论"业务口径对不对"。
我从第二个项目开始用这个方法，到现在已经积累了 200 多张财务表格。每张表背后都是一个具体业务到某个具体字段的对齐记录。
术语对齐表还有一个隐性收益，是把"业务术语"和"技术术语"的翻译权归到了 PM 端。研发不再替业务方翻译字段名，业务方也不再替研发解释业务流程。翻译集中化以后，新人入职靠这一张表能快速摸清领域全貌，比读 5 份 PRD 文档管用得多。
规则二：规则分级而不是规则平铺
PRD 里的规则不要平铺成一条一条的列表，要分级。一级规则是必须遵守的，改动要重新评审。二级规则是参考的，改动可以快速决定。三级规则是历史遗留，可以接受不一致。
分级的依据也提前定好。一级规则通常是合规要求、监管报送口径、对外协议承诺。二级通常是业务运营规则、跨业务算法策略。三级一般是边缘场景、异常分支。
我吃过亏的项目是反过来做的：把所有规则列在一起，按出现顺序讨论。结果一条边缘场景的规则被业务方挡住了，挡住了整整两天的会议，最后发现这是个三级规则，本可以快速过。
规则三：决策权在评审前分清
评审会开始前，让三方各自明确谁有决策权。
业务方的决策权按业务条线分，对公、对私、零售的决策人不一样。合规的决策权通常集中在一个部门，研发决策权按模块分。每个议题，主持人要在会议开始时明确"这个议题的决策人是 XX"。
如果决策权没分清，PM 会被迫变成决策者。PM 一旦替决策人拍板，后面出问题没人接得住。
我在第 4 个项目里犯过这个错。我替业务方拍了一个关于我所属组算法的决定，结果上线后业务方不认账。最后我背了锅，研发觉得委屈，下个版本大家配合就出问题了。
规则四：评审结论分两栏
评审结论不要写"通过"或者"达成共识"。要分两栏：确认栏和待澄清栏。
确认栏里写"已确认"的决定，附上决策人和决策时间。待澄清栏里写"待澄清"的事项清单，每条带负责人和澄清时限。
两栏的好处是会后跟踪有抓手。待澄清栏的事不在下次评审前清掉，就不算这个评审闭环。
我以前的做法是写"达成共识"，会后两小时业务方打电话来问"我们真的确认了吗"。分两栏之后，这种电话几乎没有了。
待澄清栏我后来又加了一个细节：每条待澄清都要写"为什么会变成待澄清"。这个看起来啰嗦，但其实很关键。下次会议一上来，先过上次待澄清的原因，避免变成"待澄清升级"。一个项目跑下来，待澄清栏里会积累十几条，每条背后都有具体的故事，团队复盘时翻这一栏比翻会议纪要管用。
规则五：会议纪要 24 小时内出
评审会议结束后 24 小时内，会议纪要必须发出来，并且按上面那个两栏原则写。
纪要电子版是高优先级事项，不是"有空再写"。我后来让团队把这条写进评审的 SOP，纪要不发，下次评审不开。
写纪要有个细节，要写"谁说了什么"，不要写"会议决定什么"。写"会议决定"听起来权威，但会后容易扯皮；写"谁说了什么"是事实记录，扯皮起来有依据。
一份能用的评审清单生成器
上面的五条里，前两条和第四条是可以用工具落地的。下面是一份我用的评审清单生成器，从 PRD 文档里提取评审项，按上面的规则分级。
# prd_review_checklist.py
"""
从 PRD 文档里抽出评审项，按业务 / 合规 / 技术三类打标，按一二三级规则分级。
"""
import re
from dataclasses import dataclass, field
from datetime import datetime, timezone
@dataclass
class ReviewItem:
rule_id: str # R-001
title: str # 标题
description: str # 一句话说明
category: str = "" # business / compliance / tech
level: int = 0 # 1 必须 2 参考 3 遗留
decision: str = "" # confirmed / pending
decider: str = ""
due_at: str = ""
notes: str = ""
KEYWORDS = {
"compliance": ["合规", "监管", "报送", "人行", "银保监", "等保", "反洗钱"],
"tech": ["接口", "字段", "数据库", "缓存", "异步", "幂等", "超时"],
"business": ["业务", "运营", "客户", "账户", "交易", "额度", "利率"],
}
LEVEL_RULES = [
(1, ["监管", "报送", "合规", "对外", "协议", "承诺"]),
(2, ["运营", "算法", "策略", "流程", "规则"]),
(3, ["边缘", "异常", "历史", "遗留", "极少"]),
]
def detect_category(text: str) -> str:
hits = {k: sum(text.count(w) for w in ws) for k, ws in KEYWORDS.items()}
if not any(hits.values()):
return "business"
return max(hits, key=hits.get)
def detect_level(text: str) -> int:
for lv, words in LEVEL_RULES:
if any(w in text for w in words):
return lv
return 2
def parse_prd(path: str) -> list[ReviewItem]:
items: list[ReviewItem] = []
pat = re.compile(r"^(?:### |## )(?:规则|规则描述|业务规则)[：:]\s*(.+)")
counter = 1
for line in open(path, encoding="utf-8"):
m = pat.match(line.strip())
if not m:
continue
title = m.group(1).strip()
cat = detect_category(title)
lv = detect_level(title)
items.append(ReviewItem(
rule_id=f"R-{counter:03d}",
title=title,
description="",
category=cat,
level=lv,
))
counter += 1
return items
def to_markdown(items: list[ReviewItem]) -> str:
out = ["# PRD 评审清单", ""]
out.append(f"生成于 {datetime.now(timezone.utc).isoformat()}")
out.append("")
out.append("## 待澄清")
out.append("")
for it in items:
if it.decision == "confirmed":
continue
tag = {1: "🔴", 2: "🟡", 3: "🟢"}.get(it.level, "⚪")
out.append(f"- {tag} [{it.rule_id}] {it.title} ({it.category}, L{it.level})")
out.append("")
out.append("## 已确认")
out.append("")
for it in items:
if it.decision != "confirmed":
continue
out.append(f"- ✅ [{it.rule_id}] {it.title} | 决策: {it.decider} | 时间: {it.due_at}")
return "\n".join(out)
if __name__ == "__main__":
import sys
items = parse_prd(sys.argv[1] if len(sys.argv) > 1 else "PRD.md")
print(to_markdown(items))代码不长，三件事：从 PRD 里抽出规则、按关键词打类别、按关键词定级别，最后输出一个分两栏的 Markdown 清单。
抽规则这一步是简化过的，真实场景里我会用一个 NLP 模型来识别"规则"句子，但关键词方案在我用过的项目里已经够 90% 的场景。
emoji 那几行是给清单的可视化用的。一级规则的红圆点、三级规则的绿点，会上扫一眼就能看出来。
边界：这套不灵的时候
这套做法不是万能的，下面三种情况开评审会时要换打法。
第一种是业务紧急、不能走完整流程的时候。监管发文要求一周内改完，这种项目走不了完整评审，只能开业务讨论会 + 技术快速评审 + 合规并行审查。这种情况我通常会把"会议纪要 24 小时出"改成"会议纪要 2 小时出"，把"评审清单生成器"改成手写清单。但其他几条还是要遵守的。
第二种是跨部门利益冲突大的时候。比如业务部门之间对某个字段的归属有分歧，技术评审会上根本拍不下来。这种情况下评审会要降到"摆事实"会议，把分歧和事实摆清楚，决策权交给更高一级的委员会。PM 在这种项目里的角色是协调，不是主导。
第三种是新合规要求上线的时候。新合规要求通常带监管文件原文，规则很明确，但业务理解会有偏差。这种项目我会让合规审查人在评审会上先讲一遍监管原文，业务和技术再问。不要让业务和技术自己读监管文件自己解读，解读错了不认账。
三种情况之外，剩下 90% 的金融项目，套这套清单都跑得起来。
现在 PRD 评审会上都在问什么
我后来观察到一个有意思的现象。
用了这套清单之后，PRD 评审会上问的问题变了。会前是"这个字段什么意思"、"这条规则谁拍板"、"这个边界谁来确认"。会后问的是"这个字段的解释和上次评审一致吗"、"这条规则的优先级按哪一档算"、"这个分歧的决策人确定了吗"。
问的问题变具体了，会的效率就上来了。我管过的第 11 个项目，PRD 评审 2 个小时开完，会后出纪要 4 个小时，对齐的事情比前 5 个项目加起来还多。
这套清单看起来不复杂，跑起来需要纪律。纪律比清单重要。
我后来把团队培训分成两步。第一步是讲这套清单，让所有人知道为什么这么做。第二步是陪他们开一次会的，当场复盘哪里没按清单做。第三步之后，团队自己就能跑了。
我写这篇文章不是为了讲一套新方法，是为了把我在金融项目里踩过的 12 个项目的坑整理出来。里面大部分坑，业务方、研发、测试都各自有自己的一套应对办法，但 PM 端没有把这些整合起来。
我做了 12 年 PM，这套做法陪我走过了 12 个项目。下一篇文章会讲金融项目投产窗口管理，那是另外一套清单。