漫画：程序员，你能“管理”好你的产品经理吗？

1.png 2.png

一、第三选择

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

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

这些问题，其实都可以借鉴第三选择的思想来解决。《第三选择》是一本书，作者是 史蒂芬·柯维，我想说到该作者的另外一本书，应该更多人能知道，《高效能人士的七个习惯》。而在《第三选择》中，他把之前的七个习惯浓缩成一件事情，可以说，第三选择是解决所有难题的关键思维。

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

1. 我打败你。
2. 我认怂，你打败我。

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

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

例如两个人分苹果，一人一半？这个方案对两个人都有亏欠，毕竟我赢了是可以得到一个完整的苹果的。那什么是第三选择？我们把苹果拿出去换点什么，然后再来分，或者把苹果种成苹果树，只要愿意长线投资，最终我们一人可以收获半棵树的苹果。这些都是第三选择，只要双方能达成共识，这是一个双赢的局面。

二、面对产品经理的冲突

那么我们在和产品经理合作的过程中，通常会面临什么冲突？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.3 需求变动太频繁

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

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

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

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

我通常的做法是：

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

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

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

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

2、拆分变动

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

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

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

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

例如：

• 增加了这个功能，UI 也需要变动，那你能不能和设计师沟通我们这一期就不要扣太多 UI 细节。— 减少沟通成本
• 这个需求的变动影响了原本的开发安排，你看能不能将另外一个需求（不那么重要）延期。— 置换不重要，但是需要花时间做的事情
• 这个需求如果遇到这样的情况，是不是没有办法得到处理？— 提醒他完善需求，避免再次改动
• 这个需求还有一些 "数据" 需要处理，你看能不能手工帮我处理一下。— 给他找点事儿做，有点损，不推荐

写在最后

在工作和生活中，不要把所有事情的解决方案都放在：不（第一选择，要赢）或者 是（第二选择，认怂）上，如果只存在两种选择，很容易就进入一种推拉的环境中，实际上是可以考虑考虑第三选择 。

第三选择并不是某一方的妥协，他的核心思想是创造力，找到新的出路，让双方协同找到一个大家都能接受的新方案。

说了这么多，其实都是《第三选择》的思想，推荐阅读。

3.png

今天在公众号后台回复成长『成长』，将会得到我整理的一些学习资料，也能回复『加群』，一起学习进步。

推荐阅读：

• 站在Android开发的角度，聊聊Airbnb的Lottie
• 漫画：Git 二分 Debug，火速定位出错代码！
• 找了一天找不到 Bug ? 试试 Git 的二分法吧！！！
• 如何更精准的在 Github 上搜索开源库？你需要这些技巧！
• Android 开发，遇上 Emoji 头疼吗？

公众号底部二维码.png