程序员对产品经理的说说
1、观察开发人员当前的面部表情，是皱着眉头正一本正经地在撸码，还是面带微笑和周边的人正在聊天，总之，发现他明显处理放松状态的空隙，再去找他
2、产品：可现在这个改法现在出了问题，这块是你做的，你再改一下吧，不然影响上线进度
3、已经和开发说完了本期需求，开发过程中，你由于外部因素或内部因素等原因变更了需求，和负责开发这个功能的同事说的时候
4、纸笔或白板，讨论需求方案过程当中可能随时会用到
5、说明这个需求的紧急性。千万不要以“客户很着急，不做这功能这笔订单就黄了”的负面方式来“威胁”他，而要以正面的方式来鼓励他，比如“这个需求很重要，搞定这个用户你就是大功臣”的方式来鼓励他
6、产品：“啊?这么严重，幸好你提醒了，还是你厉害，你有其它的办法没"
7、这个不易实现，要实现的话有什么不确定因素，要花费多大的成本。可以通过其他可选方法去实现，利害关系，123。 产品上在某些方面这样设计可能会更好，理由，123。
8、产品：“关于XXXX的需求，我这边做了些调整”
9、当用户提出某个需求，业务要求尽快优先完成，经过你的思考，觉得需求合理并可行，可和开发说临时增加这个需求的时候
10、产品经理，你觉得你在程序员眼中是怎样的角色？
11、倾听开发A描述事情经过2）并开发B说明当前情况，倾听开发B描述事情经过，确认开发A是否属实
12、不看文档，或者看了文档不跟产品经理细致沟通，在理解的基础上开发。开发完成才知道完全不是产品经理要的那个样。
13、写个能跑的软件，不能让用户爽，这样的软件又有什么用呢？软件是你派来占用用户机器的CPU和内存的吧？
14、结尾：当然还有其它各种情景，我就不一一举例了。在项目管理里面有一句话概况了核心方法：“为达目的，不择手段”，作为一个产品经理，同样需要做到这8个字。
15、开发前拍胸脯，开发中拍脑袋，开发后拍键盘（砸吧，Bug就是改不完！！！）。
16、要找关系好的开发，要找比较实在不会把一个简单的技术说的很难很复杂来炫技的“傻”开发（爱吹逼的人不在少数，尽量不要找他们。如何找到实在的“傻”开发，只能随缘了，为什么说他傻，因为你已经侵占到他们的业务领地了他还没有警惕，不是傻就是真爱）。
17、切忌不懂装懂：如果有可能要虚心向关系不错的开发请教，不用害羞觉得问了显得自己什么也不懂，其实你一张嘴我们就知道你的水平是什么级别的，没必要隐藏，重点是学知识。
18、接下来给大家分享一下个人“心机”，下面这些问题是经常发生在我们的工作当中的，只需要掌握这五个点：“看听说写问”就可以解决问题
20、产品：这个需求我改了一下，你按新的来做哈
21、这一种可能是最快捷的方式，但也可能最麻烦，我给两点建议助你达到更好的效果。
23、以上仅个人观点，如果不对之处欢迎指出^_^。
24、自产品经理逐渐成为互联网企业标配以来，网上也开始流传着各种产品与开发之间巅峰对决的图片，贴切又形象，这些个梗可以笑个几天几夜了。
25、产品：”会影响你当前现在的工作进度吗？“
26、对比新需求，找出需要推翻老需求的合理的“借口”，用来说服开发
28、做程序员难，做产品经理也难！你怎么看呢？
29、产品经理懂技术好比流氓会武术。这句话知乎上看到，很是到位。产品小伙伴快来学好武术虐开发吧！额...突然觉得我站错边了。
31、产品经理如果一点编程技术不懂，我们这些程序猿只能说一句“宝宝心里苦，但宝宝不说”。因为说了你不懂，不说你又觉得我们不配合工作。就算耐心给你解释了，你还总是摆出一副可别忽悠我不然弄死你的架势。这样就有了交流障碍，工作效率怎么能高。
32、我问一下，你开发的程序是不是一次通过测试，或者干脆不需要测试就发版？
33、不是我为难你，真的是你听不懂“人话”
34、将提前准备好的方案和他讨论（期间可能会用到纸和笔，或者白板），不用理会这个实现方案是否可行，重点是你要有，代表你仔细思考了这个问题，若是明知不可行可能效果更好。
35、产品：”嗯嗯，这个好，这样就不会产生这些问题了，那就按你的想法来弄“
36、开发：”好“（这时候再问开发需要的时间）
37、产品："那我把这次你的需求提测时间往后延一下，先完成这个吧"
38、如果想同事请教无果你就只能自食其力了，看一些技术相关书籍，高效快捷，其实我更推荐这种。
39、但是我相信作为一个有人格魅力的产品经理，一定有方法能轻松化解这些问题，而且会逐渐发现他们的可爱之处并建立天长地久的友谊。
40、适度夸奖：人都是这样的，都很希望得到别人的赞美。你把老师弄舒服了，老师才更卖力的给你讲知识，更别说咱们这种义务教学了。而且开发人员都比较简单没有那么多事，多几句真心的赞美，适度吹捧，要是觉得有收获偶尔请吃顿盖饭足以。
41、出现用户体验的弱智问题就说产品文档没写清楚，先推掉自己的责任。注意：常识！！！没有知识不可怕，可怕的是没有常识。
43、主动承认错误，双方互相尊重，矛盾自然迎刃而解。尤其当内部矛盾产生的时候，一定要尽快解决并处理，否则越积越深，最终可能就会发生“手机壳变色”事件。
44、产品：“我想了个方法，你看这样行不行？（描述你的方法）”
45、看法 写：尊重他人 的 说法，认真记录笔记
46、产品：”那你预计弄这个功能，需要多久时间？“
47、和情景一一样，尽量观察开发人员当前的面部表情，发现他明显处理放松状态的空隙，再去找他
48、产品：“那好，那我就按这样更新下需求文档”
49、产品经理懂技术好比流氓会武术。这句话知乎上看到，很是到位。产品小伙伴快来学好武术虐开发吧！额…突然觉得我站错边了。
50、开发：这个改动很大，我都做了一半了，又得重新来
51、开发A：这个不是我的问题，是XXX当时让我改成这样的
54、引导他的“共情”，让他和你的看法一致，自然就达到目的
57、开发：“这样肯定不行的，这个可能会对系统造成不可磨灭的灾难XXXXXX”
58、PS：你我素昧平生，生活中扮演的角色不同一些观点自然不同，不喜可喷，碰撞才有激情。
59、还有一点最重要就是在开发心情好而且时间空闲的时候去问。
60、若改动较大，则需要提前准备好纸和笔，或白板，则改动小，则不用
61、测试组提个bug给某个开发A，开发认为这个问题是当时另一位开发同事B让他这样改导致的，不愿意修改这个bug。
63、产品：“那我如果改成这样：XXXXXX，，这样这几个问题就不存在了，你看呢？”
64、开发：这样会影响了整个产品现有逻辑，改动太大了，你不懂技术，和你说了，你也不明白
65、说法，认真记录笔记 问：询问他们的建议或意见
66、开发：“有一个办法：（开始描述他的想法）”
67、我们也是人，给我们点“同理心”，好不好？
68、引导他去思考，由他来实现他提出的方法，一切顺理成章、心甘情愿。。。
69、产品：“是这样的，我发现现在的这种方式可能会存在几个问题：1......2......3......，你说是不？”
70、产品：“你说得很对，要不这样，等功能出来之后，提给测试那边验证一下？”
71、提前准备好实现需求的一种或多种方案，无论是否可行
72、开发：“这个可能会影响到之前的XXX功能”