程序员和产品经理实在是一对冤家，有私交很好的程序员和产品经理，但是没有在工作中不起争执的程序员和产品经理。那么程序员为什么和产品经理“干架”呢？

为了深入了解“程序员与产品经理干架的前因后果”在粉丝群里发起了话题讨论，且看他们是因何干架的吧。。。

想静静看着程序员与产品经理怎样厮杀……

烛光晚餐引起的群殴事件

临时晚餐阻止产品汪的絮叨

产品：what are you 弄啥嘞？来需求了，我觉得这个功能不错，把这个功能加上。

程序猿：....

产品：这个什么时候能做好？要尽快

程序猿：....

产品：今天下班前能做好不？不行啊，那明天中午之前做好。

程序猿：....（苦逼加班加点中）....

产品：上次那个功能需要改一改，这样...这样...这样会更好。

程序猿：.....xxxx.....

产品：那个功能好像反响不是多么好，我重新做了个功能原型，把这个实现下，要尽快。

程序猿：....（一脸嫌弃中）....

产品：哎呀，为了更好的用户体验，我在那基础上添加了些东西，这个不错，肯定会吸引更多用户，巴拉巴拉小魔仙中....

程序猿：....（-_-）....

产品：我想到一个不错的功能，这个挺炫酷的，一定会吸引更过用户。我给你讲讲这个功能，来把这个实现下，要尽快。

程序猿：....（默默忍受了不少唾沫星子>-_-<）....这个实现不了，从技术层面难度很大，这么短时间不好实现...

产品：这不就是一个简单的功能麽，这么...这么...不就行了...

程序猿：....（不懂不要瞎BB... -_-...依旧苦逼加班加点研究怎么实现中）.....

产品：上次那个功能不是说很难麽，不是也搞出来了。效果还不错啊。

程序猿：...（what is the fuxk，老子可是拼了命的在搞，没日没夜）..

产品：看到别的应用有一个不错的功能，我画了一个功能原型，需要实现下，这个可以不那么急的。

程序猿：.......，呵呵呵，好的。要不，晚上吃饭一起？我请客，我们好久都没聊聊了，（得需要给这家伙加点buff）

产品：好啊，晚上走了我喊你。

.....

程序猿：世界一片清净了，真好！

.....

据理力争，武力抗衡

领导参与，却也输于“性别差异”

技术和产品开撕的根源

冲突的根源：产品经理和“老板们”关起门来开了个会，赶出原型和UI图，之后交给程序员们的就是“圣旨”，“反正我们就这么定了，你照着开发吧。

和平共处很难么

先看下面的一张图片，我想大家都明白其中的意思。

01、产品需求经常变动

由于产品经理经常改动需求，导致程序员不得不把做好的东西重新再做，结果可想而知。有的时候程序员加班加点刚做完的东西，被产品经理一句话给推翻了，说需求变动了，不能这么做。严重的时候连核心模块都完全大变样。就一直这样改完做，做完改，无限循环下去。这个小编我可是深有体会。

02、产品经理对程序员的不理解

遇到一个懂技术的产品经理不容易。程序员经常听到的一句话就是，"这么简单的功能为什么要这么长时间？"这样的话令很多程序员恼火，是最能激发与产品经理矛盾的导火索。

03、程序员处在软件开发流程的最底层

看一下下面的图片，是大多数公司标准的软件开发流程。

从图中我们可以看出，产品经理可以直接跟客户讨论需要，而程序员处于流程的最底端。我们都知道，如果流程越复杂越不容易传达，对于需求的理解，最后传递到程序员这里，有可能就变了味道。如果产品经理把握不好，可能最终结果跟客户想要的完全不一样。

有的产品经理技术上和项目管理上的不专业，对产品需求的理解不深刻，随意改动需求，导致程序员的怨念值再一次上升。

换一句话说，程序员处于流程的底层，只是执行者，产品经理怎么传达就怎么执行，完全没有主动权，这也是导致需求改动的一个原因。比较聪明的公司的做法是，在产品需求会议上，允许程序员参加并发表意见，这样可以从技术的角度及早发现产品功能中存在的问题，从而避免后期需求的频繁改动。

在此也给产品经理们提点建议：

• 对需求要详细理解，不能一知半解就把需求交给开发；

• 懂点技术，懂得怎样与程序员沟通；

• 学会体谅程序员，尊重程序员的工作成果。

给程序员的建议：

• 做好需求更改的准备，提高代码的扩展性和可维护性；

• 预留出修改bug和需求的时间；

• 对需求理解透彻再开始写代码；

• 代码不要写死，防止需求变动。

未经允许请勿转载：程序喵 » 程序猿与产品经理干架的前因后果