為了和開發很好的對接工作，產品經理需要了解哪些開發知識或語言？

01-01

本人知乎處女問，非計算機或軟體編程相關專業出身的產品經理，為了在工作中能夠很好地和開發人員對接，合理的安排需求，預估好工作量，不被開發人員忽悠和甩鍋，應當get哪些開發知識和技能？
感謝各位從事互聯網工作的知友們的回答，第一次在知乎上的問題能夠得到大家充分的解答，實在是我的榮幸，抱歉不能對各位大神們的回答逐一寫下感受，但我保證每個答案和評論都會仔細研讀，再次謝過~

手機簡單答，針對新手，老油條可以不參考。希望對你有幫助。

1,輸入比輸出重要，先能聽懂別人在說啥，然後才談得上溝通。這個和具體什麼開發語言沒有關係，如果認為會寫代碼才算懂技術那從一開始就錯了。

2,做自己份內的事，能力未到時不要急著把手伸出去。一個能把產品主體關係，商業價值，用戶體驗，業務邏輯講得很清楚的產品經理已經是平均分以上水準了。上述東西說不清楚還天天瞎摻和技術選型的產品就不要怪技術噴你。

3,信任並尊重技術團隊。不要一開始就預設立場，彷彿技術會利用你知識短板來忽悠你，別用防禦性的心態去看待他們。人心是相互的，你一直這樣看待他們，他們也一定能感覺到，這樣的組織保障不是穩定高效的。

4,快速學習，反超並建立優勢，這個需要看天賦和悟性。對於不了解的東西，第一次接觸的東西，如何能快速還原本質，去除不必要的噪音，同時能想方設法獲取到對自己真正有用的信息並找到解決方案，是非常考驗產品經理方法論的。一個複雜的產品，表象背後是商業邏輯，合規，法務，財務等一系列影響項的綜合體現。研發只是其中的一環，如果努力好多年還是連研發環節都搞不定，建議還是轉行，上升空間太窄。

以上。

1.面向對象的編程思想與思維方式。

2.了解基本的前後端對接流程，弄清楚前端，後端，服務端等都是做什麼的，知道需求應該提給誰。

3.仔細研讀web，Android，iOS的設計規範與基礎控制項庫。

4.簡單搞懂介面，資料庫的概念，最好能夠自己寫寫sql，玩玩爬蟲。

5.清楚市面上其他產品比較流行的功能和樣式，主動花時間了解其實現的思路和大致的成本，這個只是為了讓自己心裡有數，避免提需求時張嘴就來的做成和xxx那個一樣就好了balabala的……

6.安利一個公眾號「給產品經理講技術」，這位前輩技術儲備非常全面，並且尤為難得的是真正做到了深入淺出，可以看出來是有資深的項目經驗的，強烈推薦五顆星。

7.主動了解技術GG的興趣愛好，動漫、遊戲、攝影、lo娘、膜法、偽娘啥子的……當然不要不懂裝懂，強撩妹子最多是被掛知乎，強撩程序猿，你的需求可就被砍了(⊙…⊙)。

以上，想到更多再加……哈哈哈

這是一個IT屆老生常談的問題，一直有人在邀請。同時，這也是一個很值得討論的問題。題主的處女問邀請我，我就說說我的看法。

（答主背景：技術型創業公司聯合創始人。）

首先，我認為：產品經理懂技術現在是加分項，以後是必備項。但，工作重點是落在「懂技術」的，而不是「看啊，我特么知道如何編程」。

其次，看題主的題面，對於「產品經理必須要懂技術」的想法也是認可的。疑慮卻是「我要懂哪門厲害的編程語言」+「應該get哪些高大上的開發知識」才能震住程序員哥哥，才不會被傲嬌的攻城獅「瞞天過海」。

此處，我想說的是：題主的動機雖然很好，想法卻有一點簡單粗暴。如果我們求的是「與傲嬌的程序員哥哥一起愉快的玩耍」+「做出一個好產品」，解決之道真的沒有這麼簡單。

所以，我打算從三個方面來回答題主的問題：

1產品經理「懂技術」的好處。

2什麼是我認為的「懂技術」。

3當然了，題主「處女問」邀請的我，你的心愿：「產品經理需要懂哪些基本技術才不會被程序員哥哥騙」我也會試著為題主總結一下。

（此答案說的不是「如何做產品經理」，有強迫症的小夥伴別抓我漏洞。）

一：我們先來看看產品經理懂技術的好處以及相關：

1:產品經理懂編程是好事情。但，不代表就能和程序員哥哥愉快溝通，產品經理「多思考產品層面的事情」是重點。「哄著程序員哥哥開開心心做事情」是次重點。

2:在特殊環境下，產品經理如果比程序員哥哥還懂編程，如果你不是老闆或者高層，這隻會是一個悲劇，除非你懂得裝傻與藏拙。

3:產品經理如果打算「懂技術」，最好能讓自己坐下來寫幾行代碼，要不然就別學。「紙上得來終覺淺，看書背誦幾個技術方面的術語毫無意義」。當然了，寫代碼的水平不需要有多高。

4:永遠記住，產品經理懂技術的本質是：可以和程序員在同一個語言環境內無障礙對話，讓團隊和產品雙贏。

懂技術，

一來不會不知道天高地厚，

二來有了良性互動，團隊可以少一點撕逼，產品可以少一點試錯，關鍵是節省時間。

如果你是沖著「鄙視程序員」或者「秀能力」去的，這個想法也很危險。

5:產品經理想要「真正意義上」懂技術，需要師父領進門，自己修行3年+，不要以為這是「勾搭一個程序員哥哥，微信上聊幾句」的事情。沒有這個心理準備，千萬不要開始。市面上有什麼《七周資料庫》，什麼《八周編程語言》。看看可以，別迷信。

6:產品經理懂技術需要懂到什麼程度？

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

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

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

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

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

什麼是前端？什麼是後端？二者是如何配合運轉的？WEB運行的邏輯是什麼？如果判斷一個前端的能力？後端伺服器是一個什麼鬼？要能判斷一個產品開發周期。等等等等等等。（我會在第三部分展開說）

7:一個沒有經驗的，還有話語權的產品經理會使項目失敗的速度加快。產品經驗豐富當然好，如果你有技術功底，你就能在關鍵時候對技術的選擇作出及時、有效的決定。

8:這條是6的延伸，互聯網項目，移動互聯網項目。是一個個非常複雜的構成。說到程序員的類型，需要用到後端開發、前端開發、界面設計、產品設計、資料庫、各種移動客戶端、三屏兼容、restFul API設計和OAuth等等，比較前衛的項目，還會用到Single Page Application、Web Socket、HTML5/CSS3。

所以，你看，產品經理首先要清楚是自己的產品是什麼，自家程序員哥哥們都是什麼水平。你（公司）能做什麼事情，那件事情你應該找誰。不要給「無辜」的程序員哥哥「找麻煩」，還說人家不配合你。

9這條是8的延伸：產品越新，項目越大，團隊的溝通成本越高，相信人月神話的，相信有位置有權力才能把事情做好的產品經理，是不合格的產品經理。

團隊中，溝通當然需要成本，情商卻是關鍵，不同崗位（技能）的程序員哥哥，各說各話，這是人性。

所以，產品經理得有本事調停。如果你有技術功底，你就能手到「病」除。

10產品經理重要的還是「產品思維」，學習技術只是為了走得更穩，千萬不要舍主求次。你可以懂技術，但千萬不要有「程序化思維」。

二：什麼是我認為的「懂技術」。

（以我團隊做標杆，歡迎討論）

1:產品經理要盡量做到「專一」而不是「萬能」。產品經理要協調好「產品」和「開發任務」之間的關係。

要比程序員哥哥更懂行業，行業的業務知識對產品經理是很重要的，有助於設計出一個滿足用戶需求的體系結構。

要比程序員哥哥更懂行業里的那個領域。能夠「給」出自家產品所在的領域，業務領域的架構，只有技術架構和業務架構緊密結合才有可能真正創造出一個好的系統!

（好的系統就是一切）

2:在一個軟體項目開發過程中，要能將自己的需求轉換為「規範的開發計劃」，如果你還能制定這個項目的總體架構，指導整個開發團隊完成這個計劃，那就太完美了。

3:產品經理要能在：開發語言、設計模式和開發平台不斷地升級，同時還需要吸收這些新技術新知識，並將它們用於軟體系統開發工作中（雖然只是分配工作給別人）。

4:要懂數據分析。

（這方面的文章知乎上面特別多，我就是再強調一下）

①把Excel玩溜了，可以嗎？溜到可以上天可以嗎？

②數據分析的方法論很多，你要做的只是時時刻刻更新你的知識體系，現在有很多數據分析的書，讓我看，只看目錄就夠了。（我可不會指名道姓）

③我看到很多數據人員做數據做的很痛苦，但這不是產品經理不去學數據分析的理由。

④懂一點SQL語句。（此處是僅僅針對數據分析而言）

⑤要擅於發現各種好用的工具。（節約時間）

⑥「數據分析」是被推上了神壇的，但你不能做一個「神棍」。即便是你有能力做好「信息控制」。

要想清楚你家產品為什麼做的數據分析？再動手開始學習。你的目的終究是：評估產品機會、分析解決問題，支持產品運營、預測優化產品，而不是告訴別人你會數據分析。

⑦知道數據來源。保證數據的有效性和真相性。數據分析的本質就是「讓產品經理少一點妄想」。通過數據分析能幫助所在團隊找到更加合適的產品和市場，找到好的商業模式。這件事情如果做假。嗯，作死。

6:很多產品決策其實是商業決策，商業本質之一是「開源節流」，「懂技術」就能夠更清晰地把握系統的現狀。

第二部分想到再補充。

第三部分是重點，我要思考一下。

謝邀。

如果你能拿到fire開發人員的權力，不管你懂不懂開發語言都可以很好的溝通。

謝邀，很久就看到了這個問題，現在停閑下來，寫點兒。

我不怎麼信馬列主義，因為我一哲學外行人都能提出三四個駁論，讓馬列主義無處辯駁，但是「矛盾統一」觀點，我真真切切的從產品經理和程序員身上看得清清楚楚、明明白白，明面上一種關係，背地裡又是另一中關係，相互依靠，又相互博弈，真是相殺相愛的好基友啊。

由於本人是程序員，所以只能從程序員的角度，結合現實中接觸到的項目產品經理進行回答，做一點總結。

做好燃盡圖，調控整體產品進度和質量。

上面答案竟然沒人提到燃盡圖，我不理解。

燃盡圖是什麼？答：便捷編程的一種可視化、績效化圖表，管理軟體項目進度、質量的倚天劍、屠龍刀。由於工作原因，不方便將本職工作的項目燃盡圖張貼出來，在網上找了一張，侵圖刪，不用我說，您一看就明白這張簡簡單單的圖功能何其牛掰。

看完上面的圖，我只問你怕不怕？怕不怕？

燃盡圖橫軸是時間，縱軸是工作量，兩條曲線表示計劃和實際，它又包括七種情況：Fakey-Fakey、Late-Learner、Middle-Learner、Early-Learner、Plateau、Never-Never、Scope-Increase——答主為什麼要寫出這七種情況？為了裝逼，還都是英文，多麼的高大上啊，其實都是百度知道中粘貼過來的，答主都不知道啥意思。

每次開會的時候，在投影儀上始終給燃盡圖留有一部分餘地，時常展現出來，說道說道進度情況，偶爾指桑罵槐也不無不可。如果更狠點，你可以定期將燃盡圖發給技術人員，並要求他們將桌面換成燃盡圖的圖片，時刻鞭策他們。

於是我的桌面從下面一張圖：

左下角的明步姐姐是我的最愛，哥就喜歡嬰兒肥，變成了：

咳咳，還是不能上圖，要有起碼的員工準則和保密素質。

2、閱讀標準文檔，編纂產品文檔。

先閱讀，然後編纂，只有閱讀了，才能有標準的格式，千萬別自己定文檔格式，不然會顯得很Low，很上不去檯面。

這裡的產品文檔包括很多，比如產品需求說明書、產品進度說明書、產品使用說明書等等，再牛逼一點，你也可上手寫通信協議的文檔。

產品需求說明書——產品經理啊，你是最懂需求的。調研很重要，但是無需和程序員打交道，產品需求說明書是你發給程序員第一份資料，重要性不言而喻。

產品進度說明書——這玩意和燃盡圖結合起來用威力巨大。

產品使用說明書——產品經理可以不懂技術，但是一定要是一個合格的產品測試員，功能實現了，親自上手測試，測試系統性能，當你作為非技術人員將使用說明書寫出來了，你想想系統實用性會差到那裡去。

產品經理可以不會編程，不懂技術，可是一定不要不會寫文檔（又是一點其他答案沒說的），所以我才把寫文檔放在第二條說，若不是燃盡圖顯水平，我肯定要把寫文檔放在第一位。

文檔是產品經理的命脈，是白紙黑字最有說服力證據，是產品經理和程序員鬥法的制勝法寶，所有有關產品的東西都要落到文檔上，每次修改需求、更改進度都要有日期。

答主要上圖了，再不上點私圖，大家還以為我胡說呢。

（1）需求說明書正文，要的就是這種規範性和條理性。

（2）我們經理自己寫的介面協議文檔，手機app和服務端的介面文檔。

3、把握技術流程，提高掌控力度，將功能模塊化。

產品經理一定要掌握產品開發流程，不知道其所以然可以，但是不能夠不知道整體框架和流程，特別是通信協議部分，更是一定要牢牢把控在手裡，比如安卓手機端和服務端的協議，怎麼強行敲打，專權獨斷都不過分，誰讓你是產品經理呢，當然前提是你懂。

一個互聯網產品肯定包括很多功能，產品經理要將這些功能模塊化拆解，分配給不同的人，這些動能模塊有的相互獨立，有的存在業務邏輯關係，是燃盡圖時間拐點的關鍵。

任務分配又是一個技術活，首先你要了解團隊人員的技術水平，我現在產品經理這點就很牛，很了解當前眾人的水平和特點，並且進行交叉性分配任務，不上圖不行啊，上一張經理出差之前發給我們的任務圖（我稍微修改了一下下，為了工作保密嘛）：

簡單看的話，主次要負責人很明確，保證工作可以順利進行，不會因為主要負責人突發情況而拖累進度，而且沒有工作重複的地方，不會出現責任推卸的情況，但是真正厲害的是，只有了解我們幾個能力和特點的人，才能知道這個任務圖的牛逼之處。

經理，請收下我的膝蓋！——雖然敬佩我的經理，但是不妨礙我背後說他壞話——哼，一個自以為是的自戀貨兒，馬蛋。

4、尊重但是要學會對程序員說NO，每一種編程語言都要學會寫「HelloWorld」

千萬別相信和程序員做朋友的鬼話，會降低你的威信度，而且你竟然墮落到要和程序員做朋友的地步，我作為一個程序員鄙視你，拒絕和你做朋友。產品經理應該統籌兼顧、高屋建瓴、提綱挈領，《Breaking Bad》中洗車店老闆曾經給老白說過：「你現在是老闆了，需要強硬，這點很多人都不不知道，你需要給員工說NO。」

不過，程序員也是人，需要尊重不是？

學會寫你的產品所涉及全部開發語言的「HelloWorld」，首先聲明這不是學習技術，寫「HelloWorld」和技術之間還隔著三個明步姐姐，不過一個最簡單的程序會讓你了解開發編譯環境和編程流程，這很重要。

世界上的第一個程序就是Hello World，由Brian Kernighan創作，我打算，等以後退休了，我要練習書法，第一個詞就先揮毫潑墨寫個「Hello World」

5、其他

今天先寫到這，寫幾行代碼耍耍去，上面只是一部分，產品經理不用學技術就能掌握的方法，此外還有很多關於產品經理如何學習技術的想法，明天繼續。

聽別人說，留下支付寶號可以得到意想不到的打賞，我心裡冷哼鄙視，但是還很誠實、很賤的留下了支付寶號：woyuanshuai1990@163.com——會不會有人打賞呢，好期待啊，像是偷糖果一般討小便宜的感覺，好久都不曾有過了。

主動了解和學習技術，承認自己比較菜，保持謙虛有禮貌，即可。

張張張子恆

作為產品經理，我常用的工具有哪些？

工欲善其事，必先利其器，作為最追求極致體驗的產品經理群體，手裡有一件趁手的法器，工作起來才會有一種享受般的快感，最近回答或邂逅了很多關於產品經理工具的問題，碰巧平日工作生活中，個人的一大愛好就是去體驗把玩各種各樣的產品，所以今天就來統一匯總一下，聊聊產品經理的工具箱里，都應該有什麼物件。

1.原型繪製工具：Mockplus

用過很多繪製原型的產品，無論是Web時代的Axure還是移動時代的墨刀，甚至高保真神器sketch，統統體驗一遍下來後，最終還是只保留了Mockplus。

不得不承認，Axure是一個偉大的產品，能在一個領域專註打磨十幾年，本身就令人尊重，但相對於更加輕便的，Mockplus，Axure就像是一把面面俱到的瑞士軍刀，但事實上，我只需要個指甲鉗就夠了。很明顯，Mockplus就是那把指甲鉗。

不管是針對Web產品還是移動端的產品設計，Mockplus都有很好的支持，簡單、便捷、上手快，產出比高，應該是對Mockplus最中肯的評價了，在交互上支持的也足夠到位，並且，完美支持移動端的展示，在目前我主導過的三個產品線里，除了最開始的那個是用Axure來搞定之外，剩下的都是靠Mockplus，快速產出快速驗證，大愛不已。

對了，選擇Mockplus還有一個很重要的原因就是，它的畫風真的很讓我歡喜，做高保真原型也並沒有阻力，就目前而言，是一款值得去擁有的產品。

2.思維導圖：Xmind

這個工具大部分人都熟悉吧，不管是思維導圖流程圖還是樹狀結構圖，Xmind都能很好的支持，之前看到有很多人推薦過mindnode和其他幾款同類產品，其實功能都差不多，推薦Xmind主要是因為個人喜歡這種性冷淡風。

對，也就是這個原因了。

除此之外還可以試試web產品百度腦圖，也足夠簡潔，像絕經後的大媽，打開後就剩專心工作了，再也不會分神去思考其他亂七八糟的事了。

3.學習整理工具：OmniOutliner

是的，你需要這樣一款產品來幫你理理思路，對產品經理而言，「不斷的學習」幾乎是職業生涯中最重要的組成部分，在一個「三十天養膘，五十天出欄」的人人都是產品經理時代，除了不斷努力去武裝自己，再也沒有什麼更靠譜的辦法讓自己在激流中勇進了。

不管是做讀書筆記，學習筆記還是用來整理一些合作項目，甚至寫文檔這種事兒也可以先用omnioutliner來列個大綱，而omnioutliner對內容的要點梳理和結構化呈現，是目前所有我用來整理的工具中最贊的一個，現在，我已經開始用它來整理我們的版本迭代計划了。

一千個人眼中就有一千個哈姆雷特，一千個omnioutliner用戶眼中也有一千個omnioutliner，不知當講不當講，我甚至看過有人用這兒玩意做任務管理和記賬呢。

4.強大的繪圖工具：OmniGraffle

它被稱作「蘋果史上最牛逼的繪圖軟體」，拋開其他的不講，僅對產品經理而言，你幾乎可以用它來完成產品相關的一切任務。

你可以用它來畫流程圖，從頂部的導航欄拖一個框下來，雙擊填充文字，再command+c來一條箭頭，一份流程圖妥妥的幾分鐘就可以搞定。

你可以用它來畫原型（沒錯，它也可以畫原型，不過當然沒有Mockplus那麼輕便），去官網下一組件庫下來，和axure一樣，想要哪個拖哪個，原型做起來也是蹭蹭快。

你也可以用它來畫交互稿，同樣簡單，把畫好的原型command+c串聯起來，再配上交互說明，一切看起來水到渠成，顏值當然也不差。

5.高顏值在線文檔協作工具：石墨文檔

一開始被石墨吸引，就是靠它的高顏值，水墨畫一般的UI帶來的寧靜與優雅，是入網這麼多年來，遇到的第一款在看到的第一眼就被顏值折服的產品。當然，並不是花瓶一樣，石墨在功能方面也不會讓你失望，在線文檔/表格協作，可多人同時編輯，真正做到了「毫秒級」響應，劃詞評論功能也讓協作更進一步，多平台支持更是慢慢讓它成為我們團隊中必不可少的工具之一，用它來管理需求或者撰寫文檔甚至記錄片刻的想法，目前來講，對我是一種享受。

6.先碼了再說的稍後閱讀工具：Pocket

進階之路上難免經常看到讓自己眼前一亮的好內容，但可能當時又由於各種各樣的原因沒有辦法繼續閱讀，這個時候，你就需要一款稍後閱讀的神器了，國內最近火了一個叫「收趣」雲書籤的產品，其實和pocket一致，都算是「先碼了再說」的稍後閱讀工具，但相比之前，我還是更喜歡pocket一些。

不管是在Web端閱讀，在APP里，還是微信公眾號里，看到的好內容都可以先碼下來，現在大部分應用都可以直接將內容收藏進pocket，而chrome瀏覽器里也有相應的插件，可以一鍵保存內容至pocket，至於微信公眾號里的文章，複製鏈接後，再打開pocket，底部會直接提示你是否要保存複製鏈接里的內容，點擊確定就算碼完，然後抽個時間，在你的iPhone、ipad或者電腦里，去閱讀你碼過的優質內容，方便到令人髮指。

7.時間管理工具：Todoist

這類產品有很多，就目前個人使用經驗而言，還是推薦這款。

每天睡覺前思考下明天要做的事情，放在todoist里，添加提醒時間，截至日期，再給它附上優先順序，然後第二天直接照著todoist排好的任務順序去執行就好。不怕忘，todoist目前全平台支持，任務提醒會在合適的時間告訴你該去做什麼事兒。

項目分組管理，任務標籤，時間管理，這款todo工具里應有盡有，團隊版更是可以添加成員進來一起協作，值得一試~

8.UI、高保真原型繪製工具：sketch

關於這款工具不用多說了，相信很多人對它都不陌生，網上現在也有大量關於它的相關內容和教程，對設計型產品經理來說，這簡直是一款不可多得的神器。

相較於應有盡有的Photoshop，sketch和Photoshop的關係也像指甲鉗和瑞士軍刀一樣，同樣以輕量便捷著稱的sketch再問世之後就迅速風靡全球，目前國內很多公司也在用這個工具作為主流生產工具，最新版本的sketch更是加入了分享協作的sketch cloud，而大量優秀的插件也讓團隊協作之間變得更加便捷。

舉個例子，目前我們團隊設計和研發之間完全沒有切圖啊標註那一說，設計師直接扔sketch源文件給研發，研發再通過sketch的插件來抓取自己想要的參數，愉快異常。

用sketch來繪製高保真原型也是個不錯的選擇，相信我，有時候一不小心，就把UI直接畫了出來。

先寫這麼多吧，要分享的法器太多，篇幅太長的話會影響閱讀體驗，以後慢慢分享給各位吧。

原文地址：作為產品經理，我常用的工具有哪些？ - PMCAFF產品經理社區

開發同學一般不會忽悠你，請相信他們。

了解了語言也不一定能溝通的好，一般後台用java、php，前端也有一些框架語言可以用。

個人理解最好的對接是：

1、首先把業務分析通透，這個方案是目前看來最合理的

2、至於開發是如何實現的，可以經常找他們溝通學習，是一個個慢慢過程

技術反駁你的時候，除了質疑你的需求之外，就是質疑你方案帶來的開發成本，下面是總結的幾個開發質疑點，供參考：

1、一個頁面呈現的信息量過大，查詢時涉及到多張表，性能低。

2、單次提交數據量太大

3、一個步驟調用了多次介面

搞清楚他們為什麼質疑，做方案合理的修改，對接會更輕鬆。

貌似應該開一個程序員如何對接產品經理的專題，因為搞不好就是程序員的鍋了...

撇開極少數學藝不精、職業素養有問題的程序員來說，如果研發經常對產品經理忽悠、甩鍋，大多數時候絕對不是欺負產品經理不懂技術的原因，而是因為研發的同學從心底里覺得現在開發的產品「沒價值、沒意思、沒用處」，自己整天在寫一大堆low到爆且莫名其妙的代碼，而感到由衷的沮喪。

將心比心，假設你作為一個產品經理，接到一個項目/需求，你經過調研、分析以後，發現這是個沒前途、沒希望、沒價值的項目，你是不是也會有懈怠的情緒，是不是也不想畫DEMO、寫PRD，同樣的道理，你把這種情況放在研發身上，你就能理解了。

首先題主要端正一個態度，產品經理需要懂技術，主要目的不是為了和研發同學吵架（撕逼），也不是為了去評估開發工作量，這些可以說是錦上添花，但絕對不是產品懂技術的核心目的。

產品經理了解技術，是為了更好的理解你的產品，知道怎樣的去規劃你的需求，懂得如何在產品功能上做取捨，是為了能讓你能和研發同學在同一條水平線上去溝通，而不是凌駕或低頭在研發的身上或身下，而最重要的是，懂技術，能讓你的需求變得更加靠譜，能知道怎樣運用技術讓你的產品更有價值（用戶價值、商業價值），能讓你的同事（UI、研發、測試、運維）知道自己在干著一件有意義的事情，而不是總給啥都不懂的產品擦屁股。

回歸正題，題主問的「需要學習哪些開發知識/語言」，這點首先是有問題的，起碼對於入門級的產品經理而言，是有很大問題的。產品經理的主要職責不是親自去開發某個產品，也不是自己獨立完成某個模塊的編碼，而是通過用戶表層的現象，還原為底層具體的需求，再將具體的需求拆分成各個精確無誤的模塊（商業模式、業務邏輯、原型、PRD、數據介面等等），為研發同學提供開發的依據，在產品上線後，再通過對需求不斷的深挖、剖析，最終形成需求、文檔，再提供給研發的同學進行開發。

在這個過程中，產品經理需要吭哧吭哧的先搭個環境，再下個IDE，然後開始編程嗎，其實不需要，更別說大多數入門/初級的產品經理，往往只負責/迭代一個相對較小的功能模塊，就更加不需要一開始就學習複雜的編程知識或語言了。大多數對產品經理在編程上有硬性要求的崗位，大多數是屬於對技術要求較高的行業/領域，比如雲計算、大數據這類的產品經理，往往可能從研發崗轉型產品崗的較多，這類崗位就更不是入門級的產品經理可以擔任的了。

所以說入門的產品，最好不要一上來就想自己寫幾行代碼，做個什麼大產品，說實話，不是計算機專業出身的同學，可能連開發環境都搭不好，然後就喪失信心，從此對技術都敬而遠之的人也不少。

以下列以下，我認為產品經理應該懂得技術

1、了解所有和產品相關崗位的工作職能和工作職責，包括你的上司和老闆。

好吧，寫到這裡，我知道肯定有人會說，了解工作職能，也算是了解技術嗎。

其實在我看來，如果你真的仔細用心的觀察過一個產品，從立項到評審再到開發、測試、部署、上線、運營，你就會清楚知道，每一個流程，其實都隱含了大量和技術相關的知識。

比如當你的上司/老闆給你一項需求，你是照著他們的需求，吭哧吭哧的開干，還是先仔細了解這個需求的業務背景、商業模型、業務邏輯、推廣策略等等信息。

假設你認為這些不重要，根本就不詳細去考慮去深究，當你在需求評審上，研發同事問你，這次的需求的背景是啥，咱們為什麼要做的時候，作為產品經理，你應該如何回答，難道你還真能理直氣壯的當著會議室所有人的面說，「唔，這個是老闆要咱們乾的，咱就幹了再說吧」，

還是「唔，這個需求是公司參考了競爭對手目前幾款具有競爭力的產品後，發現這個市場目前雖然不大，但是值得深挖，如果發展好了，有可能會給公司帶來巨大收益，當然產品還在試水，項目前期的用戶量不會太大，大概在5000-10000人左右，所以我們在研發上不用耗費太多時間在細節上，在模仿競爭對手的基礎上，我們做了如下改進，第一版我們優先把核心功能上線，後面用戶量上來以後，我們再blablabla迭代優化」

第一種說法給研發同學的心理預期是，「這煞筆啥都不知道，又在挖坑了，哎」

第二種說法給研發同學的心理預期是，「嗯，既然還是個試水的項目，肯定對項目時間有要求，在代碼質量上可以不用要求太高，如果後期真的做好了，還可以再來重構代碼，前期用戶量在1W內，那技術選型我可以這樣干blablabla」

兩種回答最大的差別就在於，前者你除了給了最基礎的需求文檔外，啥都沒給，而後者，在文檔以外，還提供了大量的技術開發依據，讓研發的同學清楚的知道，目前項目在哪個階段，我們應該使用哪些手段或方法優先完成任務。

作為產品經理，清楚的知道和你合作的每個技術同事，他們在整個項目中的定位是什麼，他們各自發揮的作用又是什麼，他們需要你這個產品經理給他們提供什麼，他們才能更好的開展工作。在這個過程中，如果你真的用心去了解，除了業務邏輯、商業模型，你會發現大量與技術相關的專業術語，比如前端工程師和後端工程師的區別是什麼，為什麼同時需要這兩個角色，他們各自使用的工具是什麼，又能達到什麼效果，如果我要做一個拿不準工作量的功能，我應該在評審前先找誰來商量。

題主說的，要和開發更好的對接工作，那我認為首先的一點就是，你首先得知道對方是幹什麼的。

2、了解所有和研發相關常用的專業術語。

前面說的是，產品經理知道研發同學各自的職能、工作內容、開發流程等等，這裡說的是，不僅要知道對方是幹什麼的，還要知道，怎麼樣配合著研發更好的幹活，完成你的需求，要實現這個目的，產品和研發首先就必須在同一個頻道上進行溝通。

對於很多（非計算機專業）初級產品經理，在和研發溝通上，會陷入很大的困難，根本原因就是研發的同事絕大多數出身於工科（計算機專業），但是產品經理則來自各種雜七雜八的專業，很多對於研發來講是基礎的計算機理論知識，一到了雙方溝通的時候，產品經理往往聽的雲里霧裡，根本不知道研發在說什麼，也不知道研發的同事為什麼會對自己的需求有這麼大的意見，這種時候，其實不需要產品經理去學什麼技術、什麼編程，相反，你首先得聽懂話。

關於有哪些知識，根據每個不同的公司，不同的產品類型，需要的都不太一致，這裡不去詳細論述，但是關鍵的一點就是，平常和研發溝通時，一旦有了不清楚、不清晰的專業術語，不要得過且過，先拿本本記下來，再去搜索引擎上找對應的知識，不必過於深入，要記住，你的目的是能聽懂、能溝通，而不是成為技術專家。

3、尊重研發同事的勞動成果，不要越俎代庖。

題主原題說的「預估好工作量」、「不被開發人員忽悠和甩鍋」，也是入門產品經理會犯的一個錯誤，以為自己是產品的管理者，所以在職能上就應該在研發頭上，其實產品和研發都是平等的，產品和研發都有可能是為了老闆的一個idea，然後通力合作的完成工作和任務，既然兩者平等，研發就需要尊重產品經理對於需求的判斷，產品也需要尊重研發的勞動成果。

題主說，產品要預估工作量，往往這是不可能的，別說產品經理預估不了，有時候連研發自己都預估不了某一個模塊需要開發的時間要多少。

我曾經試過，一個複雜的項目，前後有兩三位研發的同事進行離職交接，新來的研發的同事對於當前的系統各個模塊根本不熟悉，即使產品經理提了新需求，對於新來的研發，也很難去預估開發的工作時間。同樣的道理放在產品身上也是一樣的，比如讓你來對接你前任產品經理的工作，你在連整個系統需求都不熟悉的情況下，讓你去做需求、做迭代，同樣也是一臉懵逼。

對於產品而言，不要總想著親自下場把產品開發了，也不要把不屬於你的工作職能給扛上，充分尊重研發同事的能力和判斷才是正道。

當然了，如果你所處的環境，所有同事都是以甩鍋、推卸責任的工作態度，那還是建議你換個平台吧。

作為碼農我也不請自來吧，其實最關鍵的不是懂語言或具體的編程知識，而是邏輯性（前面也有人提到），你要知道所有功能的細節。

如果某些地方你確實沒考慮到，當程序猿提出質疑的時候你就要回去仔細思考，必要時也可以找老闆或業務部門商量一下具體是怎麼做。新增/改動一個功能，對其他功能的影響也要考慮到，不然很容易掉坑裡。

還有就是不要催，再緊急也要時間，其實產品經理跟程序猿聯合起來的話，是可以對抗老闆，如果老闆一下子把你們全炒了他短期損失只會更大。

沒有通用解法

你一個做搜索策略的pm，學一堆android開發你家researcher不會有興趣跟你聊

你一個做炫酷運營頁面的pm，學一堆演算法不會幫助你和FE更好的溝通

你一個做純Native App（如果還有的話）的pm，學腳本對你跟crd溝通也沒什麼卵用

誰知道你今天做這個明天會做啥

相對通用的解法是：

1.快速了解你家開發人員做什麼的，基本要了解清楚人家的基本原理和其中可能有哪些坑

2.充分做好競品調研，一般競品能實現的話，即使你家不一定也能實現，但可以提供給你的開發人員做參考，尤其是前端、客戶端開發這種前台可見的效果，一般都可以copy，當然類似chrome、google這種依賴自家場子支持的不算；

3.尊重開發人員，不懂主動問，但是要記要學；

4.學會把產品需求翻譯成程序員（或任何人）好理解的語言，比如你不能描述一個很虛幻的東西給程序員，他會以看sb的眼神來看你，你可以這樣

a.我需要一個策略，當我在XX輸入A的時候，給出包含所有A欄位的東西，其中按X原則、Y原則、Z原則進行排序，如果出現異常，則給出XXXX；

b.我需要一個頁面，原型如圖/動效/偽頁面，點擊xxxx分別跳轉yyyy，當xxxx大於zzzz時，則顯示「￥％……￥￥＃」；

c.我需要一個OCR識別功能，需要在xxxx場景下準確率不低於9x％，可以接受識別市場範圍是x秒，我的評估方式是％……＃￥％

5.html＋js（for前向產品）、腳本語言（for策略產品）、SQL（for every產品）在有精力的條件下可以深入學習一下，沒壞處，日後自己可以沒事做/跑點東西玩；

產品經理，怎麼說呢：

各種提需要都不要緊

各種改需要也不要緊

各種抄襲也還不要緊

但。。。

千萬你所有提過來的需求，一定要有說明書/文檔，要統領全局知道自己到底在幹啥，尊重別人的勞動成果。

不能想我們的產品經理一樣：

1、十個需求裡面有三個是互斥的，打手的。

2、提需求從來都是走過來拍下你的肩膀說「交給你做了」（沒有下一句了）然後就走開，留下你在那裡風中凌亂莫名其妙不知他想幹啥

3、明明是非技術人員，卻硬是要參與到我們的技術選型中。

4、開了一個月會，然後問你三天能否搞定。

5、從不尊重我們的勞動成果。

現在從項目經理到小開發小測試，說起那個產品經理，都是：

邏輯！邏輯！邏輯！如果一個產品的邏輯不完善，恭喜你回家休息吧！

呃，其實我還理不清項目經理、產品經理、需求分析師……的具體職責到底有哪些！

@天順和某匿名用戶的答案已經很不錯了！本人前端開發（實則頁面仔），最近剛好和同事有討論過以後發展的問題，這裡簡答下（吐槽下）！

你不一定需要知道技術知識或編程語言，有時候知道這些反而會成為一種阻礙！況且即便你前端、後端、伺服器、資料庫等等所有端的技術你都懂，你也不一定就會是個好的產品經理！

你只需要明白和只負責好自己的職責就好！

一個產品經理，最重要的技能是溝通！

對於程序猿來說，你只需要做一件事：儘可能詳細的了解需求並告訴他們！

詳細的需求包括三點：

1、為什麼要這麼做？

2、想實現什麼效果（要做什麼）？

3、詳盡的業務流程是什麼？

第一點有時候特別重要，但大多數時候沒用！另外，有些點是在實現前想不到的，請及時跟他們溝通，大多數時候，會是程序猿提出來！

具體工作中，注意以下這些問題：

1、請給程序猿明確的需求或答覆，避免出現類似「你看著辦」之類的回復！（就當他們有強迫症）

2、不要說「這個很簡單」！不要替別人做決定；不要給別人要做的事定性！即便你是某一大牛，對你來說「簡單的事」，對別人不一定！況且有些東西只是看起來簡單！

3、要勇於對客戶說「No」

4、不要催！實現中出問題了，負責任的人會提前跟你溝通！項目時間的問題，最好跟程序猿溝通，讓他們先估算，然後商量著來！

5、盡量不要改需求，除非他們還沒做！（曾給某一政府部門做一網站，本來十天半個月的事，前前後後耗了我三個月，回爐N次，那叫一個窩火）

6、7、8、……

良好的工作氛圍和人際關係會極大的提高工作效率和降低溝通成本，所以，不到萬不得已不要撕逼！

程序猿大部分是很「實在」的人，最多告訴你2是10，但絕對不忽悠你！但你也不要忽悠他們，他們也不傻，至少你不要那麼明顯好嗎！

不久將來要從開發轉pm的我，來佔個坑。

其實讀完你的提問後，如果沒有曲解的話，「不被開發人員忽悠和甩鍋」，這種心態其實很普遍但是呢，又並不可取。

讓我們來換位思考一下，開發人員也會同樣提問道：「為了和PM很好的對接工作，blablabla PPAP PPAP....不被PM吹牛屁畫大餅還亂改需求。

其實一開始，大家都開始了互相傷害，互相戒備，這會讓整個產品項目進入良性循環前就有了很大的阻力。就好比情侶間最好的狀態不是你猜我猜，關乎得失的博弈遊戲。

開頭說占坑，並不能給出我自己滿意的答案，但是簡單粗暴的答案，你主動發問了這很好（因為一部分開發並不會尊重PM甚至理解PM的工作和存在意義）。所以比較有可操作性的是，你給自己一個計劃安排，讀一個IT的學位或者嘗試自己最大可能去接觸相關的技術。我相信這會讓你如魚得水。

知乎上我記得有前輩說過一個我很認同的兩句話在此引用。大概類似是：如果你想成為一個好的PM, 先去做3年程序員；如果你想成為一個好的程序員，先去做3年PM。

我自己的感覺就是學會換位思考，以項目成功上線為基礎，多要求自己。目前身為開發人員，看到「不被開發人員忽悠和甩鍋」這幾個字眼，其實多多少少感受的到是你並沒有有足夠的功力和意識去尊重開發人員，去自信積極的換位思考，而是站在了對立面。然而這一方面的情商，PM這個角色顯然是需要比開發高出一大截才可以勝任。所以我覺得你能很好的和開發對接工作，是需要去理解技術，走近開發，而不是主動就去和開發攻防對立，拋開PM和開發的各自角色，這本來對於產品就有百害而無一益。

從內心慢慢杜絕一口一個產品狗，一口一個coding monkey。當然這需要時間。

個人淺見，也許鑽了牛角尖，請海涵。

《被打後如何快速恢復指南》

個人認為產品經理最需要了解的是開發是如何工作的，如果每個產品經理都懂，就不會有那麼多開發抱怨各種需求的更改和刪減。

至於技術，則視開發所使用技術而定。掌握一些基本知識和實現相關功能的複雜度即可。最關鍵的，是要有邏輯性，要有腦子。

什麼都不需要，就噴丫的，噴完了回家總結，然後接著噴，都噴明白了，他也就服了，互聯網產品，必須聽產品的，聽程序員的，早晚得死