在工作中，你面对产品经理的各种需求变动、项目经理对关键点的 Deadline，总会有一些冲突发生。而对于事情最终执行的开发人员来说，如果这些冲突处理的不好，可能就会变成你个人的问题。

做为最终实现功能的程序员，你总不会想被贴上一个 “无法按时完成任务的开发” ，这样的标签吧？

这些问题，其实都可以借鉴第三选择的思想来解决。

当我们面对冲突的时候，正常的思路如何解决？       我打败你。/   你打败我。

而站在第三选择的思维下，你还有一个选择：我们共同找到一个双方都能接受的解决方案，达到共赢。

注意，这里的第三选择，绝对不是来自某一方的妥协，或者一人让一步，核心思想是创造力。如何通过第三种选择，双方协同达成另外一个更好的结局。

1、 现阶段，技术上无法实现的需求

不能要求所有产品经理都是技术出身，当产品经理对技术细节不那么了解的时候，总会有一些异想天开的产品方案。当然有一些并不是技术无法实现，可能是现阶段你的团队实现起来会很吃力，可能会面临一些未知的坑，而导致整个项目进度很难把控。

面对这样的需求，你不要直接拒绝，尤其是不要立刻拒绝，说这个需求做不到，这就把对方推入了冲突的局面。你拒绝他，不做这个需求了，或者他说服你，强行要实现这个需求，这都不是我们想看到的。

那现在冷静一下，想想第三选择？

我想大多数产品方案，其实并不是唯一的解决方案，你总是想到一些更容易实现的方案的。

你可以问清楚对方的真实需求，给出一个你可以做到的方案，而不是直接拒绝对方的方案。

2、 需求复杂度和开发时间不匹配

当你面对一个过于复杂的需求的时候，可能因为各种原因，给予你实现功能的时间并不宽裕。

这个时候怎么办？自己加班加点完成吗，大家都是程序员，加班写出来的代码具体质量如何我想你也应该心里有点数。你因为加班写出了质量不好的代码，于是上线之后的 Bug 增多，还需要花时间处理，并且新周期新需求也立刻紧跟上来，发现质量不好的代码扩展性差，想重构时间上又不允许，只能打补丁，越干越慢，越干越烂，Bug 越来越多，于是你压力越来越大，被抱怨的越来越多。

现在欠下的技术债务，之后总是要偿还的，否则长此以往，只能是恶性循环。

这个时候直接答应或者拒绝，又会陷入冲突的境地。想想第三选择，你不要直接说 "不"。你应该先了解清楚，他为什么要这么做这个需求？出发点在哪里？目的是什么？当你了解清楚产品经理对这个需求的真实意图的时候，你可以从自己技术的角度，给出一个自己能接受的方案，或者和对方讨论出一个性价比更好的方案。

能讨论出一个大家都接受的方案，固然是好的，但是如果依然很需求复杂，时间和复杂度依然不匹配，怎么办？

可以选择拆分需求。你可以说，这个需求我仔细分析了一下，需要做 A、B、C 工作，以现在分配的时间来说，我只能做到勉强实现 A、B，并且 B 并不保证质量，你看你这个功能，我们能不能拆分成两期来实现，调整一下需求，这样我能保证代码质量，第一期先保证基本功能，上线让用户来验证需求，第二期再根据用户的反馈调整细节。

相信我，产品经理也是有各种压力的，他也需要保证进度在推进，在一个完成和完美的选择中，我想这不难选择。

这里的诀窍是：当我不能完全满足你的时候，我可以选择有条件的满足你。

这样的好处在于，你把选择权留给他了，这一部分压力是你们共同在承担。如果谁对于这样的延长的周期有异议，你的产品经理也会帮你说话，说自己需求设计的很细，所以我们决定按两期来做，这样也显得他对需求细节的把控很有力。

3 、需求变动太频繁

作为开发，有时候自己写代码的时候，可能写着写着发现最初的方案或者选型不合适了，就会主动去调整代码、重构代码。而产品经理在设计需求的时候，也会有这样的问题。可能是开始没有考虑的那么细，可能因为来自第三方的压力等等问题，种种原因吧，最终导致需求需要调整，而产品方案的调整，在开发周期内，他是没法自己独自调整的，工作压力一定会转嫁到实现需求的开发身上。

首先我想说，需求变动是一定会发生的，所以拥抱变化。

本身在需求排期的时候，开发者就应该预留出一些时间来应对这些变化，可这也架不住产品太频繁的变动，甚至太过分的明天要封板了，今天还在改需求。

这样的情况，你需要做的是尽量和他捆绑压力，既然对方把压力给了你，你要想办法把这个压力还回去，让对方和你一同来分担这个压力。

我通常的做法是：

3.1、先用快捷的方法实现并上线，后续再要时间偿还债务

我想很多功能，总是有一些粗暴而不优雅的方式来实现，而这些都是技术债务，之后是需要时间来偿还技术债务。

要让产品经理认领这些技术债务，并且必须立刻给予时间来偿还这些债务。

最简单的一个选择是，我可以加班加点以一个比较粗暴的方式完成这个需求，但是面临的问题是后续可能效率会有问题、扩展会有问题等等。这事后，下个周期我需要额外多出一个星期的时间来优化这一段代码，这就是对技术债务的立即偿还。

3.2、拆分变动

和之前的思路一样，将变动在现有的基础上最小化，以最精简的方式去完成这些变动。

如果没法精简，想办法拆分成二期来实现。

3.3、增加变动成本，给予对方压力

虽然所有需求上的变动，最终影响的是开发人员，但是并不是说其他人就没什么事情可做了。想办法增加产品经理的变动成本，让他来共同承担压力。

例如：

增加了这个功能，UI 也需要变动，那你能不能和设计师沟通我们这一期就不要扣太多 UI 细节。— 减少沟通成本

这个需求的变动影响了原本的开发安排，你看能不能将另外一个需求（不那么重要）延期。— 置换不重要，但是需要花时间做的事情

这个需求如果遇到这样的情况，是不是没有办法得到处理？— 提醒他完善需求，避免再次改动

这个需求还有一些 "数据" 需要处理，你看能不能手工帮我处理一下。— 给他找点事儿做，有点损，不推荐