掌握如何撕逼并没有卵用，这4个点让你和程序员好好沟通

　　知乎上有人问如何跟工程师优雅地撕逼？，以下是我的回答。
　　说实话，除了在创业的时候经常跟工程师瞎闹、吵架，在其它公司但凡流程正规化一点，撕逼就是严禁出现的现象。就算是创业时候的撕逼，也只是因为比较熟而已。
　　很多人会从抽象概念上强调，真理是越辩越明的啊、只要在理就不怕撕啊、撕也是沟通的一种技巧啊等等。在我看来是有问题的。
　　我过去也是这种死工科男的思维，认为只要道理在，我就不怕吵到多狠，反正最后大家认理就行。
　　事实上这样是大有问题的。
　　如果是在双方平等的情况下，怎么吵架都没关系，更容易就事论事。但是产品经理和工程师的撕逼、吵架（或者说好听点，激烈的碰撞）是双方不平等的状态，前者更像甲方，后者是乙方。这样造成的局面就是：
　　产品经理吵赢了。工程师会觉得，有理就可以声高吗？有理就可以这么吼我吗？又不是你来写代码，我提出这些质疑不行吗？你何必这么趾高气扬？
　　工程师吵赢了。工程师会觉得，艹，你看你提需求这么不靠谱，想问题不周全，给我埋这么多坑，我以后还能不能信任你了？
　　两边都没吵赢，勉强达成了共识。工程师会觉得，你的道理都说服不了我，那你做产品经理有什么意义？还跟我这么吵，你这是什么态度？
　　不管哪种情况，都会引起工程师非常负面的情绪。原因很简单，从本质上说，产品经理是想主意的，工程师是实现的。想主意的一点错漏、没想明白的地方，会给实现方造成巨大的麻烦；而如果想得很清楚、想得很明白，那是应该做的。
　　经常撕的话，会让工程师渐渐失去信任、也没有做好产品的动力。他写每行代码的时候，脑海里可能都会复现当时讨论功能时你狰狞得意的脸，这是件很恶心的事情。
　　我觉得撕逼不可取，但希望撕逼解决的一些问题其实仍然存在，在跟工程师的沟通中，解决这些问题的方式可能有这么几种：
　　1。事前把方方面面想周全。
　　对产品经理来说，提的方案有明显的逻辑问题（比如前后矛盾、不合理、有明显错漏），那就占不了什么理，这也是会让工程师失去信任的最关键因素你想不清楚就来跟我提需求，是不是不靠谱？
　　在我们需求评审时，一旦被工程师问住了，并且回答不出个所以然，我们就认为是产品经理的失职。这种情况我们认为是等同于开发的bug，是产品经理的失误，要记录在案，不断复盘和鞭策自己。
　　如果方方面面想的足够周全，那所有工程师提出的我不觉得这个有意义或者我认为这个没道理的问题，都能用功能的业务背景和用户需求来解答实际场景下，用户会在XXX的时候用到XXX，这是我们功能的初衷或者你觉得这个功能没有意义，但我们通过数据调研访谈观察到，用户确实有这个需求。
　　这个我也说不太清等我去跟XXX再确认下吧你说的没道理，你不懂这些都是产品经理的禁用句式。
　　2。塑造良好的沟通氛围
　　如果真的是想清楚了，那就跟工程师信息同步，让他也明白所有需求的背景和价值，不要反感；其次，像我刚刚说的，如果没想清楚，那就是产品经理的失职。错漏经常在所难免，但既然是产品经理不占理，那为什么一定要撕逼来解决？
　　在这种情况下，让工程师觉得，我们是竭尽全力在帮助他们更好地工作，而不是随便想了个点子、不负责任地提给了他们。对工程师，他们未必能知道我们也在冥思苦想、费劲心思地做功能设计，在他们看来，只要有几个漏洞和问题，就会想象出一副产品经理花天酒地不关心开发民生疾苦的画面。
　　一旦有了问题，要表现出我们马上改和下次不会犯的态度，这才能让工程师更信任。硬说人都会犯错啊，你不是也会出bug嘛！还不高兴我们也出点问题嘛！既不能挽回颜面，也不能挽回工程师的认可。
　　3。了解技术背景
　　良好的沟通都是双向的。既然我们希望工程师能了解产品和业务背景，那么我们也应该了解技术背景。这也是产品经理要不要懂技术的解答。
　　对我们来说，未必要会写代码，但要知道他们所说的做不了和很难做是什么意思。他们没有耐心讲，我们也要有耐心学。这些知识掌握之后，能更有利于我们做出让他们更满意的方案，促进更好的沟通。
　　知彼知己，是最好的沟通方法。如果信息不对称，撕逼再多也没用；如果信息对称了，那为何还要撕逼？
　　4。特殊的情况
　　还存在着一种特殊情况，就是某些工程师确实性格或者职业操守比较一般，会以各种借口做挡箭牌，习惯性跟产品经理撕逼，故意推延实现需求甚至刻意删减需求。这种是我认为的唯一能接受撕和吵架的场景。不过针对这种情况，最好的解决方案是反馈给他的上级，让上级来判断孰对孰错，同样不要指望撕逼能带来质的提升。

造句：掌握如何撕逼并没有卵用这个点让你和程序员好好沟通
造句：掌握如何撕逼并没有卵用这个点让你和程序员好好沟通