新闻资讯频道
域名领域最新资讯

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

    话不多说,直接上干货。

    本文主要分为四部分:

    1. 需求评审的标准
    2. 需求评审面临的困难及小技巧
    3. 需求评审的原则
    4. 需求评审的具体步骤

    一、需求评审的标准

    1、需求评审要细到什么程度?

    严格地讲,需求评审应当检查需求文档中的每一个需求,每一行文字,每一张图表。

    2、评判需求优劣的主要指标

    正确性、清晰性、无二义性、一致性、必要性、完整性、可实现性、可验证性、可测性。如果有可能,最好可以制定评审的检查表。

    二、需求评审面临的困难及小技巧

    1、需求评审的一个通病是“虎头蛇尾”

    需求评审特别地乏味,在刚开始评审时,大家都比较认真,进行的越往后越马虎。尤其是当需求文档很长时,几乎没人能够坚持到最后,别说你能,我不信!

    小技巧:

    1. 事先强调重点模块;
    2. 评审时间长时,建议隔时间段休息;
    3. 如果系统大文档长时,可细分成不同的部分或模块分别进行讨论;
    4. 严格控制每次评审的文档规模及评审时间。

    2、需求评审涉及的人员可能比较多

    将这么多人聚到一起开会是非常不容易的,例如某些人可能在出差,某些人可能在进行别的事物···

    小建议:

    1. 不要把所有事情挤在一起做,需求评审可以分段进行,这样每次评审的时间及与会人员都会少一些;
    2. 其次将《需求规格说明书》进行不同的标记,如草稿状态、评审状态、最终状态等,要对需求的最终状态进行更加严格的评审。

    3、需求评审会议会经常跑题

    有时话匣子一打开后关不上,大家越扯越远,结果评审会议变成了聊天会议。

    小技巧:

    1. 控制话题,避免讨论与主题无关的东西;
    2. 不需要深入讨论具体的执行,适可而止;
    3. 尽可能的阐述事实与证据,而并不是如何努力地说服别人。

    三、需求评审的原则

    1、不是谁要说服谁,而是就某个问题找出最佳解决方案

    很多时候产品经理都是抱着“我要说服研发”的态度,这就会导致需求评审变成了一场辩论赛,大家都疯狂的相互寻找极端的情况来支持自己的观点,试图让对方进行让步,然而这恰恰是最错误最可怕的情况。

    2、先建立基本的共识,在基于共识进行细化

    不要盲目的、随心所欲的发言,首先要现金礼基本共识,通俗的说就是建立一个主调,把大家都拉倒同一个频道上来,不然就会导致大家在不同的频道上巴拉巴拉,互不相让,其实完全不是在说同一件事情,驴唇不对马嘴。

    3、先求同,后攻异

    在已经形成基本共识的基础上,若对其中的小问题存在分歧时,如果一时半会讨论不清楚,可以暂时记录下来,继续讨论其他的,最后在对有分歧的小问题进行讨论。但是当这个问题是产品主要功能或流程上的问题时,尽量不要跳过。

    四、需求评审的具体步骤

    1、明确目标与目的

    通俗的说就是先说清楚我们要干什么。

    看过太多的产品经理在需求评审时,上来就打开原型,巴拉巴拉的讲功能,将流程,这是完全错误的,一定要先明确目标,并一定要在目标上完全达成一致。

    2、目标达成一致后,说说怎么做

    在讨论怎么做时,很多人就已经把话题带到了如果这么做,我们的架构有什么问题,有什么风险等细节上了,这很容易让大家陷入细节的争吵与辩论,越跑越偏。

    在讨论第一次的问题时,不要去想第二个层次的细节问题;在讨论细节问题时,不要再去质疑第一个层次的结论。

    通常在讨论总会这两种结果:

    1. 大部分认同这个方案:我们通常是按照这个方案来执行,对于其中的一小部分不太认同的部分,在进行讨论,看是否有更好的方案。
    2. 不认同这个方案:首先再次确认,目标是否认同,如果目标都不认同,那这次评审也就操蛋了,这种情况一般不会出现;如果目标认同,那就是解决方案的问题了,可以坐下来研究,通常是:

    (1)这个方案可以做基本的修正吗?

    如果可以进行修正,那么探讨如何修正;如果不可以进行修正,那么重新寻找方案。

    (2)是否可以勉强执行?你是否有更好的方案?

    如果可以勉强执行,那就先按照这个方案干;如果有更好的方案,那就按照这个更好的方案干。

    (3)我没有好的方案,也不认同你的方案

    这种人完全不是做事情的态度,也不是团队合作的状态,赶紧让他卷铺盖滚蛋···当然不排除有特殊情况,就是这个方案真的有很大的问题,完全不能用。

    3、方案达成一致了,开始做排期与风险及收益预估

    为什么做这个事情,都清楚了,也认同了;

    是不是可以这么干,也基本达成一致了;

    剩下的就是排期,安排人员,具体去执行了,这是一个新的话题,不展开了。

    总结一下:

    • 先说我们的目标与目的,在为什么要做这个事情上达成一致;
    • 再说我是这么想的,你觉得方案是否可行,我们一起看看有没有更好的方案,在怎么做上达成一致;
    • 按照我们讨论的这个做法,看看我们现有的人手,具体怎么一步一步执行。

    讨论问题与需求评审一样,是一个解决问题的过程,解决问题的最合理方式就是不断拆解问题,拆解到不能再拆解了,然后分别地寻找解决方式。

    另外,相比情商,智商反而有时候显得不是最重要的。

    未经允许不得转载,或转载时需注明出处:西部数码域名资讯|域名门户|域名新闻中心 » 干货经验:产品需求的评审和讨论
    分享到:更多 ()

    中国领先的互联网域名及云服务提供商

    域名注册云服务器