產品經理如何尊重程序員

㈠ 產品經理

產品經理的素質

同程序員不一樣，產品經理主要是同人打交道，要組織處理好很多復雜的關系和工作。良好的溝通能力、組織協調能力、資源運用能力、推動和協調各部門的合作和有序進展，是一個產品經理需要具備的綜合能力。所以做好產品經理並不是一件容易的事情，很多方面的素質培養是必不可少的。

協調溝通能力

產品經理要協調好各種關系，包括研發、測試、文檔、市場、銷售等部門的人，在保證品質的情況下如期的推出產品。任何事情都是靠人實現的，所要協調的主要是人力資源，絕不能因為要完成一個OEM的項目而佔用所有測試人員的時間。不同部門的溝通並沒有多大的區別，但不同部門的Leader做事方式可能不一樣，因此一方面要看對方配合的程度高低，同時要學會在恰當的時候和恰當的人談恰當的問題，只有解決好問題才能有效的將事情向前推進。尤其是在沒有下屬關系的情況下，人與人的互動上，要做的非常好，能夠把自己的想法非常好的表達給其他人，說服這些人配合去做事。

對事務優先順序的控制

產品經理的工作是相當瑣碎的，要處理各種各樣的關系和進度，不像其他的工作都有自己專注的方向，專業的領域。所以如何在一天之內高效的做事就顯得尤為重要。

要有市場感覺

圍繞目標市場、市場調查、市場定位、市場細分，通盤考慮產品、價格、渠道、促銷、公關、服務這些因素是開展營銷工作也是產品管理的一項很重要的工作。所謂市場感覺，更為重要的是如何能夠通過市場現象去生成一些戰略，而不是對方降價自己也降價，對方做廣告自己就做廣告。所謂戰略，就是從產品定位、用戶定位、價格和競爭對手入手，了解各自的強項和弱項，找到機會在哪裡，威脅在哪裡，並進行分析，制訂未來的戰略。這些素質不是通過看市場宣傳和匯報就能夠獲得的，它需要很多的信息反饋分析，要靠經驗和感覺。

具備一定的抗壓性

作為一個產品的負責人，產品經理的壓力是很大的。盡管在某些公司，產品的成敗不一定和產品經理的收益掛鉤，但如果某些方面考慮不周，做出來的母盤存在問題，造成整批產品銷毀，給公司帶來巨大損失，或者因為某些原因沒有和一些人員溝通好或者安排好時間，結果造成問題，產品無法如期交付，產品經理還是有「罪魁禍首」的感覺，這些都是壓力所在。

主動做事與合作

產品經理需要有獨立解決問題的能力和動力，要把產品看做自己的孩子，懷著熱情和激情去做事。這種熱情決定他是主動的，而不是被動的去做事，是為了不斷提升自己的價值和能力。

個人素質和態度

技術可以學習，素質卻難以培養，有些素質是成功的產品經理必不可少的。

對產品的熱情

有這樣一群人，他們對產品有一種本能的熱愛，把自己生活中的一切事物都看成產品，懷揣對優秀的產品的熱愛和尊重。這份熱情是產品經理必備的素質，是他們夜以繼日克服困難、完善產品的動力。這份熱情能感染團隊成員，激勵所有人。

辨別這種特質很容易，可以讓應聘者談談自己最喜歡的產品及喜歡的原因，聊聊不同領域的產品和他討厭的產品，問問對方，如果有機會，他打算怎樣完善自己最喜歡的產品。熱情是難以偽裝的，虛偽的做作容易畢露無遺。

用戶立場

理想的產品經理不一定來自產品的目標市場（這種情況有利也有弊），但是他必須融入目標市場。這一特質對製造大眾產品的高科技企業尤為難得。我們傾向於從自己的角度去理解用戶和市場。事實上，目標用戶的經驗、喜好、價值觀、知覺能力、忍受程度、技術理解很可能與我們的大相徑庭。

可以就產品的目標市場向應聘者發問，讓他談談如何換位思考。了解應聘者對目標市場的感覺，最重要的是看對方是尊重目標市場希望融入其中，還是打算一意孤行改變用戶習慣。

對國際化的產品和針對特定地域的產品來說，換位思考尤其重要。各種文化雖有共通之處，但也存在許多差異。有些差異對產品無關緊要，有些則至關重要。應該考察應聘者是否足夠了解目標市場，能否區分這兩種差異。

智力

人的智力水平是無法替換的。產品管理需要洞察力和判斷力，因此必須具備敏銳的頭腦。勤奮當然是必需的，但從事這項工作光有勤奮還遠遠不夠。

招聘聰明人是項知易行難的任務，結果在很大程度上取決於招聘者的能力和可靠性。常言道，「物以類聚，人以群分」，此言不虛。方法之一是測試應聘者解決問題的能力。微軟令人稱道的、深入而有效的面試，即是考察應聘者解決問題的能力，通常由一位或多位領域專家就一個問題對應聘者進行深入考察。面試官不關心應聘者是否知道正確答案，而看重應聘者解決問題的思路和方法（智力優於知識）。如果應聘者回答正確，面試官會將問題略作調整，詢問應聘者在新情況下如何應付。重復這個過程，直到應聘者被迫處理他不知道答案的情況，說出解決方法。

職業操守

每種團隊角色承擔的義務和付出的努力都不相同。產品經理肩負著產品的前途和命運，絕不適合貪圖安逸的人擔任。即便掌握了時間管理和產品管理的技巧，產品經理依然要為產品投入大量精力。成功的產品經理能擁有時間享受清閑的家庭生活嗎？只要具備足夠的經驗，我相信可以做到。但是，如果你期望的是一周只工作四十個小時，下班後把工作拋諸腦後，那是不現實的。

成功的產品經理需要付出多少努力？在這個問題上，我對應聘者向來坦率，產品管理工作絕不能用時間來衡量，付出多少都不為過。緊急情況下臨時找來的「救火隊員」多半不是合適的產品經理人選。

在漫長的項目周期里，產品經理需要付出的努力和承擔的義務並非一成不變。有的階段比較輕松，有的階段則很緊張。但是稱職的產品經理對產品的關注和憂慮程度，以及願意為之付出努力的熱情是不會改變的。

正直

在所有產品團隊成員里，產品經理最能體現公司和產品的價值觀。通常產品經理不直接管理團隊成員，不能要求別人執行命令，所以他必須通過行動影響、說服身邊的同事。這種影響基於相互的信任和尊重，要求產品經理必須是個正直的人。

產品經理是產品團隊、銷售團隊、公司高管之間的樞紐，經常要協調處理各種問題，比如提早供貨、滿足大客戶的特殊要求。產品經理如何處理這些難題，同事們都看在眼裡。

信任和尊重需要時間培養，產品經理唯有通過工作展示自己的素質和能力，才能成為真正的團隊領導。如果產品經理對待同事缺乏誠意，懷有私心，一碗水端不平，那麼勢必會影響整體團結和工作效率。產品經理雖然不必事事精通，但應當知道每位成員最擅長做什麼，尊重大家發揮工作特長的意願，充分信任大家。

考察一個人是否正直絕不比考察他的智力容易，考察陌生的應聘者是否正直就更難了。對那些有工作經驗的應聘者，可以問問他們如何處理工作中的壓力，多追問工作細節。

信心

很多人相信經驗可以讓人產生自信。如果僅憑經驗可以建立信心，為什麼許多工作多年的產品經理卻毫無自信？相反，剛剛步入社會的大學畢業生卻往往充滿自信（雖然這種自信通常源自對自身狀況的無知）。

自信是很重要的素質。公司高管、產品團隊、銷售團隊都需要看到產品經理的信心，確信他們投入的時間、金錢、努力不會付之東流。自信的人更有說服力，更容易成為人們願意追隨的領導者。

態度

稱職的產品經理把自己當成產品的CEO，願意為產品的最終成敗承擔全部責任，絕不找借口。雖然他清楚產品按時成功上市要克服許多困難——開發難度大、開發時間長、成本過高、產品復雜等，但他明白預見和解決這些問題是他的責任。

這並不是說產品經理要事必恭親，監督每個人的工作，而是指出現問題時他應該及時承擔責任，進展順利時他應該及時給大家以鼓勵。稱職的產品經理知道，雖然產品的實現離不開大家的協助，但是他應該對自己的產品創意負責。

技能

掌握一些重要的技能是打造成功產品的關鍵。我相信，只要具備優秀的個人素質，所有技能都可以習得。

運用技術的能力

很多成功的產品經理是工程師出身，因為策劃產品在很大程度上取決於對新技術的理解，以及如何應用技術解決相關的問題。

出色的產品經理並不需要自己發明或實現新技術，但必須有能力理解技術、發掘技術的應用潛力。

培養理解技術的能力有多種途徑，可以參加培訓課程，閱讀相關書籍和文章，向程序員和架構師請教，參加開發團隊的頭腦風暴也不失為一種途徑。

注意力

產品經理要優先解決重要問題。研發產品的[5]過程中有很多干擾。能否集中注意力解決關鍵問題、剋制不斷增加功能的沖動、不受關鍵人物或重要客戶的影響，取決於產品經理是否有足夠強的自律性——不但要遵守公司制度，還要嚴格要求自己。

幾乎所有產品都有些不那麼重要的功能——這些功能對提高銷量和用戶滿意度毫無作用。如果去掉這些功能，產品甚至會因為簡單、易用獲得更多用戶的喜愛。

時間管理

電子郵件、即時消息和手機構成的世界充滿了干擾。你可能一大早就來上班，拚命工作一整天，連吃飯喝水都顧不上，深夜回到家卻發現到頭來沒完成一件重要工作。時間都用來「救火」和處理「緊急」事件了。

熟練、迅速地區分重要任務和緊急任務，合理地規劃和安排時間是產品經理必備的技能。如果產品經理無法集中精力完成真正重要的任務，那產品就難免命運多舛了。

每星期工作七十個小時、累得精疲力竭的產品經理。他們把所有的時間和精力都花在工作上，體力透支到了極限。對他們而言，最可怕的事實莫過於做的都是無用功。為此，我有意在培訓課程中加入了時間管理和合理安排工作任務的內容。產品經理的時間應該用來改變現狀，而不是疲於奔命參加大小會議、逐一回復郵件。有許多事情不值得做。

商業技能

作為產品團隊的發言人，產品經理要協調團隊與財務部門、營銷部門、銷售團隊、公司高管之間的工作——必須使用這些人聽得懂的概念和術語。

我認為產品經理應該具備雙語技能。這並非指中文和英文，而是指產品經理既能與程序員討論技術，又能與管理層和營銷人員討論成本結構、邊際效應、市場份額、產品定位和品牌，當然還得掌握一定的原型圖設計能力，在產品初期將需求文檔更為直觀的同領導與開發人員交流，這些都是必不可少的。

㈡ 產品經理如何說服開發人員

‍‍在互聯網公司中，產品經理和開發人員在工作中會經常合作，如果相處融洽，整個產品會在很高效的情況下產生；如果相處不好，那整個產品會有很多問題出現。實際情況是，很多時候，產品經理和開發人員都是在不斷的撕逼中完成產品的。那麼，對於產品經理來說，有什麼樣方法能更好的說服開發人員？接下來我們具體看一下。

希望以上建議對你有所幫助。

‍

㈢ 產品經理和程序員,如何避免矛盾

產品汪和程序猿

一、產品經理和程序員最討厭的三句話

產品經理和程序員,就像一對情人，若即若離，有時還會撕逼，和諧的時候一切都好，撕逼的時候兩敗俱傷。

你知道程序員最討厭的三句話是什麼嗎？

1、這個需求很簡單，改一下就好了

2、你先大概弄一個，我看看再說

3、我先下班了，加油啊

我想任何一個程序員聽到這樣的話都會氣炸了，不撕逼才怪，你作為程序員會如何回答這三句話？

1、這個需求很簡單？你行你來啊！

2、大概先弄一個？請問先生（女士），什麼叫大概？

3、你大爺的

你知道產品經理最討厭的三句話是什麼嗎？

1、這個需求做不了

2、這個需求工作量太大了，估計要搞3個月

3、這個變更沒時間做，往後排吧

產品經理在前端，有用戶、有老闆、有銷售，版本發布的壓力很大，聽到這樣的話估計心情也好不了哪去？

1、這個需求做不了？又不是我提的，還不是那個2B用戶提的

2、要做這么長時間？養你們有什麼用，還不如我自己來

3、變更沒時間搞？隨便，等老闆來拍你吧。

二、產品經理和程序員本質上的差異是什麼

奶爸干過程序員，也干過項產品經理，深知這兩類工作的差異，各有各的不易。

總體上來看，做產品更側重於創造和方案能力，不需要精密的邏輯，所以試錯成本相對比較低，大不了改改原型，改改方案，這個成本是可承受的。

程序員的工作是非常精密的邏輯，一個看似很小的變更有可能對代碼產生很大的影響，所以試錯成本非常高，弄不好可能會因為需求的變化導致系統的重構，這時候程序員的挫敗感是可想而知的。

三、產品經理和程序員友好相處的清單

1、產品經理收集需求後，在需求分析階段，需要把一些不合理的需求盡量和用戶溝通去掉，避免不合理需求造成產品發布時間延遲和沒有必要的成本浪費，當然這需要產品經理去說服用戶，不能只做用戶的傳聲筒。

2、需求分析時，產品經理應該根據經驗，敏銳的發現一些在技術層面實現有困難的需求，及時讓研發介入，評估技術可行性，避免後續出現需求定下來，研發說做不了的情況。

當然這需要我們的產品經理對軟體技術架構有一定了解和預判能力，你不能所有的需求都要在需求分析階段讓研發介入，這個成本也是極高的，所以要把握好這個度也是一項能力。

3、原型還是需求溝通的最好方式，這樣是避免產品和研發在需求理解上有差異的最好手段，只靠寫一些文字的需求說明書很難達到好的效果。

但這裡面要注意一點，產品經理繪制出來的原型一般是非高保真原型，是為了更好的溝通需要，所以不能完全按照原型做，需要基於我們自己的前台架構進行定製。

4、需求評審的時候，研發可能會有一些不一樣的意見，他們做了很多年的開發，會有很多好的經驗，好的經驗要虛心接受，不能覺得自己是產品就是老大，就是要按我說的做，這樣很容易造成矛盾，求同存異，目標一致，這個是最好的結果。

5、研發說這個需求做不了的時候，有兩種情況，一個是覺得這個需求實現起來比較麻煩，故意騙你；另外一種情況就是他的知識盲區，他可能確實不知道這個事能做。

產品經理需要有能力和研發進行談判，比如採用類比法（類似的需求在其它項目上咱們就做過），比如去找架構師探討技術可行性。

6、研發有時候評估的工作量會比較大，整個上線計劃拉的比較長，產品經理可以要求研發出詳細的資源配置清單，這樣能清楚的看到一個需求被分解成了多少個研發任務，每個任務的起止時間，由誰負責完成。這樣產品經理大概能看出任務的前後置關系是否合理？工作量是否合理等。

產品經理絕不能說，這么簡單怎麼要搞這么長時間，類似的話一出，絕對會激怒對方，還是要有理有據進行談判。

如果實在無法壓縮工作量，如果增加人力能解決問題的話，可以考慮找領導申請資源。如果還是不行就要砍需求或者改方案了。

7、在版本計劃定好的情況，盡量不加需求，這樣很容易打亂開發的節奏，如果一定要加進來，一定要和研發說清楚，這個是用戶領導或者老闆的強制要求，轉移矛盾。如果可以的話，增加了需求盡量推遲上線計劃。

8、開發過程中如果需求有改動，需要及時更新需求文檔，同時發給我們的研發同學，否則只是靠嘴說一下，很可能研發的同事就不做了，所以一定要落到紙面上。

9、上線的時候要堅持和研發同事一起加班，這樣大家才是一個團隊，贏了一起狂，輸了一起扛。

10、最後一點，就是要多交流，沒有什麼問題是一頓火鍋解決不了的，大家關系好了，很多事情溝通起來自然容易，而且也會更信任對方，這樣就萬事OK了。

㈣ 產品經理怎麼和程序員打交道【3】

經常有人問我：「嗨，費傑你好！請問阿里巴巴的需求文檔怎麼寫？「，但很少聽到人談：「嗨，哥們你好！請問產品經理怎麼和程序員打交道？」你回去稍微琢磨了一下，心裡就會得到下面三種情況：1) 很多產品經理之前就是程序員，所以非常了解程序員是什麼樣的一個狀態；2) 很多產品經理還停留在關注自己產品規劃、設計本身，缺乏對團隊配合的思考；3) 很多產品經理，其實是有和程序員打交道的實踐技巧、心得的，但沒有重視和分享。事實上在很多產品研發體系下，產品經理和程序員因為思考方式、關注范圍、職能職責的差異，導致了溝通上的困難。如何更好的與程序員建立起一座暢通的橋梁也是每位產品經理需要思考的問題。一般情況下，產品經理和程序員溝通困難大概的原因：�0�21、得到信息不對稱；�0�2�0�2產品經理得到的信息一般集中在：商業需求、商業策略、戰略方向、產品規劃、運營數據、整體營收、目標任務等方面。產品經理往往在根據公司現階段的情況，以及市場的競爭情況，做一些產品策略或者一些產品的方案的策劃、發起、實施。
所以這個過程中，產品經理扮演的角色是翻譯：「市場需求、商業需求」，成為：「產品需求」，所有的信息全部圍繞需求本身。為什麼要做需求？怎麼做需求？先做什麼需求、後做什麼？基於怎麼樣一個思路去推送產品進行實施、從一個利益平衡獲得空間增長指標後達到另外一個利益平衡。程序員不一樣，很多時候程序員得到的信息是：有一個需求，可能是小需求、產品需求、或大到項目需求，然後得到一系列需求列表，然後產品經理會讓程序員看：「需求」哪些通過code改改就可以實現，哪些是需要開發可以實現，哪些是技術或構架或因為成本的原因不能實現。
所以在這個過程中，程序員扮演的角色是翻譯：「產品需求」，成為：「技術語言」的評估，所有的信息全部圍繞開發需求本身。如何開發這些需求？是溝通資料庫增加欄位？調用介面？開發新的介面？需要開發組件？重新構架引擎？來實現滿足或支撐這些需求？那這個時候問題來了，很多情況下我們只是把程序員當做一個寫代碼，通過編程語言來操作計算機完成需求的工具了。�0�22、溝通語言不對稱；�0�2�0�2說到兩者溝通的語言，這肯定是困擾產品經理本身的。產品經理的語言是：「描述「、」形容「，我也見過很多產品經理，很多人的需求文檔就是漫天飛舞的文字，一整段的描述+描述，不要說程序員看不清，可能過段時間連自己都看不清楚。除了書面語言，產品經理的溝通語言也是含糊的，沒有太多的邏輯去組織，很多時候總是試圖去述說一個需求，被程序員的一個計算機術語而打斷。程序員的語言，更偏向於技術化。很多產品經理做過技術，有技術背景，但是還有很多產品經理不懂得技術。所以在這個時候，程序員在解說或回答一個需求的時候，會把自己習以為常的變數、函數、實現方式說出來。於是很多產品經理聽到：「Sdk、webshell、select、api、組件、插件、控制項「等等的時候會雲里霧里，那這個時候問題來了，很多情況下我們總站在自己的立場上、自己的世界裡認為別人也懂自己在說什麼？實際呢？大家都是聽得一半一半，溝通沒有徹底到位。�0�23、思考角度不對稱�0�2�0�2產品經理思考的角度在於產品本身，對技術的細節、技術的性能沒有太多的發言權。很多產品經理要是的實現的業務邏輯，不管程序員是採用：c++ 、java、php、Python、找開源代碼改的，還是自己寫的都沒有關系。程序員只要在約定的時間里，把約定的業務邏輯開發出來就可以，產品經理不去會考慮目前伺服器的配置、程序員手上任務的配置、技術能力的情況，要的是結果。而且很情願的認為團隊中的工程師都是世界上最好的工程師，想做什麼都可以做，對因為技術原因而不能支持實現需求不能接受。程序員思考的角度有點區別，我也看到不到程序員本身對產品追求完美對需求的背景、意義去研究了解；但很多程序員還是停留在自己接單子任務一樣來一個做一個的境界，做好了自己玩自己的。程序員考慮程序實現的方式同樣的一個請求是get還是post，程序員考慮代碼的性能，從而採取不一樣的方案去實現需求，考慮請求並發量壓力和安全性。但是很多情況下，程序員對技術的理解會導致有一些業務需求滿足不了，不是因為不能實現，是因為實現了覺得是廢代碼，或者構架不完美了。那這個時候問題來了，很多情況下到底傾斜誰的立場上思考問題？我之前也會碰到很多情況程序員就程序的角度說業務需求不合理，產品經理說程序員消極罷工、霸得蠻。�0�24、考核標准不對稱；�0�2�0�2誰也不尿誰，哼！你能把我怎麼樣。產品經理和程序員有為完全溝通或誤會的時候，極端情況下，有一方會罷工。這個時候主要是2個角色的各個考核標准不一樣，所以在很多情況下顯得非常的無奈。產品經理很可能考核的是方案和上線的時間、產品上線後的數據；而工程師考核的是程序的性能、很多時候產品經理催的急要的急，但程序員每天的時間有限，還是得慢慢構架慢慢開發，程序員開發時間少了，未知的執行BUG沒考慮過是要負責的。這個時候問題又來了，產品經理天天干著急！咋辦？以上是我結合幾年來的工作經驗總結出來的，當然這4大因素把很多共性的因素概況進來了。當然過程中還是會因為很多產品經理或程序員本身（個性）的溝通技巧、態度、情商等因素導致的溝通不倡，影響了彼此之間的默契。其實仔細的分析一下，產品經理和程序員打交道的過程中不管是共性的因素還是個性的因素，也不是想像中那麼困難。通過一些努力之後，我們總是會找到一些快速和程序員建立溝通橋梁的辦法。我個觀點如下：�0�21、 要看到項目層面，不要只看需求本身。�0�2�0�2上面說到的幾點不管是：「信息不對稱「、」溝通的語言不對稱「、」思考角度不對稱「還是」考核的標准不對稱「是我們常見的幾個客觀隱私。把幾個因素抽取出來剖析，發現還是由於我們站問題的視角的高度不一致造成的。產品經理只是看到自己得到了商業的需求，策劃了產品的需求，接下來會把很多事情拋給程序員做了，那還是站在需求方的角色中。那如果真正的是站在意識層面的項目經理的角度，這個時候看待問題的視眼會廣很多。這個時候你就想著為了做這個項目這個需求，程序員是不是明白了為什麼要做？是不是對這哪些需求的優先順序有了重要的認識？作為產品經理我用怎麼樣一種表達方式程序員更明白？是不是需要把時間點等劃定？目前程序員的資源和伺服器情況允許他們能做的空間是多大？怎麼樣才能拉動他們的積極性更好的完成這個項目？適當的時候，需要幫助程序員做哪些申請或讓步？對產品經理來說，同樣張羅一件事情，同樣會了得到一個結果，但是中間的過程很可能是完全不一樣的。所以因為思考角度僅僅從做完一個需求死磨硬泡上升到，站在項目的角度去考慮各個關節的風險點、時間點，得到的效果是完全不一樣的。�0�22、從理解程序員開始，換位思考會更好。�0�2�0�2一直在問一個問題：「程序員是什麼一群人？「就和問自己：」產品經理是什麼一群人？「一樣，有點好笑、有點幼稚。從小工到專家，從CSDN到走出軟體作坊，發現很多很多非常優秀的程序員的心聲。程序員是什麼樣一群人？像切西瓜一樣一刀一刀切：寫php的寫Java的寫windows C的寫liunx C的寫C++的編程水平一般的編程水平還行的編程水平牛逼的編程水平大師級的構架牛的資料庫牛的勤奮的懶於思考的不會JavaScript的積極的喜歡鑽研的……好像都不太合適，因為你找不到解決和工程師溝通的好的辦法。而且這些很多是外在的條件，隨隨都在改變。看到很多朋友一年之間經歷幾個大項目水平突然猛進，態度、一些特點也變得完全不一樣。這個時候你需要的是了解和掌握程序員，作為職場的人，和我們一樣的人共同需要的一些特點。如下4點：1) 是不是特別想被肯定、獲得尊重；理解、肯定、尊重。這3個詞或許非常的空但確確實實是一個非常好的方子。靜下心來走近程序員，聽聽他們的心聲、他們的抱怨，或許產品經理和程序員的距離將不再是那麼遙遠。雖然很多時候我們講德行說尊重，但真正領悟到心裡、落實到行動、表現在態度上的完全不一樣的。真正，你是不是一言、一行本真理解、肯定、尊重程序員的，程序員是有感知的。2) 是不是想給產品提供自己的建議，而不是僅僅做一個編程的機器；很多程序員對產品非常熱愛、對產品有獨特的想法，但多數又局限於技術情節對產品的建議常常被忽視。相信很多程序員都希望參與產品，通過自己的專長改變產品，進而打磨出一款完美的產品。所以產品經理也可以適當的給程序員一點發揮的空間，特別是在技術創新、產品需要技術驅動的方面，在商業可控的層面讓程序員發揮排頭兵的作用。這樣程序員會開足馬力投入到開發實施的過程中。3) 是不是不僅僅和人任務指派，需求更多的和諧的人與人之間的溝通建立。產品經理和程序員兩者之間沒有一個良好的溝通，只是基於做與不做，做好做不好，什麼時候做好，這樣的功利性溝通肯定是不可靠的。往往兩者因默契不夠，或一方因溝通技巧不足、對待工作態度不夠積極，造成矛盾。建立一個人與人之間的良好溝通，幫助產品經理或程序員更好的認知對方、了解對方，這樣無論是在平時的溝通過程，還是在項目的合作過程中更好的促進了解、達成共致都會有一個前提保障。4)是不是需要別人的幫助，讓他在非技術領域獲得真知。看到很多產品經理朋友和程序員打成一片，和程序員一天聊天、抽煙、一起下班打游戲、打球，甚至有些時候產品頭腦風暴的時候要去幾個有產品情節的工程師參與前期的討論，效果都不錯。可能這些現象從另外一個層面來解決我們上面的一些疑惑。3、產品經理要改善心智，不斷自我學習。�0�2�0�2最近突然覺得說得想的，有點像哲學。群里的一個朋友說了， 其實哲學就是我們生活一些事情表現出來的道路。產品經理跟程序員打交道也好，對待生活也好，我個人認為是產品經理對哲學的認識、理解、應用。產品經理越往下走，拋開產品技能本身不談，沉澱商業以及人脈資源，都是需要以一種良好、可靠的思維方式去支撐的，也就是所說的心智模型。很多時候產品經理改善心智可以不斷的增強一些事物的判斷。如：遇到程序員的拒絕的、不行的理由，這個時候你通過分析起碼要判斷得出來，這個是程序員隔個人的態度問題，還是流程問題，有一點微妙的。所以產品經理需要不斷的學習，學習提高軟技能。說到學習，回應這篇《產品經理怎麼樣和程序員打交道》中，程序員常用的一些技術原理、技術術語得去學習一下、研究一下。Right? OK, End ！

㈤ 產品經理該如何跟程序員溝通

產品經理面試的過程中面試官特別喜歡會問一個問題，如果開發人員以無時間為理由拒絕你的需求怎麼辦？工作中產品經理和技術人員打交道的次數太多了，行業內也流行著一些圖片來調侃產品和技術之間的關系，兩者的關系可以用相愛相殺來形容。

之所以這么說有兩個理由，相愛是因為兩者要互利合作，把老闆交給的任務完成，而且只有彼此合作才能讓工作進展的更順利。相殺是因為這兩個職業又存在著很大的矛盾，產品經理的需求間接決定了技術人員的工作量，有些技術人員確實對產品經理比較反感。

我也看過一些關於產品與技術如何溝通的文章。這篇文章我想結合我自己的親身經驗，分享一些小技巧，可以當做是保持良好關系的潤滑劑。

1

首先我們分析一下技術與產品之間產生矛盾的原因。在分析之前，先設一個前提，每個公司在招人的時候都有其標准，尋找價值觀相同的人，所以我一直都相信開發人員並不會無故找理由拖延項目周期。反過來，如果開發人員因為品性而偷懶或者說是耍心眼不幹活的話，那就沒辦法了，個人主觀因素太大。

第一種情況是產品經理的需求與開發人員手頭的項目撞期了，解決的辦法很簡單，就是根據需求的優先順序來調整開發排期。碰到這種事，有些領導也總是期望產品經理靠著自己的方法解決。但是除了跟上級領導申請調整優先順序，沒有別的好辦法。一個客觀事實，公司在多個項目中確實有優先順序之分，雖然你自己的孩子自己最看重但是在別人眼裡並不是這樣。第二個原因是開發人員是按照公司意願辦事，說嚴重點你總不希望別人因為你的事情跟領導鬧僵，搞砸自己的飯碗吧。

第二種情況技術人員並不認同產品經理的觀點，雖然產品經理和技術人員各司其職，但是在工作中會碰到有些技術對產品特別關心，如果產品經理的做法自己不認同的話會提出質疑。如果質疑的人是技術老大，產品經理往往會更被動。遇到這種情況我覺得很正常，想辦法說服技術人員。

除了搬出之前做的產品分析和用戶調研外，我在工作中總結了一點經驗，平時可以多跟技術聊聊天，增進彼此了解，觀察他們經常上使用的產品，在溝通說服他們的過程中，可以拿他們經常用的產品舉例，這樣的話他們本身對那個產品更熟悉，自然也更好理解。另外，在跟技術講解產品的時候也要適當的畫餅，描繪一下產品上線成功後的美好未來，這會帶動起他們的積極性。

2

產品經理要做好自己的基礎工作，這利於給開發人員留個好印象。做好這方面的工作有兩點，一是想好產品規劃的原由，避免被技術的同學問住。技術人員也特別討厭產品經理說「某某產品就是這么做的，我們按照他們的做就行了」這樣的話；二是寫好產品文檔，在產品文檔中避免有遺漏的地方，特別是一些比較復雜的功能，一定要解釋清楚，因為技術人員會遵照著產品文檔進行開發，所以說如果有疏漏的地方會增加溝通成本，如果文檔寫錯了，造成開發出來的產品功能不符合預期就是產品經理的責任了。

為了提高文檔的可讀性，我們也可以多使用圖文、流程圖的表現形式，如果只是乾巴巴的一個word文檔，幾千個文字，看起來確實很枯燥。

對於產品經理和開發人員來說信任尤為重要，如果開發對產品經理缺乏了信任，結果就是你的話開發人員不會再聽了，每個需求他們需要經過你的領導確認後才會去做。獲取對方信任的一個很重要前提就是說話算數，當技術人員詢問你某一個問題時如果自己沒想清楚，可以先暫時別回答，考慮清楚後再說。要是隨口一說，過後又讓開發人員修改，不僅會造成開發人員返工，這種行為也是非常不負責任的。

即便文檔寫的再完善，在產品開發過程中也難免需要當面溝通。項目跟進，需要產品經理極大的責任心和積極性。一個項目立項後，公司通常會把參與人員列為一個小組，產品人員需要根據開發排期跟進開發進展，避免開發出來的產品與預期不符，驗收產品功能是否與產品期望一致。這個過程產品人員的工作往往會比較繁瑣，也會比較忙，當然也會鍛煉產品經理的溝通能力。

3

說一下行業內一直討論的一個問題，產品經理該不該懂技術？我覺得這個問題並沒有什麼好討論的，無論是從個人知識量還是從是否有利工作的角度講肯定是懂技術要更好，而之所以能吸引那麼大的熱議，可能是由於很多產品經理不懂技術，但是又沒有興趣學習，所以心底一直會糾結這個問題。

從我個人的經驗來看，特別是你做項目比較多的時候，會發現懂點技術跟技術人員溝通起來會順暢很多，一個重要的體現是技術人員也很願意跟你交流技術實現的一些想法，而不會說「算了，跟你說了也沒用」這樣的話。

產品經理懂技術還有一個很重要的益處是當業務部門提出需求時，自己就能評估出技術實現的可行性，對於實現起來比較困難的需求自己就可以跟業務部門商量優化方案。而不必每個功能都去詢問技術，無形中也減少了技術的麻煩。

不過我跟很多人的觀點也一樣，產品經理對技術的了解不需要太精通，說到這我還得慶幸自己大學時候學的是計算機專業，雖然學的不好，但對於現在的工作還是非常有益處的。不過我在工作中也會碰到技術人員偶爾說了一個名詞自己不理解的，這時候兩種辦法，要麼主動問一下，要麼自己去網上查，明白其中的邏輯關系，知道是怎麼一回事就好。

畢竟術業有專攻，雖然我們希望知識越多越好，但也別給自己太大壓力。況且技術知識也在更新迭代，他們使用的框架也會變化，技術的語言也有很多，如HTML、Java、PHP等，你不可能全都精通。

4

最後說點工作中會遇到的個人主觀因素。

當產品經理跟其他部門提需求或是溝通確認的時候也不排除其他同事有未及時回復的情況，為了確保項目上線也為了爭取資源，這個時候就需要產品人員更加主動一些，所以產品經理有時候還需要臉皮厚一點。

當提交一個需求給開發部門制定排期，你會發現他們都會把時間定的很充足。也許你會因此對其他同事有看法，但其實在工作中都是這樣子，大家都不會把自己的時間安排的太緊張，而且還要考慮過程中可能會出現的風險因素，例如請假的情況。當然也不能把時間定的太長，那樣老闆該不開心了，所以最好是產品經理根據上線時間與開發人員定一個時間結點，讓開發人員在這個時間點前完成即可。