起點課堂會員權益
職業(yè)體系課特權
線下行業(yè)大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業(yè)技能直播
會員專屬社群
榮耀標識產品經理吐槽大會，程序員勿入
前兩天網上有個程序員吐槽大會我看挺多人在轉的，這么公開黑產品經理，除了娛樂效果之外，確實也反映了很多問題。作為一個前程序員，現產品經理，我覺得還是得說幾句。首先以產品經理的角度自省，然后我再吐槽一下程序員。禮尚往來嘛！
01?吐槽產品經理
做產品之前我是做技術的，主要是做前端開發(fā)，Android 和 iOS 通吃，之前也做過一段時間的后端開發(fā)。
到現在轉產品 5 年多了，以一個產品經理的身份也越發(fā)能理解為什么程序員對產品經理的意見那么大。
其實最關鍵的一點就是“不確定性”。
舉幾個例子你就明白了。
第一個例子是需求評審，在評審會上如果遇到一些沒有定義清楚的問題，通常有兩種處理方法，一種是當場聊清楚，一種是事后再討論。
如果是第一種，可能當時是聊明白了，但是產品經理事后去完善文檔時有可能和會上的結論有出入，或者干脆忘記完善文檔這回事了。
程序員拿到文檔去開發(fā)時，很可能對這個問題的理解產生偏差，導致開發(fā)出來的產品有問題，最后這個鍋誰來背？
因為都參會了，也有共識，但文檔沒體現。毫無疑問，這個鍋該產品經理來背。
產品經理是決策者，需要保證方案以確定性的狀態(tài)進入開發(fā)環(huán)節(jié)，不管是溝通還是文檔。所以這種“不確定性”往往會令程序員比較反感。
如果是第二種，對于評審會上不確定的點進行會后討論，很可能出現因為別的優(yōu)先級插入或者其他事情而忽略了這個問題。
以至于當再次回來進入開發(fā)時，之前的問題就是不確定的，程序員如果根據自己的理解做了，最后的結果肯定和預期是不符的。
如果不做，就會卡在那，然后再找產品經理溝通。
這中間一來一回，效率其實挺低的。一旦不能進入寫代碼的環(huán)節(jié)，程序員都覺得是在浪費時間。
真的，以前我就會這么覺得。聊了半天確定不了，又有很多變數，這種不確定性讓我不敢輕易寫代碼。
為什么，一怕返工，二怕背鍋。
所以啊，產品經理如果想把自己的工作做好，就需要提升自己對需求對方案的確定性，提前功課做足一點。
不僅是需求背景、意義目標、方案細節(jié)、可能的沖突、數據埋點這些，還有就是對過程中的不確定性管理，比如需求變更、優(yōu)先級調整等，都需要給到程序員非常明確的結論。
一是一，二是二，別弄怎么都行的中間狀態(tài)。那樣真的很煩人。
02?再次吐槽產品經理
第二個例子，是提需求。
程序員吐槽大會中提到，產品經理和程序員就像唐僧和孫悟空，唐僧說“我就要取經”，孫悟空說“那得殺了白骨精變成的妖怪”，唐僧覺得不能濫殺無辜，孫悟空又說“那怎么辦”，唐僧說“我不管，我就要取經”。
說實話，我挺認同這段的。做技術時也確實見過這樣的產品經理，做產品后，也見過這樣的業(yè)務方。
這個需求很簡單，怎么實現我不管，明天上線。就是這么直白（沙雕）。
作為程序員，面對這樣的產品經理，和作為產品經理，面對這樣的業(yè)務方，內心真的不知道該說什么。
他們聽不進也無法理解你的表達，死死抓住自己的需求并強烈的 push 給你。這種情況通常是兩個原因，第一種是真的不懂，第二種是傳話筒。
先說第一種情況，真的不懂。
不得不說，大部分的產品經理是不懂技術的，這是行業(yè)現狀。
但也有越來越多的產品經理開始學習和了解技術，我一直說產品經理不需要具備技術能力，但需要掌握技術思維。
簡單說，技術能力就是能上手寫代碼、能改bug。技術思維就是能聽懂程序員的表達、能理解功能背后的技術原理。
有些產品經理帶著需求過來找程序員，準確說是帶著原型過來找程序員溝通，也不說為什么要做，也不說做了能帶來什么好處，開篇就描述功能該怎么實現。
要么功能對現有的技術實現方案改動很大，要么就是技術成本很高。
程序員用技術語言告訴產品經理為什么做不了，產品經理反正也聽不懂，然后繼續(xù)死拽著這個需求向程序員 push，矛盾就這樣產生了。
再說第二種情況，傳話筒。
領導或者業(yè)務方來了個需求，產品經理本身也沒很好的理解，也沒有對需求做轉化，直接就落到程序員這里。拿著尚方寶劍說這是上面來的需求，只能做。
程序員此時是無語的，一個奇葩需求還非得讓我寫代碼實現，沙雕得不行。
讓你產品經理吸氣的同時呼氣，你做一個試試！
我做技術時遇到類似需求就是這樣的感覺，非常不爽。然后覺得產品經理整天都在干啥呢！
這種情況就是典型的沒有對需求做轉化，有的甚至是直接把業(yè)務方案落地成技術需求，沒有經過中間的產品方案。
這就是產品經理工作的不到位了。世界上這么多軟件、這么多需求，如果是一個邏輯合理場景成立的需求，在技術層面實現是沒問題的。
此外，產品方案也不是唯一的，先入為主的拿著老板或者業(yè)務方的方案就覺得是唯一解，那只能說動腦還不夠，沒有發(fā)揮自己的專業(yè)性在業(yè)務和技術間尋找好平衡。
回憶一下，是不是一些沙雕需求其實都有 plan B 的做法。
03?產品經理吐槽
說完了產品經理，下面就該吐槽一下程序員了。
“這個頁面對應的是一個 Activity，如果要加個按鈕新開一個頁面，我需要改一下 Layout 然后在代碼里新寫一個 Intent”。
說實話，有哪個產品經理看懂了上面這句純技術語言？很少是吧，這是 Android 開發(fā)用語。
簡單說，就是一個頁面對應一個布局文件（Layout），按鈕擺在哪長什么樣都在這個文件里登記記錄了。每個頁面的操作都由配套對應的中央處理器（Activity）來控制，頁面的跳轉和更新邏輯都登記在里面。而 Intent 就是一個消息，將一個事件通過消息傳遞出去。
我當過程序員，我也跟程序員合作過。用技術術語跟外行對話的毛病真的得改，不是所有人都懂這些天書，說人話很重要。
業(yè)務用一堆營銷和行業(yè)術語跟你說話，你也懵逼是一樣的。
再說一個。
“你找下后端把這個字段定義清楚吧，我不知道具體的數據類型是什么”，產品經理肯定遇到過這樣的前端。
而實際上，后端程序員就坐在他的前面，非得找產品經理轉一下。拜托，技術問題你們不能直接面聊么，沒必要這么含蓄。
還有。
別總覺得產品經理安排活兒，如果沒人安排活兒，天天在那寫 bug 么！市場是變化的，需求也是變化的，互聯網變化這么快，我們也沒法一招鮮吃遍天。
04?產品經理再次吐槽
被堵住是什么感覺？
就是程序員說“這個需求做不了”的時候。真的，在你說了一堆后，最后這么來一句，也不告訴你為什么做不了。
大家都是專業(yè)人士，專業(yè)人士都講科學依據、有理有據，為啥做不了說出來，結論容易下，過程難推導。
如果做不了，是否有其他可行的方案？別用一句話把大家的路都堵死，堵路不要緊，關鍵是心堵。
咱們都是合作方，相互扶持才是正事嘛！
可能有程序員覺得產品經理水平不行，同樣，程序員怎么證明自己的水平真的行呢，每個人的認知邊界都是有限的。
早上跟老板聊、上午跟業(yè)務撕、中午寫方案、下午開評審會、晚上還要把評審會要修改的東西拿回來返工。
可能程序員只看到了自己和產品經理的這一環(huán)，其實還有很多糟心事他們沒感受到。
說產品經理沒事干的，工作不飽和的，過來輪崗兩天試試就明白了。
程序員覺得跟產品經理說不通，那一定是沒試過跟業(yè)務溝通需求有多費勁，產品經理是擋了多少刀才把需求篩選到技術那。
大家都不容易，互利共生才是正事呀。
寫在最后
以上，當然不是針對程序員或者產品經理，有的也只是玩笑。
程序員和產品經理同在一家公司，公司好大家好，出來做事的嘛，最重要的就是開心咯！
少一些懷疑和抨擊，多一些耐心和理解，狗和猿還是可以和諧相處的。
當產品上線被用戶被市場認可的那一刻，相信所有的吐槽都會煙消云散，一起享受成功帶來的快感。
祝程序員和產品經理們工作快樂！
#專欄作家#
唐韌（Ryan），微信公眾號：唐韌，人人都是產品經理專欄作家。前Juliye Care產品總監(jiān)，《產品經理必懂的技術那點事兒》作者，在創(chuàng)業(yè)公司負責過多款從0到1產品，目前在某電商巨頭負責產品工作 。
本文原創(chuàng)發(fā)布于人人都是產品經理。未經許可，禁止轉載。
題圖來自Unsplash，基于CC0協議
有沒有吐槽群，想加入
讓你產品經理吸氣的同時呼氣。。哈哈哈哈，不過還真的有這么一個技巧哦??可百度下“偷氣”
不過還是建議出一篇完整的吐槽開發(fā)，讓開發(fā)改進自己的文章
總結一下
1、開發(fā)吐槽產品：需求變動大、提需求不考慮實現
2、產品吐槽開發(fā)：用技術術語溝通、這個做不了
產品的吐槽也太弱了吧，復制粘貼代碼、無腦碼代碼沒有產品意識、情商低不會換位溝通、拍胸脯承諾或者開懟最后啪啪啪打臉等，產品還得哄著做事…經驗不足是個核心因素
還在因為“不懂技術”被開發(fā)忽悠？本文作者、前京東高級產品經理@唐韌 帶你15天系統(tǒng)化解鎖產品經理必懂的技術知識。助你日常溝通更順暢，產品設計不挖坑！
詳情戳>http://996.pm/7daXE 或咨詢起點學院蘑菇（wx：qdxymg）
開發(fā):這個需求實現不了。
產品:過來，我告訴你怎么實現。
開發(fā):哭唧唧……慌得一筆……
哈哈哈哈
這些舉例太真實了~還表述了產品經理該如何改進，收藏+點贊