撕逼大会之需求评审

【字数:2849;阅读时长:8min】

需求评审会,又名【撕逼大会】

你们感受一下,脑洞下看看有没有什么画面感可言:安卓端、IOS端、后台、H5端、UI····在会议过程中各种不可以、各种充斥着辩论的声音,然而一个产品孤零零的舌战群儒!

经历过需求评审的我们都知道一件事,就是当我们各项产出物都完成、流程捋顺的之后,我们会跟需求方确认,确认之后呢,紧接着就会进入到技术方的需求评审,这个评审的过程目的很明确,就是阐述自己的观点并且将设计文档在最可行下的方案得以落实和执行~

但是需求评审中,往往不少产品会把自己搞的伤痕累累,为什么呢?做过产品的都知道——技术会喷嘛~而且一路一个坎的喷~

以上是现状!我们今天要说的是,如何让需求评审更高效,更具体的可以落实,而不是变成异常各抒己见的撕逼大会!

1

一、首先,我们得搞清楚需求评审会议的目的:

1、产品自身可以很清晰的表达设计文档的每个流程、每个板块的各项情况,例如各个板块的流程、各个功能的正常情况、异常情况的说明,特殊需求点的规则阐述等等。

2、关于人人都是产品经理,并不是说每个人都可以做,而是每个人都会站在用户角度去观察产品经理设计出来的文档内容是否合理,这样来说,就会出现众口难调的结果——每个人都会有自己的想法,每个人都会觉得自己的观点是正确的,这样我们就需要正确的、合理的、全方位的沟通(此项为沟通方法)

3、关于表达,是否可以正确的表达和聆听,这是产品在需求评审会的核心原则!

2

二、再次,我想通过个人的经历来阐述一下需求评审会的表达方式和原则

1、不可否认,很多人都不会说话!

其实,无论是我们产品经理的产出物(如PRD、流程图、框架图),还是我们的语言表达,最终想要达到的目标就是一次性尽可能没有任何问题的与各个涉及开发的技术方与执行方来正确的交流和表达。那么我们表达的前提就是对业务的了解和对市场的研究

只有对整体业务流非常了解,才能从各个方面去说服技术来按照产品的方案去落地,而针对一个行业的深入了解,是需要时间和经历的;所以,每句话的说与不说,心里一定要有底!

这里面涉及到一个原则性问题,就是,我们为什么有时候被技术一句话怼回来却无言以对?不是因为我们不知道怎么反驳,只是对行业的积累性不是很全面,对某些原理性不是很了解——这也就是我们经常说的那句话:学会站在对方角度去思考~

站在对方角度思考,不是说我要怕你或者无力回击,真心的希望同胞们不要把每次需求评审都当做一场战争去做,那样只会两败俱伤,别忘了,我们做任何事的前提只有一个——我们都希望产品越来越优秀,越来越多的用户爱上我们的产品——这才是我们得以骄傲的事情!而不是战胜谁······

总结:说与不说,有时候不是失败或成功,我们有时候需要通过积累来成为可以拥有更多发言权的人,前提是我们要做到熟知于心!

2、上帝给了我们两个耳朵,是让我们更好的去聆听!

现在让我们静下来,然后深呼吸一下,安静的回忆一分钟,我们在参加了这么多需求评审会,起初我们去撕逼的心态如果是为了坚持自己的想法,那么继续撕逼是为了赢得胜利感,还是为了产品能够得到更好的建议?

首先我需要说明一点的是,产品经理一定要有自己的原则和坚持!但,这并不意味着我们不去倾听别人的建议和意见,如果前提站在为了产品的发展和用户更好的体验来给的建议,最起码我,一定会听!这里面我们需要知道的是,任何一个公司的任何部门的任何人,都是需要相互合作,不是处于敌对双方的关系~技术方在我看来都是非常敬业非常专注的人,有时候可能说话只是为了表达某个建议,如果我们作为产品的误认为人家是为了证明自己,那么有效合作的效率会越来越低。因为你不知道人家的意思啊,总以为是在打仗,那还说什么,谁怕谁?来啊~

但如果这样,产品就完了···我们需要知道的是,大多数人的思想只不过是环境的产物,脑子很清晰和另一种脑子很清晰的想法,最终是通过文字或者语言来进行表达和阐述,但是如果两种思维发生了碰撞,只能说明有一方的思维有了固化的枷锁并且暂时无法摆脱。不要紧,跳出来,想一想,是为了打仗体验胜利感还是为了产品更好?

不管多么激烈,只要我们明白我们最终的初心是没有变的,那么依然可以继续讨论(当然,讨论也是需要技巧的)

总结:不忘出现,方的始终——沟通的过程中实时反思和摆正位置,要知道产品角色的属性不是为了争吵,而是为了解决问题,那么所谓的撕逼,就不是问题了

3

三、技巧

1、不要在某一个点一直争论:

当我们停留在某一个点,打个比方,注册时候我们要不要邀请码?是必填还是选填?(只是举个例子)

如果我们在这么一个点上因为每个人的每个不同的想法而一直争论,那么无疑是对需求评审会的亵渎,需求评审会在我看来本身就是一件以讨论技术实现方案以及评估工期时间节点为主的一场会议,如果真的停留在某一个点上一只撕的话,那么先过,会后冷静下来根据公司业务和数据来给个最终的方案!

2、适当的学会调频:

如果同时负责两个以上产品的时候往往会有这种情况,就是之前某个做过的产品的某些逻辑可以直接拿来复用,这个无可厚非,既节省了时间成本也节省了人工成本;但是出于业务的差异性,如果讨论的过程中,突然某个人想到了之前的某个业务流的问题并发起了谈论,那么暂时不要阻止,允许他有思考的时间,当节点到了之后,那么拉回来,继续我们刚才没有继续完成的问题,继续讨论。

否则,我们在讨论什么?

3、别红脸、别出言不逊:

作为产品来说,需求评审会可能会出现各种意外的情况,不管发生是什么,一定要谨记隐忍这两个字,不能把自己搞的失控了,进而做出主观色彩很强烈的表现,那样首先是对别人的不尊重,另外来说,会影响后期各个部门的协调的配合工作。耽误了工作,恐怕自己也会很难受的!

别做让自己后悔并且无法挽回的事~

以上我们说了需求评审三个需要注意的点

另外,评审会有几个阶段,也想分享一下:

1

一、会前

会前最好把相关部门的现有工作进行一个总体的了解,因为任何一个新需求出来之前,我们要保证之前的需求可以正常完成,没必要给谁增加过重的工作量

提前将产品的交互、需求说明等产出物邮件给相关人员和上级,这种预热是需要的,不然会议前大家一无所知,会上很容易实时发挥各自的意见,那样就真的是临场发挥,各抒己见了

最后,会前一定要自己仔细的过几遍自己的输出文档,以免会议出现自身出现的问题而导致印象会议正常进展,那,你就等着被蹂躏吧

2

二、会中

会中,我唯一的建议就是先把自己即将要做什么、为什么要做这些,做这些可以为用户带来什么、为公司带来什么等等说清楚,可以场景化需求,也可以目标化需求,这样的余热是有必要的,最起码大家知道:哦,做这个可以这样~这样的话,也许,评审会会更顺利呢~

再,就是如何表达和聆听,这个参考上述几个点就可以了

3

三、会后

总结、总结、总结!

首先要有会议纪要,罗列清楚问题和争议点,想清楚如何解决,并给予最终的方案和结论即可

再,将最终文档邮件给各个人员,建立交流群(方便实时交流)、建立项目共享文档、建立反馈渠道

督促、跟进、测试

最后,如果是新上线,要提前准备好商城上线相关材料!切记、切记!

所有的所有,都是我走过的坑,希望我的分享对你有用

别怕,你并不孤独!

原文发布于微信公众号 - Miguel三先生(Miguel-sxs)

原文发表时间:2018-01-22

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏华章科技

大数据黑洞

如今我们可以轻松地从云端雾端,或者某些静态设备(staticdevice)收集数据,但是这些数据无法量化客户体验时的情感。大型企业利用无处不在的信息感知移动设备...

752
来自专栏Java学习网

是什么让PM成为一个伟大的PM?

是什么让PM成为一个伟大的PM? 在正式进入这篇文章之前,我首先要声明,以下内容纯属我个人主观的观点。我认为自己很幸运,因为我担任过产品团队的PM,并且目前我...

2159
来自专栏DevOps时代的专栏

Devops 是否是一条不归路?

序言 实施 DevOps 有什么前提条件?大型分布式互联网系统从何处入手启用 DevOps?互联网金融平台,本身测试就复杂度大,究竟如何迎合快速交付的要求?企业...

2618
来自专栏Java进阶干货

转型架构师之路——郑天民

架构师是一个综合性的角色,需要熟练掌握架构设计方法和开发技术,同时具备良好的组织管理能力。在第2篇《深入剖析架构师角色》中我们分析了架构师的主要职责和所开展的活...

794
来自专栏CLEAN_CODER

ThoughtWorks中的敏捷团队建设

如果你已经阅读过 我在ThoughtWorks中的敏捷实践,可以跳过项目回顾,直接进入 团队建设。

942
来自专栏landv

流程内耗的雾霾几时休?

一个企业,无论大小,都具备“麻雀虽小,五脏俱全”的职能部门,都有人数或多或少的运作团队。正如金庸在《笑傲江湖》中写道:“有人就有恩怨,有恩怨就有江湖”,在协同运...

791
来自专栏镁客网

今日头条整改首先扩招审核团队,靠机器学习推荐内容已是伪命题?

944
来自专栏罗超频道

内容平台管理难题如何破?知乎的答案是这样的

知乎今天开始试运行新版管理规范,对一些影响用户体验、扰乱社区秩序的行为进行了明确限制,主要包括六种行为:诱导投票或关注、重复发布相同内容、频繁发布乱码内容、发布...

2446
来自专栏云市场·精选汇

小程序让文具行业“活”起来 ,助力商家抓住90、00后的小心思

大家是不是线下感觉生意难做?房租居高不下?人工成本剧增?线上冲击大?其实这些都不是问题,生意难做,你有很好的管理库存出入库的比例么?还在死板的拒绝网络、拒绝小程...

1616
来自专栏腾讯大讲堂的专栏

运营是什么

作者:邬嘉文,微信高级运营。精通用户研究,推荐算法,Growth用户运营,结果在微信都用不上。 从市场调查转行腾讯做互联网,那时候还不懂什么是运营。记得有一份大...

54119

扫码关注云+社区