这篇是之前发过的《懂程序员的产品经理是什么样子？》的镜像篇，这次是程序员视角。

两个相爱相杀的岗位，想要更好的达成共识、更好的合作，自然不仅仅是一方的事情。这次Z哥先会带你看看产品经理眼中的程序员是什么样子。然后给出一些我的建议。

直接进入正题吧。

从产品视角是怎么看程序员的呢？我根据我自己的经历以及与其他产品经理的交流下来看，吐槽的主要是以下几点：

1. 这个功能实现不了。

2. 希望所有产品都不要改版，一次性把现在或未来要做的开发完。

3. 只关心要写多少代码，不在乎产品体验。

4. 写完程序从不自测，直接丢给别人测试。

5. 过分追寻新技术潮流，完全不考虑对产品带来什么价值。

第一点，的确存在一些由于技术限制导致实现成本无限大的需求，比如手机屏幕背景色根据手机壳颜色切换……

但是，国内的技术环境不像老美那的技术味道重，大多还是商业导向的，很少企业里需要用到高精尖的技术，所以，真正实现不了的功能微乎其微。

对于大多数的功能需求来说，无非是一个成本大小、价值高低的问题。从立场上看，程序员自然是站在「成本」一方的，但对大多数人来说，决定这个成本的主要因素往往是自己工作的难度和耗时，费时费力的功能就容易得到“实现不了”的结果。

第二点对大多数产品经理来说是他们的对立面。因为大多数产品经理最喜欢“走一步算一步”地高频迭代，甚至是有一个想法就开始干。而程序员则喜欢来一个大而全的，并且内容要非常详细的，心里的想法是，这样的话我一开始就可以设计一个完美架构来支撑它。

而且，内容越详细，产品经理就越不敢乱调整需求，毕竟“证据在手”嘛：D。

第三点在大多数程序员身上都能看到。毕竟做程序员的还是理科男偏多，对需要有同理心、需要靠感受的事情的确弱了一些。

第四点的原因主要有两个。

一个是对自己的代码过度自信导致，我自己深有体会。我还记得有一次我交付一个功能，那个功能我单元测试都写了不少，对质量很有信心，觉得就算有bug也都是比较深层的bug。结果没想到……第一天就测出来好几个低级的bug。

另一个原因是反正有测试人员在，等他们测出问题我再改不是更轻松。惰性使然，从个人角度的确如此。但是从团队角度来看，徒增了不少的沟通成本。

第五点的原因也有两个。

一个是行业里的新技术迭代的确太快，怕不学新技术被淘汰。

另一个原因是，只有用上新技术才能有谈资，显得自己与众不同、有成就感。

以上就是对这五点的简单分析，那么如何改善呢？继续往下看。

下面这些方法都是我亲测有效的，强烈推荐你也试试。这里的序号与前面被吐槽的五点一一对应。

01  说实现不了之前，先三思

根据先后可以做以下3个思考：

1. 是觉得这个功能没有价值不想做吗？

2. 真的实现不了？我想全了吗？

3. 这些方案里，有成本比价值低的吗？

第一个问题先确定必要性。我们不是说不能推需求，而是要推掉低价值、无价值的需求。当然有没有价值不一定你说了算，但至少这才能算是拒绝的理由。

第二个问题，努力拓宽自己的边界、舒适区。如果我们总是习惯性地从大脑的记忆中找解决方案，那么将会永远在舒适区止步不前。

第三个问题，拒绝需求虽然不用动之以情，但一定需要晓之以理。当你能清楚的阐述利弊、收益比，拒绝需求自然不是一件需要相互扯皮的事情。

经过了这三个问题的思考，不管最终能不能实现，相信可以很好的与产品经理达成共识。

02  明白需求本身也是成本

过度地苛求需求要细、要完整、要全面，这个本身也是在增加产品经理需要投入的时间。你的开发成本是成本，产品经理的也是。

与其等一个“XXXX最终绝对不改版”，不如从已经达成共识的部分开工，在这个过程中再与产品经理「共创」，多一起沟通打磨，此时再让产品完善PRD等文档，形成最终版。

03  刻意练习，多换位到用户视角

平时多去体验一下自家的产品以及竞品，把整个过程中的感受记录下来。比如，哪里感到不太顺手、哪里感受到了小惊喜、哪里感到特别烦人等等。结果不重要，重要的是这个过程，慢慢锻炼自己作为用户的感知力。

有些程序员看起来经常把用户体验挂在嘴上，其实提出来的很多反而是脱离大众习惯的“个性化”需求，就是因为平时缺少对同行、外界的关注。

04  交付的东西是自己的「招牌」

“有人的地方就有江湖，有江湖的地方就有称号”。如果长期报以等测出来bug再去修的心态，你在别人心中的称号就是负面的。

轻则影响自己的口碑，影响与他人之间的协作关系；重则失去未来的晋升机会。一个对自己的东西都不负责的人，如何负责更多的人、更大的事情呢？

在这件事上，除了多自测外，作为过来人，我建议每一个程序员认真对待单元测试。特别把核心、复杂的方法单元测试给做上，这对交付功能的质量的提升非常明显。

05  不产生价值的新技术是“垃圾”

拥抱新技术是值得鼓励的。但是单纯的为了体验某新技术而去使用它，这不但给团队在挖坑，也在给自己挖坑。

比如你花了不少的时间在项目里用了某个新技术，但是对团队没有带来什么价值，你说后续公司还会继续投入资源加大新技术的使用吗？大概率并不会。那么之前了解到的一些知识，就会随着时间的推移而淡忘，投入的时间大多数浪费掉了。

所以，对待新技术Z哥的观点是。对于无法在工作中找到价值点的新技术浅尝辄止即可。相反，遇到可以产生价值的新技术，请全身心投入进去，而不是仅仅在应用层面捣腾，不去深入细节。之前发过一篇讲解新技术选用的文章《程序员与新技术之间的「爱」与「恨」》，可以点击文末的链接阅读。

很多程序员对待新技术的习惯是，打一枪换一个地方，经过了几年，发现技术实力还在原地打转，不免有些可惜。

另外，推荐大家可以阅读一两本心理学、行为学相关的书，特别是我们做程序员的。

这不但可以提高自己对用户体验的感觉，还能提高对人性的洞察力，包括对自我的认知。是一项不管在生活中还是工作中都非常有用的技能。

好了，总结一下。

这篇呢，Z哥和你分享了我对程序员如何更好地与产品经理达成共识这件事的看法。主要是以下五点建议：

1.说实现不了之前，先三思。

2.明白需求本身也是成本。

3.刻意练习，多换位到用户视角。

4.交付的东西是自己的「招牌」

5.不产生价值的新技术是“垃圾”

希望对你有所帮助。

如果你有关于软件架构、分布式系统、产品、运营的困惑

可以试试点击「阅读原文」