订阅

需求评审与讨论问题的基本方式

总结一下,其实就是一个不断拆解的过程

关于什么是需求评审,不在这里做解释与定义了,直接进入主题。

关于需求评审的几个原则:

1、需求评审不是谁要说服谁,而是我们要就某一个具体问题寻找到最优的解决方案。

我们有很多PM总是会抱着「我要说服研发」的态度来做需求评审,所以整个需求评审的基本氛围是辩论,是相互的寻找极端情况支撑自己的观点,试图让对方让步,这是非常错误的开局。

2、所有问题的讨论,都必须要先建立基本共识,然后基于这个共识再细化。

什么是基本共识呢?就是我们首先要把双方调整到一个频道上来。不要在不同的频道上相互努力,那没意义。比如,我们先要定义清楚什么是激活用户、什么是注册用户;比如我用到的这个名词指代的是什么这样的基础的小问题。

3、先不要在僵持不下的观点上浪费时间,先求同,后攻异。

在已经形成基本共识的基础上,如果一个小问题有分歧,且一时半会讨论不清楚,那就先放下,继续讨论其他的,等其他的解决了,再回来解决这个差异点上的问题。

关于需求评审的推进步骤:

1、先说我们这次需求的目标与目的。

简单说就是先讲明白我们要做什么,我们为什么要做这个。

就像是演讲的时候,先讲一个能够引起观众兴趣的故事或者观点,然后再提出一个在这个美好的故事中需要解决的难题。

这个问题是经常会产品经理忽略的,但也恰恰是需求评审中最最重要的,它的重要性甚至超过了后面所有的步骤!

我看过太多的产品经理在需求评审的时候,上来就打开画好的原型图,开始讲功能,讲流程。这是完全错误的。一定要花时间先讲为什么要做这个,要达到什么目标,并且一定要在这个目标上达成一致意见。

就像我之前说的,「设计师,别急着打开设计软件」,产品经理在需求评审之前,请别着急讲功能点与流程,这非常重要。

2、在目标与目的达成一致的基础上,再说你准备怎么做

在谈怎么做的时候,我们是默认为什么做大家达成了一致的。这个时候,不要再返回去讨论第一个问题了,聚焦在怎么做上。

在我们讨论问题的时候,在我们评审一个需求的时候,很多人会很着急,当你说要做这个的时候,他的思路会跑的很快,立刻就先跑到了想要是这么干,我们目前的架构会有什么问题,会存在什么潜在风险,已经跑到细节上了。

这样很不科学,也很不高效,很容易把问题混到一起去了,然后就会陷入到细节的争吵与辩论,然后就走偏了。这样的讨论也是低效的。

谈第一个层次问题的时候,就不要想第二个层次的事情,谈第二个层次的事情的时候,就不要再回去质疑第一个层次的结论了。

讲述你准备怎么做的过程,实际上就是要描述你的解答对解决问题而言的好处。

关于「准备怎么做」的讨论,会有2个结果:

2.1、你认同或者大部分认同我的方案

那么,就按照这个方案来执行,其中有一些不太认同的,我们坐下来讨论,看是否有更好的方案来做。

2.2、你不认同我的方案

那么,我们先回到第一个问题「关于我们要做这个事情的目标与目的」是否认同。如果认同目标了,那就是实现方案的问题了,我们可以坐下来研究。如果不认同这个目标,那这评审也就没得玩了,这个状态一般极少出现。

好,现在问题出在不认同方案上了,又有2个结果:

2.2.1、这个方案可以做基本的修正吗?

可以,那我们探讨如何修正

2.2.2、你是否有更好的解决方案呢,这个方案是否可以勉强执行?

可以,那好,先按照这个方案干。如果你有更好的方案,我们按照你的方案干。

2.2.3、我没有更好的方案,我也不认同你的方案

靠,你这完全不是一个团队合作的状态,赶紧换人。

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

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

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

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

总结一下,其实就是一个不断拆解的过程,

讨论问题3步走

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

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

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

相关日志