众所周知，在 IT 公司，不吵架的程序员和产品经理，不是一名合格的程序员和产品经理，不过大部分原因是因为产品经理的不合理需求所引起，例如有这样一个需求：
App 的主题颜色可根据手机壳颜色自动调整
对于这样谜一般的需求，程序员最终按捺不住还是动了手。本以为这仅是一个素来“死对头”即程序员和产品经理之间的一个段子，万万没想到事件得到了进一步的证实。
那么在这些问题暴露的同时，随之而来的就是另一个问题，小公司到底需不需要产品经理？
就在今天早上开例会的时候，老大还在说“就咱们公司这点业务，完全不需要产品经理，凭我们开发的聪明才智，自己去和业务人员确定需求就好了嘛！”
所以，有时候我也在想，产品经理应该怎样和程序员友好地合作呢？
一、提清楚需求，这是最重要的第一步
无论是什么样的程序员，他都希望自己对接的产品经理能够把需求提清楚，我每到一个公司的时候，都会先跟程序员同事确认他们喜欢什么样风格的需求，得到的答复基本都是只需要把需求写明白提清楚就可以了。
所以，产品经理一定要学会把需求提清楚。你可以尝试画高保真原型，把一些比较复杂的交互使用动态效果表现出来，这样做的目的不是为了炫技，而是为了减少不必要的沟通，提高研发效率。要知道，很多时候，产品经理的需求多写一句话，就有可能让程序员少返工一次。
遇到不了解的逻辑怎么办？大胆去问，不要怕程序员认为你不懂技术，也不用担心问他们会丢面子，术业有专攻，你要做的是给出可以执行的需求，如期完成研发工作发版上线，面子什么的不重要，都是自家哥们，何必纠结繁文缛节。
二、技术崇拜，能动手尽量不撕逼
大部分的程序员唯技术论，他们认可一个人的重要指标是这个人的技术能力如何，IT界有一句名言是“Talk is cheap ，show me the code”，大致的意思就是“会说不算什么本事，把你的代码拿给我看看”。
记得当初在一家公司做产品负责人的时候，新来一个安卓程序员，入职第一天就过来跟我们说他来公司不是写代码而是管人的，结果第三天就辞职了，问了个比较熟的程序员哥们，告诉我说这家伙写不出代码，导致组员不服他的管理。所以产品经理们一定要注意一点，就是千万不要炫技。
这一点在那些从程序员转型做产品经理的人身上是最容易出现的问题，程序员转型做产品经理的人有一个最大的优势在于，因为非常清楚代码逻辑，所以在写需求文档的时候，可以很好的写出让程序员容易理解并执行的需求。
但是，这往往也是最容易出现问题的一点，我见过不少程序员转型的产品经理，会经常与研发部门的同事之间因为一个功能的代码应该如何去写而吵得不可开交，其实这是非常不明智的做法。
很多时候，程序员同学选择如何去写代码，并不是受制于本身的技术水平，而是来源于系统架构、业务逻辑与其他系统模块的耦合程度等因素的影响。
既然你选择了产品经理这个岗位，那么就应该把专业的事情交给专业的人去做。你可以提建议，但是不要去教他们怎么写代码。
三、程序员说话直接，也希望你说话直接清楚
沉默寡言是大部分程序员给人的第一印象，但是其实这并不完全正确，很多时候你会发现程序员的沉默寡言只是对你如此，因为他们认为跟你没有什么好说的。
你既不会写代码，也不懂数据库，但是他们在同组之间的话题永远不会少，而沉默寡言也会相应的导致程序员们说话会很直接。
如果当你发现一个程序员同学开始学会跟你讲套路的时候，那么他极有可能已经升级为组长级别了。
大部分的程序员在说话的时候通常不会讲太多废话，因为他们与其浪费那么多时间来说话，倒不如多写几行代码，所以能一句话说完的事情，尽量不要三句话。
在你想要跟程序员沟通一件事情的时候，请先把你想要说的话在脑子里过一遍，抓住重点，理清思路，实在不行，你可以拉住别的同事，跟他说一遍你的想法，看看他能不能快速理解你的意思。只有这样，你才能不引起程序员的厌烦情绪。
四、程序员尊重他人，也希望得到你的尊重
现在越来越多的段子都是在全方位的嘲讽程序员，说什么“找男朋友要找程序员，钱多话少死的早”，什么“程序员没有女朋友，男朋友到是有很多”这类的话。
作为产品经理，这样的段子自己知道就好，不要不适时宜的去拿来跟你的同事们开玩笑。
要知道，你在天马行空设计出好玩、酷炫的功能的时候，是程序员一行一行的写出代码实现的；公司盈利、上市，是程序员熬了无数个通宵创造出来的价值。
拿程序员来进行调侃，实在不是一件多有趣的事情，所以请尊重他们，能闭嘴的时候，尽量不要开口。
五、提出问题之前，请先称赞程序员
很多人都知道，程序员最不喜欢听到的一句话就是“你这个功能有BUG啊”，“你这个功能做得不对”，先不说到底是不是真的有BUG，当你说出这句话的时候，就意味着你完全无视了他们工作的过程，这会让他们本能地产生抵抗的情绪。
虽然程序员不一定是玻璃心，但是人都是习惯于听好话而不喜欢听坏话。所以在你提出你的问题之前，先称赞他们，你可以告诉他们，功能做得挺不错的，但是好像还存在着一些问题。
所以，你也可以告诉他们，代码写得挺快的，但是结果好像跟预期的不一样。你也可以直接让他们来现场操作功能给你看，如果真有BUG，相信他们也一定会发现。
六、如果程序员想多了解业务，花点时间沟通
在我职业生涯里，一直是以怼天怼地怼空气自居，曾经在一家公司撕遍全公司所有组长，却在一次对话中，头一次让我觉得哑口无言。
当时是我在提交了版本需求给研发部们了以后，接着规划下个版本的需求。按照惯例，接手我需求的程序员组长会把根据需求评审会上的内容，将版本功能进行拆分，然后分配到每个组员身上。
其中，PHP的组长在分配完工作以后，就其中的一个功能跟我进行了讨论，大致对话如下：
程序员：这个功能的逻辑感觉有点不太对啊，这样做没问题么？
我：我在评审会上讲清楚了，需求里也写清楚了，你们就按照这个来做就好。
程序员：但是我没见过有这样的做法的，是因为什么原因要这样设计功能呢？
我：因为公司业务要求这样去做，所以你们就按照这个来做就好了。
程序员：那你能跟我讲讲是什么样的业务要求么？
我：你很烦啊，你不要管业务要求是什么，你只要按照需求来写代码就好了。
程序员：你怎么这样呢，我作为程序员，想了解多一点业务，只是怕到时候功能写错了，又要返工，到时候你也会挨骂。你作为产品经理，还不如我一个程序员对业务上心！
当时因为频繁加班，而且拼命赶进度，我的状态并不是很好，所以在跟这位程序员同学沟通的时候，难免有一些不耐烦，原话我不太记得了，但是我承认他在说那句话的时候，我瞬间感觉很难堪，他只不过是对项目负责，对系统负责，而我甚至都不愿意抽点时间来回答他的问题。
所以，自那一次开始，我对于任何一个程序员同事都会或多或少的讲一讲公司的业务模式、业务发展需要，即使是他们不一定能听得进去，或者不一定能够理解的了。但是我相信，会有很多程序员需要对业务有一定的了解。
七、不要只是告诉程序员做什么，还要告诉原因
提需求很简单，但是讲清楚故事就会很难，很多产品经理在提需求的时候，往往会忽略了一件事情，那就是应该要告诉他们为什么要这么做。
特别是在提出临时的紧急需求的时候，为了避免引起不必要的麻烦，你其实是可以好好跟他们沟通的。
你可以告诉他是因为老板临时调整了思路，你已经为他们争取最大程度降低工作量了，希望他们能抽出点时间帮你改一下需求；也可以告诉他们因为运营这个月打算冲一冲注册量，这样一来，这个月的新注册用户数可以破百万，这是产品的非常重要的里程碑时间。
要知道，程序员也是这个团队中的重要参与者，他们是有权力知道项目的所有事情的，虽然很多时候出于岗位职责不同，你往往忽略了这些东西，但是不代表你就可以完全不用告诉他们。
得到他们发起内心的认可，是为对你们的工作有很大的帮助的。
八、聊聊家常，不要刻意得去营造隔阂
见过很多的产品经理，好像生来跟程序员就有仇一样，除了正常提需求、解答问题以外，甚至都不愿意跟他们多说一句话，更不用说聊天了。
要知道，程序员也是人，他们也会有喜怒哀乐，也会经历悲欢离合。你们之间不应该只有工作上的交流，还应该有朋友之间的友情。
我可以清楚的知道研发部门大部分人的籍贯、家庭状况、哪个学校毕业的、有没有结婚、女儿还是儿子等等。
其实，很多时候你会发现，和他们相处，有的时候真的很简单。不要老觉得程序员很沉闷，跟你之间不会有太多的话题可以聊，但是其实他们很多时候也会想要把自己的快乐分享给别人，也会想要找个人来倾诉自己的痛苦。把你们之间的隔阂去掉，拉近点距离。
九、学会承担责任，不要老甩锅
不知道从什么时候开始，教产品经理如何把锅甩到程序员身上成了一种主流论调，居然还会有人写出课程长篇大论的分析应该怎么去甩锅，这是非常可笑的想法。
作为一个产品经理，要先想着承担责任，然后再想甩锅，而不是先想着甩锅，再去承担责任。思想的先后顺序不一样，所造成的影响也是不一样的。
前者是以甩锅为己任，只有当遇到甩不出去的时候，才想着应该要由自己来承担责任了；而后者是以承担责任为目标，只有在必要的时候甩锅给程序员，惩罚不是目的，而是为了避免下次出现同样的问题。
十、你和程序员都该知道彼此的底线在哪
了解并坚守彼此的底线，是与程序员相处时候的关键，你可以告诉他们你可以允许研发进度延期，但是最多能延期多少天。
你也可以告诉他们允许出现BUG，但是在多久的时间内必须解决BUG并发版上线，你也可以尝试去了解他们的底线，彼此保留一点神秘感，不是更好么？
只要你还在做产品经理的一天，你就要学会如何去跟程序员打交道，不要把他们想成是豺狼虎豹，也不要把他们视为洪水猛兽，以平常心来对待，你将会感受到不一样。