產品經理與程序員矛盾的本質是什麼？

12-31

理性探討，請勿撕逼。

說原因有很多，說本質的話只有一個：

產品的功能、質量、發布時間和需要投入的資源這四者不能都是封閉條件，否則可能無解。

需要投入的資源和發布時間一般是大老闆定的，所以產品經理、開發經理和質量經理只能在「砍功能」、「降低質量要求」和「程序員加班加到死」這三個選擇上相愛相殺了。

根源是：高層放衛星玩大躍進，那下面只好群眾斗群眾了。

佛曰：與人斗其樂無窮。

對於程序員來說，很多時候問題是 PM 不能證明自己存在的價值。PM 要證明自己的價值有幾種可能性：

有出色的產品記錄，自己的名字就是個品牌，程序員知道跟著你做事能成功。
請長假會導致產品方向混亂項目失控，這很容易證明為什麼你需要存在。
能夠通過程序員可以理解的方式把道理講明白，讓程序員信服為什麼你管理產品的方法是對的，以及為什麼程序員自身不可能做得跟你一樣好。

可能還有別的方法讓一個 PM 證明自己存在的價值，但如果證明不了的話程序員就會把 PM 看作純粹的 overhead（額外負擔）。PM 對產品團隊帶來的價值和負擔是不可能客觀測量的，別人的主觀評價是什麼就是什麼。如果程序員對 PM 的主觀評價是負擔大於價值，那這個 PM 就沒有存在的意義了。

2017-10-02更新

評論區有不少人在因為瀑布和敏捷，PRD工具爭論，這個話題已經和題主的問題偏的有點遠了，這裡我針對評論區的一些討論做個統一回復。

1、要PRD文檔的恕我不能外發，因為答主是乙方，所有文檔產出以後產權歸甲方所有，並且都有簽保密協議，這一塊對不住想要模板的小夥伴們啦~

2、答主自己做的一直是後台系統，採用傳統瀑布式的開發，原答案中的那種PRD文檔確實不適用現在主流的互聯網敏捷開發模式，不管是敏捷還是瀑布，都是根據項目的性質決定的，但產品經理的職業態度是不變的，答主認為，在開發過程中，程序員和產品經理撕逼，大不分情況下都是細節問題，矛盾積少成多，然後就爆發了，為了避免這樣的情況發生，身為產品經理非常有必要在程序員開始coding之前，就將這些細節性的問題都梳理好，至於要做成什麼程度，文檔要細化成什麼樣，不同的項目、不同的產品都不一樣，如何拿捏就是這個產品經理的水準了。

3、咳咳，有人問，你們做的到底啥項目啊，當真不能用敏捷開發？我也不想多說，再多說也偏題了，就貼一張圖來表達就好了：

某個項目中的workflow，我們叫它「蜘蛛網」，你覺得這個流程事先不確定好，後面再改再迭代？程序員會殺我祭天的！

分割線

===========================================================

以下是原答案

作為一個傳統行業在乙方的產品經理，前段時間公司接到一家互聯網公司的項目，我作為項目經理兼產品經理帶了一位高級開發人員入場，談需求，作為甲方的他們也有自己的技術團隊，負責做窗口的是他們的一位產品經理。

這位產品經理和我們說，不需要寫PRD文檔，畫出原型懟就可以了。。。我承認是可以用原型作為開發依據，但是如果沒有詳細的PRD文檔，開發中的細節問題根本沒法扯清楚啊，我和我的開發同事都表示這樣肯定不行。於是我拿出了我們別的項目的一份PRD文檔給他看，他看完目瞪口呆，再也不說話了，說你們寫吧。

文檔大小：54M

字數：25W

所有要寫的話都必須寫在前面，方便別人閱讀。

每一個功能都要寫的清清楚楚，許可權，條件，流程，欄位的屬性，邏輯等等。

涉及到介面的，必須附上介面文檔，可以直接附上對象鏈接。

作為一個傳統行業，一直做瀑布式開發的乙方產品經理，文檔中的內容光是評審就要評審好幾遍，業務方面內容的要甲方一再確認簽字，技術方面的，要內部確認是否有難度能否實現，現有技術框架是否能滿足等等。

我就不信光靠原型可以涵蓋這25W字了么？

我的觀點是，每一個產品經理，再考慮怎麼和程序員撕逼之前，先好好想想自己的本職工作是不是真的做好了？其實很多撕逼本身就是可以避免的，我在工作中遇到的所有甲方提出的需求變更，我都必須要他們發郵件，為什麼要發郵件？就是要留痕啊，開發軟體也是一個道理，白紙黑字，寫的清清楚楚，職責劃分清楚，撕逼撕的不都是這些細節的東西么？

我不排除現在很多程序員開發的時候不看文檔，這種程序員很多，這時候我可以大聲的對他吼：文檔第XX章第XX節寫的清清楚楚，就是這麼做的，你眼瞎嗎？？

總之，作為產品汪，要不想和程序員有矛盾，多先考慮從自身找問題！

先說結論：產品經理和程序員的矛盾是永遠存在的。

核心原因是——好的產品經理永遠缺貨。當然，優秀的程序員哥哥也缺。既然都缺貨。為什麼矛盾的核心要指向產品經理？

不要生氣，聽我把話說完——（移動）互聯網的發展快，人口紅利的風口多，給大家帶來了「產品經理很容易」的假象——然，產品經理爛大街，合格的產品經理永遠缺貨。一個不知天高地厚的不合格的產品經理帶來的「危險」，懂的人都懂。

所以，再一次，既然都缺貨，為什麼矛盾的核心要指向產品經理？

聽我說，這個邏輯很容易理解：

產品經理是決定公司效率高低的關鍵，產品經理在一個成熟的公司成熟的團隊意味著靈魂和中樞，程序員哥哥不過代表著執行力和能力的邊界（想不明白就瞅瞅喬幫主馬化騰周鴻禕）：1個不知天高地厚的產品經理，2個不經過思考的決策，他的工作量也許只增加了3倍，但他賦予程序員卻是10-1000倍的工作量。

（以上邏輯總沒有錯？）

是的， 我首先想要表達的就是：「人人都是產品經理」是個偽命題，是個一廂情願的想法，是導致矛盾的根本。反正有時間，那就展開說一下：

好的產品經理至少得具備：

一：懂技術（多義）。

產品經驗豐富當然好，如果你有技術功底，你就能在關鍵時候對技術的選擇作出及時、有效的決定。我這裡說的「懂技術」至少包含了兩個含義：

一層指懂技術這個群體。

一層指懂技術原理。

產品經理需要「懂技術」的本質是：

1可以和程序員在同一個語言環境內無障礙對話，讓團隊和產品雙贏。

2懂技術，一來不會不知道天高地厚，二來有了良性互動，團隊可以少一點撕逼，產品可以少一點試錯，關鍵是節省時間。當然了，如果你是沖著「鄙視程序員」或者「秀能力」去的，這個想法相當的危險。

產品經理「懂技術」需要懂到什麼程度？

1歸根結底與――與你所在公司的產品形態有關。

2事實上和越強的技術配合，你需要懂得就越少。

3你若是溝通能力不錯、理解能力也強，你需要懂得也越少。

4不需要「翻譯」是入門級，別得意。

5知道與你合作的每個程序員哥哥擅長什麼，產品出了問題，你知道找誰。

一言以蔽之：工作重點是落在「懂」的，而不是「看啊，我特么知道如何編程，你個程序員敢騙我？」。

二：產品人的思維習慣。

當然，好的產品經理不應該有思維定勢，這裡說的思維習慣，只是分享一下我身邊那些CEO的思維習慣——如果我們默認「優秀的 CEO 往往都是一流的產品經理」。

1尊重事實。

2資源永遠有限，要擅長單點突破。

三：最起碼的邏輯能力。

待碼。

四：整合能力。

待碼

五：溝通能力。

待碼

六：掌控能力。

待碼

七：直覺和想像力。

待碼

八：培養一些好的工作習慣。

待碼

總結：所有指標里，為什麼沒有「智商」的要求，人和人最大的差別就是認知，而不是智商。自以為是，沒有敬畏之心，是自我認知的死敵。沒有人是傻瓜，特別是程序員哥哥。

好的，讓我們再一次回到問題本身：

產品經理與程序員矛盾的到底本質是什麼？

答：當我們明白了產品經理的本質，大家再來看看大部分產品經理的現狀（我自己的觀察）——

1不懂邏輯。或者邏輯混亂。

2不懂技術實現的原理，會拼出「JavaScript」或者「python」這些單詞而已，就以為自己懂了這些語言。

3不懂程序員群體。在網上認識一個程序員哥哥，微信聊幾句，就以為自己懂了天下所有程序員。

4沒有整合能力。

5沒有掌控能力還喜歡當官，想程序員服你管，也得有最起碼的資本。

6溝通能力差還學不會好好說話。

7中國確實也缺少原創的環境。

8中國互聯網骨子裡就缺「產品經理」的基因。

9行業風氣。

這種環境下出現的產品經理唯一會做的事情就是——「堆功能」。

堆功能的本質是什麼？

就是：

1：公司文化造成的。

2：向領導邀功。

3：急功近利，只想著向外界證明自己。哪裡管程序員和公司的死活。

4：大老闆逼的。

5: 沒有學會「忍」。

6:性格沒有問題，能力沒有問題，但工作習慣真的不好。

其他毛病就更多：

7不理解技術實現的代價。

8或明知故犯，因為他們要通過「堆功能」來滿足上級的考核，根本不關心程序員需要付出什麼樣的代價。

9沒有合作意識。

10自己蠢也就算了，還要想辦法比程序員拉到和她一個水平。

11聽不懂程序員說話。

12遇到問題，只會利用「讓程序員加班加到死」解決問題。

13因為什麼都不「懂」，經常出現一些無關緊要，卻很難實現的功能。

14自己的本職工作都做不好，不停的返工，導致程序員工作大部分是作廢的。

15一個沒有經驗的，還有話語權的產品經理會使項目失敗的速度加快。

16互聯網項目，移動互聯網項目。是一個個非常複雜的構成。所以，你看，產品經理首先要清楚是自己想要的產品是什麼，市場想要什麼，用戶想要什麼，自家程序員哥哥們都是什麼水平。你、你團隊，你公司的能力，能讓你做什麼事情。不要給「無辜」的程序員哥哥「找麻煩」，還說人家不配合你。

（算了。說得太多，我也累了，算了。）

最後：產品經理們不要委屈，我明天會寫「優秀的程序員哥哥為什麼這麼少」。

文章很長，謝謝你看到這裡。

對程序員來說，技術是手段，需求是目標。

對產品經理來說，需求是手段，用戶是目標。

對老闆來說，用戶是手段，盈利是目標。

認知不同，定位不同，也就有了矛盾。

同意 @覺淺的說法，因為不學無術，自以為是。

和其它職位不同，產品經理的不學無術，後果是讓程序員來背的；而程序員的不學無術，又會影響產品經理完成自己的任務——後果包括但不限於加班、沒節假日、項目無限延期、被不明所以的老闆罵的狗血噴頭、壓力過大精神失常乃至過勞死等等。

補充：經評論區實際案例提示，另還有一種情況：產品經理奴顏卑骨，不敢為公司、為團隊主張應有的、甚至只是最基本的權利；而是各種委曲求全、任由甲方玩的團團轉；自個吃裡爬外、跪地下任人作踐，卻還總能感動自己。這種閹人完全搞不懂自己的職責所在，只會以叭兒狗的本能對任何敢對自己使臉色的人溜須拍馬。它的存在，不僅給團隊帶來毫無意義的沉重負擔，還把整個公司置於極大的風險之中。正文只討論正常情況，這種等外品不予討論。

想討論產品經理-程序員的矛盾，首先得知道軟體開發是怎麼回事。

軟體開發根本上說，和其他工程項目沒什麼不同：都是做某件事。

就好像一間工廠一樣，首先需要選定一個目標（食品廠？玩具廠？具體哪種食品/玩具？）；然後購買/建造生產線、購買/製造模具、安裝、調試、試生產，最後正式開工。

如果你一開始打算生產農藥的，結果廠房都蓋好、生產線也安裝調試完成，就等著驗收了……你說我改主意了，咱造飲料——都差不多嘛，不都是弄點液體裝瓶子里貼上標籤賣出去嗎？你來弄個方案，別動我的廠房，盡量少動生產線，給你三個月，我要看到飲料廠。

這不扯淡嗎。

現實生活中，當然沒有這麼扯淡的老闆。但在軟體開發領域，這樣做事的團隊卻比比皆是。

典型問題可分三大類：

1、需求不清

需求不清是最為致命的。連造農藥還是造飲料都沒搞明白，你敢指望這個項目能有好嗎？

但是，在代碼的世界裡，因為不像現實世界那樣，你得鏟車鉤機甚至定向爆破，弄出一片斷壁殘垣的慘烈景象……

所以，很多人就掉以輕心，以為「改一點沒什麼」、「哪個項目都得改來改去」甚至「敏捷開發的意思就是改啊改啊就成功了」。

你信么？

這種玩意兒最典型的表現，就是需求文檔喜歡興沖沖的詳細描摹軟體界面細節（這是UI設計師的工作，壓根不應出現在需求文檔中！），卻對產品目標、應用場景、核心數據與功能邏輯等要害問題避而不談——即「該說清楚的提都不提，不該干涉的長篇大論」。

正確做法：徹底搞清需求，不把自己變成客戶領域的半個專家就別回來；如果對技術太過抓瞎，帶你們部門最優秀的技術專家去，讓他搞定需求（程序開發是個超級交叉學科，好的技術專家必然是萬能的。別看平時再木訥，但常常只有他，才能和客戶方技術專家談得來）。

評判標準：至少得讓自己（或需求團隊）對複雜/未知場景單獨做出的90%以上的判斷/決定，能和客戶想法一致。

2、設計不明

設計不明基本都是需求不清的後續問題。

很難想像，一個能做清楚需求的產品經理，能忍下含含糊糊的扯淡設計。

然而……很多產品經理壓根就不要設計文檔；或者，把設計文檔和UI設計混淆——就好像他們熱衷於在項目需求中設計UI一樣。

根本原因：產品經理是個既不懂程序開發、又不懂客戶領域的雙重外行，或者兩者全都理解岔了的雙重半吊子。這種半吊子水平，使得他的理解嚴重浮於表面，從而自然把團隊導向「拿UI當需求」的扯淡之路……

正確做法：先搞定需求吧，乖。

3、設計不良

設計不良是技術人員的鍋。

根本原因：技術人員能力問題。包括但不限於未能正確理解需求、抽象能力差、對技術缺乏掌控力等。

正確做法：好的核心設計是不需要改的。只要核心需求明確穩定，那麼你盡可以加多功能、改變流程、修改UI，但核心代碼一定是「寫完即凝固」的。如果你的技術人員做不到，請找能做到的人。

軟體開發，和其它任何工程一樣，分需求-設計-開發（建造）-測試（驗收）四個主要階段。

其中，需求和設計階段是關鍵。這兩個階段，完全可以，也必須做到「無需返工」。

說的更準確點，需求和設計文檔，需要做到「可以續寫很多條目，但不得刪除/修改已有條目」。

就好像你修工廠，目標是造農藥還是造飲料，這是必須搞清楚的，絕不容含糊。

類似的，建造工廠之前，哪塊搞生產、哪塊建庫房；鍋爐放哪、蒸餾塔建哪，必須搞好規劃；絕不能按藍圖施工半年了，發現尺寸對不上、甚至乾脆漏裝了某個關鍵設備，麻煩就大了。

只要需求明確、設計合理，這個廠子必然可以正確、穩定的運行下去；之後再搞什麼廠區綠化、增設員工休息區甚至引進機器人什麼的，都是不動筋骨甚至不傷皮肉的錦上添花之舉。

真能做到這一步，矛盾自然就沒有了。

不學無術，所以明確不了需求、或者即使明確了需求，也做不出扛折騰的好設計；然後，也因為不學無術，所以不僅無法準確指出錯誤所在、提出解決方案，反倒相互指責、把矛盾引向下三路。

自以為是，使得他們永遠理解不了問題所在，甚至把種種醜態視為理所當然、是軟體開發工作的「正常狀態」，從而永遠認識不到自己的不學無術。

最後，差之又差的，因為不學無術，所以壓根不知道哪些是自己的權利、更不知道主張這些權利只會為甲乙雙方帶來共贏；反倒無原則無底線，跟著甲方外行的指揮棒瞎胡鬧，致使開發計劃被打亂（甚至壓根無設計無計劃）、有能力的開發人員大量出走、代碼敷衍塞責，埋下工程質量低劣、延期、失敗的隱患，給雙方帶來嚴重損失。

————————————————————————

集中回答一下評論區那些幹了產品經理的銷售代表的問題。

問：部級部門玩你怎麼辦

答：部級部門很忙的，沒時間消遣你。

我明白，作為一個推銷員，你會遇到客戶的很多很多刁難——你賣甜豆腐腦，過來一人說我是咸黨；你改賣咸豆腐腦，過來一群人說你異端……

作為一個最最底層的推銷員，你確實沒辦法。於是你只好今天告訴客戶經理，客戶要甜的；明天你又報告說客戶要鹹的。

正常情況下，客戶經理會罵你一頓，說你這人怎麼這麼死腦筋，連街邊練個攤你都幹不了。有人要甜的有人要鹹的，你就兩樣都帶點，隨他選擇嗎。

你看，客戶經理不愧是經理，人家就是能想出解決方案，解決毛孩子束手無策的問題。

當然，這樣一來，你就得吃力的拉著兩個大桶，一桶甜一桶咸……

然後，技術部一小兵喊住你了：「你這人怎麼這麼傻？有你這麼賣豆腐腦的嗎？弄一桶無味的就夠了，糖和鹽裝小瓶子里，讓客戶酌情添加」——你看，你省力了，客戶口味有輕重的問題也解決了。

同樣的，軟體開發這個行業發展了這麼多年，同樣有無數種滿足各種口味人群需求的現成方案。

比如，最最基本的，UI和邏輯分離（典型如QQ換膚功能）等等。

如果你事先提出了「UI需頻繁修改」的需求、並將其作為一個功能點安排了開發時間，那麼哪怕之後你每十天半月都要改頭換面一次，技術部門都能夠支持——只要軟體邏輯不變。

類似的，需要經常調整流程？那麼這就叫「流程可配置化」需求。我們有無數種現成的框架來支持這種需求——前提是，你得事先明確這個需求，我們自然會安排時間，在這個點用上合適的框架。

所以，按照現代標準，如果一個產品經理只能做到上面小故事裡客戶經理的水準，他是不合格的。

事實上，他應該在練攤的銷售人員發現問題之前，就通過市場調查等多種手段，發現目標人群存在口味差異（甜黨/咸黨），從而直接把「滿足這個差異」作為需求列出，要求技術部解決問題——具體如何解決，你並不需要知道。只要你把需求摸清楚了，技術部搞不定，就是他們的問題。

我在正文第一條便指出過，需求達標的判定依據之一，就是產品經理本身得把自己訓練成客戶領域的半個專家——非如此，你是不可能做出「核心功能/邏輯是……在xxx和xxx存在何種差異、需要通過策略配置/界面選擇切換」這樣的需求的。

換言之，如果你是個練攤都練不利索的毛孩子，我可以體諒你今天爬回來告訴我「張局長想要這樣」、明天你又爬回來捅出來一句「王局長說他們情況特殊」——這沒辦法，經驗/智力差距太大，所以我們才安排你出去練攤的。甚至練攤沒練好都得怪我們沒教好你。

當然，你這麼蠢，挨罵也是不可避免的——畢竟練攤的人精也是不少的，我們怎麼就攤上你這麼個傻孩子。

但是，如果你是個產品經理，不能第一時間捕捉到「張局長和王局長業務重點/面對環境不同，在某某功能有所分歧」的信息、然後深入調查雙方分歧所在、不能事先做出「我們需要在這裡做成可配置策略，以同時支持兩位局長的工作」這樣的合理判斷——你丫還是回去練你的地攤吧，你的智商面對產品經理這個職位的基礎要求……像蚍蜉撼大樹一樣可笑。

呼應第一句：客戶沒時間沒心情更沒膽量去消遣你——除非你表現的像一個傻孩子。

恰恰相反，需求調研正是他們表現自己的機會。

是人都有表現欲，平常默默無聞，現在終於有個「兄弟單位」來問我們都干點啥了，神奇的是他必須認真聽我吹、還必須聽懂……哎呀我可得讓他們知道知道，我們平常乾的活都有多高大上——凡做過需求調查的，對這種心理再熟悉不過了：還是那句話，除非你是個不可理喻的傻孩子。

怎麼判斷自己是不是被人當傻孩子了呢？

很簡單，看人家大致聊一下做什麼然後大家都覺得沒啥好說的了、於是興緻勃勃和你聊八卦呢；還是興緻勃勃的和你聊具體事物的某一細節有多複雜、又該怎麼解決、甚至你經常一句話都能問的他們陷入思考或者爭論（這種地方需要特別注意），從而使他們拿你當內行看。

然後，把人家的細節串起來，看看有無遺漏或者邏輯不通之處，猜一猜，倘若遇到非常非常奇葩的特殊情況，他們應該怎麼做，然後問問看，看自己猜的和人家的答案是否一致。

這就是需求。

這裡面最大的陷阱就是，你覺得你什麼都懂了，其實你什麼都沒懂；人家天天玩，早把某些東西當常識、以為你肯定知道了，你不問，人家當然就不會說。所以沒聊幾句，雙方都覺得「說清楚了」，多餘的時間當然只好用來八卦（不然會冷場）——然後，當然是沒完沒了的需求更改，以及沒完沒了的唇槍舌劍。

傻孩子才會因為自己的榆木疙瘩表現，導致一次兩次十次八次都挖不出需求全貌，非得做出來不行客戶一個個捅過來給你——然後開發人員惱、客戶拍桌子罵娘找你老闆，傻孩子夾在當中里外不是人。既傷感情又浪費雙方的寶貴時間。

所以你看，對那些聊不清楚需求的傻孩子，說他們「不學無術」，是否精當？

PS：記得有人說過，網路辯論最為無聊的一點，就是逮住對手陣營里最傻最2B的貨一通狠K，然後自以為佔了上風。

現在看來，我的這個回答，不可避免的被評論區帶到了「對著連『練地攤的傻小子『檔次都不如的一些產品經理一通懟「的節奏上。

有趣的是，我明明也指出了「只要需求明確穩定，哪怕之後增加功能、改變流程、修改界面，核心代碼都應該做到『實現即凝固』。凡做不到的技術人員皆不合格，需要尋找有這種能力的「——這個要求可著實不低，一些senior engineer都未必能做到；但卻不見有技術人員敢來懟我。

有趣。有趣~

產品經理和程序員之間矛盾的本質就是地主家的狗腿子和地主家的長工之間的矛盾

若以用戶為出發點，不同的背景會有不同的觀察角度。爭鳴會趨向最優體驗，不爭就不對了。若是本位主義，這樣的團隊離死不遠了，沒什麼討論價值。

感性VS理性

無序VS邏輯

行空VS嚴謹

開放VS保守

我覺得VS我認為

P.S. 彼此很少有矛盾的是真愛。

世界上大部分的矛盾，都是源於人們認識的片面，產品經理和程序員的矛盾也不例外。具體表現在，雙方都對彼此的職責劃分不明確，產品經理尤甚。

這裡有幾個典型的場景：

1 許多產品經理考慮需求時只考慮功能、交互和視覺，基本無視背後的邏輯（或者說許多產品經理邏輯思維太差）。他們不清楚某個功能到底會走哪些流程，甚至不知道實現該需求要調動哪些資源，聯繫哪些部門。這樣的PRD只是一紙空文，這樣的需求根本無法push。

2 一些程序員正是因為看到場景1經常發生，所以每次需求評審會他們總是事無巨細地提問。他們會把技術問題問個遍：介面怎麼定義、某些測試用例怎麼寫、甚至是之前的功能是怎麼實現的。一方面，他們要告訴PM這事兒沒這麼簡單；一方面，他們要確認需求確實ready了。然而，和PM探討技術方案，基本是對牛彈琴。PM本身也不需要知道技術細節。最終，需求評審會變成了技術研討會，會議時間無限期delay。

3 迭代過程中，程序員總會遇到各種問題：需求確認，需求變更，測試環境出錯等。很多情況下要依賴其他同事甚至其他部門解決問題，這時PM要實現樞紐和橋樑的作用。遺憾地是，很多PM在解決這些問題時效率極低，有的PM甚至要開發自己找人解決（他們怎麼會知道找誰？）。問題的根源還是需求沒考慮清楚。

4 正是由於職責不清，一些程序員會覺得PM根本沒做多少有用的事情，是可有可無的角色。一些PM則認為程序員問題太多，總是麻煩自己，而且能力不足造成了需求delay。某些不靠譜的人的出現也強化了這些想法。

國內互聯網產品經理是新興職業，大學還沒有對應的專業，程序員也沒有早多少年。這種矛盾的存在是必然的。我想，雙方對彼此的工作職責、工作內容多一份了解，心中對彼此就會少一分怨念和鄙視。

目標論，定位論雖然看上去高大上，但是是不對的。

pm和rd的共同目標在於，做出產品。

矛盾在於，pm不懂軟體工程，會阻礙rd的開發過程，並且不覺得是自己的問題。

這是很常識的一件事，各種書上都講透了，只不過現在發財的那批老闆還不懂這些，等大浪淘沙吧……美國軟體業淘了這麼多年了，不也很多情況和中國類似么……

pm噴rd，無非是一些這麼簡單的東西為啥說很難做？這麼簡單的東西怎麼還沒做好？為啥說我這個做法是錯的？之類的幼稚言論

所以，如果，非要說rd有錯，那大概錯在沒有向老闆科普一些常識吧……碼農畢竟沒有政治鬥爭經驗，笑

所以說本質是公司too young所以招了些沒能力的人嗎……？

程序員：「這個功能為什麼要這麼設計？」

產品經理：「xxx App就這麼設計的呀」

根本矛盾在於：大多數產品經理無法用產品自身的邏輯說服程序員。

這答案現在接近100贊居然被排到只有1贊的答案後面,看來是戳中了不少人的痛處.

矛盾的本質是大部分產品經理的不專業性.

理論上產品經理的職責:

1.幫助不專業的甲方或者領導整理出可用的需求文檔.

2.根據需求文檔整理出一套完整的業務邏輯體系.

可以不懂任何技術,不知道背後有哪些表,但是各個功能各個數據之間的業務邏輯關係設計一定要清晰.

3.整理出各項功能和需求的輕重緩急,排出合理的開發順序.

4.尊重功能的工期預排,頂住甲方或領導的臨時變更需求和不合理的進度安排.

假如一定要變更需求,一定要走正式流程並增加合理的工期安排.

實際上大部分的產品經理的表現:

1.寫出來的需求文檔幾乎不可用.

需求文檔近乎一句"做成和淘寶一樣"或者"做一個商城"這樣的級別.

2.根本整理不出完整的業務邏輯體系,設計靠嘴傳遞.

以至於把設計文檔做成UI文檔,連個功能業務流程圖都畫不出來.

3.根本就是甲方或者領導的傳聲筒.

無論是各項功能的輕重緩急還是甲方或者領導的臨時需求變更和要求工期,都發揮不了任何作用,直接原樣傳回給程序員.

這樣的產品經理對於程序員有什麼真正意義上的作用嗎?

對於程序員來說,根本就只是一個"不給錢的狗腿監工"而已.

你說狗腿監工和長工的矛盾本質是什麼?

以下是我最近一次和產品經理的會議發生的情況:

產品:這個功能是很簡單的一個功能,就是一個表格根據搜索條件展示所有符合條件的行業,然後加一個按鈕可以增加和刪除行業.表格有這麼幾個列......,都是行業本身的一些屬性,展示一下就行了.

我眉頭一皺,總感覺事情沒那麼簡單:其他列我都知道,都是行業的屬性,展示出來就行了,但是這個"行業標籤"是什麼?我們根本沒有這個屬性,到底什麼用的,怎麼來?

產品:對,這個屬性原來是沒有的,所以要新加一個這個屬性,就是很簡單的,手動增加或者編輯的時候可以輸入這個屬性,就是文本而已.

我心中的第六感警報已經在瘋狂作響:這就是一個備註一樣的用來看的欄位?那為什麼不直接叫備註?而且為什麼我看你這裡寫的事例都是幾個詞語中間用逗號分隔?

產品:哦,這個欄位除了這裡看之外,後面的功能還要用到的,所以不單純是備註.

我:那麼具體是什麼用呢?(乖巧.jpg)

產品:還沒定具體是哪種,但是基本就是要麼標籤可以在選擇行業的時候,把標籤當做一個行業選擇,或者新增一個行業標籤的選擇項,選擇了哪幾個標籤就等於選擇了所有有這個標籤行業.

我,尷尬而不失禮貌的微笑,臉上笑嘻嘻,心理mmp:...

(1.尼瑪,要在別的地方用來選擇生效的值,你告訴我只是簡單的展示用的屬性?

2.原來行業體系是一張表的設計,只能是單關聯的樹狀結構,這等於額外又多了一套可用的行業體系,肯定是要增加表來修改行業體系的,你就這麼輕描淡寫地帶過了?

3.而且這種要進行關聯的外鍵屬性,而且還能多標籤的關聯,你居然設計是用文本框輸入,用戶輸入時自己用逗號隔開?)

設計補圖:

就算單純從用戶體驗的UI設計角度來說,也不該把這種功能做成這樣"樸實"的文本輸入框吧?

知乎要是把類似的問題標籤功能設計成"樸實"的文本輸入框,那這產品經理基本就要被用戶天天罵了.

我實在不知道這樣的產品經理用處是啥.

這應該是某些人共同的疑問吧:難道程序猿就都不會有錯嗎?

我就在這裡回復一下吧.

這種程序猿我當然也知道有(排除4這個情況不知道是不是真的不能做),但是這裡我們不說到底這種程序猿多還是我答案寫的產品經理多,畢竟可能有些主觀,沒有統計數據.

但是有一點我們可以確認,這種程序猿,通常沒有辦法造成題目所說的"產品經理與程序員的矛盾".

這種程序猿會理直氣壯地用你說的這種理由去和產品吵架嗎?

既然產品有詳細的需求文檔,那產品還不拿XX日期XX版文檔直接甩他一臉?

就算他們用這種理由吵,難道最後會對產品有任何影響,需要產品加班來彌補程序猿造成的失誤,或者為程序猿背鍋嗎?

這叫單方面被罵.

既然如此,又哪來的"產品經理與程序員的矛盾"?

我說的這種產品經理就不一樣了,他們會理直氣壯地用這種借口去開發吵.

他們完成不了自己的職責的結果是連累到程序猿背鍋和加班更改需求代碼.

另一個問題:老闆或甲方根本沒想好需求就隨便胡來,是不是該聽老闆的瞎搞一通,然後浪費時間精力,而且還要賠上自己的個人利益去加班,再來回反覆改,甚至期間還可能因為需求設計不完善造成其他損失.

我覺得這個問題根本不需要回復了.一般人都應該知道無論從公司角度還是從個人利益角度都該選擇哪種做法.

但是有的人的腦迴路就是要聽老闆的,我也真是搞不懂了.

這麼說會計應該因為是老闆就可以忽略財務流程和規範就直接對公司資金隨意操作?

別啊,回復我啊.就一個註冊登錄,你能搞出多少問題來?求實錘,別BB

這是此人原來的回復,我沒截圖,居然這回復被刪掉了.

以下為應他的要求的實錘,由於隨便一想立刻想到的東西寫出來就太多了超過回復字數限制,就直接發答案吧.

你該考慮一下,開發如果真的只需要你一句"手機+用戶名註冊"就能明白所有業務邏輯,那麼你存在的意義是什麼?

老闆說不出這麼一句話?

註冊和登錄的破事可多了好嗎?實際上都可以寫幾篇文章出來,搞個專欄了好嗎?

以下僅為開發角度,事實上這些幾乎每個問題都能在產品角度考慮出一大堆東西.

首先最直觀的第一反應,登錄和註冊前是否什麼事情都不能做,所有操作都建立在登錄和註冊之上?如果否,那麼哪些操作可以在登錄之前操作,如果遇到了需要登錄的操作,提示跳轉等如何設計?

然後,手機+用戶名註冊,用戶名和手機之間的對應關係到底是什麼?

完全的一對一關係?還是一個用戶名可以綁定多個手機?或者一個手機綁定多個用戶名?

通常這個問題就會直接影響到背後的表結構設計.

接下來是有沒有可能會有三方註冊登錄的設計?

如果有的話,和現有的註冊流程怎麼結合?是必須要註冊新號還是可以綁定已有的賬號?

如果是第三方時要註冊新號,到底哪些信息是需要用戶輸入的,還是所有信息都由系統自動創建?

再然後,手機+用戶名註冊,需要用簡訊驗證碼驗證手機,那麼還要不要密碼?

實際上現在大量的產品都設計了只用手機號+驗證的註冊和登錄渠道,我們要不要有這種渠道?

甚至是我們要不要只設計這種渠道?

再接下來如果一定要有密碼的話,那麼註冊的時候是否要強制用戶設定密碼?

比如說是不是可以直接只用手機號+驗證註冊,然後生成簡單的初始密碼,客戶可以自行修改?

甚至可以聯想到是否會設計一套功能體系用戶客戶的登錄,比如說客戶用什麼渠道註冊,就只開通了哪種登錄方式,然後客戶在註冊完登錄進去後,可以手動更改開啟和關閉哪些登錄方式.

接著如果要設定密碼的話,那麼密碼的要求是什麼?

前段時間爆出消息,密碼複雜度概念的提出和設計者認為現在認為密碼複雜性規範是錯誤的,那麼項目到底還要不要設計這個概念進行校驗?

如果不使用密碼複雜度這個概念進行校驗,但是也不能讓用戶把123456這種最常用的簡單密碼設置為密碼,那麼密碼設置校驗規則要有哪些?

甚至這個自定義的密碼設置校驗規則體系可以設計地非常複雜,比如說根據當前擁有多少用戶信息,就增加哪些校驗規則.

比如說已經擁有了用戶的手機號碼,那麼校驗規則中就增加用戶不能用手機號的連續XX位作為密碼.

比如說已經擁有了用戶的生日和身份證號碼,那麼校驗規則中就增加不能用生日和身份證號碼中的連續XX位作為密碼.

事實上,騰訊的QQ的密碼更改規則的"有過被盜或者說被異地登錄記錄的多久時間之內的用過的舊密碼不能作為新密碼"就是這種自定義的密碼校驗規則體系.

騰訊的這種設計甚至都已經影響到了用戶表的結構設計.

然後註冊和登錄的時候,我們要記錄哪些用戶的信息?

比如說是否要記錄註冊和登錄時用戶用的是手機還是PC?

接著我們說驗證,你看你的原話

難道連那些基本規則（用戶名/手機號是否已被佔用、重複輸入密碼是否一致、手機驗證碼是否正確）都還要一條一條的羅列出來嗎？

實際上我們上面說的註冊規則的一些疑問已經完全影響到了這裡你所謂的"不需要提的基本規則".

比如說用戶名和手機之間的對應關係,對"用戶名/手機號是否已被佔用"規則有影響.

比如說是否強制在初次註冊時設定密碼,對"重複輸入密碼是否一致"規則有影響.

比如說大小寫字母是否視為相同字母,對"手機驗證碼是否正確"規則有影響.

同時,我還一下就想到了很多你沒提到的驗證規則的疑問.

驗證碼有效期多久?

用戶收了好幾條驗證碼後,都在有效期內的驗證碼是只有最後一條有效還是都有效?

同一個用戶對於發送驗證碼的請求有沒有限制?多久才能申請發送一次?

同一個手機號有沒有單位時間內的驗證碼請求限制?多久能發送一次?一天內只能發多少條?

驗證碼範圍包括什麼?只有數字,只有字母還是數字字母混合?字母是小寫還是大寫還有都有?

甚至最基本的,密碼登錄的嘗試次數和限制?

限制是否影響到其他登錄方式?(牽扯到前面的多種註冊登錄方式的自定義開啟關閉的設置體系).

然後登錄的校驗包括什麼內容?

有沒有異地登錄校驗?

有沒有更換了移動設備校驗?

有沒有登錄網路環境校驗?

這些校驗同時又和前面的設計"每次註冊登錄時需要記錄的內容"息息相關.

接下來,我們說驗證校驗的方式.

眾所周知,驗證分為前端校驗和後端校驗.

前端校驗主要是為了用戶體驗和減少對伺服器的請求來減少伺服器的壓力用的.

理論上前端校驗是能被繞過的,所以前端有的校驗,後端一定要有,而後端有的校驗,前端不一定要有.

那麼問題就出來了,哪些校驗是前後端都有?哪些校驗是只要後端有?

比如前端是否對手機格式進行校驗?

手機格式的前端校驗又校驗到哪一步,比如說是否校驗號段是否存在於運營商已經出的號段中?

同時校驗也很複雜,到底哪些動作會觸發校驗?

除了提交按鈕以外,到底是失去焦點時要不要進行校驗?

輸入中要不要進行校驗?

甚至是否要把手機號碼的輸入框做成用戶根本沒法輸入數字以外的字元的校驗方式?

甚至校驗的處罰動作和校驗方式還會在混合中產生疑問,用戶的每次輸入鍵盤的動作進行後端校驗顯然太頻繁也沒必要,但是失去焦點時的校驗是否要進行後端校驗呢?

比如說失去焦點時,前端校驗了用戶名的格式之後,要不要發送請求直接去後台校驗用戶名是否已存在,來避免客戶提交時才發現用戶名已被佔用?

校驗又很自然地牽扯到,校驗後的提示語風格如何?

是否需要做成可以由產品和運營隨便更改的模式?

提示語要不要支持多語種?

還有提示語到底如何提示,項目里到底有哪幾種提示風格,什麼時候用哪種?

比如到底是用彈出框提示?還是用氣泡提示?還是提示在輸入框的右邊或者上邊?

說實話有疑問的地方太多太多了,這又不是我的工作,我也就不真的去考慮了,僅僅把第一反應想到的東西寫出來就算了.

這麼多疑問內容,你不寫到文檔里,開發就知道.

你們公司的開發怕是會讀心術哦?

你們公司該不是叫做星靈議會哦?

產品經理日益增長的需求與程序員日益增加的疲憊之間的矛盾。

其實本質上，是兩者的目標是一樣的，都是能有好的產品結果。但由於角色的不同，造成了對目標的理解不同，也就造成了執行的不同，也就形成了兩者的矛盾。

產品經理看到程序員同事的桌上有個計數器。

問：「這個計數器是用來記錄你每天發生bug的次數嗎？」

程序員：「不是啊，是用來記錄我每天被傻逼打斷的次數。」

程序員說完在計數器上按了一下。

我是分割線啦啦啦啦啦啦~~~~~~~~~~~~~~~~~~~~~~~

產品開發早期，工程師（即我們所說的程序猿~）和產品經理的分工協作很容易出問題。

工程師最喜歡問：你有數據嗎？
產品經理一聽這話很崩潰：產品都還沒做呢，確實沒數據。

兩者之間應該怎麼協作？

（不好意思，放錯圖了。。。下面是重點！！！）

工程師應該從擴展性出發，進行前瞻性提問，而非靜態關注單個項目成功率。

這是一種什麼樣的提問呢？比如，

我們到底圍繞什麼樣的用戶，解決什麼樣的需求痛點？
我們跟競爭對手是有一定差異化，還是和它同質？
我今年希望達成一個什麼樣的進度？

而產品經理，則要考慮及時反饋對規模和用量的判斷，讓工程師給你跑數據，以技術和運維掌握全局判斷。

為什麼呢？用戶規模的改變所帶來的變化，是環境改變裡面非常重要的一環。

很多人認為，環境改變就是競爭對手改變。實際上用戶規模除了可以改變競爭對手，對你自身平台所帶來的衝擊也是非常大的。這對社交性產品尤其明顯。

拿豆瓣舉個栗子~

豆瓣為什麼不溫不火？有人說它是被環境打敗的，其實它是自己作死了。

豆瓣早期是「小而美」的地方，用戶都是高質量的文藝青年，主要圍繞讀書產生的，後來擴展到音樂、電影等。在這些領域又衍生出來一些小組，這些小組的話題變成興趣社交，成為更大的一個敞口。

但是，如果豆瓣不去分析規模所帶來的變化，只求擴大規模，對產品就會有影響。

2010年，豆瓣和騰訊合作，從QQ導入很多用戶，規模一下子變得很大。但是，這部分用戶跟之前的用戶不一樣了：他們最喜歡討論的是情感問題。

情感絕對是一個特別好的生意，永遠沒有正確答案——「我愛上一個天蠍座，我該怎麼辦」，這種問題是永無止境的，別人問過你也會問。

導入亂七八糟的用戶以後，豆瓣產品發生質變。

這時候要提醒工程師注意這個問題：考慮用一些手段制約和約束用戶行為。

從技術上怎麼解決這個問題？

Tip1：工程師，應該對用戶ID、活動軌跡、行為模式都要去約束和監控，找出異常用戶。

Tip2：產品經理，不應該給技術定義的太死，要開放地讓技術找解決的方案。

Tip3：最後雙方再坐在一起去商量，每個手段對系統的提升一級代價和誤傷是什麼？

Tip4：這些都弄清楚後再上線實踐，檢驗是否和當初想像的一樣。

通過這樣迭代，產品經理和工程師就能形成很好的默契，失敗幾率變的越來越低。

李明遠：現在還是不是做產品最好的時代？ | 完整版筆記

以上根據5月6日李明遠在混沌大學的課程整理而成，私信混沌君關鍵詞「李明遠」即可免費獲得李明遠完整課程視頻兌換券~

戳課表了解詳情?加入混沌大學

不會開車你能設計車嗎？

不會編程你來告訴我這程怎麼編？

低級產品經理和低級程序員才有矛盾，他們的矛盾的本質原因是個人眼界的局限性

哪那麼多看不懂的大道理，程序員都是很實在的！

我覺得矛盾就這幾點啊：

1.產品不懂技術，不知道技術是怎麼實現需求的，提出來的需求不靠譜，你行你來啊～

2.需求沒有寫清楚，很多細節沒有考慮全面，開發要一個個問，問到最後發毛了！

3.不停的改需求，有些產品態度還不好，不過現在好了，都是掃碼付費改需求

4.需求沒價值，開發大哥辛辛苦苦寫的功能，寫到一半被叫停了，上線沒人用，上線不久就下線了，總之，傷心了...

補充下

以上前提都是建立在有責任心的開發大哥前提下，我也曾遇到傻逼故意托著我的需求不做，這種矛盾請直接懟謝謝，評論區有產品自己寫代碼666

別問我為什麼知道，我現在正跪著提需求呢...

懂行的產品PM太少，一名優秀的PM從協同工作的角度來講，他/她所提供的需求文檔要全面詳細，把團隊中其它人（設計師，前端，後端）需要配合的地方都標清楚，用語規範統一，注釋詳細易懂，狀態值的流轉清晰明了，無邏輯缺陷，少返工，讓大家可以無阻塞地同步開始工作。

打嘴炮寫ppt的水貨太多，產品重界面輕邏輯，和優秀的PM相反，需求傳遞全靠一張嘴，幾張圖，不懂得分析競品，對自己想做的東西沒有一個清楚的認識，無需求文檔，無線框圖，邏輯沒有驗證過，細節經不起推敲，文案隨心所欲，一到設計師和程序員手裡發現一堆重大缺陷，細節全漏，需要停下來互相扯皮，拖累整組常態性加班。

還有對技術的不尊重，對程序開發沒有一個完整的概念，低估設計師和程序員的工作量。

一名優秀的PM應該成為團隊的領航員，帶領大家快速高效地完成任務，而不是成為團隊的累贅，徒增溝通和返工成本。

矛盾的本質是性別相同！