需求文档写完了,研发说＂做不了＂怎么办?

你花了两周写PRD，改了六版，每一个字都抠过。
评审会上，你信心满满地讲完需求。研发Leader翻了三页，抬头说：
“这个做不了。”
你心里咯噔一下。
“为什么做不了？”
“底层架构不支持，改动成本太大。”
你追问：”多大成本？”
“至少多两周。”
会议室安静了三秒。领导看看你，又看看研发，说了句：”再对齐一下。”
散会。
你回到工位，盯着PRD发呆。两周的心血，三分钟被毙。

这个场景，我经历过。不是一次，是几乎每个PM都经历过。

但后来我发现一件事：研发说”做不了”，绝大多数时候不是真的做不了，是你没搞清楚他说的”做不了”到底是哪种”做不了”。

今天这篇，我就把需求评审这件事掰开揉碎——上会前、会上、会后，每个阶段该干什么，怎么干，全部讲透。

先搞清楚：”做不了”有五种

在讲具体操作之前，先给你一个框架。

研发说”做不了”，你第一反应不应该是”怎么办”，而是先判断——他说的”做不了”是哪一种：

第一种：技术上做不了。

真正的技术不可行。比如你要在3秒内处理10亿条数据，或者你要在不root的情况下读取其他App的数据。这种确实做不了，或者做出来的成本不值得。

但说实话，这种情况在B端产品里是少数。根据我的经验，大部分你以为的”技术不可行”，其实是”技术成本高”。

第二种：排期上做不了。

技术上完全可行，但在当前迭代周期内做不完。研发说”做不了”，其实是说”做不了这么快”。

这种情况最常见。你需要做的不是争论可行性，而是拆需求、降范围、调优先级。

第三种：架构上做不了。

技术可行，排期也够，但跟现有系统架构冲突。比如你的需求要改底层数据结构，或者要推翻已有的权限模型。

这种”做不了”最棘手，因为它牵一发而动全身。你需要拉上架构师单独评估，不能在评审会上临时拍。

第四种：资源上做不了。

技术可行，排期也够，架构也不冲突——但人不够。负责这个模块的开发在忙另一个项目，或者关键人员休假，或者团队同时扛了太多并行需求。

这种情况跟”排期做不了”有交集，但本质不同：排期是时间维度，资源是人/设备维度。经常出现”时间够但人不够”的尴尬。应对策略也不同——借人、调并行项目优先级、拆给两个人做，而不是单纯砍范围。

第五种：不想做。

技术可行，排期够，架构也不冲突，资源也没问题，但研发觉得这个需求没价值，或者觉得你的方案不够优雅，或者纯粹是情绪上不想接。

这种情况最难处理，因为你不能直接说”你就是不想做”。你需要用数据和业务价值来说服，或者找到双方都能接受的替代方案。

记住这五种分类。 会上研发说”做不了”的时候，你脑子里先过一遍：是哪种？不同种类，应对策略完全不同。

下面进入正题。

上会前：90%的评审失败，都败在会前

我见过太多PM，PRD写完直接发会议邀请，拉一屋子人评审。结果会上被问得哑口无言，场面一度非常尴尬。

需求评审不是考试，不应该在会上才有”第一次接触”。好的评审，会上只是走个流程——真正的功课在会前做完了。

上会前要做五件事：

1. 预沟通：别让会上出现”惊喜”

这是最重要的一件事，没有之一。

PRD写完，先别发评审邀请。先拿着PRD，找关键人一对一聊。

找谁聊？三类人：

第一，找模块开发负责人聊。

注意，不是找技术Leader——技术Leader通常很忙，不一定有时间提前看你的PRD。更实际的做法是先找负责该模块的开发聊，把PRD给他看，问他：”这个方案技术上有没有什么风险？”

模块开发比技术Leader更了解代码细节，能帮你识别具体的技术依赖和底层限制。如果他说”这个可能要改底层架构”，你再拿着这个结论去找技术Leader确认，Leader一看你带着具体问题来的，30分钟就能给方向。

我现在的习惯是：评审前48小时，必找模块开发预沟通一次。 30分钟够了，但这30分钟能帮你省掉2小时的无效评审。

第二，找业务方聊。

确认需求优先级和业务目标。评审会上研发一定会问”这个需求急不急””能不能下期做”，你手上要有业务方给的明确优先级，不能现场拍脑袋。

第三，找设计聊。

如果需求涉及UI改动，提前跟设计师对一下交互方案。别在评审会上让研发评估一个还没设计的页面的工作量。

预沟通完，还有一步：根据反馈调整PRD。 预沟通和正式发材料之间通常隔一天，这一天就是留给你改PRD的——把预沟通发现的问题在文档里修掉，或者准备好替代方案。别预沟通完原封不动就发材料，那预沟通就白做了。

2. 发材料：给研发留出消化时间

预沟通完，方案调整好了，再发正式评审邀请。

材料至少提前24小时发出。 别上午发邀请下午就评审，研发连PRD都没看完，来了也是走过场。

发材料的时候，建议附一段话说明：

这次的PRD主要涉及XX模块的XX功能。核心变更点有三个：1、2、3。请重点关注第X节的XX部分，可能有技术实现上的讨论。会上预计1小时。

这段话的作用是引导研发的关注点。你告诉他重点看哪，他就有准备；你不引导，他可能只看了前三页就来开会了。

另外说一句：不是所有需求都需要开会。 简单的需求变更、小功能追加，完全可以走异步评审——把PRD发到群里，@相关人评论，给24小时反馈窗口，没人提异议就算通过。只有涉及多模块联动、架构变更、或者有争议的需求，才值得拉正式评审会。别什么都开会，研发最怕的就是”为一个小需求拉一屋子人”。

3. 自查：拿着清单过一遍

发材料之前，先自己做一轮PRD自查。我有一个评审前自查清单，每次评审前都过一遍：

内容自查（6问）：

1. 1. 需求背景写了吗？ 不写背景的研发不知道你为什么要做这个，他会质疑需求的必要性。
2. 2. 用户故事写了吗？ “作为XX角色，我希望XX，以便XX”。没有用户故事的需求就是功能堆砌。
3. 3. 非目标写了吗？ 明确”这个功能不做什么”，防止研发过度设计，也防止评审时scope蔓延。举个例子：你做一个审批流功能，非目标可以写”本期不做移动端适配””不做批量审批””不做审批数据看板”——把不做的事写清楚，比把做的事写清楚更重要。
4. 4. 流程图 / 状态机画了吗？ 涉及流程的必须有图，光靠文字描述研发理解不了全貌。
5. 5. 异常分支考虑了吗？ 上篇文章讲的5种业务异常 + 5种系统异常，检查一遍。
6. 6. 验收标准写了吗？ 每个功能点都要有验收标准，否则测试不知道怎么写用例，研发不知道做到什么程度算完成。

格式自查（4问）：

1. 7. 版本号和修改记录有吗？ PRD改了几版、每版改了什么，要有记录。
2. 8. 待确认项标注了吗？ 没想清楚的地方标注”待确认”，别藏着掖着。
3. 9. 名词解释有吗？ 业务术语、缩写要解释，别默认所有人都懂。
4. 10. 页码和目录有吗？ 评审时方便定位，”大家翻到第12页”比”大家往下翻翻”高效得多。

十个问题都答”有”，再发材料。

4. 准备”防御工事”：提前想好会被问什么

每个PRD都有”软肋”——那些你也没完全想清楚、或者技术上可能有争议的地方。

评审前，自己先做一遍红队测试：假装你是研发，找自己PRD的漏洞。

常见会被挑战的点：

• • “这个需求的数据来源是什么？”——你要准备好数据支撑
• • “竞品是怎么做的？”——你要准备好竞品对比
• • “这个方案有没有更简单的实现？”——你要准备好Plan B
• • “这个功能的使用频率是多少？”——你要准备好频率预估
• • “如果不做这个功能会怎样？”——你要准备好不做的影响分析

把这些问题的答案写在PRD的备注里，或者单独准备一个”QA预案”。会上被问到的时候，你能从容回答，而不是现场抓瞎。

5. 确认参会人：区分”必须到”和”可同步”

评审会的人不是越多越好。人太多，七嘴八舌，效率低；人太少，缺关键决策者，评了也白评。

标准参会人清单：

一个原则：必须到的人，能做决策、能评估工作量、能把关验收标准。 可选到的人——比如运营需要了解功能变化、客服需要提前准备培训材料——发个会议纪要就行，不用拉进来浪费时间。关键是区分”必须参会”和”会后同步”，而不是一刀切地砍人。

会上：这不是考试，是协作

很多PM一到评审会就紧张，觉得自己像在答辩。研发坐在对面，像评委一样挑毛病。

这个心态要改。

评审会不是答辩，是协作。你和研发是同一战壕的，目标都是把需求做成、做好。你紧张是因为你把它当成了”被审判”，但其实它应该是”共同设计”。

心态对了，会上的一切操作都会自然很多。

1. 开场：3分钟定基调

别上来就讲功能细节。用3分钟把三件事说清楚：

第一，为什么要做这个需求。

一句话讲清业务背景和目标。比如：”这个功能是为了解决客服每天有200条工单无法自动分配的问题，预计能减少客服30%的手动操作。”

这句话的作用是让所有人先对齐”为什么”，再讨论”做什么”。没有”为什么”的”做什么”，研发没有动力。

第二，今天评审的范围是什么。

明确边界：”今天主要评审核心审批流和权限设计，报表模块下一期再做，不在今天范围内。”

这能防止会上scope蔓延——有人说”顺便把报表也讨论了吧”，你就可以指着自己说的范围挡回去。

第三，今天的预期产出是什么。

“今天的产出是：确认核心方案可行性、识别技术风险点、明确待确认项的负责人和deadline。”

让所有人知道这个会开完应该得到什么，避免开完会觉得”好像说了很多但又什么都没定”。

2. 讲需求：先讲Why，再讲What，最后讲How

很多PM一上来就讲功能怎么实现——页面长什么样、按钮在哪、点击后跳哪。

研发不关心这些。至少不首先关心。

研发首先关心的是：你为什么要做这个？这个需求的业务价值是什么？不做会怎样？

讲需求的顺序应该是：

Why（5分钟）：业务背景、用户痛点、数据支撑。让研发理解这个需求存在的理由。

What（15分钟）：核心功能、用户故事、流程图。让研发理解需求的内容和边界。

How（10分钟）：交互方案、数据流转、接口要点。让研发理解技术实现的方向。

三段加起来30分钟。剩下30分钟用来讨论、决策、处理异议。评审会不是宣讲会，讲完不是目的，讨论出结论才是。 留够讨论时间，别把1小时全用来讲。

一个关键技巧：讲What的时候，跟着流程图走。 不要按PRD的章节顺序讲（背景→功能1→功能2→功能3），而要按用户操作路径讲（用户提交→经理审批→财务审核→归档）。跟着流程走，研发能在脑子里建立完整的业务画面。

3. 面对”做不了”：三问拆解法

这是全文最核心的部分。

会上研发说”做不了”的时候，你的第一反应不应该是慌，也不是反驳，而是问三个问题：

第一问：”你说的做不了，主要是哪方面的问题？”

这句话的目的是让研发自己归类。注意，不要替他框定选项——比如别问”是技术上还是排期上”，因为你替他二选一，可能漏掉架构、资源、意愿的问题。问得开放一点，让他自己说出来。如果他只给了模糊回答，你再追问：”是技术上有困难，还是排期排不开，还是架构上有冲突？”

如果研发说是排期问题，那好办——拆需求、降范围。如果说是技术或架构问题，进入第二问。

第二问：”具体是哪个技术点卡住了？”

这句话的目的是定位。不要接受”整体做不了”这种模糊回答，要让他指到具体的点。

“是数据结构改不了？还是接口不支持？还是权限模型冲突？”

定位到具体点之后，你才能判断是真做不了，还是只是成本高。

第三问：”如果一定要做，最小可行方案是什么？”

这句话的目的是转化。把”做不了”转化为”怎么做最省”。

这一招非常有效。因为你把问题从”做不做”变成了”怎么做”，研发会从”拒绝模式”切换到”解题模式”。

举个例子：

研发：”这个实时同步做不了。”

你：”主要是哪方面的问题？”

研发：”技术能做，但要做实时同步得改消息队列架构，至少多两周。”

你：”如果一定要做同步，最小可行方案是什么？不一定要实时。”

研发：”那可以做成准实时，每5分钟同步一次，不用改架构，两天能做完。”

你：”可以，先上准实时，后续再优化。”

你看，三轮对话，从”做不了”变成了”两天做完”。

但如果研发不配合呢？

现实中更常见的情况是，研发说”反正做不了”就不展开了，或者甩一句”这个说起来复杂”。这时候别追问”为什么”，改用选择题降低他的回答成本：

“那我理解你的意思是技术成本比较高。能大概估个量级吗——是加几天的工作量，还是加几周？”

给选项比给开放题容易回答。只要他报了个量级，你就能判断值不值得争取，还是直接砍范围。

三问拆解法的本质，是把”立场对抗”变成”问题拆解”。 研发说”做不了”是他的立场，你问”怎么做最省”就把对话拉回到问题本身。

4. 会上四种常见翻车场景及应对

除了”做不了”，评审会上还有几种高频翻车场景：

翻车一：研发当场推翻你的方案，提出完全不同的方案。

应对：不要当场battle。说”你的方案有道理，我们把两个方案都记录下来，会后分别评估一下技术成本和业务影响，再定”。评审会不是方案决赛，是方案海选。保留多个方案，会后评估比当场拍脑袋更靠谱。

翻车二：业务方临时加需求。

应对：立刻挡回去。”这个需求不在今天的评审范围内，我们记下来，下期评估。”如果你当场接了，研发会认为scope不可控，后面的评审他会更加保守。

翻车三：两个研发意见不一致，当场吵起来。

应对：立刻叫停。”两位的意见都有道理，我们先把核心方案定下来，这个技术细节会后你们对齐，结论同步给我。”评审会不是技术辩论赛，技术分歧应该在技术内部解决。

翻车四：领导突然插话，提出一个你没准备的方向。

应对：先判断是方向性问题还是细节补充。

如果领导说的是方向性问题——比如”审批流是不是可以试试会签模式”——这会影响整体方案设计，不能跳过。当场花2分钟讨论一下可行性，如果当场定不了，记为待评估项，明确负责人和deadline。

如果领导说的是细节补充——比如”报表里加个按部门统计的维度”——那就说”这个我们记下来，会后单独拉个会评估一下，不占用今天的评审时间”。给领导留面子，也保证评审节奏不被打断。

关键区别：方向性问题当场处理，细节问题会后跟进。 一刀切”会后聊”会让领导觉得被敷衍，一刀切”当场讨论”会让评审失控。

5. 实时记录：别依赖记忆

评审会上，一定要有人做记录。最好是你自己边讲边记，或者指定一个测试同学记录。

记录什么？四样东西：

• • 已确认的决策：方案A还是方案B，做还是不做，这期做还是下期做
• • 待确认项：谁负责、什么时候给结论
• • 技术风险点：哪些地方有技术风险，需要进一步评估
• • 范围变更：评审过程中增加、删除、修改了哪些需求

会上不记录，会后全凭记忆写纪要，一定会有遗漏和偏差。 研发不认账的时候，你没有记录就是哑巴吃黄连。

会上还有一种情况：评审被打回

上面讲的都是”评审基本通过，有些待确认项”的情况。但还有一种结局：评审直接被打回，方案需要重做。

这种情况不丢人。方案被打回，说明评审机制在起作用——总比带着问题方案上线、开发到一半才发现走不通要好。

打回之后怎么办？四步：

第一步，搞清楚打回的原因。 是技术方案完全不可行？还是业务逻辑有硬伤？还是范围太大需要拆分？不同原因，回去改的方向不同。

第二步，重新预沟通。 带着打回的原因，重新找模块开发和业务方聊。别一个人闷头改——你第一次没想清楚的东西，闷头改大概率还是想不清楚。

第三步，缩小范围再上会。 第二次评审不要把整个方案重新讲一遍。只讲改了什么、为什么这么改，聚焦打回的那个核心问题。范围越小，通过越快。

第四步，调整心态。 评审打回不是否定你这个人，是帮你把方案做得更好。研发愿意花时间指出问题，说明他在乎这个需求。最怕的不是被打回，是研发当场说”都行，你定吧”——那才是真的没人在乎。

会后：评审结束才是真正的开始

很多PM以为评审会开完就万事大吉了。其实不是。评审会只是达成共识，会后才是把共识落地成行动的过程。

会后要做四件事：

1. 发会议纪要：当天内，不等不拖

评审结束后当天内发会议纪要。别等第二天，别等”我整理一下”——隔了一夜你的记忆就开始模糊了。

如果评审讨论了十几个需求点，完整纪要当天整理不完，可以先发决策摘要——核心方案通过没通过、哪些待确认、谁负责——详细纪要第二天补。但决策摘要必须在当天发出，让所有人知道结论。

会议纪要模板：

【需求评审纪要】XX功能需求评审

会议时间：2026-XX-XX 14:00-15:30
参会人：张三（PM）、李四（技术Leader）、王五（前端）、赵六（后端）、孙七（测试）

一、评审结论
- 核心方案：通过
- XX模块方案：待技术评估后确认（负责人：李四，deadline：X月X日）
- XX功能：本期不做，移入下期
- 开发预计启动时间：X月X日（待确认项全部close后启动）
- 下次同步时间：X月X日（待确认项review）

二、已确认决策
1. 审批流采用方案A（逐级审批），不采用方案B（会签）
2. 超时策略：默认3天，可配置
3. 权限模型复用现有RBAC，不新建权限体系

三、待确认项
| 序号 | 问题 | 负责人 | Deadline | 是否阻塞开发 |
|------|------|--------|----------|-------------|
| 1 | 消息推送方案选型 | 李四 | X月X日 | 是 |
| 2 | 历史数据迁移策略 | 赵六 | X月X日 | 是 |
| 3 | 报表字段确认 | 张三 | X月X日 | 否 |

四、技术风险
1. 底层数据结构需新增字段，涉及历史数据兼容
2. 第三方接口调用频率可能超限，需评估限流方案

五、范围变更
- 新增：撤回功能（评审中确认必须做）
- 移除：批量导入功能（本期不做，下期评估）
- 修改：审批超时从5天改为3天

注意模板里多了两个关键节点：开发预计启动时间和下次同步时间。没有这两个节点，研发不知道什么时候可以动手，待确认项的deadline也失去了锚点。另外待确认项加了一列”是否阻塞开发”——阻塞项必须在开发启动前close，非阻塞项可以边开发边确认。

发完纪要，@所有参会人确认。有人对纪要有异议，24小时内提出，逾期视为认可。

这一步看着繁琐，但它是你后续追溯的依据。研发说”我没同意做撤回”，你掏出纪要：”会议纪要第二条，你确认过的。”

2. 更新PRD：把评审结论固化进去

评审完，PRD一定要更新。别让研发看的是第一版PRD，但实际做的是评审后的方案——那一定会出问题。

更新PRD的时候：

• • 修改记录要写清：第X版，修改了什么，为什么修改（评审结论 / 技术建议 / 业务方反馈）
• • 待确认项要标注：用醒目的颜色标注”待确认”，研发一看就知道这块还没定
• • 删除的内容怎么处理，取决于你用的工具：如果是离线文档（Word），建议用删除线标注，旁边写”评审决定移除，原因：XX”，这样以后翻回来能知道为什么当初没做；如果是在线协作文档（飞书、Confluence），版本历史会自动保存，直接删就行，在修改记录里注明删除原因即可，不用在正文留删除线把文档搞乱。

更新完的PRD，重新发给所有参会人。附一句话：”PRD已更新至V2.0，主要变更见修改记录，请查阅。”

3. 追踪待确认项：别让它石沉大海

评审纪要里的待确认项，是最容易掉链子的地方。会上说”会后确认”，会后没人跟，到了开发阶段才发现问题没解决。

建议建一个追踪表，阻塞项每天跟进，非阻塞项每周更新一次：

为什么阻塞项要每天跟？因为阻塞项卡住的是开发启动——开发等不了你一周。非阻塞项可以边开发边确认，每周跟进一次够用。

追踪待确认项是PM的责任，不是研发的责任。 你不追，没人会主动给你答案。

4. 做一次”评审复盘”：给自己成长

评审完，需求进入开发之后，花10分钟做一个简单的自我复盘：

• • 哪些问题是会前预沟通应该发现但没发现的？
• • 哪些问题是自查清单能覆盖但没覆盖的？
• • 会上哪个时刻处理得不好？下次怎么改进？
• • 研发对PRD的哪些部分理解有偏差？说明我的文档哪里写得不够清楚？

不用写长篇大论，几句话记在笔记本上就行。每次评审都复盘一次，三个月后你会发现评审通过率明显提升。

需求评审自查清单：上会前10问 + 会上5问 + 会后4问

把前面的内容浓缩成一张清单，评审前翻出来对照。标了「必查」的是底线，不检查一定出事；标了「选查」的是加分项，检查了评审更顺。

上会前（10问）：

1. 1. 「必查」模块开发预沟通了吗？（至少提前48小时）
2. 2. 「必查」业务方确认优先级了吗？
3. 3. 「必查」PRD提前24小时发出去了吗？
4. 4. 「必查」需求背景、用户故事、非目标都写了吗？
5. 5. 「必查」流程图 / 状态机画了吗？
6. 6. 「选查」异常分支和兜底方案考虑了吗？
7. 7. 「必查」验收标准写了吗？
8. 8. 「选查」版本号和修改记录有吗？
9. 9. 「选查」竞品对比和数据支撑准备好了吗？
10. 10. 「必查」参会人清单确认了吗？（区分”必须到”和”可同步”）

会上（5问）：

1. 1. 「必查」开场3分钟讲清Why、范围、预期产出了吗？
2. 2. 「必查」讲需求是按Why→What→How的顺序吗？留了讨论时间吗？
3. 3. 「必查」面对”做不了”用了三问拆解法吗？（归类→定位→转化）
4. 4. 「选查」临时加需求挡回去了吗？
5. 5. 「必查」决策、待确认项、风险、范围变更都实时记录了吗？

会后（4问）：

1. 1. 「必查」会议纪要当天发出了吗？（至少决策摘要当天发）
2. 2. 「必查」PRD更新到最新版并发给参会人了吗？
3. 3. 「必查」待确认项在追踪吗？（阻塞项每天跟，非阻塞项每周跟）
4. 4. 「选查」做自我复盘了吗？

19个问题，其中12个必查、7个选查。时间紧的时候，至少把12个必查过一遍。全部做到，评审翻车概率大幅下降。

最后几句

需求评审这事，看似是开会，其实是沟通管理。

你以为评审的失败是”研发不给面子”，其实评审的失败是”你没做好准备”。

研发说”做不了”不可怕，可怕的是你不知道他为什么做不了，更可怕的是你没有准备好应对方案。

记住三句话：

会前做足功课，会上就不会慌。 预沟通是评审成功的第一前提。

“做不了”不是终点，是谈判的起点。 三问拆解法，把对抗变协作。

评审会不是考试，是共同设计。 你和研发不是对手，是队友。

好的需求评审，开完之后研发觉得”这个需求我理解了，我知道怎么做了”，你觉得”研发帮我把方案补全了”。双方都有收获，这才是评审该有的样子。

写在最后：

这篇和上一篇《手把手教你画不被研发吐槽的业务流程图》是姐妹篇。那篇讲怎么把PRD里的流程图画好，这篇讲怎么把PRD评审做好。两篇加一起，解决的是”PRD从写完到开发”这段路上最容易翻车的问题。

你在需求评审时，遇到过最离谱的”做不了”是什么？欢迎评论区分享，我猜一定有人比你经历的更离谱。

下篇预告：《B端流程的系统异常处理——数据校验、网络重试、权限变更怎么办》——流程图文章里点到为止的5种系统异常，这次掰开揉碎讲透。

觉得这篇有用，转发给团队里那个总在评审会上被研发怼到说不出话的同事。拉他一把。