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

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