需求评审你会了么?这里有一个标准的失败案例

4 评论 5201 浏览 23 收藏 9 分钟

作为一个产品经理,提需求是家常便饭的事情。但是,如何跟别的部门沟通是个大问题。本文作者基于自己的亲身经历,进行了三个角度的分析,希望对你有帮助。

一、南南南:细数提一个需求需要跪舔几个部门几多人

今天小胖讲一个别人的故事,怎么样的需求会把一个工作群从开始的5个人最后拉到了22个人?

是需求特别大么?是需求特别重要么?是需求特别复杂么?

不太是(产品经理谨慎的用词赶脚)……

事情是这样的:上周有一个活动需求,对接的产品同学想在APP的页面增加一个任务广场,用户完成任务后就可以愉快地抽奖了。

到现在为止,是不是觉着这个需求特简单,1天开发够不够,不够就加多2天,3天足够了!

我估计这个产品同学应该当时就是这么想的,当然表述上是产品经理们经常听到的贯口儿:“这个需求很简单鸭,领导很关注鸭,下周能不能上线呢?”

但是,作为需求承接的一个小部分,咱们就只能听着、认着、惯着……

Round 1 :周一第1次需求评审

产品同学愉快地把相关方叫了来,感觉组织评审、开会——这才是头等大事儿!

需求以迅雷不及掩耳之铃儿响叮当之势讲完了,开始技术大大也觉着好简单鸭(产品同学此时一定乐开了花,如果能够预料到后续的菊花生疼,他一定笑不出来)。

等闲平地起惊雷。

是的,你没有听错,交互小姐姐有意见啦:“你这个原型太简单了,好多交互都没有,这样评估的工作量是不准确的!” 作为乖巧的产品狗,此时肯定是满脸堆笑,道:“马上补,咱们先评审”。

这时候你猜技术小伙伴会怎么想,果然技术小哥哥说话了:“这个没法评估鸭,什么时候可以先出交互再看看”。

Round 2 :周四第2次需求评审

大家又被叫到了一起,大公司么,会议不多是不可能的。

我想这次产品同学是带着万全之策来的,果然,整个需求讲述过程行云流水、快马加鞭、江河泛滥而一发不可收拾。

对了,各位一定想知道这次参与会议的人是不是有变化呢?

恭喜你都会抢答了,这次不但来了前端开发、交互、产品、后台开发;没错,还来了云端开发、活动开发、插件开发(谁让咱们家的APP复杂呢),工作群的人数激增。

欢乐的日子总是那么短暂。

就在大家准备举杯相庆、策马奔腾的时候,突然有人gang(讲):“是不是品质没有来?”对头,品质就是测试同学的意思。

赶紧群里继续拉人鸭,不管怎样先盘他!

你想想,你如果突然被人拉到一个群里,然后告诉你有一个需求排期定了,需求我再单独给测试讲讲就好吧?好你个头 !

测试小姐姐当然是不答应的,让我,我我我……我也不答应!

Round 3 :周五第3次需求评审

就像那部有名的电影一样:一个都不能少。

这次评审没有问题,但是问题出在评审前:尼玛这样一个不是那么大的需求,每个人都只是占了一丢丢工作量的需求,你让我评审三遍?!并且按照前几次的体验来讲,有第三遍,是不是还有第四遍,我们是不是不要做其他事情了呢?

许多人这个时候不免都会问这个问题。

怎么办?当然只有产品gg跪下,跪舔大佬们再拨冗参加一下最最最后一次评审。

二、产品经理战地日记总结

先说基本问题。这是在一个大公司普遍存在的沟通和协同问题,也是一个产品成长到比较大的时候会遇到的一个痛点:模块细分,各模块不说各自为政吧,但是按照“流程”来办事儿,不免让人有些蛋疼。

产品经理或者项目经理的问题:要做好尽量充足的准备。

  • 把涉及到相关方一定要叫齐,减少重复沟通的次数和风险;
  • 做好产品设计的本职工作,开会要尽量准备完善的需求文档,而不是开会过程中区反复讨论。

老板的紧急需求怎么做?

这次一个很重要的原因在于,新产品同学对于老板的紧急需求理解有偏差,并且还只是自己的老板,又不是相关系统的老板,其实以时间倒逼开发的手段并不高明。并且,是在自己完全没有准备好,也没有对相关系统了解清楚的基础上,就匆匆忙忙来过需求,这本身就是沟通和协调中的大忌。

三、一点引申:大公司大产品需求沟通无障碍指南

按环节我们可以这样分:

  • 与直接需求方(一手需求)的沟通,比如老板、业务方;
  • 与中间传达方,比如运营的沟通;
  • 与执行操作方,比如技术开发、UI设计、测试品质等;
  • 与一手需求方、中间传达方和执行方的再次确认。

与直接需求方(一手需求)的沟通,比如老板、业务方:

  • 拒绝一句话需求,最起码讲清楚为什么做,大概怎么做,有哪一些基本的边界情况等。同理,是不是一句话需求,我们只需要一句代码就好了,请记住这句话,或许你下一个需求就用上!
  • 倒逼一手需求传达者,让他们尽量可以跟老板框定一定的需求范围。不要说老板很难搞,你搞个简单方案给老板,老板会砍你么?怕死的接口人刀片跟你更配哦。

与中间传达方,比如运营的沟通:

  • 你或许已经习惯了运营同学经常的一句“这个需求很紧急”,不论怎么紧急,都要问清楚为什么做?是不是可以不做?或者换种方法做?
  • 不要指望运营同学帮你想清楚所有的边界,踩过多少坑就用多大的脑容量去装满那些方案中的闷雷。
  • 我们说过的都不算数,邮件才是王道。

与执行操作方,比如技术开发、UI设计、测试品质等:

对于这些小伙伴,第一我们要讲清楚;第二,要保证他们能够听明白;缺一不可。一个都不能少,少了哪一环都不行。就像一条锁链一般,大家都被牵连到一起,每一环都不能断,我们关注每一个里程碑关键节点。

与一手需求方、中间传达方和执行方的再次确认:

  1. 上线前,测试是一段宝贵的时间,这个时候赶紧再确认一遍,没有惊喜就是“惊吓”;
  2. 上线中,系统的稳定比你所有的加班都重要一百倍;
  3. 上线后,在之前做好数据埋点,这是唯一一个可以怼各位爸爸的时间,最好变成大家庆祝的日子。

爱你们的小胖子。2020年夏。

#专栏作家#

FatBoy,微信公众号:夜来妖,人人都是产品经理专栏作家,做了几年产品。

本文原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 很明显是没准备好呀,只要涉及的相关方都要叫其,并且需求内部也要评审过后再跟研发他们评审会比较好,不然就会不断的被挑战

    回复
    1. 是的,非常浪费感情和时间

      回复
  2. 我只能说这个例子里边所谓的大公司连个规范流程都没没有,乱的一匹,还不如许多小公司的流程标准

    回复
    1. 一针见血。准确说是A部门有,B部门没有。。。 😉

      回复