开发怼产品，天经地义？大惊小怪？

最近，又有一件轰动程序员界的事情发生了，想必大家伙都已经奔走相告了。

来回顾下事情的经过，1张图就能说明白了

骚不？反正有句话叫「从技术层面出发，总归有办法实现的」，还有这么一句话叫「从技术角度出发，做都是可以做的」。当年年纪小，还在做DBA的时候，就看着产品和开发怼起来，就因为产品一句「这个总归能做的咯，要多久啦？」

其实还有个小视频，30多秒的近景第一手视频，如果你感兴趣的话，可以在后台回复「solo」即可获得。

那这件事情就引发了我无限的遐想。其实刚看到别的群再传这个小视频的时候其实并没有在意，就点开看了一眼，然后「哦」了一声。然后没多久，有小伙伴给我发了个上面的截图，我就来劲了。我去？产品和开发怼啊。不怼死丫的产品。要我直接肉弹战车了……

其实在IT互联网里一直流传着一张表格

这张表格有点糊了，大家将就着看一下。

这还不止，其实在开发和运维里也存在着鄙视链

以上都是玩笑，大家记住就好……不用当真……

说回正题，最近我一直在看产品方面的内容，也购买了一些课程、书籍。在学习的过程中，我深刻感受到产品思维对于我们生活以及工作的帮助。

张哥的星球里曾经举过一个产品思维的案例，是拿卖酸菜为例，带着产品思维去做和村里的是天差地别的，这个完全可以通过预演得到结果。

我也是从那个时候开始决定让自己尝试接触产品，学习产品思维的。目前已经快有2周了，时间很短，但是感受颇深。

在刚看完「人人都是产品经理2.0」的前六章的时候，印象最深刻的就是「Y模型」以及「用户说的不能照做」。我们要深挖用户需求，将用户需求转化为实际痛点，如果可以，继续深挖人性，最后回到解决方案上。

用户需求是最容易改变的，也是最早接触的。但我们的经验告诉我们用户需求是不能相信的，如果你一味的抄捷径，直接从1到3，那么剩下的只有深渊。

所以这个时候我们需要往下挖一步，把用户需求转化成实际的产品需求，只有产品需求才是可以确定的，但这远没有马斯洛需求来的到位。

为什么3到4是虚线是因为人性的需求并不是每个人都能挖到的，也不是每个产品需求都能被转换成人性需求。所以这里采用了虚线。

而在表现形式上，产品功能是呈现给用户的最终形态，需要简单、易懂。

解释完Y模型，就可以来说我这个例子了。当时快下班了，我一个同事跑过来问我借钱

我说：要多少

他说：随便（用户往往是不知道他要什么的）

我说：那我给你100吧（当用户不知道的时候，我们需要引导他，比如直接给一个明确值）

他说：行啊（用户默认接受了我给的解决方案）

我说：你要100干嘛？（换个方式了解需求）

他说：我要付停车费（原来就是付个停车费，我们那只要20一天，不需要100）

我说：那你只要20就够了啊，我给你20（缩小范围，直击用户痛点），我没有20不过我可以给你交通卡你拿去刷（当了解清楚真正产品需求后，解决方案是多种多样的。）

他说：那太感谢了（获得了用户的认同）

这个例子就很好的解释了深挖用户需求，转化产品需求的过程。

那么再来看看我们这位产品经理，你说做个变色主题可以，要跟着手机壳来变色？你能和我说说当时是那两根筋搭在一起才会有这个想法的吗？我帮你解开。

程序员是需要尊重的，产品也需要得到尊重，这都是建立在彼此认可的基础上。为什么我和很多同学说做运维要懂开发，就算你做纯Python后端开发，也要学点Linux？

1. 广度可以帮助你深根。

2. 会开发的运维是技术的发展趋势，是提高生产力的捷径。

现在很多的产品都是觉得只要出点子就好了，拍拍脑袋的事情简单，了不起学个原型图，在会点Excel已经不得了了。要是能做个高大上的PPT那简直就是人才了。

其实呢？在我看来都是……为什么说懂技术的产品有优势？不是绝对，但也不算片面了，因为产品脱离不开技术，在做任何方案的时候如果都有一个技术思维在后面拖着，那你的产品一定不会很离谱。

产品经理懂技术最大的几个好处在于：

1. 能够准确的评估用户故事完成周期。

2. 不至于产品在后期加功能的时候，让程序员重构初期的代码。

很多产品重构并不是程序员水平不到位，而是产品看得不够远，导致给出的产品需求只满足1.0和2.0 到了5.0的时候，自己都不知道要怎么堆功能了。

而这位程序员呢，我只能说太年轻了……虽然该打，但你在公司里打是影响很差的……太冲动。

这件事情也是第一次真正的把程序员和产品的矛盾公开在大众面前，小胖以为蛮好，让很多不了解IT的小伙伴也一起感受一下互联网圈子的氛围～

正视这件事情，请产品们不要在胡乱的提些用脚趾头都觉得不合理的需求了！谢谢！