一、产品经理和程序员最讨厌的三句话
产品经理和程序员就像一对恋人，若即若离，有时还会撕破脸皮。和的时候一切都好，撕的时候都输。
你知道程序员最讨厌的三句话是什么吗？
1，这个要求很简单，改一下就行了。
2、你大概先弄一个，我看看。
3.我先下班了。走吧。
我想任何一个程序员听到这样的话都会怒不可遏。不撕才奇怪。作为程序员你会怎么回答这三句话？
1，这个要求简单？你能做到的。加油！
2.或许先买一个？请问先生(女士)，大概是多少？
3，你叔叔的
你知道产品经理最讨厌什么吗？
1，这个需求做不到。
2.这个需求太重了，估计要三个月。
3.我没时间做这个改变。以后再安排吧。
产品经理在前端，有用户，有老板，有销售，版本发布压力很大。听到这个估计心情也好不到哪里去。
1，这个需求做不到？我没提，那个2B用户也没提。
2.需要这么久吗？养你有什么用？我还不如自己做。
3.没时间做改变？管他呢，等老板拍你。
二、产品经理和程序员的本质区别是什么？
爸爸做过程序员和产品经理，知道这两种工作的区别，各有各的难处。
一般来说，做产品更注重创意和方案能力，不需要精确的逻辑，所以试错成本比较低，换个原型和方案也实惠。
程序员的工作是非常精确的逻辑。一个看似很小的改动，可能会对代码产生很大的影响，所以试错的成本很高。如果做不好，可能会因为需求的变化导致系统的重新配置。这时候程序员的挫败感可想而知。
第三，产品经理和程序员的友好关系列表
1.产品经理收集完需求后，在需求分析阶段，就要尽量去掉一些不合理的需求，与用户沟通，避免不合理的需求造成产品发布的延迟和不必要的成本浪费。当然，这需要产品经理去说服用户，而不仅仅是做用户的传声筒。
2.产品经理在分析需求时，要根据自己的经验，敏锐地发现一些技术层面难以实现的需求，让R&D及时介入，评估技术可行性，避免后续出现需求固定，R&D说做不了的情况。
当然，这需要我们的产品经理对软件技术架构有一定的了解和预测能力。你不可能在需求分析阶段就让R&D参与所有的需求，成本也是极高的，所以把握这个度也是一种能力。
3.原型是沟通需求的最好方式，是避免产品和研发在需求理解上产生差异的最好方式，仅仅写一些书面的需求规格说明很难取得好的效果。
但是需要注意的是，产品经理画出来的原型，为了更好的沟通需求，一般都是非高保真的原型，所以不能完全按照原型来做，需要基于我们自己的前端架构来定制。
4.在需求评审期间，R&D可能会有一些不同的意见。经过多年的发展，他们会有很多好的经验。好的经验要虚心接受。你不能认为你是产品的老大，就按我说的做。这样就容易产生矛盾，求同存异，殊途同归。这是最好的结果。
5.当R&D说这个要求不能实现时，有两种情况。一个是实现这个需求比较麻烦，故意骗你；还有一种情况是他的知识盲区，他可能真的不知道自己能不能做到。
产品经理需要能够与R&D协商，比如采用类比(我们在其他项目上也做过类似的需求)，比如去找架构师讨论技术可行性。
6.R&D有时涉及大量的工作，整个网上计划需要很长时间。产品经理可以要求提供资源分配的详细列表，这样我们就可以清楚地看到一个需求被分解成多少个R&D任务，以及谁负责每个任务的开始和结束时间。这样产品经理大概就能看出任务的前后关系是否合理。工作量是否合理等。
产品经理绝对不能说，把它做得这么简单，要花这么长时间。如果出了这样的事，肯定会激怒对方，还是要在理智的基础上协商。
如果实在无法减少工作量，如果增加人力可以解决问题，可以考虑向领导申请资源。如果还是不行，就要削减需求或者改变计划。
7.当版本计划确定后，尽量不要添加需求，这样容易打乱开发的节奏。如果一定要加，一定要跟研发说清楚，这是用户领导或者老板转移矛盾的强制性要求。如果可能，增加需求，尽可能推迟上线计划。
8.如果在开发过程中需求发生了变化，需要及时更新需求文档并发送给我们的R&D同学。否则，R&D的同事们很可能不会这样做，因此必须把它写在纸上。
9.上线时坚持和R&D同事一起加班，让大家都是一个团队，一起赢，一起输。
10，最后一点就是多沟通。没有一顿火锅解决不了的问题。大家关系都很好。很多事情自然就容易沟通了，他们也会更加信任对方，所以一切都会好的。