致血气方刚的产品经理：如何不被程序员嫌弃
如何做一个让程序猿讨厌的产品经理
可能对方会说——很多事情，在开始的时候是谁也不知道的，应该大家在一条船上同舟共济，这就是“接力跑”和“踢足球”在交棒/传球之后的区别。
你可以回：我不管我不管我不管；实施过程中【做了一半改需求】，scrum里的表现就是sprint内的「非受迫需求变更」，太狠了，技术同学肯定很难忍受，特别是产品经理自己没想清楚，而导致的劳动浪费，俗话说“没有变更就没有伤害”，碰到性子烈的就直接要干架了，汪们，这时候要注意保护自己；【开发过程中消失】，你可以多安排点出差、多开开会，注意尽量手机关机，不要响应技术的问题，要不然，责任就回来了。
让他们为了进度照着自己的想法做下去，关键是，验收的时候跳出来说“这不是我要的”，再次，注意人身安全；【过度关注实现细节】，帮技术决定技术方案，也是技术出身的产品经理应该很容易做到这点，变着法儿的越俎代庖，把他们全部从积极主动小伙子，打击成一个纯打工形态的「资源」，哎，又用这个厉害的词了；产品发布之后【发布后没有反馈】，技术人员也需要从市场、用户那里获得反馈，从而知道自己做的事情产生了价值，提升成就感，我们要做的就是，做完发布，马上石沉大海，不告诉大家任何结果，甚至庆功会都忘了他们，紧接着赶紧继续安排他们干活；【无节奏感】，让技术人员忙一阵闲一阵，发布之后再忙着研究接下来做什么，一会儿让技术人员有着干死干活的高强度，我就是要结果，deadline，死命令，之后突然不知道做什么——你们也一起来讨论下业务吧，或者培训培训做做团建什么的；全过程都可以做的【优柔寡断无决断】，能表现出这个品质就最棒了，就是在已经讨论完毕后，大家都等着你拍板的时候“你说吧，往哪儿走我们就跟着办”，这时候你说“啊，那个，各种方案各有利弊啊，我也不知道怎么办啊，你们有什么好想法……”；【报喜不报忧】，藏着掖着一些信息，比如“老板在考虑干掉这个项目”这类信息，表面打死不承认，但让大家通过其他途径知道，很容易就把互信完全打破，这时候他们可讨厌你了；【不要把他们当人】，这点，最狠了，不关注成长，只关注结果，不能再说了，我们只是要做一个程序猿讨厌的产品经理，不是要做一个被砍死的产品经理……还有啥招，欢迎补充。
产品经理吐槽开发的话术
产品经理吐槽开发的话术1.虽然我提供了清晰的需求文档，但是开发人员总是不明白我的意思。
2.我已经反复强调过这个功能的重要性，为什么开发人员还是不重视？3.开发人员总是拖延完成时间，是不是不想尽快交付产品？4.每次跟开发人员沟通都感觉像在说天书，他们的话术太专业了让我晕头转向。
5.开发人员为什么总是忽略用户的真实需求，照搬规范？6.开发人员对于产品的创新想法总是持怀疑态度，太保守了。
7.让开发人员理解一个简单的设计改动都需要费尽口舌，真是累死人。
8.我提供的界面设计稿明明很清楚，为什么开发人员总是无法按照要求实现？9.开发人员总是不愿意尝试新技术，一直停留在过去的开发框架上。
10.产品经理和开发人员的语言总是不通，每次沟通都需要翻译才能明白对方的意思。
11.开发人员总是强调技术难度，而不是思考如何解决用户问题。
12.每次产品迭代都需要进行大量的修改，在开发人员眼里简直就是一场灾难。
13.开发人员不理解产品的商业逻辑，总是只关注代码是否符合标准。
14.开发人员总是偷懒，不愿意进行足够的代码测试，导致线上出现频繁的bug。
15.开发人员一点都不关心用户体验，只关心技术实现的细节。
16.开发人员总是追求技术的纯粹性，而不注重产品的实际效果。
17.每次开发人员都喜欢提出各种冷门技术方案，而不是注重产品的实用性。
18.开发人员总是喜欢抱怨需求变更，却不思考如何更好地适应变化。
19.开发人员总是把问题归咎于产品经理，却不检视自己的开发流程是否有问题。
20.开发人员总是找借口推诿责任，不愿意主动解决问题。
21.开发人员对于产品定位和市场趋势的理解总是片面而模糊。
22.开发人员总是拒绝参与用户交流和产品测试，导致产品质量难以保证。
23.开发人员总是过分追求代码的优雅性，而忽视了产品的实用性。
24.开发人员经常抱怨需求变更频繁，却不愿意去理解背后的用户需求变化。
25.开发人员总是只看到眼前的技术难题，却不思考如何更好地解决用户问题。
产品经理应该如何与程序员打交道
产品经理应该如何与程序员打交道产品经理与程序员之间的矛盾冲突，并不特殊，它是一个系统性风险问题。
那么，产品经理应该如何与程序员打交道？与程序员打交道，是产品经理的日常工作之一。
从网上流传的各种商品轶事与技术起冲突的段子可以看出，产品经理与程序员之间的关系，总的来说，并不十分融洽。
我相信，有相当多的同行朋友，都为之苦恼过，我也不例外。
这几年下来，被程序员怼得多了，渐渐地也就变得波澜不惊了。
虽然技术对产品有诸多不满，产品也对控制技术有各种意见，但是，这里我并不想回来大书特书双方的矛盾。
在讨论“如何与程序员打交道”之前，我想先对这种矛盾定个调。
我认为，产品经理经理与程序员之间的矛盾冲突，并不特殊。
如果关注设计师圈子，你会发现，甲方与设计师相互之间，也有类似的“恩怨情仇”。
其实，在任何协作网络中，处于对接工作的上游和下游之间，普遍存在类似的矛盾关系紧张。
它是一个系统性症结，贴切地将之归因为某些人的某些错误，是一种思想上的懒惰。
从某种程度上讲，我们无需过度关注与程序员的矛盾，等闲视之，做好自己的工作即可。
产品销售经理的工作是围绕着“需求”进行的。
在与技术部门负责人进行对接时，产品经理需要关注的，始终是“需求”。
产品明星很容易在这上面可能犯错。
因为外界夸大歪曲了产品与技术之间的矛盾，导致产品会不自觉地把自己工作的重心，放在“不惹程序员生气”上面。
在与程序员打交道的过程中，为了避免被怼，过度关注脚本语言的情绪，想方设法地“讨好”程序员，与程序员“交朋友”。
而另一方面，却忽视了“需求”，导致融资需求传达得不清不楚。
这其实是不专业的表现，在与技术部门对接时，我认为，产品总经理的核心任务，是“及时准确地阐明需求”。
这里面有3个要点：2.1 核心目的是传达“需求”目标是什么，要实现什么效果，产品经理需要将这些“需求”传达给技术部门。
这里面容易犯错误的错误是，混淆了“需求”与“技术实现方案”。
比如说：我要做一个“统计订单总数”的功能。
产品经理们,坐冷板凳怎么办？
作为中国产品经理最多的社区，不在上面回答过个赞同过百的问题，是很过意不去的。
另外，通过回答别人的问题的同事也可以审视自己的问题，通过看别人的答案也可以看到自己的视野的狭隘
四、多研究公司的其他产品
说不定哪天就要接手公司的其他产品，在坐冷板凳的时候，可以静下心来研究下产品，资源都是现有的，可以将自己的想法和其他同事进行交流，这其中也是很好的积累。
五、不要忘记自己的产品
产品的后期，或许公司不会投入再多的资源，但是如果产品还在，用户还在，就还是有可以进步的空间，有资源就有用资源的做法，没有资源就有没有资源的的做法，不是么？甚至在现有产品的基础上迭代出新的产品让老板看到希望也是有可能的。
六、尝试做一些内部分享
一个team中，产品可能是最全面的那个人，也应该是最乐与分享的那个人。
将自己的经验能力见解梳理形成PPT，然后分享出来，定期做一个产品的分享会，这个将会让你又可能向更高的层面进行进步
七、享受生活
工作不是全部，不忙的时候多关心关心父母，老婆。
多多锻炼身体，关心自己，身体是革命的本钱。
人人都是产品经理（）中国最大最活跃的产品经理学习、交流、分享平台。
程序员最讨厌的5种产品经理，其中一种叫程序员哭笑不得！
程序员最讨厌的5种产品经理，其中一种叫程序员哭笑不得！程序员+产品经理=世界上最遥远的距离。
对程序员来说，技术是手段，需求是目标。
对产品经理来说，需求是手段，用户是目标。
对老板来说，用户是手段，盈利是目标。
看问题的角度不同，定位不同，也就导致了各种矛盾。
特别是产品经理和程序员，他们经常会有摩擦。
今天w3cschool 就来盘点一下，程序员最讨厌的5种产品经理。
1、频繁改需求如果项目经理想要整死程序员，频繁改需求是最快的办法。
特别是做了一半硬是改掉需求，scrum里的表现就是sprint内的非受迫需求变更，太狠了，技术同学表示不能忍。
2、拿老板和运营做挡箭牌不说清需求价值，当技术童鞋问“为什么要做”的时候，支支吾吾，或者说“老板要的、运营要的”。
最绝的就是说，这个功能老板说必须要做，那个功能老板说明天就得上……3、扮用户程序员会产品经理沟通的时候，比较经常就是听到，“关键字是用户不会这么觉得，如果我是用户。
”这种产品经理通常关注点会有问题，比如更多的时候讨论的是这个按钮是这么颜色，应该放在哪里，文案应该怎么写等，如果把这些问题当做核心，那难免会让人啼笑皆非。
4、口头禅——不就是xxx有些产品经理口头禅：不就是xxx，这也引来一些程序员的反感。
比如“这个问题不就是在数据库里加个字段就可以解决了吗?你要是没时间，我给你写个SQL 语句，你执行一下吧。
”结果程序员一脸懵逼。
其实，如果是在你的非专业领域里，最好少用这种「不就是XXX」这样的句型为妙。
5、不懂装懂特别是对技术一窍不通的产品经理，会不停让程序员加班赶工。
“开发大哥，我代码写的不多，你可别骗我，这么简单的需求，明明一下午可以搞定，你跟我说一个星期?”此时，想必程序员口袋里50米大刀已经饥渴难耐......这种产品经理叫程序员哭笑不得。
最后，哪种产品经理是你所不能忍的呢?。
产品经理产品设计-写给产品经理十条建议帮你与程序员建立天长地久的友情
写给产品经理十条建议帮你与程序员建立天长地久的友情产品经理与程序员，一个是消费需求提出方，一个是需求受理方，由于工作内容的差异性以及有时的沟通当，极易出现矛盾，这些问题该如何避免呢？产品经理从出生那一刻开始，似乎就决定了与程序员之间的敌对关系，一个是需求提出方，一个是需求受理沃洛韦齐区，伴随着相爱相杀，产品经理与程序员之间的矛盾由来已久。
作为一个产品经理，每天打交道最多的就是程序员，不管是IOS程序员还是安卓程序员，不管是java程序员还是PHP程序员，在产品经理每天的工作过程中都会忙于提需求、解答问题、改需求、再解答问题。
坦诚讲，刚开始入门产品经理的时候，对于这些程序员心理还是有点发怵的，因为他们一个个都非常不好打交道。
这些成天对计算机程序着电脑看着代码的人，你都不知道他们到底在想些什么，甚至你都不知道哪相信一句话会得罪了他们。
但是其实产品经理大可不必同学自己放在程序员将的对立面，因为究其本质还是人与人的相识，哪来调和那么多绝不能调和的矛盾。
那么，产品经理应该怎样和程序员友好地合作呢？无论是什么样的程序员，他都希望自己对接的产品经理能够把需求提清楚，我每到一个公司的时候，都会先跟程序员同事确认他们什么样风格的需求，的答复基本都是只需要把需求写明白提清楚就可以了。
所以，产品经理一定要学会把需求协会提清楚。
你可以尝试所绘高保真原型，把一些比较复杂的交互使用动态效果表现出来，这样做的目的不是为了炫技，而是为了减少不必要的沟通，提高研发效率。
要知道，很多时候，产品业务经理的需求多写销售经理一句话，就有可能让一回程序员少返工一次。
遇到不了解的逻辑怎么办？大胆去问，不要不怕程序员认为你不懂技术，也不用回答担心问他们会丢面子，术业有专攻，你要做的是给出可以执行控管的需求，如期完成研发管理工作上线发版上线，面子什么的不非常重要，都是自家哥们，何必纠缠繁文缛节。
大部分的程序员唯技术论，他们认可一个人的重要指标是这个人的技术能力如何，IT界有一句名言是“Talkischeap，showmethecode”，大致的意思就是“会说称不上本事，把你的代码拿给我看看”。
产品经理如何跟程序员友好相处？教你3个技巧!
我们经常在网上看到各种段子，程序员与产品经理互相嫌弃，其实这种情况比较普遍，那么产品经理应该如何跟程序员友好相处呢？教你3个技巧！1.尝试寻找解决方案真的有产品经理对程序员提出了要求APP的主题颜色可以根据外壳自动调整的要求？这个我不清楚。
但我们常说的技术可行性确实是产品需求的硬前提条件之一。
在计划之前，程序员需求的可行性。
程序员不一定深入研究、有空或沟通良好。
直接案例的实现效果，实际情况，技术框架或系统未必适用；凭直觉和经验，产品经理更倾向于独立思考，直接。
我曾经在一个项目重构中提出过优化ES搜索规则，但是搜索结果的权重并不理想，程序员让我接受现实：涉及全文检索，列表显示的结果不能完全精确，一时僵局，后来在CSDN中找到了类似的案例，发送了解决方案的，程序员的解决思路就通了。
因此，在梳理需求时，我们可以提炼可预测的技术难点，并学会寻找可解决的方案：如果是小程序、、企业生态系统的产品，我们可以多逛逛开发社区，了解开发、运营文新的内容，了解开放规则。
假如是自主开发的系统，还可以逛CSDN，简书，或者直接带问题去百度。
记住要有场景才能找到解决办法，而不是沉浸式的理解学习，毕竟我们是为了解决问题，而不是做一个懂技术的产品经理。
2.试着说明业务背景你为什么这么设计？你的需求是为了什么？看不懂你写的A和B的关系？程序员这三个问题不是很熟悉？经常问是不是让人语塞，或者反复解释逻辑，还是有代沟，很正常。
在回忆我们的需求链之前，经常有许多复杂的业务问题和业务流程。
许多需求需要产品经理进行深入研究，整理出一套标准化的系统架构。
如果不是像电子商务这样的ToC产品，我们可以在日常生活中理解到位的操作流程，程序员更难通过一次评估、一份文件或零碎沟通来理解。
所以除了原型，需求文档，我们还会配套输出业务流程图，产品流程图，帮助他们了解业务背景，但是还不够。
通过以下方式，我们可以尝试向程序员说明业务背景：在谈论产品计划之前，带上业务同事代表或我们额外整理一些业务示例，如数据图表或业务文档，帮助程序员了解业务日常工作中的痛点，以及一些专业演讲实际上与哪些信息对标。
程序员喜爱的产品经理养成计划
如果不是妹子，请来一只对开发有基本了解的！如果有开发经验的产品经理实在太贵！老板你一定要找一只会吹牛的！可以愉快的搅基！这不是我说的，这是某资深产品经理说的：交给他基本的开发原理这有两个好处：1. 你们会更好沟通。
2. 会让他感受到他智商的边界，从此每天看你都星星眼。
像这样：让他了解产品和开发的矛盾本质是什么知乎上有大牛说“认知不同，定位不同也就有了矛盾。
”对产品来说：用户是目的，需求是手段。
对开发来说：需求是目的，技术是手段。
然而这都没有什么卵用，最重要的还是给老板赚钱。
认识到这一点，你们可以愉快的去喝酒了。
恩，产品请客。
培养他用图说话的能力让他用三张图把话说清楚。
第一张，逻辑图：前端所有页面的相互关系。
第二张，交互图：第一张图里每个提到的页面里放那些信息，按钮排布。
第三张，描述表：第二张图里每个元素的解释。
不要让他习惯于给你长长的文档或是QQ上留言说“hi，我要加个功能巴拉巴拉巴拉。
”要像这样：和他经常沟通也要培养他经常和你聊天的意识。
想要一个功能的时候，先和你商量一下这个有没有实现的可能。
设置 deadline 的时候让你估计一下。
如果让他习惯了不考虑你的实现能力就提需求，他以为你是蓝胖子吗？如果……当然如果产品团队像我司一样。
前面几条就都无所谓了。
你看开发都自觉跪着吃饭的。
以及最重要的：让他领悟到卖萌的力量。
领悟容易学习难。
来源：扣钉Coding人人都是产品经理（）中国最大最活跃的产品经理学习、交流、分享平台。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
脑子了吧？！这么做有数据依据吗？！做过市场调研吗？！老用户会因此流失吗？！能保证上线后不再改了吗！？@$%^^%%$$@% #$%^^% ” 真的是没法儿做朋友啊！
曾经有一个自以为很牛掰但其实能力已经跟不上时代的RD总监，在kickoff会议上把我所有的需求都推翻了，让我差点在十几个老男人面前哭鼻子。
话说人在经历苦难后，要么变乖，要么变坏。
这种迫切想要搞定RD，让他们听命于我的心情，实在太强烈，于是我学会了通过非正规途径收买RD 的心－－比如请他们吃KFC啦，陪他们聊黄色笑话啦，穿低胸装秀黑丝大腿啦。
在这些努力之下，我和RD的关系改善很多，他们开始敞开心扉，解释他们对于新需求的负面情绪到底从何而来：有时是因为实在忙不过来，有时是因为实在无法理解这个功能有什么意义（至少他们自己肯定不会用），有时是因为PM不但不调解现有项目的优先级，反而还每天做梦，想些有的没的，让他们极为
恼火。
而负面情绪最大的根源，则是他们对这个项目失去了信心，觉得反复改版却一直没有大的
突破，老板和PM都应该去吃shi。
正当我沾沾自喜，认为自己靠美胸美腿赢得了这场战役时，一个Ruby程序员幽幽的跟我说 “我好喜欢你的门牙。
” （鸦。
你们果然是无法沟通的生物。
）
RD眼里的PM也分成两种：有脑子的，和没脑子的。
后者占90％。
（呵呵呵）
没脑子的PM，RD们是打心底森森嫌弃你的。
嫌弃你的理由可能有以下三点，欢迎对号入座，我们一起舔伤口：
嫌弃理由1：你没有自己的想法。
听清楚哦，我说的是RD们“认为”你没有自己的想法。
这个话题实在很辛酸，哪个PM会没有自己的想法呢，就是想法多的溢出了脑门儿才跑来当PM的啊魂淡！！但是PM的生存环境无比艰辛，很多决定都身不由己（尤其当你有一个心思活络的老板时）。
于是，有些PM选择推卸责任，两手一摊 “老板说必须做” ，急着撇清关系强调只有老板是傻逼哦我不是哦。
此言一出，你在RD心里的形象全毁。
PM必须是产品的灵魂，无论老板决定闹哪样，你都要把这个决定翻译成大家能接受的理由，建立你自己的口碑和信任。
在跟RD沟通的时候，不要说“我和老板争论了很久他就是不听我的”，这样更凸显你的无能；也不要撒谎说“其实我觉得老板的想法挺好的”然后硬掰些白痴的理由，这样显得你特别虚伪。
比较好的应对方式是开诚布公，说你自己真实的想法，如果你觉得老板真是玩过火，也要解释下老板为何会有这样的执念（是被投资人逼的，还是被老婆逼的，还是看到竞争对手做的什么事情眼红了想抄袭），然后安慰体恤下RD们的辛苦，并表现出和他们同甘共苦的决心。
嫌弃理由2：你风花雪月没有逻辑。
都说能做出牛逼产品的PM要感性和理性兼备，因为牛逼的产品能直戳人性，满足用户多层次的生理和情感需求，这就要求PM对生活细节敏感，情感丰富。
可是情感丰富的PM通常思维比较跳跃（艺术家嘛都这样），情绪波动幅度巨大，郁闷时会在阳台发呆抽一下午的烟，兴奋时连坐在马桶上都拿着手机写文档，这样的节奏RD们真心吃不消。
他们觉得你丫的赶紧吃点儿脑残片吧！（插播吐槽：我的上一篇文章发布后，就有人建议我服食脑残片！）因此
，论起PM的自我修养，你必须有收放自如的情感，还得有理性的逻辑思维去支撑起每一次的灵感乍现。
你可以问自己三个问题：一、这个功能是否服务于产品的主线业务，比如一个听歌的软件是否要有日间／夜间模式切换？如果只是锦上添花，使用场景不足整体的10％，那劝你还是等自己学会写代码以后在家做着玩吧；二、这个功能的技术实现成本有多大，如果用工时或天数来预计工作量不够直观，请去HR部门问一下RD全员每天的工资总额，再乘以所需要的开发时间，哈，这个金额应该足以让你好好思考“需求性价比”这件事了！（这招在创业公司尤为实用）三、这个功能的效果是否能被评估，这样至少你能检验自己的判断是否正确，无论如何都能积累宝贵的经验。
嫌弃理由3：不信任RD的能力。
呵呵呵呵呵呵，说起这个真是百感交集。
每一个有血有泪的日子里都在重复上演这样的剧集：PM问RD这个功能要做多久，RD说至少3周，PM于是去问自己做技术的好基友 “真的需要3周吗？”，基友拍桌子说 “这有什么难的，换了我3天就搞定！” 然后两人忿忿不平的拍案皱眉，开始讨论公司里的RD们到底是能力差还是在偷懒。
我曾经也这样，因为不懂技术害怕被骗，于是勾搭各种民间技术大牛让他们给我做狗头军师。
军师们为了维护自己伟岸的形象，通常会拍胸脯各种夸大各种装逼。
更糟糕的是，军师们也变相破坏了我和RD之间原本就已经很稀薄的信任。
（哦多么痛的领悟～～～）
最后，RD眼里的RD，只有一种：比自己牛的人。
剩下那些能力不如自己的，他们的存在早已消失散尽在雾霾里了。
……………………………………..我是口沫横飞的分割线…………………………………….
让RD觉得你很优秀的方法…
1.眼观四路耳听八方，知识渊博，掌握行业内的各种动态，分析市场趋势，没事就盯着友盟的数
据看，各种国外新推出的牛逼产品统统用起来。
RD们会觉得你什么都知道，那你的判断八成是靠谱的。
2.混对圈子，积攒几个牛逼人脉，难得和大人物有饭局的时候一定拍照发朋友圈，时不时去知乎回答些问题，去各种活动刷脸，撮合各种合作，尽一切可能把公司推到聚光灯下，这样也更容易招聘到优秀的程序员，产生良性循环。
RD们大多不喜欢抛头露面，所以他们会觉得你的付出无可取代（不然他们老觉得PM每天看看文章聊聊天，简直是悠闲的废物）。
3.无论是口述的需求还是撰写的文档，文字和原型图的呈现都要有逻辑，有条理，最好用写代码的思路来写产品文档，功能细节上的逻辑处理无一遗漏，实乃RD们的心头好。
4.在老板责问为什么还没上线的时候，冲上前去说，“都是我的错，前几天又改了个需求”。
5.在RD们被各种部门的需求同时袭击的时候，为他们安排最合理的优先级，并承诺担起一切后果（包括被某部门主管批斗责骂等）。
6.招到漂亮的实习生妹子给RD们养眼。
7.给他们加薪，给他们加薪，给他们加薪。
文章的最后，我想对所有还在拼搏的产品经理们说，就算你的行业环境不断限制你的创新和畅想，就算你身边的程序员总是打压你的积极性，攻击你的决策和判断，就算你觉得全世界都没有人肯定你的努力，没有人理解你的无奈，你都不可以放弃。
勿忘理想，勿忘初心。
你们是美好未来的希望。
转自：36氪
人人都是产品经理（）中国最大最活跃的产品经理学习、交流、分享平台。