需求评审会上频频被技术团队问住的尴尬，往往是产品经理准备不足的体现。本文深度剖析技术团队追问背后的五大核心逻辑——边界问题、性能问题、逻辑问题、数据问题与安全问题，并给出评审前必须完成的四项关键准备，助你将被动应答转为主动掌控，打造高效的评审体验。
为什么你每次需求评审都在被技术吊打
你有没有这种感觉：明明觉得自己准备好了，评审时却被技术连环追问，答不上来就开始心虚？
别急着怪技术太刁钻。换个角度想，他们追问的每一个问题，其实都是在帮你发现需求里的漏洞——只是这个发现的过程，有点让人下不来台。
需求评审被追问，本质上是你没把功夫下在评审之前。
很多新人觉得技术追问是在”找茬”，其实不是。他们问的每一个问题，背后都有合理的技术逻辑。
技术问你”用户不登录怎么办””数据为空怎么展示”，不是在为难你。他们见过太多线上事故，都是因为没考虑边界条件。
举个小例子：用户查询订单列表，结果历史订单被删了，页面是显示空白、显示占位符，还是提示”暂无数据”？这种细节如果没写进文档，开发只能猜，猜错了就得返工。
所以评审前，你得把异常场景过一遍：网络中断、数据为空、权限不足、接口超时……每个分支都要有明确处理方案。
技术问你”并发峰值预估多少””能接受多少延迟”，是因为他们要评估这个功能会不会拖垮服务器。
比如你说”实时展示用户在线状态”，技术就会想：实时是多实时？1秒刷新一次还是5秒？如果同时在线10万人，每秒就要处理10万次请求。这个成本谁来承担？
评审前你要心里有数：这个功能的用户规模大概是多少、响应时间要求是什么级别、需不需要做缓存或预加载。给不出具体数字没关系，但要有量级概念。
技术追问排序规则、规则冲突、状态转换，其实是在帮你检查需求完备性。
比如做一个订单状态功能，你写了”已支付→已发货→已完成”三个状态，但有没有想过：用户申请退款是什么状态？退款失败又是什么状态？这些逆向流程如果没想清楚，开发时就会不断加补丁。
画流程图的时候，不仅画主流程，每个分支路径都要画出来。你会发现需求文档里可能少了一半的逻辑。
技术问你数据从哪来、数据质量能不能保证，是因为他们怕功能开发完了，发现数据根本不可用。
举个例子，你想做一个”用户活跃度”的功能，但”活跃”的定义是什么？登录算活跃还是操作算活跃？如果历史数据缺失，图表一上线就是空的，谁都尴尬。
评审前，把每个关键指标的定义写清楚：统计口径是什么、计算公式是什么、数据从哪个系统来、准确性谁来保障。
技术问接口要不要鉴权、会不会被刷，其实是在替你兜底。产品经理关注的往往是功能能不能用，不太关注会不会被滥用。
比如做一个”用户签到领积分”功能，如果没有防刷机制，可能一夜之间被人写个脚本刷光积分。这种漏洞一旦被发现，产品和开发都得背锅。
涉及用户激励、优惠券、抽奖的功能，上线前一定要和技术确认防刷策略。
理解了技术为什么问，接下来就是准备方向。
技术不是不想做你的需求，他们想知道的是”值不值得做”。评审前你要回答：
这个功能解决什么问题？有没有数据支撑（比如用户调研、埋点数据、竞品分析）？如果不做会有什么代价？做了之后怎么衡量效果？
这些不需要写得多复杂，但心里要有底。哪怕只是“参考了XX竞品，用户反馈这个功能使用率很高”这样的定性判断，也比什么都没有强。
拿着你的流程图，从用户视角完整走一遍：从哪进、做什么操作、每个节点显示什么、最终输出什么结果。
然后问自己：用户取消怎么办？退款怎么办？超时怎么办？每个逆向流程都要有处理方案。
建议用思维导图把正常流程和异常流程分开画，正常流程一张图，异常流程一张图，评审前自己先检查有没有遗漏。
提前想好”最坏情况”：网络断了页面怎么显示？接口超时等多久？数据加载失败提示什么？并发量超过预期怎么处理？
不需要每种情况都给出完美方案，但至少要说明“当XX发生时，系统应该XX”。技术会根据你的意图来判断实现成本。
给技术一个参考范围：预计多少用户会用？峰值并发大概多少？页面加载能接受几秒延迟？
如果不确定，就明确说”这个数据我需要和运营确认”，然后在评审后补上。千万别随口说“应该没多少人用”——技术会按你说的做预估，说错了要担责任。
即使准备充分，评审中也可能遇到没预设到的问题。记住一个原则：先承认，再说计划，不要硬撑。
不要急着辩解，先听清楚技术质疑的点是什么。然后给出你的验证依据：竞品怎么做的、用户怎么反馈的、这个功能的核心目标是什么。
如果确实没做过验证，坦诚说”这块我考虑不够，后续会补充用户调研”，这比硬撑着说完要体面得多。
先完整听完。技术提出替代方案，往往是因为他们看到了你没考虑到的技术成本或风险。
听完之后，说出你原来方案的权衡点，再一起分析哪个更合理。评审的目标不是证明你对了，而是找到最优解。
最忌讳说”这种情况不可能发生”。概率再低，也不排除发生的可能，这句话只会让技术觉得你不靠谱。
正确的做法是：承认这个点没想过，先记录下来，和技术一起判断这个问题的严重程度。低频场景可以会后补充，高风险问题当场讨论。
追问具体原因：是技术实现不了，还是成本太高，还是时间不够？不同原因对应不同的解决思路。
如果确实是复杂度太高，评估能不能缩小范围先上线一个简化版本。技术说“做不了”往往不是拒绝，而是在告诉你需要调整预期。
直接说”这个问题我需要回去确认”。记下来，承诺会后给出书面答复，然后结束这个话题继续往下走。
切记不要现场编答案，编出来的方案大概率是坑。
评审会的本质不是”说服技术接受你的方案”，而是”和技术一起把需求想清楚”。
被追问不可怕，可怕的是不知道为什么被追问。每次评审后复盘一下：技术问的问题，我评审前有没有想过？如果没有，下次就补上这一项。
把功夫下在评审前，评审自然顺畅。
本文由 @徐大大的产品日记 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。