需求评审与讨论问题的基本方式
总结一下,其实就是一个不断拆解的过程
关于什么是需求评审,不在这里做解释与定义了,直接进入主题。
关于需求评审的几个原则:
1、需求评审不是谁要说服谁,而是我们要就某一个具体问题寻找到最优的解决方案。
我们有很多PM总是会抱着「我要说服研发」的态度来做需求评审,所以整个需求评审的基本氛围是辩论,是相互的寻找极端情况支撑自己的观点,试图让对方让步,这是非常错误的开局。
2、所有问题的讨论,都必须要先建立基本共识,然后基于这个共识再细化。
什么是基本共识呢?就是我们首先要把双方调整到一个频道上来。不要在不同的频道上相互努力,那没意义。比如,我们先要定义清楚什么是激活用户、什么是注册用户;比如我用到的这个名词指代的是什么这样的基础的小问题。
3、先不要在僵持不下的观点上浪费时间,先求同,后攻异。
在已经形成基本共识的基础上,如果一个小问题有分歧,且一时半会讨论不清楚,那就先放下,继续讨论其他的,等其他的解决了,再回来解决这个差异点上的问题。
关于需求评审的推进步骤:
1、先说我们这次需求的目标与目的。
简单说就是先讲明白我们要做什么,我们为什么要做这个。
就像是演讲的时候,先讲一个能够引起观众兴趣的故事或者观点,然后再提出一个在这个美好的故事中需要解决的难题。
这个问题是经常会产品经理忽略的,但也恰恰是需求评审中最最重要的,它的重要性甚至超过了后面所有的步骤!
我看过太多的产品经理在需求评审的时候,上来就打开画好的原型图,开始讲功能,讲流程。这是完全错误的。一定要花时间先讲为什么要做这个,要达到什么目标,并且一定要在这个目标上达成一致意见。
就像我之前说的,「设计师,别急着打开设计软件」,产品经理在需求评审之前,请别着急讲功能点与流程,这非常重要。
2、在目标与目的达成一致的基础上,再说你准备怎么做
在谈怎么做的时候,我们是默认为什么做大家达成了一致的。这个时候,不要再返回去讨论第一个问题了,聚焦在怎么做上。
在我们讨论问题的时候,在我们评审一个需求的时候,很多人会很着急,当你说要做这个的时候,他的思路会跑的很快,立刻就先跑到了想要是这么干,我们目前的架构会有什么问题,会存在什么潜在风险,已经跑到细节上了。
这样很不科学,也很不高效,很容易把问题混到一起去了,然后就会陷入到细节的争吵与辩论,然后就走偏了。这样的讨论也是低效的。
谈第一个层次问题的时候,就不要想第二个层次的事情,谈第二个层次的事情的时候,就不要再回去质疑第一个层次的结论了。
讲述你准备怎么做的过程,实际上就是要描述你的解答对解决问题而言的好处。
关于「准备怎么做」的讨论,会有2个结果:
2.1、你认同或者大部分认同我的方案
那么,就按照这个方案来执行,其中有一些不太认同的,我们坐下来讨论,看是否有更好的方案来做。
2.2、你不认同我的方案
那么,我们先回到第一个问题「关于我们要做这个事情的目标与目的」是否认同。如果认同目标了,那就是实现方案的问题了,我们可以坐下来研究。如果不认同这个目标,那这评审也就没得玩了,这个状态一般极少出现。
好,现在问题出在不认同方案上了,又有2个结果:
2.2.1、这个方案可以做基本的修正吗?
可以,那我们探讨如何修正
2.2.2、你是否有更好的解决方案呢,这个方案是否可以勉强执行?
可以,那好,先按照这个方案干。如果你有更好的方案,我们按照你的方案干。
2.2.3、我没有更好的方案,我也不认同你的方案
靠,你这完全不是一个团队合作的状态,赶紧换人。
3、方案达成一致了,开始做排期与风险及收益预估
为什么做这个事情,都清楚了,也认同了;
是不是可以这么干,也基本达成一致了;
剩下的就是排期,安排人员,具体去执行了,这是一个新的话题,不展开了。
总结一下,其实就是一个不断拆解的过程,
先说我们的目标与目的,在为什么要做这个事情上达成一致;
再说我是这么想的,你觉得方案是否可行,我们一起看看有没有更好的方案,在怎么做上达成一致;
按照我们讨论的这个做法,看看我们现有的人手,具体怎么一步一步执行。
讨论问题与需求评审一样,是一个解决问题的过程,解决问题的最合理方式就是不断拆解问题,拆解到不能再拆解了,然后分别的寻找解决方式。
另外,相比情商,智商反而有时候显得不是最重要的。
建议继续学习:
- 不懂技术的人不要对懂技术的人说这很容易实现 (阅读:4413)
- 关于架构的一句话,还有一个实例 (阅读:3578)
- 用Unix的设计思想来应对多变的需求 (阅读:3583)
- 百度PM万维雅:需求把握和正确决策 (阅读:2694)
- 如何准确看清用户需求? (阅读:2556)
- 技术方案评审 (阅读:2400)
- 用户的地图需求分析 (阅读:2384)
- 如何媒体正确的看待:产品需求文档和产品需求 (阅读:2245)
- 姐要的视频广告 (阅读:2242)
- 分析用户需求:在场景中寻找“痛点” (阅读:2051)
扫一扫订阅我的微信号:IT技术博客大学习
- 作者:kent.zhu 来源: 幻风阁|kent.zhu'sBlog
- 标签: 评审 需求
- 发布时间:2015-05-11 23:37:00
- [65] Oracle MTS模式下 进程地址与会话信
- [65] Go Reflect 性能
- [64] 如何拿下简短的域名
- [59] android 开发入门
- [59] IOS安全–浅谈关于IOS加固的几种方法
- [58] 图书馆的世界纪录
- [58] 【社会化设计】自我(self)部分――欢迎区
- [53] 视觉调整-设计师 vs. 逻辑
- [47] 界面设计速成
- [46] 读书笔记-壹百度:百度十年千倍的29条法则