需求|需求评审几个最常见的坑( 二 ) 交易法|指控|联邦贸易委员会

但这些貌似省掉的工作，不仅可能会让你在评审会时招架不住，也会在后续的开发过程中反复折磨你。
所以，敏捷的是思想、是形式，但核心的工作内容一定不可少，要学会灵活变通。
一般这种情况下，我都推荐产品一定要写一个敏捷版的需求说明文档，不必在意形式是否合规，核心就是把主要的产品功能所涉及到字段规则、业务规则等表达清楚。
要牢记，只有把这个敏捷的需求文档写出来之后，再启动召开评审会才能成功，否则，一定会得不偿失的。
三、原型设计没有彩排事实上，需求评审前产品同学都需要彩排演练一遍，将准备的产品工作成果都提前准备好，会议室、会议通知等等，都需要提前安排妥当。
但还是特别想强调下，产品同学在原型设计上的彩排缺失所带来的被动不利局面，因为，这个坑出现的频率很高，这背后的原因，一是没有准备意识，二是缺乏科学方法。
所谓原型设计彩排，是自己要实地演示，最好去会议室实地操作一遍，因为有时候环境影响你的发挥，一般来说，在工位心里默念不如去会议室效果好。
其次，原型演示时，要掌握技巧：

可以先整体快速浏览下原型页面，让大家对本次产品开发工作有个感性认知。
按照业务流程，逐一演示产品功能，要有章法，不要想到哪儿就说到哪儿。
页面演示时，页面元素要讲解到位，尤其是像 “数据来源”、“数据状态值”、“数据记录”、“计算规则”等等，这些是开发必问的内容，自己必须要搞得很清楚，可以在原型上加上注释。
原型设计演示时，存在有争议时，要学会搁置争议，不要抓着不放，可以先记录，回头再解决。
针对存在的问题，不要避讳，要讨论充分。

这些技巧能有效帮助我们开好评审会，缺失则会往往带来失误，影响需求评审的效率和产品经理的形象。
比如，上次我们评审时，一个产品同学对于列表数据的数据来源、数据状态没有完全搞清楚，对于数据什么时候展示，什么时候消失等理解不够透彻，结果可想而知，自然不够理想。
事后产品复盘，发现他原型设计并没有提前演练，只是简单翻看一下，所以也就漏掉了这个页面的把控。
总之，原型设计一定要提前演练，提前按照方法去演练，且演练要高效、到位。
事实上，需求评审时有很多坑，也有很多避坑指南，但归根结底来说，凡是都有因果，需求评审会存在失误的背后一定是有其失误原因的。
对于我们来说，重要的事，不是完全避免问题，而是找到问题的原因并解决掉，并且不断反复练习、总结复盘。
唯有此才能从根本上避免失败，才能开成功每一场需求评审会。
因为，古人说过：
扬汤止沸，莫如釜底抽薪。
#专栏作家#产品大峡谷，公众号：产品大峡谷，人人都是产品经理专栏作家。七年B端产品经理，供应链物流与金融领域，擅长需求设计、业务指导、商业观察等。
本文由@产品大峡谷原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于CC0协议