感谢大家被这个可憎的标题吸引进来，但任何项目想要取得成功，需要的是产品和研发的精诚合作而不是敌视。所以手撕产品经理本身就是个伪命题，研发如何手撕产品经理=> 研发如何跟产品经理合作，这才是正确的打开方式。本文主要介绍了我（项目经理及研发团队leader）在项目中与产品经理合作的一些小小心得。无论是你产品、研发、设计或者项目经理，我都希望本文能够你一些启发，当然也接受任何形式的建议。
前戏的重要性：
研发不认同产品提出的需求是一个常见的场景，这里包括很多因素，但很常见的一条就是信息不对等。很多情况下研发不了解需求的背景，可能产品同学会在需求提出之前跟老板、跟市场、跟客户把背景介绍了一遍又一遍，等到了需求评审的时候就可能会懒得介绍了，而内向的研发同学也没有提出要了解背景的意愿（但在项目总结会议中，我发现大部分研发都有这方面的诉求，希望能够了解项目的背景和具体的使用场景）。不了解背景和使用场景的情况下孤立的看需求，想要让人认同确实有点强人所难。想想敏捷的用户故事为何不定义成这样：为一个<角色>, 我想要<活动>, 以便于<商业价值>。
研发同学就像个怀春的少女，明明很想要却又不好意思开口，想要就要说，不说怎么知道你想要呢。同样提醒产品经理，评审的时候不要上来就XXXX，前戏也是很重要的。
合作的态度：
“反人类的需求、屎一样、烂的要死、丑的要命、敢不敢再搓点……”细数一下我在评审时的口头禅还真是不堪入目，仔细反思一下自己是否也和我有着同样的坏习惯。换位思考一下，如果有人用类似的词语评论你的代码，那可能就要出人命了。在需求评审中有异议是件再正常不过的事情，但过于直白或者带有攻击性的言语只会引发产品的反扑，而我们需要的是产品的反思。正确的方式应该是：
1. 提出具体的问题
2. 尽量给出一个自己认为更好的解决方案
3. 还有就是要注意态度保持微笑:)。
“跟你说了你也不懂、我们已经讨论过了你就不要问了、要不你说怎么办……”产品经理虽然更文明一点，但钝刀子割肉也很痛呀。有些产品希望研发只是执行者，对需求不要有异议，只要写好代码就可以了。但是这种合作方式已经过时了，互联网时代人人都是产品经理，团队中的每个人要可以参与到产品讨论当中，并且产品所提的需求也不会全部正确。所以产品经理应该想办法让研发认同你的产品，而不是强势的I think you do。
肚里没货、脑袋空空：
在评审的时候，会不会有一种觉得需求不合理却又找不到反驳的理由。产品经理在做产品的时候会花很多时间去做产品调研、头脑风暴，而很多研发却只是在评审时候才去了解需求。建议做好以下几点不要到评审时候再去抱佛脚：
1. 根据产品计划提前做好调研，研究有类似功能的产品，或者找找有没有开源的同类产品，去读一读核心代码。记得一次帮助运营同事做SEO监控平台，先花时间去体验了几款世面现有的网站分析平台，同时看了本关于网站分析的书籍，然后下载了一套开源的网站分析平台部署体验并研究了一下实现代码。做好了以上调研才开始着手去做项目，整个调研过程大概花了3-4天，但有了以上积累确实解决了很多问题。
2. 平时多积累，像什么36Kr、虎嗅、极客公园之类的平台还有各种订阅号，每天撸个几十条，实时的了解一下国内外的热门科技资讯，遇到感兴趣的产品会去官网看看甚至下载体验。互联网从业人员一定要保持一颗求知若渴的心，每次听到不了解的技术或者产品，总会记录下来事后去搜索研究。记得某次开会，问手下的小伙伴们一种技术（两周前公司内一次技术讲座中提到的，当时我也是首次听说但回去就立刻google了解了一下），两周后再问十几个小伙伴们却都是一脸茫然。引用一句话你可以不成功，但不能不成长。
3. 深入了解业务，例如我之前在互联网金融公司，自己就花了些时间去学习一些金融、基金和股票的基础知识；现在做外贸saas也会花时间去读一读外贸入门的书籍。平时还可以读一些互联网公司或传奇人物的传记，或者互联网相关的非技术书籍。
有了以上的各项准备，评审过程就不会变成填鸭式评审了，评审应该是一个双向的有交流有互动的合作过程。就好像这个临近的情人节，不要让一个美妙温馨的夜晚变成交作业。
当然除了写给研发，也一样给产品经理一些建议：
1. 介绍每个功能的背景和使用场景必不可少。
2. 前期做好充分的准备，做一份对得起观众的产品文档和原型。
3. 注意说话的态度，不要把研发当工具。
4. 对研发好一点，比如多发点红包多请他们吃饭:D
