某大公司产品经理被研发人员暴打！是你产品飘了，还是我开发提不动刀了？

吐槽产品经理提需求很随便

开发人员们非常抓狂

但当时都是当作乐趣看看

不会确切的体验去研发人员

与产品经理之间的血海深仇

只知道他们的关系是这样的

还有这样的

最残忍直接是这样的

这些虽然是是网上调侃的趣图

产品与开发

一直都是相爱相杀

大部分的在工作上配合是默契的

但昨天刚发生了一件事

又引发了小伙伴们对

产品与开发的关系

疯狂讨论

产品经理在提需求的时候

根本就没有想过

技术的实现难度吧

默默心疼这个开发人员的同时

大雄竟然觉得有点好笑

程序员们的反应是这样的

在程序猿的眼里

这个需求提得简直是

丧心病狂 无法理解

并且众多网猿都表现出

同仇敌忾 一致对外

的气势

今天大雄就跟大家

聊一聊产品经理

在提需求时是否应该考虑

技术的实现难度

产品经理了解技术，有助于和研发人员沟通。但了解技术后提需求时，会权衡需求和实现难度。有人说产品经理提需求时，只需要考虑用户需求，不应该考虑技术实现难度，这样做是否正确？

有不少互联网PM经理

针对这个问题给了的答案

让我们一起来看看大佬们都是怎么说的吧

1

支持率最高的，认可度103：0

回答来自PMCAFF社区PM 广州林更新

从本质上来说，没有实现不了的需求，只是实现的代价有多大，价值高不高，打开需求的姿势对不对。

这个问题要从几个方面看：

1、从产品本身来看需要你确定这个需求的价值，可以从KANO模型，ROI投资回报率上来对需求重要性排序，优先做有价值的东西，时间来不来的及。

2、确定了价值，下面就是需求实现的问题，一般来说需求是有多种实现方式的。不仅仅是技术上的，还有其他表现形式上的。

打个比方，用户说要可乐，基本的需求是因为渴了，而你如果提供矿泉水其实一样能解决问题，这个需要你从本质上理解用户需求；

技术上，实现一个功能，可能写一个工厂方法就可以简化很多事情，而开发也可以己脑洞大开过度设计（这种对于入门没多久又有理想的程序员是比较常见的）。

这个在提需求的时候，提给开发的需求更应该说用户story，而不是描述解决方案：规定好他应该怎么做。同时尽量找开发领导提前沟通需求，这样有可能他会给你一种更加好的实现方案。

3、最后就是努力充实自己，面向对象的编程思维可以多了解了解。产品经理的UML工具其实就是面向对象的思考方式，你可以不用管这个方法具体是通过写了多少行代码实现的，只需要想通中间的逻辑是怎样的即可。

这样又可以反过来促进你了解：你的设计中有没有遗漏什么，下一版功能可以往哪拓展；从整体逻辑的复杂性推算功能的实现时间，对整体开发时间的估算越来越有把握，避免被开发忽悠。

2

认可度92：1

回答来自PMCAFF社区PM 布玛

沟通这个话题永远都聊不完，我见过专业能力不怎么样但是沟通能力强情商高的产品经理在职场上顺风顺水，却从来没有见过不会“说话”不懂人情世故的产品经理能在职场上顺利的。

所以现在抛开流程，机制等等不讲，谈下个人，产品经理的基础素养里面，数据分析，UED这些应该逐渐成为基本技能，说服不了开发和设计的原因不在流程，而在个人。

在假设大家都是做事情的基础上，有以下几点可以办：

1、用数据说话

这次的优化改进预期能带来多少的提升，上次的改进效果如何如何，这些是数据和预估。任何一个做事的人都必须正视数据，是数据反映这个改进有没有作用。当然，预估要准确。

2、尝试用户的视角来看优化

技术，开发在这个产品上有双重身份，一方面是开发者，要评估实现方式，实现成本，开发周期，另一方面是用户，因为这个用户比较“专业”，所以有时会丧失细节，毕竟开发者是按照自己的偏好来看产品的。

尝试从这两个角度来看问题，然后给对方一个理由。是否是成本不可行，还是因为对方在用户视角里面考虑了自己，而没考虑大部分用户？如果是，说出理由，证据。

3、冷静想清楚自己的建议是否是用户的诉求

是否也因为自己的偏好而去改产品，有没有基于用户视角，CE，UED，数据，技术等多角度的思量？

将以上的这三点思考一下，在沟通之前做好被拒绝的准备，心态好一点耐心一点，正常的话整个推动过程是顺利的。如果做到三点研发还是拒绝说实现不了，那么就跟CTO或者CEO沟通吧， 让他们来决策。

3

认可度85：3

回答来自PMCAFF社区PM 楠色天空

你认为简单的开发起来并不简单，你认为很难实现比较复杂的对于技术来说也许并不复杂，关于需求是否合理，是否具有开发性，需要多方面的评估.

1、需求来源

如果是已有产品的功能更新，用户习惯性问题想更改使用流程，这部分需求提都不要提，相当于是否认开发前期的成果；

如果是功能优化，用户的使用反馈和建议等方面的数据委婉的告诉开发，这种方式忽然好，但是用户达不到这个水平，如果以一种更简单的方式会更容易接受；

2、需求的市场调研

有一些系统性的产品开发，有很多细节的问题大同小异，其实用户既然提出这个需求说明是见过别人有，而且初步认可了这个功能；有些小而精，有些大而全，如果需求的实现结果一致的话，开发那边不会轻易的改变实现的方式；

3、需求的使用

有些功能隐秘性比较强，有些用户不易轻易发现，而且这个功能又是一个亮点；开发一般会把普遍使用的基础性功能放在显眼的地方，个人小小的创意性功能由于位置有限会隐藏起来，而一旦用户发现认可并强烈需求时，可以向开发提出改进的方案；

4、需求的合理性

需求是否合理，且技术上是否可以实现，一般开发工作量比较大，且手头项目都不止一个，时间上面比较紧迫！有些需求异想天开的话，开发几乎都不愿意去了解，所以需求的评估和过滤还是非常重要的！

点评

产品经理在提需求的时候

得站在程序员的角度

他是你的第一个用户

同时

产品经理要充实自己

了解技术

提出更好的需求