作为“无冕之王”的产品经理，沟通能力是格外重要的一项技能，强沟通下就难免会有争执，我稍微整理了一下，在实际工作中，与开发人员产生争执时所处的场景，以及对应的解决方式，分享给大家。

为什么会撕逼？

产生的因素实在是太多，可能是性格不合，能力问题，企业文化，天生敌对等等…

但有一点毋庸置疑，因为角色的分工不同，因此产品经理考虑内容，问题，方向，范围一定比程序员考虑的多，因子与因素越多，变量和结果就越多，这也就导致了产品经理们与程序员们，撕逼原因最多的一种情况：更改需求。

为什么会改需求？

1. 产品经理设计时，自己没有考虑到，没想清楚，忽略，遗漏，错误设计…等。
2. 失败的市场调研，错误的用户画像，导致错误的产品设计上线后，不符合用户胃口。
3. 为了配合公司与竞品的市场竞争，而展开的战略性的需求调整。
4. 公司内部政策，导致需求的紧急调整。

以上仅仅是我所经历过，最主要的几点，其中产品市场试错，是导致需求更改最多的一种情况，也是程序员们最不理解的一种情况，敏捷开发就是为试错而生，倡导快速思考，快速执行，快速试错，行就Ok，不行就立即plan B。

撕逼场景

程序员：我不知道改了需求，你没有通知，所以下次再改

改了需求必须要通知到位，这一点很重要，否则PM会陷入两头挨骂的局面。

上面或用户骂你：为什么没有改呢？下面程序员骂你：你改了需求并没有通知我们，这是你的责任。

所以改需求别忘记两点：通知到位，可追溯。

我的做法是：

1. 每次更改需求时，首先是PRD、线框原型图、UI设计稿的更新。
2. 在项目管理系统中(我们公司使用的是“腾讯敏捷研发平台”)，在对应的需求条目里，增加更改记录，且写上更改日期、原因、更改内容。
3. 除了口头通知，必须要在对应的QQ/微信群中，@相关人员，或@全体成员，截图告知我更改了什么地方的内容，在哪里可以查看到。如果再严谨一点，还可以发送电子邮件来通知，具体视企业具体情况而定。

有可追溯的记录，能向所有人证明，这次需求的更改，你是做过的且通知过大家，在争论时能为你提供有力的优势。

如果你真的忘了做这些，且没有什么能证明你做过，那就只有自己背锅吧。

程序员：我觉得你这样做是有问题的，我不建议你这样考虑

有些情况下，如真的是PM考虑欠妥，那么程序员在开发过程中发现了问题并告诉你，这还真的是好事情，否则别人只管实现，最后上线流程大问题，屁股还是得自己擦。

那么当开发人员，质疑产品经理所设计的内容时，抛出以上的问题，产品经理应该如何应对呢？

我的做法是：

1. 首先认真倾听，对方的理由，并结合自己的想法思考。
2. 如果你认为对方提出的质疑是错误的，那么立刻把你的想法，告诉对方，纠正并说服对方。
3. 如果你认为对方提出的质疑是正确的，那么你应该“示弱”，并表示马上重新考虑一下。

需要注意的是：

1. 无论是你的理解，你的说辞，还是你的想法，都一定要表现出产品经理应有的专业。
2. 别暴露出“我没想好”，“完蛋了，好像真有问题”这类状态，一旦你这样，那么你连反驳的机会都没有了，自己都没想好为什么让开发人员做？
3. 记别做出一副“我是产品经理，我提出想法，你落地实现就行”这类状态，这样是很容易发生争执的，

在大部分企业中，PM毕竟不是管理岗，因此别太把自己当回事，只要有利于产品，适当的“示弱和退步”，没坏处。

程序员：又改需求，这个地方已经改了几次了，为什么还要改？

改需求对开发人员来讲，是很痛苦的，写代码也讲究一个成就感，试想你花了1天的时间研究并实现了一种你曾不会的方法，正在享受着成就感时，PM对你讲需求改了，要换一种实现方式，你抓狂不？

我的做法是：

1. 别因为自己的疏忽，而让程序员为你买单，宣讲前，我会对流程和设计内容过3遍左右。
2. 如果是因领导、市场、用户所决定的，零时需要更改的需求，那么把实际情况告诉对方就好了，同时你应该无奈的告诉对方：“我也没办法啊，这不是我所能控制的”这类话，试着让程序员感受到，你们是站在同一边的。
3. 如果是你没想好，不如请别人抽支烟，喝杯咖啡，吃顿饭，用实际行动感化对方，让对方帮你弥补这个错误。
4. 争吵是最没效果的方法。

程序员：这个真的不好实现，你让我怎么实现

对于此类情况，通常可以分为从两种类型的程序员口中说出：认真负责或偷奸耍滑。

如果是前者，我的做法是：

1. 首先倾听，试着了解，并结合同类功能，尽力判断，是不是确实不好实现。
2. 如果非我所认知的那么难，我会尝试说服对方，冲一下，攻克困难。
3. 考虑是否有其他方式，代替方案的实现，或更改需求。

如果是后者，我的做法是：

1. 无论我懂不懂技术，只要我知道对方是抱着想蒙我的态度，那么我会加入感性的情绪来与他交流，比如故意提高音量，态度强硬，以表明出“别tm想来蒙我，这个东西必须做”的这种气势。
2. 我会提前背书，如百度搜索相关技术答案，私下询问朋友等，以便在辩论中有足够的谈资和话语权。
3. 当然也要告诉对方，实现后对用户带来什么好处，对平台带来什么价值，不实现会有哪些不好的后果…

才疏学浅，欢迎补充与指教！

本文由 @Palowlto 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自PEXELS，基于CC0协议