前兩天網上有個程序員吐槽大會我看挺多人在轉的，這么公開黑產品經理，除了娛樂效果之外，確實也反映了很多問題。作為一個前程序員，現產品經理，我覺得還是得說幾句。首先以產品經理的角度自省，然后我再吐槽一下程序員。禮尚往來嘛！

01?吐槽產品經理

做產品之前我是做技術的，主要是做前端開發，Android 和 iOS 通吃，之前也做過一段時間的后端開發。

到現在轉產品 5 年多了，以一個產品經理的身份也越發能理解為什么程序員對產品經理的意見那么大。

其實最關鍵的一點就是“不確定性”。

舉幾個例子你就明白了。

第一個例子是需求評審，在評審會上如果遇到一些沒有定義清楚的問題，通常有兩種處理方法，一種是當場聊清楚，一種是事后再討論。

如果是第一種，可能當時是聊明白了，但是產品經理事后去完善文檔時有可能和會上的結論有出入，或者干脆忘記完善文檔這回事了。

程序員拿到文檔去開發時，很可能對這個問題的理解產生偏差，導致開發出來的產品有問題，最后這個鍋誰來背？

因為都參會了，也有共識，但文檔沒體現。毫無疑問，這個鍋該產品經理來背。

產品經理是決策者，需要保證方案以確定性的狀態進入開發環節，不管是溝通還是文檔。所以這種“不確定性”往往會令程序員比較反感。

如果是第二種，對于評審會上不確定的點進行會后討論，很可能出現因為別的優先級插入或者其他事情而忽略了這個問題。

以至于當再次回來進入開發時，之前的問題就是不確定的，程序員如果根據自己的理解做了，最后的結果肯定和預期是不符的。

如果不做，就會卡在那，然后再找產品經理溝通。

這中間一來一回，效率其實挺低的。一旦不能進入寫代碼的環節，程序員都覺得是在浪費時間。

真的，以前我就會這么覺得。聊了半天確定不了，又有很多變數，這種不確定性讓我不敢輕易寫代碼。

為什么，一怕返工，二怕背鍋。

所以啊，產品經理如果想把自己的工作做好，就需要提升自己對需求對方案的確定性，提前功課做足一點。

不僅是需求背景、意義目標、方案細節、可能的沖突、數據埋點這些，還有就是對過程中的不確定性管理，比如需求變更、優先級調整等，都需要給到程序員非常明確的結論。

一是一，二是二，別弄怎么都行的中間狀態。那樣真的很煩人。

02?再次吐槽產品經理

第二個例子，是提需求。

程序員吐槽大會中提到，產品經理和程序員就像唐僧和孫悟空，唐僧說“我就要取經”，孫悟空說“那得殺了白骨精變成的妖怪”，唐僧覺得不能濫殺無辜，孫悟空又說“那怎么辦”，唐僧說“我不管，我就要取經”。

說實話，我挺認同這段的。做技術時也確實見過這樣的產品經理，做產品后，也見過這樣的業務方。

這個需求很簡單，怎么實現我不管，明天上線。就是這么直白(沙雕)。

作為程序員，面對這樣的產品經理，和作為產品經理，面對這樣的業務方，內心一萬頭草泥馬奔騰而過。

他們聽不進也無法理解你的表達，死死抓住自己的需求并強烈的 push 給你。這種情況通常是兩個原因，第一種是真的不懂，第二種是傳話筒。

先說第一種情況，真的不懂。

不得不說，大部分的產品經理是不懂技術的，這是行業現狀。

但也有越來越多的產品經理開始學習和了解技術，我一直說產品經理不需要具備技術能力，但需要掌握技術思維。

簡單說，技術能力就是能上手寫代碼、能改bug。技術思維就是能聽懂程序員的表達、能理解功能背后的技術原理。

有些產品經理帶著需求過來找程序員，準確說是帶著原型過來找程序員溝通，也不說為什么要做，也不說做了能帶來什么好處，開篇就描述功能該怎么實現。

要么功能對現有的技術實現方案改動很大，要么就是技術成本很高。

程序員用技術語言告訴產品經理為什么做不了，產品經理反正也聽不懂，然后繼續死拽著這個需求向程序員 push，矛盾就這樣產生了。

再說第二種情況，傳話筒。

領導或者業務方來了個需求，產品經理本身也沒很好的理解，也沒有對需求做轉化，直接就落到程序員這里。拿著尚方寶劍說這是上面來的需求，只能做。

程序員此時是無語的，一個奇葩需求還非得讓我寫代碼實現，沙雕得不行。

讓你產品經理吸氣的同時呼氣，你做一個試試！

我做技術時遇到類似需求就是這樣的感覺，非常不爽。然后覺得產品經理整天都在干啥呢！

這種情況就是典型的沒有對需求做轉化，有的甚至是直接把業務方案落地成技術需求，沒有經過中間的產品方案。

這就是產品經理工作的不到位了。世界上這么多軟件、這么多需求，如果是一個邏輯合理場景成立的需求，在技術層面實現是沒問題的。

此外，產品方案也不是唯一的，先入為主的拿著老板或者業務方的方案就覺得是唯一解，那只能說動腦還不夠，沒有發揮自己的專業性在業務和技術間尋找好平衡。

回憶一下，是不是一些沙雕需求其實都有 plan B 的做法。

03?產品經理吐槽

說完了產品經理，下面就該吐槽一下程序員了。

“這個頁面對應的是一個 Activity，如果要加個按鈕新開一個頁面，我需要改一下 Layout 然后在代碼里新寫一個 Intent”。

說實話，有哪個產品經理看懂了上面這句純技術語言？很少是吧，這是 Android 開發用語。

簡單說，就是一個頁面對應一個布局文件(Layout)，按鈕擺在哪長什么樣都在這個文件里登記記錄了。每個頁面的操作都由配套對應的中央處理器(Activity)來控制，頁面的跳轉和更新邏輯都登記在里面。而 Intent 就是一個消息，將一個事件通過消息傳遞出去。

我當過程序員，我也跟程序員合作過。用技術術語跟外行對話的毛病真的得改，不是所有人都懂這些天書，說人話很重要。

業務用一堆營銷和行業術語跟你說話，你也懵逼是一樣的。

再說一個。

“你找下后端把這個字段定義清楚吧，我不知道具體的數據類型是什么”，產品經理肯定遇到過這樣的前端。

而實際上，后端程序員就坐在他的前面，非得找產品經理轉一下。拜托，技術問題你們不能直接面聊么，沒必要這么含蓄。

還有。

別總覺得產品經理安排活兒，如果沒人安排活兒，天天在那寫 bug 么！市場是變化的，需求也是變化的，互聯網變化這么快，我們也沒法一招鮮吃遍天。

04?產品經理再次吐槽

被堵住是什么感覺？

就是程序員說“這個需求做不了”的時候。真的，在你說了一堆后，最后這么來一句，也不告訴你為什么做不了。

大家都是專業人士，專業人士都講科學依據、有理有據，為啥做不了說出來，結論容易下，過程難推導。

如果做不了，是否有其他可行的方案？別用一句話把大家的路都堵死，堵路不要緊，關鍵是心堵。

咱們都是合作方，相互扶持才是正事嘛！

可能有程序員覺得產品經理水平不行，同樣，程序員怎么證明自己的水平真的行呢，每個人的認知邊界都是有限的。

早上跟老板聊、上午跟業務撕、中午寫方案、下午開評審會、晚上還要把評審會要修改的東西拿回來返工。

可能程序員只看到了自己和產品經理的這一環，其實還有很多糟心事他們沒感受到。

說產品經理沒事干的，工作不飽和的，過來輪崗兩天試試就明白了。

程序員覺得跟產品經理說不通，那一定是沒試過跟業務溝通需求有多費勁，產品經理是擋了多少刀才把需求篩選到技術那。

大家都不容易，互利共生才是正事呀。

寫在最后

以上，當然不是針對程序員或者產品經理，有的也只是玩笑。

程序員和產品經理同在一家公司，公司好大家好，出來做事的嘛，最重要的就是開心咯！

少一些懷疑和抨擊，多一些耐心和理解，狗和猿還是可以和諧相處的。

當產品上線被用戶被市場認可的那一刻，相信所有的吐槽都會煙消云散，一起享受成功帶來的快感。

祝程序員和產品經理們工作快樂！

#專欄作家#

唐韌(Ryan)，微信公眾號：唐韌，人人都是產品經理專欄作家。前Juliye Care產品總監，《產品經理必懂的技術那點事兒》作者，在創業公司負責過多款從0到1產品，目前在某電商巨頭負責產品工作 。

本文原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協議

給作者打賞，鼓勵TA抓緊創作！贊賞

總結

以上是生活随笔為你收集整理的程序员吐槽_产品经理吐槽大会，程序员勿入的全部內容，希望文章能夠幫你解決所遇到的問題。

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