前言
知乎上有一个提问：程序员有必要知道为什么做某个功能吗？
不知道程序员的你，在接到产品经理提的一个需求后，是习惯马上动手开始撸代码呢？还是会先暂停一下，认真思考一会如下一些问题，比如这个需求产生的背景是什么？有什么实际使用价值？解决了一个什么问题？
我的回答
据我多年的职场观察来看，程序员拿到一个需求，有主动去思考上述我提的几个点的真是屈指可数、凤毛麟角。
绝大多数的程序员，拿到需求后，第一个反应是想着怎么去实现这个需求(用什么技术亦或什么方案)，最多遇到技术无法实现的或对现有代码改动较大有一系列冲突的，他们会提出来。
我的观点认为非常有必要，因为这正是体现一个程序员是否拥有产品思维的体现。
说到产品思维，那请问到底什么是产品思维？为什么说程序员需要掌握产品思维，拥有产品思维的对我们程序员有什么好处？
先给大家贴一张图，是我近期有在仔细研读的一本计算机书籍，里面主要描述的是反映程序员的底层思维一系列认知与思考。
大家简单看下贴图的文字，相信一定程度会对产品思维有个初步认知：它其实注重的是用户体验，以及用户深层次的需求。
所以产品思维的核心是解决用户实质性的问题，给用户带来真正的价值，提升用户体验。
所以产品思维和我们程序员一贯的工程思维还是有一定的区别的。
个人觉得就像上面说的那样，现在市面上的产品经理水平参差不齐，鱼龙混杂。
一个好的产品经理，你不说，他也会提前告诉你，我为什么要提这些个需求，它们解决了用户什么问题，能为公司、为用户带来什么价值与体验？
但最怕的是，产品经理是某些人(老板、运营、市场)的传话筒。
这些个人信奉主张的观点是：竞品有什么我们也要有什么；先把功能堆出来再说；什么XX大公司很成功，他们有什么用户体验组啊巴拉巴拉一大堆理由，然后来一句我们直接抄他家的功能准没错。简直让你听了大跌眼镜，打破认知。
他们完全不去思考，我们的基因是什么有什么？现阶段，我们最需要、迫切的功能点有哪些？XX大公司并不是所有功能都合理正确，中途也是经过了一手又一手的人（产品技术），导致四不像，仔细用过后，你会有一种，功能撕裂的感觉。
当我们程序员拥有一定的产品思维后，你就可以抛出这些个问题给产品经理：这个需求到底它的背景是什么？有什么实际使用价值？解决了一个什么问题？为什么不能抄？
帮助我们分辨出哪些是真需求，哪些是伪需求，尽可能的将一些伪需求分辨出来，拒之门外。
让我们程序员花时间在真正的需求上面，而不是疲于实现一堆没有太大价值的伪需求，到最后的最后，这些个需求压根用不上或用不起来，最终被无情的抛弃，浪费我们的时间与表情。
PS：上文我贴的产品思维图片内容，摘自阿里高级技术专家——张建飞老师的最新力作《程序员的底层思维》一文，里面介绍了众多它自己多年在一线互联网大厂思考、总结的能提高程序员编程技能、思维认知的一本绝佳好书，感兴趣的小伙伴，可以关注作者公众号，回复“思维”即可免费获取。
OK，今天我的分享就先到这里，接下来，分享两则我们可爱的知友关于这个问题的精彩答复，灰常精彩，一定看到最后哦！
知友作答
回答一
回答二
点击关注公众号，阅读更多精彩内容
