程序员，你能“掌控”你的产品经理吗？

1。第三选择

在工作中，当你面对产品需求的各种变化和项目经理在关键点上设定的期限时，你总是会遇到冲突。对于最终负责让事情发生的开发人员来说，如果这些冲突处理不好，它可能会成为你的个人问题。

作为最终实现该功能的程序员，你绝对不想被贴上“不能及时完成任务的开发者”的标签吧？

这些问题其实可以利用第三种方案的思路来解决。 《第三选择》是一本书，作者就是史蒂芬·柯维。我想谈谈作者的第二本书，应该让更多的人知道，《高效能人士的七个习惯》。在《第三选择》中，他将之前的七种方式浓缩为一件事。可以说，第三种选择是解决一切问题的关键思路。

当我们遇到矛盾时，我们该如何用正常的思维去解决呢？

1. 我打败了你。
2. 我放弃了，你打败了我。

第三种选择就是第二种选择：我们一起寻找双方都能接受的解决方案，实现双赢。

注意，这里的第三种选择绝对不是一方的妥协，也不是一个人的让步。核心理念是创造力。如何通过双方的合作，利用第三种选择，达到第二种更好的结果。

例如，如果两个人分享一个苹果，各分一半？这个计划是对两个人都有的。毕竟，如果我赢了，我会得到整个苹果。那么第三个选项是什么呢？我们把苹果拿出来，换上一些东西，然后我们分享它们，或者把苹果种到苹果树上。只要我们愿意长期投资，我们每个人最终都可以收获半棵苹果树。这些都是第三种选择，只要双方能够达成协议，就是双赢。

2。面对产品经理的冲突

那么我们在与产品经理合作时会面临什么样的冲突呢？

2.1现阶段技术上不可能的需求

我们不能要求所有产品开发人员都具有技术背景。当产品经理不太了解技术细节时，总会出现一些古怪的产品解决方案。 。当然，其中一些在技术上并非不可能实现。您的团队在这个阶段可能很难实施它们，并且可能会遇到未知的陷阱，从而难以管理整个项目的进度。

面对这样的要求，不要直接拒绝，尤其是立即拒绝，说要求无法满足，从而将对方推入冲突的境地。如果你拒绝他并停止满足这个要求，或者如果他说服你并强迫你满足这个要求，我们不想看到这种情况。

现在你冷静下来了吗，正在考虑第三种选择吗？

我相信大多数产品解决方案并不是唯一的解决方案。您总是会想到更容易实施的解决方案。

你可以询问对方的真实需求，并提供你能实现的解决方案，而不是直接拒绝对方的解决方案。

2.2 需求复杂度与开发时间的冲突

当面临过于复杂的需求时，您可能会因为多种原因而没有足够的时间来实现该功能。

现在该怎么办？为了完成这件事，你加班了吗？都是程序员。我想你应该对加班写出的代码的特殊品质有所了解。因为你加班加点，写出了质量很差的代码，所以上线后Bug越来越多，处理起来也需要时间。新周期的新要求也立即流行起来。您发现质量差的代码可扩展性差，并且需要很长时间才能重建。这是不允许的，所以你可以修复它。它运行的时间越长，速度就越慢，情况也就越糟糕。错误越来越多，你的压力也越来越大，抱怨也越来越多。

当前的技术债总是要在以后偿还的，否则长远来看只是一个恶性循环。

如果此时你直接同意或拒绝，你会发现自己陷入了冲突的境地。考虑第三个选项，不要只是说“不”。你首先应该清楚地明白他为什么要这么做？起点在哪里？什么目的？一旦你了解了产品经理针对这一需求的真正用途，你就可以从自己的技术角度提供一个你可以接受的解决方案，或者与对方讨论一个更具成本效益的解决方案。

能够讨论出一个大家都接受的方案固然很好，但是如果需求还是很复杂，时间和复杂度还是达不到呢？

您可以分享您的要求。可以说我对这个需求分析得很仔细，A、B、C工作我都要做。现在在规定的时间内我只能勉强完成A和B，B工作不保证质量。您能否将这个功能分成两步来实现并调整需求，以便我可以保证代码的质量？第一阶段，基本功能得到保障，用户可以上网查看需求。第二步，根据用户反馈修改细节。 。

相信我，经理的产品也承受着各种压力。他还必须确保开发取得进展。我认为从完整且完整的选择中进行选择并不困难。

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

这样做的好处是你把选择权留给了他，你们都承担了一些压力。如果有人反对这么长的周期，你的产品经理也替你说话，说他的需求规划很详细，所以我们决定分两个阶段来做，这也说明了他对需求细节的把控。真的很强大。

2.3 需求变化太频繁

作为开发人员，有时在编写代码时，你可能会注意到原来的解决方案或选择不合适，而主动调整和重构代码。产品经理在设计需求时也存在这样的问题。也许他一开始没有考虑详细，也许是因为第三方的压力等等等等，种种原因最终导致需要调整需求，适配产品。该计划不是他在开发周期中可以自己完成的事情。工作压力肯定会转移到满足要求的开发上。

首先我想说，需求的变化是不可避免的，所以接受变化。

在安排需求时，开发人员应该留出时间来处理这些变更，但这无法处理产品过于频繁的变更。甚至可以极端到明天产品就关掉，今天需求就变了。 。

遇到这样的情况，你一定要试着和他一起减轻压力。既然对方给了你压力，你就要想办法回报压力，让对方与你分担压力。 ？而这些都是技术债务，而偿还技术债务需要时间。

让产品经理索取这些技术债务，他必须有时间立即偿还。

最简单的选择是，我可以加班粗略地满足这个要求，但我面临的问题是，将来可能会出现效率、可扩展性等方面的问题，之后我需要额外一周的时间下一集中优化这段代码。这是技术债务的立即偿还。

2。拆分变更

和之前的想法一样，在当前基础上尽量减少变更，并使这些变更尽可能精简。

如果无法精简，就想办法分成两步。

3。提高可变成本，给对方施加压力

虽然所有需求的变化最终都会影响到开发商，但这并不意味着其他人就无事可做。想办法增加经理产品的可变成本，让他分担压力。

例如：

• 增加了此功能，用户界面也需要更改。您能否与设计师沟通一下，本期我们不应该减少太多的UI细节？ — 降低沟通成本
• 这种需求的变化影响了原来的开发安排。看看是否可以推迟另一个要求（不太重要）。——换不重要，但是需要时间
• 如果这个索赔遇到这样的情况，有没有办法处理呢？ — 提醒他改进需求，避免再次更改
• 这个需求还有一些“数据”需要处理。您能帮我手动处理吗？ — 给他找点事做，有点亏，不推荐

写完

不要把所有事情都给出解决方案：否（第一选择，获胜）或是（第二选择，放弃） ，如果只有两个选项，很容易切换到推拉环境。其实，你可以考虑第三种选择。

第三种选择并非一方妥协。其核心理念是创造力，寻找新的出路，让双方合作，找到大家都能接受的新解决方案。

说了这么多，其实是《第三选择》的想法。建议阅读。