|需求评审你会了么？这里有一个标准的失败案例
作为一个产品经理 ， 提需求是家常便饭的事情 。 但是 ， 如何跟别的部门沟通是个大问题 。 本文作者基于自己的亲身经历 ， 进行了三个角度的分析 ， 希望对你有帮助 。
本文插图
一、南南南：细数提一个需求需要跪舔几个部门几多人
今天小胖讲一个别人的故事 ， 怎么样的需求会把一个工作群从开始的5个人最后拉到了22个人？
是需求特别大么？是需求特别重要么？是需求特别复杂么？
不太是（产品经理谨慎的用词赶脚）……
事情是这样的：上周有一个活动需求 ， 对接的产品同学想在APP的页面增加一个任务广场 ， 用户完成任务后就可以愉快地抽奖了 。
到现在为止 ， 是不是觉着这个需求特简单 ， 1天开发够不够 ， 不够就加多2天 ， 3天足够了！
我估计这个产品同学应该当时就是这么想的 ， 当然表述上是产品经理们经常听到的贯口儿：“这个需求很简单鸭 ， 领导很关注鸭 ， 下周能不能上线呢？”
但是 ， 作为需求承接的一个小部分 ， 咱们就只能听着、认着、惯着……
Round 1 ：周一第1次需求评审
产品同学愉快地把相关方叫了来 ， 感觉组织评审、开会——这才是头等大事儿！
需求以迅雷不及掩耳之铃儿响叮当之势讲完了 ， 开始技术大大也觉着好简单鸭（产品同学此时一定乐开了花 ， 如果能够预料到后续的菊花生疼 ， 他一定笑不出来） 。
等闲平地起惊雷 。
是的 ， 你没有听错 ， 交互小姐姐有意见啦：“你这个原型太简单了 ， 好多交互都没有 ， 这样评估的工作量是不准确的！” 作为乖巧的产品狗 ， 此时肯定是满脸堆笑 ， 道：“马上补 ， 咱们先评审” 。
这时候你猜技术小伙伴会怎么想 ， 果然技术小哥哥说话了：“这个没法评估鸭 ， 什么时候可以先出交互再看看” 。
Round 2 ：周四第2次需求评审
大家又被叫到了一起 ， 大公司么 ， 会议不多是不可能的 。
我想这次产品同学是带着万全之策来的 ， 果然 ， 整个需求讲述过程行云流水、快马加鞭、江河泛滥而一发不可收拾 。
对了 ， 各位一定想知道这次参与会议的人是不是有变化呢？
恭喜你都会抢答了 ， 这次不但来了前端开发、交互、产品、后台开发；没错 ， 还来了云端开发、活动开发、插件开发（谁让咱们家的APP复杂呢） ， 工作群的人数激增 。
欢乐的日子总是那么短暂 。
就在大家准备举杯相庆、策马奔腾的时候 ， 突然有人gang（讲）：“是不是品质没有来？”对头 ， 品质就是测试同学的意思 。
赶紧群里继续拉人鸭 ， 不管怎样先盘他！
你想想 ， 你如果突然被人拉到一个群里 ， 然后告诉你有一个需求排期定了 ， 需求我再单独给测试讲讲就好吧？好你个头 ！
测试小姐姐当然是不答应的 ， 让我 ， 我我我……我也不答应！
Round 3 ：周五第3次需求评审
就像那部有名的电影一样：一个都不能少 。
这次评审没有问题 ， 但是问题出在评审前：尼玛这样一个不是那么大的需求 ， 每个人都只是占了一丢丢工作量的需求 ， 你让我评审三遍？！并且按照前几次的体验来讲 ， 有第三遍 ， 是不是还有第四遍 ， 我们是不是不要做其他事情了呢？
许多人这个时候不免都会问这个问题 。
怎么办？当然只有产品gg跪下 ， 跪舔大佬们再拨冗参加一下最最最后一次评审 。
【|需求评审你会了么？这里有一个标准的失败案例】 二、产品经理战地日记总结
先说基本问题 。 这是在一个大公司普遍存在的沟通和协同问题 ， 也是一个产品成长到比较大的时候会遇到的一个痛点：模块细分 ， 各模块不说各自为政吧 ， 但是按照“流程”来办事儿 ， 不免让人有些蛋疼 。
推荐阅读
- 行业互联网|苹果向三星支付9.5亿美元罚款 因iPhone屏需求量不够
- 需求|营销谎言：“马斯洛需求”其实不是金字塔
- 科技小数据|希捷发布Nytro 3032/1360系列企业级SSD 充分满足各场景使用需求
- |对数据安全的需求将造就新一代安全储存架构
- 阿里|饿了么全面改版解决即时需求 与美团“狭路”相逢
- 需求|小身材大能量，Anker充电套装承包你所有充电需求
- |如何让PM完成需求评审而不被打？
- 人人都是产品经理|如何让PM完成需求评审而不被打？
- AMD|索尼再下订单 扩大 PS5 产量满足需求
- |疫情导致娱乐需求增长 索尼或将PS5产量提升至1000万台