産品經理吐槽大會

前兩天網上有個程式員吐槽大會我看挺多人在轉的，這麼公開黑産品經理，除了娛樂效果之外，确實也反映了很多問題。

作為一個前程式員，現産品經理，我覺得還是得說幾句。首先以産品經理的角度自省，然後我再吐槽一下程式員。

禮尚往來嘛！

01吐槽産品經理

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

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

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

舉幾個例子你就明白了。

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

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

程式員拿到文檔去開發時，很可能對這個問題的了解産生偏差，導緻開發出來的産品有問題，最後這個鍋誰來背？

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

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

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

以至于當再次回來進入開發時，之前的問題就是不确定的，程式員如果根據自己的了解做了，最後的結果肯定和預期是不符的。 如果不做，就會卡在那，然後再找産品經理溝通。

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

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

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

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

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

一是一，二是二，别弄怎麼都行的中間狀态。那樣真的很煩人。

02再次吐槽産品經理

第二個例子，是提需求。

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

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

這個需求很簡單，怎麼實作我不管，明天上線。就是這麼直白（沙雕）。

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

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

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

不得不說，大部分的産品經理是不懂技術的，這是行業現狀。 但也有越來越多的産品經理開始學習和了解技術，我一直說産品經理不需要具備技術能力，但需要掌握技術思維。

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

有些産品經理帶着需求過來找程式員，準确說是帶着原型過來找程式員溝通，也不說為什麼要做，也不說做了能帶來什麼好處，開篇就描述功能該怎麼實作。

要麼功能對現有的技術實作方案改動很大，要麼就是技術成本很高。 程式員用技術語言告訴産品經理為什麼做不了，産品經理反正也聽不懂，然後繼續死拽着這個需求向程式員 push，沖突就這樣産生了。

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

上司或者業務方來了個需求，産品經理本身也沒很好的了解，也沒有對需求做轉化，直接就落到程式員這裡。拿着尚方寶劍說這是上面來的需求，隻能做。

程式員此時是無語的，一個奇葩需求還非得讓我寫代碼實作，沙雕得不行。 讓你産品經理吸氣的同時呼氣，你做一個試試！

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

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

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

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

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

03産品經理吐槽

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

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

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

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

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

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

再說一個。

“你找下後端把這個字段定義清楚吧，我不知道具體的資料類型是什麼”，産品經理肯定遇到過這樣的前端。

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

還有。

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

04産品經理再次吐槽

被堵住是什麼感覺？

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

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

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

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

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

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

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

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

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

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

寫在最後

以上，當然不是針對程式員或者産品經理，有的也隻是玩笑。

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

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

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

祝程式員和産品經理們工作快樂！ 

  推薦閱讀

這個女人欠我們的，終于兌現了

騰訊産品、阿裡營運、百度技術、京東項目