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