辛先森科技说|懂程序员的产品经理是什么样子？我是一个着迷于产品和运营的技术人

我是一个着迷于产品和运营的技术人，乐于跨界的终身学习者。欢迎关注我哟～
每周五早6点按时送达～
我的第「155」篇原创敬上
大家好，我是Z哥。
在互联网行业，产品经理和程序员之间的关系很微妙。表面看上去水火不容，在一方的眼里看另外一方总是有这样那样的问题，相互吐槽。但现实是，大家都知道和对方在同一条船上。
产品没做好的话，除了公司利益受损，产品经理和程序员也会各回各家各找各妈，重新找新工作去。
产品做得好的话，双方和睦相处、其乐融融？那是不可能的，这个辈子都不可能和睦相处。矛盾会更加严重……（都觉得自己功不可没）
所以Z哥就想来聊聊产品经理和程序员之间的协作问题。不管你是产品经理还是程序员，都应该找到与对方打交道的好方法。好的方法必然是寻求双赢的，而不是一个零和博弈。
这个主题会分别从不同的两个视角展开，今天我们先聊程序员视角，本来想两个视角一起聊，发现内容太多，写到一半还是拆了，先把一个视角写了。
如果你是程序员可以看看以下这些描述是你眼中的产品经理么？
如果你是产品经理可以看看从程序员起家的Z哥给出的一些建议。
程序员吐槽产品经理最多的原因主要是以下几个（以下内容可能会引起程序员们的极度舒适～）：
开发过程中频繁修改需求。验收过程中要求做比较大的修改。说不清楚需求的价值替程序员评估工作量需求整理的不够细。其中，频繁修改需求是程序员们最反感的，这是毋庸置疑的。
从产品经理的角度来说，虽然无法100%在开发过程中不修改需求，但是如果前期的工作做得足够充分，与业务方的沟通足够到位，至少去掉“频繁”两个字还是很有可能的。我甚至遇到过一些产品经理，在自己对业务都是一知半解的时候就开始整需求了，这必然会导致后续频繁的需求变更。
第二，验收过程中要求做比较大的修改。此时往往会伴随一句短语——“这不是我要的” 。每当程序员听到这6个字的时候，脑子里是一万头草ni马奔过……
产生这个情况的原因有很多。可能是程序员理解偏差，也有可能是产品觉得功能效果不佳。但是大多数时候，产生这个情况的根本原因还是在需求评审阶段的沟通不够充分，双方之间并没有达成真正的共识。
但是如果要说什么时候双方的矛盾最激烈，那还不是修改需求的时候，而是需求评审的时候。
此时，很容易看到的一个景象是“讨价还价” 。产品经理站在「价值」一方，程序员站在「成本」一方。当程序员们追问某个他们不认同的功能时，如果产品经理无法阐述出该功能令人信服的价值，那么必然受到吐槽。这是原因三。
原因四，有些产品经理是从程序员转过去的，之前做过一两年的开发工作。这个时长的经验其实是很危险的，很容易陷入到「达克效应」的第一阶段：高估自己的技术能力，低估他人的技术能力和工作难度。这会导致不管是明面上还是私底下会不自然地去评估程序员的工期是否合理，甚至会在需求评审的时候替程序员预估时间，如果高于自己的预估，便会认为他们偷懒。
最后一点。相信每个人程序员都提出过这样的问题“这里如果…… ，那么要怎么处理？” 。这种就是需求考虑不够细致的体现。不过，要做好这点的确挺难的，这也是产品经理花费时间最多的地方。
聊了这么多场景，作为产品经理应该如何应对呢？
从思路上分为以下几步。
01
先明确大方向，并与程序员达成一致。
正如前面所提到的，产品经理站在「价值」方，程序员站在「成本」方，这注定了他们是对立的。最坏的结果就是双方互掐，就算相对好的结果也只是相互妥协做一个半吊子的功能（用系统的人不太舒服）。