產品經理和程序員的操作

『壹』 為防被程序員「砍」，產品經理需要注意這些場景

互聯網行業中，眾人熱衷於討論「程序員砍產品經理」。雖然，「砍」更多是調侃的意思，一種消遣工作的方式；但是，這不是一個飯後笑話，側面反應了產品經理和程序員間的對立關系。很多時候，產品經理和程序員間就像對手，產品研發過程就像打仗，總要爭個你死我亡。「砍」的本質，是程序員表達對產品經理的不滿，也是一種情緒的宣洩。

在產品研發的過程中，產品經理與程序員對立關系，會嚴重影響項目的推進。一旦產品經理和程序員對立關系公開化，很容易導致團隊人心渙散。這種對立關系，經常滋生出一些極端的事情，罵娘、打架已屢見不鮮。

下文就列舉一些程序員想砍產品經理的場景。這些場景都是我過去和很多程序員朋友交流時，他們遇到的對產品不滿的場景。這些場景，都會以產品經理的溝通話語表現出來。通過這些場景，去解析這種對立關系產生的原因。以及，作為對照，產品經理應該如何規避和處理這種對立關系。

這樣說法是程序員們最不喜歡的，最容易惹毛程序員的。這句話，在程序員們看來就是削減工時、加班的代名詞，他們當然不喜歡。而且他們也非常討厭，一個非技術人員為技術人員做技術難度的定論。簡不簡單，都需要技術人員做了技術評估，才能下結論。

這種言語，會讓程序員們覺得產品經理不靠譜。大家通常都是比較排斥借鑒。借鑒你也得有合理明確的理由。以我某程序員朋友的話來說：微信怎麼做的，你就怎麼做，那你不如去微信做產品算了。

每個產品，在表面的UI下，都有其背後的復雜的業務邏輯。如果產品經理只是叫程序員照著某個產品做，很多時候技術們是很難實現的，因為他們也需要弄懂背後的邏輯和流程。當然，這應該是產品經理的工作。

這就是抬杠。產品經理雖然名字裡面有「經理」二字，但並沒有經理的權利，當然不能命令合作的技術們。這句話，言下之意也是拒絕了商量和討論。而程序員也需要參與感和團隊感。

這就是質疑他人能力，是人都不會喜歡。如果產品經理提出的方案，程序員們沒有理解。那就說明產品經理的解釋說明和文檔，做的不夠優秀，不夠簡潔易懂。讓程序員們理解需求，是產品經理的基本工作內容。

在互聯網產品開發中，修改需求和插入新需求都是挺常見的。對於程序員們來說，這是非常不爽的事情。這種操作通常會打斷程序員的思路，思路被打斷是非常痛苦的。當然，這樣也會影響他們的開發效率。更可怕的是，反復的修改需求，會使他們有種勞動成果不被尊重的感受，同時也會對項目的未來抱有懷疑的態度。反復的更改方案，也說明產品經理設計是未經過嚴密的論證，或對細節的把控是不夠。

程序員都比較討厭反復的催促。當項目的節點確定後，技術們會嚴格遵守節點，產品應該信任他們。當然，時間比較緊湊時，反復催促也會加大程序員們的壓力，使他們變得非常煩躁。在這種時候，催促就是添麻煩。

甩鍋會導致團隊分崩離析，人心不齊。不管任何問題，都是團隊的責任，不要將責任指定給某人。特別是在項目復盤時，如果心態不好同事，這是非常難堪的。所以，我們要盡量以原因和結果為導向，而不是責任為導向。

程序員也是也是團隊的一份子，有權利知道知道需求的背景。同時，了解需求背景也利於程序員們更好的開發程序。

產品經理給程序員們畫餅是最不切實際的，只會引起大家的反感。程序員都是喜歡偏實際的東西，虛的東西只會招致白眼。

任何傳遞給程序員的需求，都是需要有計劃和規范的。如果口頭傳達一個需求，很容易導致開發出的功能與需求不匹配。同時，因為缺乏相關的記錄和文檔，可能會造成需求流失。這對於程序員們來說，可能就是延遲、加班、返工、擔責等等風險。這是團隊合作的大忌，也是項目管理不專業的體現。

以上的這些場景，可能出現一次，程序員們都會順著我們的想法做。但是，這會漸漸改變程序員們的心態，最終會使產品經理與程序員間產生隔閡和矛盾。如果出現這些場景，作為產品經理都需要小心的處理好，以免影響項目的正常推進。當然，最好是不要出現這些場景。作為產品經理，我們的最終目標，都是要保證我們的產品，准時、保質、保量的落地。

產品經理在與程序員們合作時，產品經理需要講究合作共贏、互相體諒。在產品經理的相關工作中，最要避免的就是抬杠。抬杠是一切矛盾的根源。很多時候，產品經理要站在程序員的角度考慮問題。比如，對於產品來說可能就是改改需求，但對於程序員，他們更在意的可能是因為改需求而導致的加班。

產品經理在工作中，經常會追求產品上的極致。追求極致本身是好事，但是切忌過分偏執。我們也需要考慮團隊的現狀和資源，在極致和現實間尋找均衡。畢竟，如果沒有喬布斯的團隊，要像喬布斯一樣做產品，只會拖垮團隊。

在產品開發的過程，改需求、改方案等項目異常，都是不可避免的。這是項目管理的第一部分。如何進行項目異常的處理，考驗的是產品經理的溝通能力和項目管理能力。產品經理需要在保持技術們高效工作的情況下，完成項目異常的處理。

當然，在產品經理工作中，矛盾的根源也並不總是產品經理。有時候，也可能是某些程序員的性格或者對該工作的態度導致的。這時候，產品經理要明確，作為團隊的潤滑劑，有責任推動和協調大家的工作。如果，矛盾不可調和，我們需要盡早提出問題、控制風險，避免「勉強」行事。

有時候，程序員在私下評價一起工作的產品經理時，總是會補加一句「我感覺我也能做產品經理」。這句話的背後，是產品經理沒有讓程序員們感受到產品工作的價值。在這種背景下，產品經理是很難獲取程序員們的注重，也會為很多爭論埋下誘因。那如何感受到我們工作的價值那？其實很簡單，就是保持工作信息的透明。將我們針對需求和產品做的相關工作，體現在我們的溝通或者文檔中。

導致程序員想「砍」產品經理，本質是產品經理工作方式的問題，也有情商的問題。在我的產品經理工作經驗中，我總結下了以下四點，我們需要注意和避免的。這四點，都可以和上文的場景相對應，是最容易慢慢改變程序員的心態的。

『貳』 產品經理該如何跟程序員溝通

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

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

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

1

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

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

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

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

2

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

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

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

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

3

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

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

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

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

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

4

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

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

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

『叄』 程序員和產品經理究竟哪條路更好

如果你本身喜歡寫代碼，那麼我覺得程序員的工作挺好的，未必要做產品經理。程序員主要是和機器、代碼打交道，工作難，但是邊界清晰、可控，事情比較聚焦。我並不建議大家都要去做產品經理。
寫代碼是純手工業勞動，大家平時用的各種互聯網產品，都是程序員一行一行代碼寫出來的，還要考慮代碼的邏輯，解決各種Bua等等。如果想做好程序員，就一定要熱愛寫代碼這件事。優秀的程序員，都能夠從自己的工作里獲得樂趣。我認識很多優秀的程序員朋友，我非常尊重他們，而且也特別佩服他們的能力，還有對於工作的熱情。

產品經理要解決的問題的要更綜合、更廣。例如要考慮用戶需求，考慮市場、業務情況，還要考慮和設計、運營、研發之間的配合。

有一些人適合做產品經理，有一些人不適合。我也不太建議大家一窩蜂都去做產品經理。我建議就像做產品一樣，你要大膽假設、小心求證。如果要做產品經理，就多了解這方面的信息，多試試，然後看看自己適不適合。

無論是學生，還是想轉行的人，往往的問題在於糾結太多，想的太多，嘗試太少。如果你想做程序員，那你先寫寫代碼，先做出一些東西，除了看你自己適不適合之外，也能夠成為你找工作時的籌碼。如果你想做產品經理，那麼多試試做做產品，哪怕是虛擬的項目，增加自己的經驗和感知，也能夠成為找工作時的籌碼。

所以，並不存在說產品經理或者程序員到底哪個更好，相比很多行業和職位，產品經理和程序員這
兩個職位都應該是非常好的了。做的事都有意思，工資待遇也都高。
關鍵在於你自己適合哪個，這個問題歸根結底別人沒法回答你，得靠你自己通過了解更多知識來做出判斷。

『肆』 「碼農」轉型產品經理

技能：需求分析、產品設計、項目跟進

內功：邏輯判斷、數據分析、溝通、個人管理等。

從0起步，實現從「碼農」轉型為產品經理，實現從產品門外漢——產品助理——產品經理——產品主管這個過渡，從最開始只負責一個功能，到可以接手APP+後台兩條產品線的規劃工作，並能夠帶領一個產品團隊。

每個工作崗位的成長必經過「痛並快樂」的蛻變。同時解決以下問題：

如何利用工具來評估產品的工作進度？

如何保證上線時間？

如何預測項目狀態？

如何挖掘出用戶潛在的需求？

Stage1：入門期

1、新手如果什麼也不會，沒有經驗，建議多去畫原型頁面和跳轉鏈接，找找感覺，把最基礎的工具給用熟練，以後再畫原型的時候，可以手到擒來；【挑一個代表性的APP，照著全部頁面畫了個遍】

如果有一定經驗，建議把每一個細節性的操作實現了，多去做幾個，便可以發現其中交互不夠完善的地方。

2、傾聽比提意見更容易讓人接受。產品經理一般都願意說幾句，這個時期，融入團隊才是第一要素，讓別人能夠快速接受你，才能夠在日後方便開展工作。

如果上來別人就對你抱有敵意，那麼在日後的溝通中，很容易出現問題。

Stage2：高速提升期（1-3個月）

在這個時候，你將迎來自己野蠻生長的時候，在產品方面，有天賦和熱情的人，能夠表現出強烈的願望，為了一個功能，可以較真半天，實現其中每一個細節，初級產品的思維和理論框架會逐漸形成。

這個時期產品基礎必須打牢，否則在後期中，很容易出現產品細節考慮不周詳，想法多而實現不出來的現象。

工作中：

1、參與到每一個版本迭代的功能設計，提高產品設計能力，對需求理解的能力，惡補相關設計、交互知識，完善每一個功能實現的邏輯，測試產品功能，確保產品上線無誤。

2、建立公司標准統一PRD文檔模板、BUG管理模板、需求管理模板，根據模板，書寫每一份文檔，定期修改模板、完善模板，接收技術團隊反饋信息，逐步細化每一個功能點的實現說明和邏輯說明。

3、積極溝通，與項目干係人溝通產品方向的問題，確保自己的想法能夠觸達到老闆；積極和技術溝通，把邏輯上有問題第一時間解決掉，然後改各種bug。

4、（粗略）看報告、看競品、看分析、看文章，日常空閑了，便會去人人、知乎等網站查看一些別人寫的分析報告，學習新的知識，好的理念和方法都會記在本子上，一些行業報告會存在收藏夾中，幾乎每天看2個小時左右。

建議：

1、做好基本的工作——文檔、原型、溝通。要想快速的提升，加班是必不可少的，通過加班，可以更好的自我學習，利用更多的時間，來填補產品方向的空白，利用加班時間，好好思考功能的設計、文檔的書寫、競品的分析等等，完善這些基礎性的工作。

2、學會理解、管理需求。明確需求是怎麼來的，清楚為什麼要做，知道怎麼實現，這是理解&實現需求的3個步驟。很多的需求我們沒法在短時間內實現，我們便要將這些需求存放起來，以待日後拿出來實現，這個時候就要將需求分類、分程度進行管理，基本一張Excel便可以解決。

Stage3：波動期（1個月）

這人有了點成果就開始膨脹，然後開始犯錯了，接著就被打回原形。開始時覺得干起什麼事來都得心應手，覺得什麼事情自己都乾的來，設計的功能也一定有人會使用，下個版本就是產品爆發的時間。

結果就是，一切如舊，沒有提升。一時間，競不知道如何是好，情緒波動很大，總覺得自己能做，但仔細一想卻終是覺得做不好，我知道這是到了瓶頸。

切勿做以下的事：

1、產品規劃完全脫離實際，跟著領導一起想入非非，設計的功能實現起來非常復雜而且困難，給技術造成很大壓力，並且多次返工，強行上線版本，bug居高不下。

2、錯誤估計技術實際開發實力，公司當前實際情況，人員情況，考慮團隊的穩定性，協作能力。

3、原型設計，交互邏輯有問題，開發結果是不符合當天階段版本。

建議：

1、時刻對自己進行審視。知己知彼百戰不殆，了解自己，才能更好的打仗，產品經理必須要對自己的能力做清楚判斷，小步試錯，多次迭代完善，不能一口吃個胖子。每做一個功能的時候，多去問問自己為什麼，怎麼做最好。

2、失敗不要氣餒，回頭重整士氣。產品經理很容易影響他人的情緒（多數是懟），如果你情緒很down，那麼在交流過程中也會出現詭異的氛圍。

Stage4：沉澱期（1個月）

發現了自身很多的問題，一下子被打回了原形，受到了多方的指責，用戶負面反饋急劇增多，用戶流失嚴重，很難受。

雖然明知道不是自己一個人的問題，但在關鍵時期沒有堅持產品經理的基本職責，也是失職。

工作中：

1、深入了解資源問題。了解自己能動用多少的資源，包括：時間、資金、技術、跨部門協作等等，從公司內部進行剖析，分析公司現在所處在的位置。

2、分析人員管理問題。重新招入測試人員，減輕產品負擔，與每一個成員進行溝通，了解他們的真實想法，以及對產品的意見，然後總結原因，上報給公司領導，然後再仔細討論這些問題，以及如何解決。

3、總結自身問題，重新規劃路線，專攻一個領域。總結4~6月份出現的種種問題，分析每一個由自身導致問題產生的原因，找到自己薄弱的地方，然後制定一份半年提升表，按照月份，每個月實現其中一個計劃目標。

建議：

1、沉澱期是自我剖析最好的時間，主要分析三個問題：我是誰，我從哪裡來，要到哪裡去，以公司或者產品為主題，仔細的分析下去（這三個問題，我第一次想得時候，竟然無法准確的回答上來，這就是對產品理解的不足）。

2、總結經驗和方法，形成體系。每次版本更新迭代的時候，產品經理都能形成一定的方法，但是一直都沒有體系，在這個時候，將自家每個版本的方法論重新整理一遍，然後分析不足之處，非常有利於思路的擴展，理論框架的完善。

3、聚焦內部的同時，逐步擴大外部視野。在內部，做產品要多關注其他人的意見，接受用戶的反饋，學會分解工作，制定優先順序，然後引領產品的導向；其次，要將視野放在外部，慢慢去了解行業的動向。

Stage5：穩步提升期（現在）

到目前為止，已經經歷了大大小小20多個版本的迭代，產品也終於從0-1走向了正軌，這個時期，總算覺得自己做了一件有意義的事情。

嗯，然後回頭又被技術、運營、UI各懟一遍，一場硝煙又彌漫、相顧無言淚兩行~~~

工作中：

1、學會控制節奏。這點我放在第一位講，之前經常被各種領導帶節奏，導致加班頻繁、狀態堪憂，現在每個版本前，我都會仔細的思考一些問題，然後將我的見解說出來，以實際的角度來闡述問題（時間、范圍、成本、質量）。

即使我的意見最終不會被採納，那領導提出的需求，也需要在我正常可控的范圍內，這是我提出的要求，除非領導要強制執行。

2、開始橫向發展。主動關注產品戰略、行業觀點、業務模式，提高眼界，希望能夠從更高層次來審視產品。

這是產品經理能力提升的一個必經過程，主要培養自己的大局意識和核心意識，領導的優勢在於經驗豐富，但產品經理可以隨著成長，更加的專業，當你在某個小領域的知識和經驗超過他時，那你便能輕松的說服他。

3、關注產品本身。這里有兩點，一是從外部關注產品，通過分析競品，分析相似產品，來提高自己對某方面功能的設計能力；

二是從內部關注產品，通過建立數據分析體系，對產品進行埋點，以數據來驅動產品的功能迭代。這兩點是我最近主要做的事情。

4、思考更多細節。APP異常情況處理、極端邏輯的判斷、交互設計、數據異常等，通過這些不斷深入細節末節的功能操作，完善產品的體驗；

其次，參與其他崗位的工作，每天定時回訪幾個用戶，與客服、運營、市場等同學交流，談談自己的感受，傾聽他們的想法，雖然現在看起來對產品的優化還沒什麼作用，但對於自己思維的拓展確實有不小的提高。

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

產品的功能、質量、發布時間和需要投入的資源這四者不能都是封閉條件，否則可能無解。需要投入的資源和發布時間一般是大老闆定的，所以產品經理、開發經理和質量經理只能在「砍功能」、「降低質量要求」和「程序員加班加到死」這三個選擇上相愛相殺了。根源是：高層放衛星玩大躍進，那下面只好群眾斗群眾了。佛曰：與人斗其樂無窮。對於程序員來說，很多時候問題是 PM 不能證明自己存在的價值。PM 要證明自己的價值有幾種可能性：

1、色的產品記錄，自己的名字就是個品牌，程序員知道跟著你做事能成功。

2、假會導致產品方向混亂項目失控，這很容易證明為什麼你需要存在。

3、通過程序員可以理解的方式把道理講明白，讓程序員信服為什麼你管理產品的方法是對的，以及為什麼程序員自身不可能做得跟你一樣好。

可能還有別的方法讓一個 PM 證明自己存在的價值，但如果證明不了的話程序員就會把 PM 看作純粹的 overhead（額外負擔）。PM 對產品團隊帶來的價值和負擔是不可能客觀測量的，別人的主觀評價是什麼就是什麼。如果程序員對 PM 的主觀評價是負擔大於價值，那這個 PM 就沒有存在的意義了。核心原因是——好的產品經理永遠缺貨。當然，優秀的程序員哥哥也缺。既然都缺貨。產品經理是決定公司效率高低的關鍵，產品經理在一個成熟的公司成熟的團隊意味著靈魂和中樞，程序員哥哥不過代表著執行力和能力的邊界（想不明白就瞅瞅喬幫主馬化騰周鴻禕）：1個不知天高地厚的產品經理，2個不經過思考的決策，他的工作量也許只增加了3倍，但他賦予程序員卻是10-1000倍的工作量。

『陸』 程序員和產品經理相愛相殺，打完架再「牽手」，全公司都沸騰了

在某個職場論壇里，有網友發帖爆料，大方曬出自家公司 產品經理 和 程序員 相愛相殺的照片。畫面中，兩個大男人手牽著手，面朝牆壁背對眾人，濃濃的基情感撲面而來，讓人忍不住浮想聯翩。

這可不是他們成功「出櫃」了，而是公司對兩個人動手打架的懲罰措施。因為在產品項目上溝通不順，產品經理和程序員起了爭執，兩個認死理的人互不相讓，一言不合就打了起來，拳腳相向好不激烈，費了老大勁才把他們各自拉開。

程序員和產品經理的矛盾，早已經不是什麼秘密了，在 互聯網公司 里， 要論程序員 最討厭誰，產品經理絕對能排進前三。要求多還奇葩，反反復復變動，指手畫腳叨叨個沒完，讓程序員們苦不堪言。只是雖然彼此間矛盾多多，但還算克制，真真動手的還是比較少的，像這種大庭廣眾之下互毆的，就更不多見了，也難怪公司要當眾懲處了。

兩人動手打架的影響非常惡劣，公司要求要麼一起辭職滾蛋，要麼牽手一下午。終究胳膊擰不過大腿，雖然這個要求很詭異，但為了不被辭退，也只能捏著鼻子認了。本來還劍拔弩張的兩人，在眾人的見證下，大手拉小手整整牽了一下午，畫風都歪了！

其實無論是產品經理還是程序員，大家最終的目的都是為了整個項目能夠完美交付，為公司完成這筆業務。只是兩個人的側重點不同， 產品經理 要考慮客戶考慮市場， 程序員 則更關心產品本身的合理性。當關注的重點不一樣，難免會產生分歧，引發彼此之間的沖突。

而且都是公司的同事，平日里抬頭不見低頭見，大打出手確實不應該。在有著共同目標的大前提之下，即使兩人的立場不同，但也應該彼此互相體諒，只有精誠合作，才能事半功倍不是。

公司的處理決定也很機智，辭退可能只是玩笑話，要他們牽手和好才是真的。畢竟都是為了公司的產品項目才弄得這么大火氣，把他們安撫好了，項目也能更順利完成。而且這種方法雖然看起來尷尬，但也沖淡了矛盾的尖銳，尷尬總好過對立，詼諧才更容易讓人接受。

這不，還有網友打算效仿呢！嗯，都是人才！

『柒』 你是如何從程序員轉型做產品經理的

程序員的工作其實和產品經理還是有很大的區別的，最大的區別就是你自己做程序員的時候，只需要考慮的是你的產品的問題。而當你轉型最產品經理了就不是這么簡單了，你還需要考慮就是這個市場調查的用戶需求問題，以及你的產品線的組合問題。

產品問題

你從程序員向產品經理轉型的過程中最重要就是做好這一點。你需要改變的就是你不能僅僅只看這個產品的質量的問題，不能僅僅去修一修BUG呀，你需要的是有一個全局的思想的。

如果你想要從一個程序員轉為產品經理的話，你需要改變的事有很多的，比如你對待產品的問題上，以及這個產品組合上，你需要學習的還是有很多的。

『捌』 產品經理主要工作流程是怎樣的

一、產品經理的需求來源

產品經理一切工作的本源是：需求。所以我們從需求來源開始講起產品經理完整的工作流程。互聯網需求來源一般有：

1、產品需求：產品經理通過數據分析耐唯、用戶調研、競品分析等方法驗證通過的需求

2、運營等業務部門提交的需求：比如以京東為例，服飾業務部/生鮮業務部/家電事業部的運營、采銷等人員出於提升業務指標的角度會提出各種需求

3、老闆的需求：領導從外部合作的角度或者產品戰略的角度也會給手下的產品經理提一些需求，比如我還接到過大Boss和老闆娘的需求

4、Bug修復等：在工作中修復BUG是一件比較常見的事情，影響面大的BUG會走緊急修復流程，不太嚴重的BUG會走迭代排期。

二、需求池的管理

通過以上幾種方法收集到的需求會統一放到需求池中。需求池大家可以理解為所有需求的集合（包含待確認、設計中、帶排期、開發中、已上線等所有狀態）。

一般來說，使用execl表格管理需求池即可，按照各種需求狀態進行分類展示。

三、需求優先順序

我們需求池的需求會非常多，但是每個迭代的時間是有限的/研發資源是有限的，所以導致我們只能從需求池中挑選出少量需求進行開發，從而誕生了需求優先順序的概念。

一個迭代中肯定有限做優先順序高的需求！

那如何排定需求優先順序呢？

一般來說有兩個場景：

1、從0到1設計一款產品

這種場景下的需求來源基本上都是產品需求。建議大家去了解一下KANO模型，這個場景下的需求優先順序一般來說是：基本型需求>期望型需求>興奮型需求

2、在原有產品基礎上優化

這種場景的需求來源會非常廣泛，可能之前講到的4中來源都是涉及，那如何排定需求優先順序呢？一般按照產品價值和實現成本兩個維度。

產品價值可以分為兩類：業務價值和用戶價值。

價值定義：

• 業務價值：對應商業類產品，稱為商業價值，體現在能給業務帶來多少收益。

• 用戶價值：對於使用者來說，能給他帶來的價值，比如說能減少操作步驟。

在這種方法下，優先順序的排序邏輯是：產品價值大實現成本低>產品價值大實現成本高>產品價值小實現成本低>產品價值小實現成本高。

四、需求確認

當梳理完需求優先順序之後，我們就按照開發工作量挑選優先順序高的功能組成新版本/新迭代周期的需求列表。

梳理完需求列表之後一般要跟直屬領導當面溝通一版，這叫需求確認。在這個階段要做好挨批、被懟的准備。領導會從各個維度「挑戰」你需求的合理性。所以大家在需求評審前一定要多思考幾遍，盡量多用客觀數據去說服領導。

如果需求確認通過，會進入到產品設計階段。

五、產品設計

產品設計階段會包含如下幾個小階段：

1、使用產品腦圖梳理產品/功能結構框架，特別是對一些邏輯復雜的新產品/新功能。

2、使用產品流程圖梳理產品/功能核心業務邏輯。流程圖的梳理盡量詳細，各種異常場景的判斷一定要在流程圖中有所體現。對於涉及多個參與方業務，可能還要梳理泳道圖。

3、使用墨刀/axure等原型工具輸出產品原型。原型是產品邏輯的可視化表現，也是產品經理最最基本的基本功。

4、察擾撰寫產品說明文檔（PRD）。PRD是產品詳細邏輯的最終呈現，也是內部溝通的標准文檔。PRD撰寫完成之後就可以進入到需求評審階段

六、需求評審

需求評審是指產品經理要向UI、交互、研發、測試等內部人員講解產品邏輯，保證產品邏輯在內部傳輸過程中不失真。

需求評審的過程中，有4點需要注意：

1、評昌沒培審的時候，先講需求背景。即這一版本為什麼要做這需求？做完以後預計會達到什麼效果？讓相關參與方從心理上認同做這件事的價值。

2、在講具體需求的時候，按照對應的責任人進行拆解。比如在講解功能A的實現邏輯時，我一般會說客戶端需要完成的內容是1、2、3；服務端需要完成的工作是1、2、3；演算法側的工作是1、2、3等等。

3、存在爭議的地方先記錄下來，評審結束後再細化。

4、就是評審結束以後要追排期。即作為產品經理你要盯著研發Leader，設計Leader，測試Leader讓他們出需求排期，以此保證項目按時上線。

七、項目管理

需求評審完成之後，項目經理（大部分公司由產品經理擔任）會輸出詳細的項目排期表，然後項目所有相關人員會按照項目排期表有條不紊的協作。項目管理的詳細流程如下：

八、數據分析

產品上線之後，產品經理要做好產品分析工作，以驗證產品/功能是否達到預期目標。特別是產品上線7天後，產品經理需要想全體組員發送產品上線數據報告。

如果數據不達預期，就要進行深入的分析內在原因是什麼，然後數據分析的結論很可能是下一迭代的需求來源，從而開始一個新的迭代周期

『玖』 產品經理和程序員,如何避免矛盾

產品實現是你的目的，為了這個目的不必太講究。

做了一陣子之後我有了自己對於與程序員相處的方法論，對這句話並不苟同，我還是傾向於把事做好的同時也能把話說好，雖然我現在也能深刻的領會到當時leader的核心意思是產品本身是第一位的。

接下來我就闡述下自己的一些心得：

• 產品經理與程序員最大的矛盾在於——改需求。這牽涉兩個問題，一個是如何盡量地做足前期工作，盡量把需求細化，需求做的足夠扎實就會大大減少改需求的次數，這是產品本職工作，不屬於溝通問題；另一個問題就涉及如何溝通了，就是需求無論如何確實要改。這個時候有一點很重要就是努力與程序員（或者開發經理）達成共識，比如「我們的目的是要做最好的xxAPP」、「這個功能對於我們的目的來說是必不可少的」等，然後再來談詳細的需求點，程序員也就會逐步認可改需求這件事情。（還有一點很重要的就是，如果無論如何也達不成一致，也有必要反思這個需求是否真的有改的必要？）

• 用數據和客戶來幫你增加底氣。在談論某項功能實現的時候，產品經理經常會碰見程序員消極被動不願意做，或者質疑這么做有沒有道理的時候，採取需求依據的數據和真實的客戶需求是能有效推進的好辦法。比如「80%的同類產品都有這個功能」、「每周都能收到幾個客戶對某某問題的反饋」，一般來說程序員是能夠接受這種說服的。

• 試著多用詢問的語氣。讓程序員感到他是專業的，他是能夠解決這個問題的，要依仗他才能做的更好。這會無形中賦予他一種責任感（因為你把問題拋給了他，他就隱形中負有解決這個問題的責任），在傳達出意願的同時也避免了話語的生硬，讓程序員感受到對其職業技能的尊重。

• 注重日常交往。日常生活中交個朋友，比如一起打球、打游戲，聊聊電影和漫畫，實在是沒有共同語言就經常沖他賣個萌、攪個基、撒個嬌、講個笑話。這樣，大家都是朋友了，不看工作職責的那一半看交情的那一半，溝通起來也會順暢很多。

總結：有很多時候產品的產生不完全是靠嚴格的流程和規章制度誕生的，也需要很多溝通的潤滑。能夠開開心心地把產品做出來最好，但是最終我們還是不能離開產品實現這個 標的物。