产品经理怎么称霸需求评审会?

前几天有同学在老K的知识星球写了需求评审,我觉得这个话题很有意思。需求评审,别称撕逼大战,指一群心怀鬼胎的人在固定的战场进行多轮PK,最终脸上笑嘻嘻心里MMP达成暂时性一致意见并时刻准备着下次战斗的“友好”交流形式。

产品经理怎么称霸需求评审会?

在我漫长的职业生涯中,参与需求评审大概经历了3个阶段:

第1阶段是冲锋陷阵,作为需求评审的绝对主角,带着职业假笑拉着一群平级和上级开会,一顿舌战群儒之后,强行给他们安排工作,或者被他们骂回去加班改需求。

第2阶段是悠闲旁观,端着咖啡刷着微博悠闲的听产品经理1Vn,然后在产品弱势的时候,凭借着自己的title、资历以及常年和CEO谈笑风生转化来的社交货币果断出手护犊子,以保证产品部门工作的顺利开展。

第3阶段是不闻不问,需求评审会都不去参加了,只在会后听产品经理做简明扼要的结果汇报,结果满意就好,如果砍了我的核心需求,立即拉着技术老大出门按照江湖规矩1V1单挑,撕出结果之前,递来的烟都不接。(撕出结果也不接烟,毕竟老K不吸烟~

根据我多年的实战经验,给大家聊聊,怎么称霸需求评审会。

明确需求评审的目的

需求评审,这个没找到百度百科之类的定义,那就说我的理解:产品经理的职责是去迭代产品,我们会通过很多途径收集需求,经过自己的思考之后,形成产品需求文档,在文档变成功能之前,你需要说服很多人来支持你,包括:老板或者上级总监、开发测试设计同学等等。这个不择手段的说服的过程,就是需求评审。

所以,需求评审会的目的,就是说服团队的人,至少是关键的人,支持认同你的产品迭代决定,并一起去完成产品迭代的开发上线工作。

找到关键人物

很多同学对需求评审会都有一个误解,就是你要说服团队所有的人。其实没必要,你只需要说服关键人物。

一个典型的产品开发团队包括:老板、产品经理、开发、设计、测试。其他的市场运营客服等,对产品迭代不具有决策权,甚至连发言权都没有,只有上线前被邮件通知的知情权。

在这个团队中,有两个关键角色:老板和技术老大。老板决定产品的方向,你的所有尝试,必须符合这个方向,否则会被一巴掌拍晕。技术老大有一票否决权,一句“需求通不过技术评估”就让产品经理无fuck说。

所以,说服这两个关键人物支持你,需求评审也就成功了90%(惊喜)。

需求评审会的黄金原则

我在第一阶段时,觉得产品经理都是最聪明最牛X的,什么人情世故策略技巧,全都一边去,哥是凭实力说话的好吧。

需求评审会的基调就是简单粗暴,经过用户调研和自己绞尽脑汁的分析取舍,输出一份自认为很完美的需求文档,然后直接拉所有人开会。结果呢,就是会议经常卡在需求是否刚需和技术实现上,还没讲到具体功能就已经开始口吐芬芳。

你们一群写代码的,跟我扯刚需高频?你们一群写代码的,连技术实现都搞不定!年少的我是这样想的,大家有同感吗?

后来到了第二阶段,我对团队里的产品经理都有一个要求,画原型写文档之前,先跟我沟通你的想法和你要做的需求方向,确认没问题之后你再去做具体的事儿,免得做无用功。

在这个阶段我也明白了,为什么在产品经理嘴里有那么多的SB老板,本质原因是二者出发点就不一样,一个看重付出的回报率,另一个则不管不顾的代表用户向天请命。

我也渐渐明白,要达到需求评审的目的,关键一步就是说服核心人物:你的老板、技术老大。最好是在需求评审会之前完成这一步,把需求评审会当成确认需求细节后的产品迭代启动会。

所以需求评审会的黄金原则就是,在会议前,跟老板/总监沟通需求本身,确保对方认同你的需求;跟技术老大沟通需求的技术实现,同时说明需求的业务目的,在确保技术实现没问题的同时,让技术负责人也认同你的需求本身。

最后,需求评审会上,老板/总监在场的话是你的靠山,有技术同学出于本能(科普一下,技术和产品会不经思考条件反射的反对彼此的观点,这叫本能)给你挑刺时,不需要过多言语,一个怀疑其领导水平和威信的眼神看向技术老大,他大概率会跳出来制裁小弟。

需求评审会最终也就走个过场,确认一下需求细节,正式启动一次产品迭代。

其他注意事项

即使在会前已经搞定了关键人物,需求评审会对产品经理还是非常重要的,这是一次难得的表现自己的舞台,是一次向整个团队表明你是一个非常专业、牛X、甚至幽默风趣的产品经理的机会。一次次成功的需求评审会会提高同事对你的信任甚至钦佩,对以后工作的顺利开展很有帮助。

需求评审会一定要注意以下几个方面:

会前:至少提前2天与整个团队约定会议时间、预定会议室,并将产品原型、需求文档等资料通过协作工具发给每个人。

会中:讲具体功能之前,先讲需求背景、业务目的,告诉大家我们要做什么、为什么要做、以及做了之后有什么价值。

讲功能时要系统条理,对照产品原型、需求文档,确保每一个细节都讲到。

会后:及时输出会议纪要,包括会议结论、争议点和解决方案(暂时没有方案的,备注出方案的deadline),然后邮件所有人,记得在邮件的最后要求开发测试设计同学评估工作量和大概工时。

然后总结需求评审会中的争议点,重新输出解决方案,如果有必要,可以拉二次会议进行确认。

遇到分歧怎么办?

因为需求是会前就确认过的,所以这里的分歧多是细节方面,比如交互细节、文案细节等。

如果对方有更好的建议,果断采纳,并趁势带着职业假笑舔一波:“你的建议真是太棒了,我学习了,会后马上改!”这样有助于拉进你和狗开发的距离。

如果对方指出了你的错误,特别是接手新产品时,老开发往往比新产品更懂产品细节,开发指出你的需求与产品有冲突,这个时候切记要冷静,不要脸红露怯,风轻云淡的微微一笑,用一切尽在掌握之中的语气说一句:产品交接时没说明这一点,多谢**指出,问题我记下了,会后重新调整需求。

如果对方不认同你的方案,提出了另一个你不认同的方案,这种情况往往会陷入无尽的撕逼,让一场原本40分钟能结束的会议拖到2个小时。所以这时你不要想着马上就能说服他,很难!最优解决方案是记下争议,会后解决。

总结

其实很多事情,我们看到的都只是个形式,关键步骤在这个形式之前已经完成了。

比如表白是胜利的凯歌而不是冲锋的号角,要确保表白之前就已经获得了妹子的心,否则容易尴尬…

再比如上市敲钟,公司的业绩发展、财务审计才是关键,敲钟只是个形式。

所以对需求评审也是一样的,把最后的需求评审会做成一个形式,关键的步骤会前完成,既能保证工作的顺利进行,又能在会上保持产品经理该有的风度和潇洒,结果要好,过程也要帅!

本文由 新媒体之家 作者: 产品经理日记 发表,其版权均为原作者所有,文章内容系作者个人观点,不代表 新媒体之家 对观点赞同或支持,未经许可,请勿转载,题图来自Unsplash,基于CC0协议。
0

发表评论