配图来自网络
撕逼，是互联网公司团队在沟通过程中很常见的现象，几乎每个业内从业人员都懂得的， 大部份来自于产品同技术，产品与测试，产品与设计，产品与运营，产品同boss(只敢提)，谁叫产品是大管家呢？他们只是负责其中的一个环节，设计负责只美如画，技术负责实现，设计负责实现的没毛病，运营负责用起来好用，产品要担起全部。因此，和稀泥，充当团队万金油的能力是产品能力模型中的一个重要部分，沟通耐撕推进力就这样隐晦的进入了招聘要求当中。
为神马要撕逼？为什么撕破所有？其实，撕逼大概是产品狗程序员各自自嘲时的用词，在团队中，严格意义上的撕逼可是命令禁止的，影响团结嘛。但在沟通中还是难以避免，本意上只是在讨论，难免会演变成争论、争吵。在我看来，现在撕逼已经成了一个伪名词，尽管现在说的如此心平气和，也是经过的暴风雨的洗礼之后的，（我分明看到程序猿得意猥琐的笑笑）。如果有很强的沟通能力，顶多胜算的可能性略大而已，但依然解决不了问题且已脱离了事物的本质。回到这个朴素的解决问题的字面意义，聚焦到产品设计层面就是你的解决方案每一步都没有问题（通常是指交付物BRD、MRD、PRD相关文档）。此乃解决一些团队bug的万能钥匙，因为产品设计就是解决问题的设计啊，当然，解决方案每一步都没有完美，方方面面想周全，这是想当然状态，不在讨论之列。
避免撕逼，从我开始！
不断提升自己的核心能力，把方案想清楚。从流程上来说，由于产品经理在战略形式上占有有利地位，功能确定了，然后进入开发阶段，开发人员一打开腻的PRD文档，如果遇到逻辑不清，流程残缺的情况，你说不做吧，工作流做到这一步了，做吧，相当于对着一个idea再开发，一边看，一边脑补。产品经理也不要怪人家撕你了吧，纵你超强的沟通能力、玲珑八面，这个局面也说不过去。更严重的饿后果是，你失去了他对你的信任...因此，作为核心能力之一，先把自己的本职工作做好，比如产品文档之类的交付物要竭尽全力的完善好，事无巨细，先把自己屁股擦干净，保证在源头上没有问题。自己想不清楚，在产品评审会上就如同现场直播吃翔啊...
学一些技术知识。听不懂他们在讲什么是件很尴尬的事，目前的见解是：尽量的去学，不求会写，但求哪些是可以实现的，大体听的懂一些术语知道，怎么回事。这点在学，不能瞎说。
为团队挡一部分伪需求。这部分大多是来自上层领导的，帮助程序员阻挡一些伪需求、不合时宜的需求，可以有效缓解程序员的焦虑问题。这个问题无外乎：这个需求做了有什么意义呢？一方面尽可能的说服上层领导，伪需求扼杀在摇篮里，产品要提升自己的鉴别需求真伪能力。研究了多年终于研制出一批胡萝卜，准备去钓鱼，结果可想而知，准确辨别真伪需求，可以确保团队走在正确的道路上...一切产品都是多方妥协的产物。
制定沟通协议，形成良好的互动机制。这应该是对工作制度的补充，就事论事，产生分歧则最佳方案，观点不同仅仅是观点不同，并非对个人有意见。
适时施展点情怀。你的产品，你有多少次反复推到重来的耐心？通常在工作中施展的话真的会被打死，一般用于边吃边聊，属于补充式招式，对付老程序员慎用。
尊重团队的每一个人。每个人必配技能。
树立不是核心的伪核心意识。作为团队的万金油，应视所有的团队成员都是可用的资源，拥有资源意识不是说不把人当成人，而是一种“成事”之举，团结一切可以团结的力量，就是抱团当下所有的资源，最大的资源当然是人力，以此出发，沟通中一点忍让承担点委屈也仅是鸡毛蒜皮之流了吧。只要达到产品目的，也就成了不是核心的核心了。
盘点一下过去在沟通方面踩过的坑及经验教训：
-
文档不全，流程残缺，是因为自己没有想到，能力不够，惭愧。
-
程序员大声问比他还大声，当时想至少在气势上不能输，其实吧功能定义清晰才是解决对手的终极武器。
-
对于没有深入思考尽量、没有明白问题不要发表言论。会被程序员当场笑话：你是不是现场失意了？
-
需求从idea阶段尽量不能跳过产品让老板同开发直接沟通。结果就是开发跟你要文档，你还不知道有这回事。
-
产品经理还是要把重心放到产品感觉思维的培养以及市场的嗅觉当中，知道什么该做什么不该做，然后不断细化产品设计及文档，至于沟通中的的打打杀杀，乐在其中就好了。
总结一下，最大的危险是不知道自己在冒险，沟通中最大的坑是不知道自己应该避开“撕逼”这个行为，所以，尽量避免不要去争执，争吵。基于一个合作共赢的目的做好产品，拥有多种“撕逼”高级技能并没有什么卵用，既然是团队，谁不想追求多人秉持共同的目标而各司其职的前进，那种彼此信赖、共同存在的快感呢？
话说你有没有那种饥渴感？