作为产品经理最亲密的战友，经常会有程序员找产品经理要求改需求。一般来说都还好，如果是真的不能改，这种情况，如何应对更好呢？

各位小伙伴们！你们有没有碰到过这种情况？

产品研发过程中，那些聪明的研发或测试小伙伴总是来找你聊需求，哪怕你已经把需求写得跟字典一样清楚，他们还是会“孜孜不倦”地试图说服你改一改。

这时候呢，我发现有些产品经理特别“硬气”，他们会说：“我就按这需求来，出了问题我扛着谁叫我是产品经理。

有些产品经理就稍显弱势，只要研发能安心把活干完，你说怎么改就怎么改。

说到这，大家可能都有点儿迷茫了，这改还是不改，到底应该怎么办呢？

是硬刚到底，还是随他去吧？

其实啊，这两种方式都不太对。

单纯以产品经理的身份去拒绝，或者为了讨好研发而随意改动需求，都不是解决问题的最佳途径。

接下来，我就给大家来分享下关于这个问题的应对策略。

一、研发为什么会找你改需求？

1. 需求设计不合理，存在逻辑实现上的漏洞

对于研发人员而言，一个需求写的好不好，不是去评判对于用户好不好用，而是去研究你写的产品需求文档逻辑上是否严谨。

只要你的原型在逻辑上把该考虑到的都设计出来了，把可能存在的情况都写的清楚了，那研发人员可就挑不出毛病来了，只能乖乖按照你的需求来。

研发人员经常喜欢diss产品经理的是，你设计的这个功能不合理，存在哪些方面的情况没有考虑到。

导致他们写代码的时候，就碰到了一些“坑”，不知道咋处理，逻辑上有点漏洞，代码就写不下去了，写出来也跑不通。

有些测试人员就更喜欢去做这种从需求中“找bug”的游戏了，一旦发现你的需求文档有啥遗漏，，那就得揪着你说道一通。

甚至得把你喊到他坐位边上去，训仔似的教你怎么“写需求”。

然后，把你列入需求文档不严谨的重点关注对象之一，逮着机会就喊你过去，这滋味，真是“酸爽‘啊！（产品经理咋个牛逼，还不是被老子呼来唤去）。

同时，他已经处理占据了有利的位置，会盯着、催着、吵着你赶紧把需求文档完善掉。

催人改东西，和从东西里面找问题，这是测试人员最擅长的两项基本功。

所以，一旦你写的需求文档逻辑上存在问题，就等着被研发和测试来回diss！

2. 功能设计太复杂，实现起来技术难度太大

我们在进行需求评审的时候，研发人员可不是在欣赏你的产品设计设计的多牛逼，他们可是拿着放大镜在找“坑”。

心里盘算嘀咕着：这个功能要弄起来，得新建多少张表格啊？数据要从哪里来？要不要单独跑个任务？跟现有的功能会不会打架？还有哪里没考虑到？逻辑上能不能通？

一通分析下来，大概就知道接下来的一段时间的“砖”好不好搬，烫不烫手。

要是你是一个还算比较好说话，或者经验尚浅容易被说服的产品经理，大概率研发会来找你沟通一下，建议你需求不要这样做设计，可以简单一点，整那么复杂干什么，研发起来多费劲。

我在刚开始做产品经理的那几年，每次设计的需求逻辑规则复杂一点，就会听到研发总监的那句经典语录：“这样设计做不了，要这样做的话，我的整个架构都要改。”

一开始我是迫于人家是总监的岗位不好顶嘴，在评审结束之后立马就去调整需求，但在心里还是会鄙视一番“不就是技术水平不行，瞎逼逼那么多干嘛！”。

后来工作经验多了，和研发也打了几百回交道了。才明白过来，只要稍微复杂一点的功能，“改动太大，做不了”这句话就会伴随着出现。

不是做不了，而是不想做。

当然啦，还有一种情况，研发小伙伴的能力确实不足，把自己的毕生所学都用上了，还是没有办法解决。怎么办，只能两手一摊，凉拌。

告诉产品经理：“我尽力了，但真的做不了。”然后让产品经理想办法，调整需求了。

3. 项目工时太紧张，找产品改需求碰碰运气

每一个项目都有上线的时间要求，就像有个“小闹钟”在耳边嘀嗒嘀嗒地响，项目经理很多时候都是把“赶工”两个字时刻挂在嘴边，鞭策大家抓紧时间干活。

这样带来的一个问题就是，在限定的时间内，研发人员有时候真的是没有思路，如何去实现这个产品功能？

如果想技术实现方式花了一天的时间，那周末可得加一天的班把进度补回来啊！

这种情况下，能不加班那是铁定不加班，人本能的会想着能不能找产品经理这个“甲方”商量下，毕竟是为产品经理做产品（99%的研发都是这种想法，除了不写代码的研发经理）。

只要产品经理同意，自己不就不用加班，何必去绞尽脑汁想解决办法呢？费那个脑子干嘛！

4. 需求性价比太低，做出来没啥价值不划算

研发人员可不是那种“你说啥我做啥”的“机械工人”哦！他们也有自己的工作热情、成就感和小骄傲。

有些功能在他们看来，如果做起来觉得没有什么价值，就会产生抵触心理。

本着为自己工作贴金和为公司节省资源的角度考虑，和你沟通需求的价值问题，这是一种非常合理的心态。

特别是有些功能做起来实现的技术难度太大，需要投入的时间比较多，并且还有一定的风险做不出来。

在他看来做这个功能价值就不大，就会盘算做出来划不划算的问题，也得考虑下保住个人工作饭碗的问题。

二、应对需求改动的四个妙招

1. 化身用户去思考这个需求要不要

往往很多对用户比较友好，产品使用起来比较简单、便捷、智能的功能，其背后实现的逻辑都会比较复杂。

这时候，你的站位就很重要了！

如果你化身成用户，想想这个功能是不是真的很方便、很实用，那么你就会坚定地支持它，哪怕研发小伙伴觉得这是苦活累活。

但如果你站在研发的角度，想着“打工的何必为难打工的”，那你可能就会被研发小伙伴说服，然后妥协一下，调整需求。

一个优秀的产品经理，一定是代表用户来发声，站在用户的角度去设计产品的。

面临研发人员找你沟通需求调整的时候，一个万能的回答方式是“用户说要这么做的”。不要“你觉得”，也不要“我觉得”，只要“用户说的”。

2.坚信一点：99%技术问题都有办法解决

当研发人员告诉你某个需求从技术上搞不定，别慌！咱们来分情况聊聊：

1）现有技术可以实现，只是方法没有找到

有时候，研发人员觉得某个功能难搞，可能是因为他们还没找到正确的技术路径。

这时候，咱们产品经理就要发挥“指路明灯”的作用啦！让研发说说他们的想法，咱们一起找找逻辑上有没有问题。

要知道，解决问题的方法从来都不是“华山一条路”，不一定要在一条道上走到黑，此路不通就换一个角度，换一条道路去试试。

2）现有技术实现不了，需要用新技术解决

要是现有技术真的搞不定，那就得考虑引入新技术了。

比如我们要做一个3D地图，没第三方接口就做不了。这时候就得去找找外部资源，让他们来帮个忙。虽然多了一道工序，但总比放弃强吧！

3）需求实现改动太大，得改现有技术框架

有时候，为了满足某个需求，可能需要改动现有的技术框架。

比如，在一个用FastAdmin框架开发的中台系统里加视频和动画效果，可能就得换个前后端分离的框架。这时候，就得和研发一起商量下，怎么调整需求才能尽可能少地改动框架。

当然，要判断一个功能到底技术上能不能实现，产品经理也得懂点技术知识。要不自己也是两眼一抹黑，脑子一团浆糊，那怎么去和研发沟通技术上如何实现。

3. 时间问题多半是分工或能力问题

时间问题导致的研发希望需求调整，主要涉及到两个方面：

1）本身有别的项目在身，新需求上线时间撞车了

这种情况，咱们在产品需求评审前就得摸清底细，看看研发人员手头是不是已经有一大堆事儿了。

如果这项目非得这哥们儿参与不可，那咱们就得调整项目排期或者重新排序功能优先级，而不是简单地调整需求。

2）需求要求的时间太短，个人技术能力上做不到

咱们在做项目时间评估时，通常就是按人天来粗略算的，但往往没考虑到每个人的能力水平。同样是做一个功能，高手可能两小时就搞定了，而新手可能得花上两天时间。

所以，这种情况下，就需要合理分配项目的人员，进行研发能力的均衡搭配。

有些产品经理可能会觉得，这些问题都是研发总监和产品总监该操心的，跟自己没关系。

千万别这么想！产品经理对产品可是负有“终极责任”的，从研发、销售到交付，每一个环节都跟你有关。产品就像你的孩子一样，怎么能做这么不负责任的爸爸呢？

4. 有没有说出需求价值背后的故事

产品经理对于需求的收集大多是直面客户的，可以通过客户的言谈举止感受到该需求的强烈程度。

可研发的小伙伴们，他们就只能看你们写的需求文档，想象你们描述的“战场画面”，这可就容易产生误会和偏差了。

有时候，你觉得对客户超有价值的功能，可能在文档里没写清楚，研发就一头雾水，完全get不到点。

这时候，产品经理们，你们那口才可得派上用场了！从业务场景、用户、价值等方面，给研发小伙伴们好好讲讲。

他们不像产品经理，接触不到客户，不需要调研市场，很多时候他们也不了解业务，理解能力也稍弱一丢丢，角度跟你不一致，需要多解释几遍才行。

实在不行，那就在调研阶段，直接把研发人员拉过来，让他们一起听听客户怎么说。这样一来，他们就能“身临其境”，更容易“感同身受”了。

当然，要是这个功能背后的客户故事你自己都讲不出来，需求是自己意淫出来的，自认为对客户有价值。

这种情况下，还是趁早改掉吧，研发的资源也很宝贵，经不起大家去实践一些不着边际的想法。

三、最后的话

在产品制作的过程中，难免会有各种声音，有人夸，有人骂，有人给你出主意。

但别忘了，你是产品的“亲爹”，你代表了“客户”的心声。

所以，当各种声音纷至沓来时，你得坚定信念，保持清醒的头脑，做出最明智的决策。

毕竟，你是这个产品小宝贝的“守护神”，得让他茁壮成长，不是吗？