需求评审你会了么？这里有一个标准的失败案例
一、南南南：细数提一个需求需要跪舔几个部门几多人今天小胖讲一个别人的故事，怎么样的需求会把一个工作群从开始的5个人最后拉到了22个人？ 是需求特别大么？是需求特别重要么？是需求特别复杂么？ 不太是（产品经理谨慎的用词赶脚）…… 事情是这样的：上周有一个活动需求，对接的产品同学想在APP的页面增加一个任务广场，用户完成任务后就可以愉快地抽奖了。 到现在为止，是不是觉着这个需求特简单，1天开发够不够，不够就加多2天，3天足够了！ 我估计这个产品同学应该当时就是这么想的，当然表述上是产品经理们经常听到的贯口儿：“这个需求很简单鸭，领导很关注鸭，下周能不能上线呢？” 但是，作为需求承接的一个小部分，咱们就只能听着、认着、惯着…… Round 1 ：周一第1次需求评审 产品同学愉快地把相关方叫了来，感觉组织评审、开会——这才是头等大事儿！ 需求以迅雷不及掩耳之铃儿响叮当之势讲完了，开始技术大大也觉着好简单鸭（产品同学此时一定乐开了花，如果能够预料到后续的菊花生疼，他一定笑不出来）。 等闲平地起惊雷。 是的，你没有听错，交互小姐姐有意见啦：“你这个原型太简单了，好多交互都没有，这样评估的工作量是不准确的！” 作为乖巧的产品狗，此时肯定是满脸堆笑，道：“马上补，咱们先评审”。 这时候你猜技术小伙伴会怎么想，果然技术小哥哥说话了：“这个没法评估鸭，什么时候可以先出交互再看看”。 Round 2 ：周四第2次需求评审 大家又被叫到了一起，大公司么，会议不多是不可能的。 我想这次产品同学是带着万全之策来的，果然，整个需求讲述过程行云流水、快马加鞭、江河泛滥而一发不可收拾。 对了，各位一定想知道这次参与会议的人是不是有变化呢？ 恭喜你都会抢答了，这次不但来了前端开发、交互、产品、后台开发；没错，还来了云端开发、活动开发、插件开发（谁让咱们家的APP复杂呢），工作群的人数激增。 欢乐的日子总是那么短暂。 就在大家准备举杯相庆、策马奔腾的时候，突然有人gang（讲）：“是不是品质没有来？”对头，品质就是测试同学的意思。 赶紧群里继续拉人鸭，不管怎样先盘他！ 你想想，你如果突然被人拉到一个群里，然后告诉你有一个需求排期定了，需求我再单独给测试讲讲就好吧？好你个头 ！ 测试小姐姐当然是不答应的，让我，我我我……我也不答应！ Round 3 ：周五第3次需求评审 就像那部有名的电影一样：一个都不能少。 这次评审没有问题，但是问题出在评审前：尼玛这样一个不是那么大的需求，每个人都只是占了一丢丢工作量的需求，你让我评审三遍？！并且按照前几次的体验来讲，有第三遍，是不是还有第四遍，我们是不是不要做其他事情了呢？ 许多人这个时候不免都会问这个问题。 怎么办？当然只有产品gg跪下，跪舔大佬们再拨冗参加一下最最最后一次评审。 二、产品经理战地日记总结先说基本问题。这是在一个大公司普遍存在的沟通和协同问题，也是一个产品成长到比较大的时候会遇到的一个痛点：模块细分，各模块不说各自为政吧，但是按照“流程”来办事儿，不免让人有些蛋疼。 产品经理或者项目经理的问题：要做好尽量充足的准备。
老板的紧急需求怎么做？ 这次一个很重要的原因在于，新产品同学对于老板的紧急需求理解有偏差，并且还只是自己的老板，又不是相关系统的老板，其实以时间倒逼开发的手段并不高明。并且，是在自己完全没有准备好，也没有对相关系统了解清楚的基础上，就匆匆忙忙来过需求，这本身就是沟通和协调中的大忌。 三、一点引申：大公司大产品需求沟通无障碍指南按环节我们可以这样分：
与直接需求方（一手需求）的沟通，比如老板、业务方：
与中间传达方，比如运营的沟通：
与执行操作方，比如技术开发、UI设计、测试品质等： 对于这些小伙伴，第一我们要讲清楚；第二，要保证他们能够听明白；缺一不可。一个都不能少，少了哪一环都不行。就像一条锁链一般，大家都被牵连到一起，每一环都不能断，我们关注每一个里程碑关键节点。 与一手需求方、中间传达方和执行方的再次确认：
爱你们的小胖子。2020年夏。 本文素材来自互联网（编辑：晋中站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
