作为产品汪，撕逼技能就像Axure、墨刀、Xmind、PPT一样，是一项必备技能，跟技术撕简直就是家常便饭，而且还可能会跟运营撕、市场撕、设计撕、老板撕~总之，一切跟产品相关的人都可能成为你撕逼的对象，没办法，产品经理是产品的核心和owner，沟通中只要有不畅的地方，都避免不了一场撕逼大战。
今天和大家聊聊和程序猿撕逼的那些事儿！
撕逼四重境界
撕逼第一重：程序猿哥哥你好腻害，我就小小的反抗一下
大部分缺乏经验的产品经理以及性格偏软的产品经理会遇到的问题，甚至在一些技术主导型的公司，这样的现象更普遍，产品经理提出的观点论断甚至都没有程序猿提出的靠谱，就算产品经理内心有一些想法，提出来遭到程序猿反驳后，都没底气辩解，依靠小小的反抗刷下存在感。
撕逼第二重：需求评审拍桌子，需求变更扯嗓子
有点脾气，或者有些经验的产品经理，会想办法说服程序猿，我在上家公司做过，你这种技术观点不靠谱，我做这个做了3年了，我能不了解，你看看这数据，就应该这么改，我就需求变更一下，哪家公司上线前不变更需求啊？办公室就像菜场一样！
撕逼第三重：抄领导
你不听我是吧，我这个和老板过过了，邮件抄CEO,CTO,COO,CPO,CXO，产品总监，研发总监，来，我们进行不下去了，我们在邮件说吧，邮件里再来一场血雨腥风！领导也纳闷：玛德制杖！
撕逼第四重：拜拜~
女产品哭了，找产品总监提了离职报告。程序猿怒了，劳资不干了，你爱找谁找谁吧！同是打工者，相煎何太急！
撕起来了，产品狗该怎么办
一个负责任的产品经理不是为了撕逼而撕逼，都是为了解决问题而来的，既然都已经吵了起来，怎么才能稳住大家情绪，围绕核心问题展开激烈的讨论呢？
首要原则，请不要人身攻击！撕逼就是撕逼，请优雅的撕逼，别俗不可耐的一堆脏话出来了，你个傻逼，你这么low走后门进我们公司的吧。控制好你的情绪，你的那些所谓不经意间的口头禅都会伤人，这伤疤留下了，即可调解好了，日后也难以痊愈！
其次，对事不对人！我曾经遇到一个女PM需求评审时候，研发总是提出各种质疑，这个女PM脾气也大，直接来一句：你是不是看老娘不顺眼！完了，整个桌上的人都懵逼了，你在质疑人家的动机，你对人不对事儿，这评审会还怎么开下去！撕逼是为了解决问题，不是为了制造问题，单纯的程序猿人家就是逻辑性强，你逻辑有问题，自己没想好，还不允许人家提啊！有城府的程序猿别提了，想坑你，太容易了，分分钟让你成为背锅侠，没必要在需求评审时候卡着你！
第三，就事论事！产品经理经常遇到这样的质疑，研发问：你上次主导的产品害我们加班通宵，结果辛辛苦苦搞出来的的产品数据那么差，那这次我们还听你的？所以这个时候讨论的核心点就不是看产品需求本身是什么了，转而先确认要不要相信这只产品狗。但是话说回来，就算上一款产品失败，也不能论断该产品失败的原因就归结于产品汪的能力问题啊，有些只是为了验证老板的想法是错的罢了，这锅，不背！
第四，别老是拿权威说事儿！程序猿也总会质疑产品为啥要这么设计，你会说，看看京东，看看淘宝，看看微信等等，张小龙说过，XXXX，乔布斯说过，XXXX，李彦宏说过，XXXX。作为产品经理，还是要基于具体使用场景和用户需求进行讨论。毕竟，权威的话不一定适用于我们特定的产品以及讨论场景。
如何在程序猿间游刃有余
第一，不要抱着撕逼的心态
抱着撕逼心态的时候你的潜意识就是在别人对立面，反正人家说什么我都要辩驳，进了评审会议室，自动开启撕逼模式，容不得别人对自己的设计指手画脚，哪怕别人是对的。心态不对，基本上很难做好沟通工作，那么许多工作也会很难推进下去。
第二，想清楚你的需求是什么
在某个行业做互联网产品经理，不代表我们只需要懂产品设计，要把这个行业吃透，才能有更完整的信息和论据，得出来的结论才更可信。所以每次做需求前，最起码你要把需求本身的意义想清楚，你要有充分的论证，市场分析，竞品分析，运营数据，用研反馈，这些你要有逻辑的向程序猿们阐述清楚，让大家觉得我们不是在瞎做，我们是有目的的在做一些东西，大家做的不是无用功，最起码，我们产品是用心做了调研！就算是老板的需求，那么你也要问清楚需求是什么，为什么这么做，有没有什么市场前沿信息，老板的战略构想是怎样的等等
第三，评审前和技术充分沟通
产品经理在规划产品的时候要及时跟技术团队沟通技术上实现的可能性，开发可能耗费的工期，以及对目前技术架构的改动。一个懂技术的产品经理能够节省很多时间。每个技术团队的能力不一样，都有一个客观的边界，如果实现起来的困难很多，时间很长，那就需要产品经理对相应功能进行取舍或者变换一种设计形式。当然，如果你在平时交流过程中，结交了不少研发好朋友，多向他们讨教讨教聊聊需求，工作会事半功倍。
第四、完整的需求文档
只有你把你的需求文档想的细致想的全面甚至连一个错别字都没有，这样才不会在需求评审的时候不被喷，才不会撕逼。
1. 逻辑清晰你的整个需求当中，逻辑是不是清楚，整个流程能不能走完，页面跳转流程是不是正确，别一番走下来，流程上都有问题。
2.完善产品的异常流程和细节补充说明。很多产品经理的完成产品规划的时候，大致一看主流程。其实由很多异常流程没有想到。比如用户登录时候，什么时候出现图片验证码，用户手机号输入错误，密码输入错误怎么提示，你做个分享，icon，title和content有没有附上等等
3. 在PRD中建立note项，强调关键的东西别让研发遗漏，自己评审时候也能注意到，会后，研发也可以根据你的标注来理清思路，起到查漏补缺的效果。
第五、不要频繁变更需求。
需求文档确定以后就不要频繁变更需求。如果变化大的话意味着之前做的东西推倒重来，技术所做的成功付之东流。频繁的变更需求，会让研发人员不信任你，自然你的沟通也不会那么顺畅。所以会有下面一副忍俊不禁的图片。所以产品经理为了不频繁变更需求，一定要在需求发出之前把所有的细节都想到，尤其是面对一个新的问题的时候不要急于做决定，你完全可以告诉研发，这个问题我现在有些想法，但是不完整。我在想想，尽快给你答复。一个迟来的完整的决定总比一个没有经过深思熟虑做出的决定好。
第六、产品经理参与到测试中去。
产品经理如果时间充裕可以和测试一起写test case，这样你就能发现自己有哪些没考虑到，和测试的test case比较，测试有哪些没考虑到，和测试一起测试，可以最快速的了解你这个产品的全貌，也许你做的只是APP的某个功能，但是你一起测试时候，有些关联功能会测到，几次测试下来，你对你的APP会有一个全貌的了解。
第七、产品上线后，适当的犒劳一下项目组。
一次产品的孵育，大家都经历了不少的辛酸和无奈，结束之后，大家完全可以吃吃喝喝，把酒言欢，起码研发会认为你这产品经理实在，大家在吃喝的氛围中培养一下友谊，大家以后会更愿意给你卖命。
最后再说几句大家不爱听的
1.埋头做事，也别忘抬头看看
2.别以为title里面有个manager，你就觉得自己是manager，manager和你无关
3.永远积极，乐观，正能量
大城小胖，一个喜欢读书和写字的互联网金融产品经理，不定期更新原创文章，转载请私信联系，支持原创！
