最近，又有一件轟動程序員界的事情發生了，想必大家伙都已經奔走相告了。

來回顧下事情的經過，1張圖就能說明白了

騷不？反正有句話叫「從技術層面出發，總歸有辦法實現的」，還有這么一句話叫「從技術角度出發，做都是可以做的」。當年年紀小，還在做DBA的時候，就看著產品和開發懟起來，就因為產品一句「這個總歸能做的咯，要多久啦？」

其實還有個小視頻，30多秒的近景第一手視頻，如果你感興趣的話，可以在后臺回復「solo」即可獲得。

那這件事情就引發了我無限的遐想。其實剛看到別的群再傳這個小視頻的時候其實并沒有在意，就點開看了一眼，然后「哦」了一聲。然后沒多久，有小伙伴給我發了個上面的截圖，我就來勁了。我去？產品和開發懟啊。不懟死丫的產品。要我直接肉彈戰車了……

其實在IT互聯網里一直流傳著一張表格

這張表格有點糊了，大家將就著看一下。

這還不止，其實在開發和運維里也存在著鄙視鏈

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

說回正題，最近我一直在看產品方面的內容，也購買了一些課程、書籍。在學習的過程中，我深刻感受到產品思維對于我們生活以及工作的幫助。

張哥的星球里曾經舉過一個產品思維的案例，是拿賣酸菜為例，帶著產品思維去做和村里的是天差地別的，這個完全可以通過預演得到結果。

我也是從那個時候開始決定讓自己嘗試接觸產品，學習產品思維的。目前已經快有2周了，時間很短，但是感受頗深。

在剛看完「人人都是產品經理2.0」的前六章的時候，印象最深刻的就是「Y模型」以及「用戶說的不能照做」。我們要深挖用戶需求，將用戶需求轉化為實際痛點，如果可以，繼續深挖人性，最后回到解決方案上。

用戶需求是最容易改變的，也是最早接觸的。但我們的經驗告訴我們用戶需求是不能相信的，如果你一味的抄捷徑，直接從1到3，那么剩下的只有深淵。

所以這個時候我們需要往下挖一步，把用戶需求轉化成實際的產品需求，只有產品需求才是可以確定的，但這遠沒有馬斯洛需求來的到位。

為什么3到4是虛線是因為人性的需求并不是每個人都能挖到的，也不是每個產品需求都能被轉換成人性需求。所以這里采用了虛線。

而在表現形式上，產品功能是呈現給用戶的最終形態，需要簡單、易懂。

解釋完Y模型，就可以來說我這個例子了。當時快下班了，我一個同事跑過來問我借錢

我說：要多少

他說：隨便（用戶往往是不知道他要什么的）

我說：那我給你100吧（當用戶不知道的時候，我們需要引導他，比如直接給一個明確值）

他說：行啊（用戶默認接受了我給的解決方案）

我說：你要100干嘛？（換個方式了解需求）

他說：我要付停車費（原來就是付個停車費，我們那只要20一天，不需要100）

我說：那你只要20就夠了啊，我給你20（縮小范圍，直擊用戶痛點），我沒有20不過我可以給你交通卡你拿去刷（當了解清楚真正產品需求后，解決方案是多種多樣的。）

他說：那太感謝了（獲得了用戶的認同）

這個例子就很好的解釋了深挖用戶需求，轉化產品需求的過程。

那么再來看看我們這位產品經理，你說做個變色主題可以，要跟著手機殼來變色？你能和我說說當時是那兩根筋搭在一起才會有這個想法的嗎？我幫你解開。

程序員是需要尊重的，產品也需要得到尊重，這都是建立在彼此認可的基礎上。為什么我和很多同學說做運維要懂開發，就算你做純Python后端開發，也要學點Linux？

廣度可以幫助你深根。

會開發的運維是技術的發展趨勢，是提高生產力的捷徑。

現在很多的產品都是覺得只要出點子就好了，拍拍腦袋的事情簡單，了不起學個原型圖，在會點Excel已經不得了了。要是能做個高大上的PPT那簡直就是人才了。

其實呢？在我看來都是……為什么說懂技術的產品有優勢？不是絕對，但也不算片面了，因為產品脫離不開技術，在做任何方案的時候如果都有一個技術思維在后面拖著，那你的產品一定不會很離譜。

產品經理懂技術最大的幾個好處在于：

能夠準確的評估用戶故事完成周期。

不至于產品在后期加功能的時候，讓程序員重構初期的代碼。

很多產品重構并不是程序員水平不到位，而是產品看得不夠遠，導致給出的產品需求只滿足1.0和2.0 到了5.0的時候，自己都不知道要怎么堆功能了。

而這位程序員呢，我只能說太年輕了……雖然該打，但你在公司里打是影響很差的……太沖動。

這件事情也是第一次真正的把程序員和產品的矛盾公開在大眾面前，小胖以為蠻好，讓很多不了解IT的小伙伴也一起感受一下互聯網圈子的氛圍～

正視這件事情，請產品們不要在胡亂的提些用腳趾頭都覺得不合理的需求了！謝謝！

總結

以上是生活随笔為你收集整理的开发怼产品，天经地义？大惊小怪？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。