干货经验：产品需求的评审和讨论

《干货经验：产品需求的评审和讨论》由会员上传分享，免费在线阅读，更多相关内容在工程资料-天天文库。

1、干货经验：产品需求的评审和讨论话不多说，直接上干货。本文主要分为四部分：需求评审的标准需求评审面临的困难及小技巧需求评审的原则需求评审的具体步骤一、需求评审的标准1、需求评审要细到什么程度？严格地讲，需求评审应当检查需求文档中的每一个需求，每一行文字，每一张图表。2、评判需求优劣的主要指标正确性、清晰性、无二义性、一致性、必要性、完整性、可实现性、可验证性、可测性。如果有可能，最好可以制定评审的检查表。二、需求评审面临的困难及小技巧1、需求评审的一个通病是“虎头蛇尾”需求评审特别地乏味，在刚开始评审时，大家都比较认真，

2、进行的越往后越马虎。尤其是当需求文档很长时，几乎没人能够坚持到最后，别说你能，我不信！小技巧：事先强调重点模块；评审时间长时，建议隔时间段休息；如果系统大文档长时，可细分成不同的部分或模块分别进行讨论；严格控制每次评审的文档规模及评审时间。2、需求评审涉及的人员可能比较多将这么多人聚到一起开会是非常不容易的，例如某些人可能在出差，某些人可能在进行别的事物···小建议：不要把所有事情挤在一起做，需求评审可以分段进行，这样每次评审的时间及与会人员都会少一些；其次将《需求规格说明书》进行不同的标记，如草稿状态、评审状态、最终

3、状态等，要对需求的最终状态进行更加严格的评审。3、需求评审会议会经常跑题有时话匣子一打开后关不上，大家越扯越远，结果评审会议变成了聊天会议。小技巧：控制话题，避免讨论与主题无关的东西；不需要深入讨论具体的执行，适可而止；尽可能的阐述事实与证据，而并不是如何努力地说服别人。三、需求评审的原则1、不是谁要说服谁，而是就某个问题找出最佳解决方案很多时候产品经理都是抱着“我要说服研发”的态度，这就会导致需求评审变成了一场辩论赛，大家都疯狂的相互寻找极端的情况来支持自己的观点，试图让对方进行让步，然而这恰恰是最错误最可怕的情况。

4、2、先建立基本的共识，在基于共识进行细化不要盲目的、随心所欲的发言，首先要现金礼基本共识，通俗的说就是建立一个主调，把大家都拉倒同一个频道上来，不然就会导致大家在不同的频道上巴拉巴拉，互不相让，其实完全不是在说同一件事情，驴唇不对马嘴。3、先求同，后攻异在已经形成基本共识的基础上，若对其中的小问题存在分歧时，如果一时半会讨论不清楚，可以暂时记录下来，继续讨论其他的，最后在对有分歧的小问题进行讨论。但是当这个问题是产品主要功能或流程上的问题时，尽量不要跳过。四、需求评审的具体步骤1、明确目标与目的通俗的说就是先说清楚我们

5、要干什么。看过太多的产品经理在需求评审时，上来就打开原型，巴拉巴拉的讲功能，将流程，这是完全错误的，一定要先明确目标，并一定要在目标上完全达成一致。2、目标达成一致后，说说怎么做在讨论怎么做时，很多人就已经把话题带到了如果这么做，我们的架构有什么问题，有什么风险等细节上了，这很容易让大家陷入细节的争吵与辩论，越跑越偏。在讨论第一次的问题时，不要去想第二个层次的细节问题；在讨论细节问题时，不要再去质疑第一个层次的结论。通常在讨论总会这两种结果：大部分认同这个方案：我们通常是按照这个方案来执行，对于其中的一小部分不太认同的

6、部分，在进行讨论，看是否有更好的方案。不认同这个方案：首先再次确认，目标是否认同，如果目标都不认同，那这次评审也就操蛋了，这种情况一般不会出现；如果目标认同，那就是解决方案的问题了，可以坐下来研究，通常是：（1）这个方案可以做基本的修正吗？如果可以进行修正，那么探讨如何修正；如果不可以进行修正，那么重新寻找方案。（2）是否可以勉强执行？你是否有更好的方案？如果可以勉强执行，那就先按照这个方案干；如果有更好的方案，那就按照这个更好的方案干。（3）我没有好的方案，也不认同你的方案这种人完全不是做事情的态度，也不是团队合作的

7、状态，赶紧让他卷铺盖滚蛋···当然不排除有特殊情况，就是这个方案真的有很大的问题，完全不能用。3、方案达成一致了，开始做排期与风险及收益预估为什么做这个事情，都清楚了，也认同了；是不是可以这么干，也基本达成一致了；剩下的就是排期，安排人员，具体去执行了，这是一个新的话题，不展开了。总结一下：先说我们的目标与目的，在为什么要做这个事情上达成一致；再说我是这么想的，你觉得方案是否可行，我们一起看看有没有更好的方案，在怎么做上达成一致；按照我们讨论的这个做法，看看我们现有的人手，具体怎么一步一步执行。讨论问题与需求评审一样，

8、是一个解决问题的过程，解决问题的最合理方式就是不断拆解问题，拆解到不能再拆解了，然后分别地寻找解决方式。另外，相比情商，智商反而有时候显得不是最重要的。标签：产品需求经验分享需求评审