產品經理和程序員的對話

『壹』 產品經理如何找到妥協與堅持需求的平衡點

首先，這個平衡點肯定是模糊的，定性而非定量的。而且偏主觀，所以大家一般都會說 「拿捏一下」 平衡。在對方提出與自己不同的意見時，妥協之前我們需要盡可能地進行一番就事論事、有理或有據的辯論。然而，並不是每個決策點都能看出不同方案的明顯差距的。所以會出現雙方都有一定的道理，但誰也說服不了誰的情況。說白了，就是大家的側重點不一樣，導致最終的選擇也不一樣。面對無法通過辯論而達成一致的情況，有以下幾種解決方案：1. 雙方做進一步的理論或資料調研，再次 PK2. 通過紙上原型、展示頁面效果圖或可交互 Demo 進行用戶測試（User Testing）3. 兩套方案都開發，投放至線上進行 A/B Testing4. 一方主動/被迫妥協然而，採取第 1 個方法很可能還是無法達成一致，因為雙方的側重點依然不同；第 2 個方法成本較高，適用范圍也較為狹窄；第 3 個方法顯性成本最高，在A/B 測試有什麼局限性？ - 鄭堅義的回答中有討論；第 4 個方法，即一方主動/被動妥協，是最常見的做法。但妥協也是有技巧的，最重要的一點是抓大放小。也就是說，在關鍵的決策點上不能夠輕易地妥協，因為它決定了方案質量的 level。而對於一些不影響大局或方案效果差異不大的決策點，則允許在一定條件下進行妥協（相關回答：高級產品經理和普通產品經理有哪些區別？ - 鄭堅義的回答）。允許妥協決策點不意味著就要主動妥協，可以觀察和猜測對方的堅持程度。如果十分堅持，則妥協，這樣可以讓自己在下個決策點上掌握更多的話語權，就像談判一樣。如果察覺對方態度其實也並不堅定，則可以強硬一些，盡量把方案拿下。但一定要避免大比例地進行妥協，否則將喪失產品經理基本的影響力。其實，倘若在平常的工作中已經建立了良好的影響力，遭遇到的不同意見會少很多，因為大家都選擇信任你。

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

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

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

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

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

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

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

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

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

『叄』 項目負責人如何和程序員溝通

做一名程序員，雖然好的口才不是必要條件， 但不善於表達自己想法以及與上司同事溝通，吃虧的是自己；

最近做一個項目，與項目的負責人出現一些不愉快的事情,出現這種情況雖然與其它雜七雜八的事情有點關聯， 但最重要的原因還是在工作上缺乏溝通； 例如， 上周他給我們C#組的人員分配工作， 每人負責一個小模塊， 資料庫和需求文檔已經提供有，但資料庫的表欄位有可能根據實現開發情況做少許改動，而且也給我們一個例子看， 可能參考該例子來做； 在統一講需求時雖然聽起來明白了，但做起來會發現很多關節的細節沒考慮進去，而這些細節往往會影響到開發的速度， 甚至看駢符合了文檔的需求，但卻不符合負責人或者說是客戶的實際需求;因為文字類型的需求是比較抽象，特別是要做用戶界面， 雖然有例子，但也只能參考，不能照搬也做，這樣做出來的程序很多情況下只符合程序員自己的需求； 已經花了很多時間去做一個可能不需要的功能，如我當時做一個日歷控制項來顯示排班信息，且也接近交貨日期了，到時交到負責人手裡時才發現，這個日歷控制項不是必要的，選擇的時間范圍是在彈出窗口裡，且不保存到數據...， 這時發現做了很多無用功，又要加班加點去趕進度了。雖然這只是一個小例子，但相似的例子在前幾個月里已經發生過幾次，為什麼呢，因為表達能力差，也不善於與人溝通。可以利用日事清管理工具來溝通，把想法寫出來。然後@給項目負責人。不用直接面對，效果不錯。

『肆』 暴風影音程序更新稱殺程序員祭天是什麼小幽默

暴風影音軟體新版本描述中，出現「殺了一個程序員祭天」這一表述，屬於「產品經理和程序員的一個小幽默」。

今日下午開始，一張截圖在網路刷屏。截圖系暴風影音軟體在蘋果商店的下載頁面，其最新版本更新於8月25日，最新動態一欄中，描述為「修復了閃退的bug，還殺了一個程序員祭天」。

引發關注的產品描述，是「產品經理和程序員的一個小幽默」。一名公關人員稱，暴風影音本次更新，涉及的工作量較大，程序員及產品經理工作要求都比較高。其表示，軟體的更新描述，是「產品經理和用戶溝通的一個窗口，很多APP的說明都很生動有趣」。

估計那程序員已經是前同事了。

『伍』 如何向外行解釋產品經理頻繁更改需求為什麼令程序員煩惱

某產品經理經過多年努力，終於研製出可定製多層冰淇淋，可以根據顧客的需要現場定製。開張第一個顧客是聰明可愛的小湯姆，指著攤位的冰淇淋機問：我可以要多個自己喜歡的口味嗎？產品經理：當然了，你可以自由選擇4種口味來疊加哦。湯姆：那太好了！那我第一層要巧克力味的。產品經理：好嘞，巧克力味的。第二層呢？湯姆：我還喜歡吃奶油，那就要奶油的吧。產品經理：奶油，OK了。湯姆：第三層要花生醬吧。產品經理：搞定，花生醬。湯姆：嗯...叔叔，我能不能把花生醬的換成草莓味的呢？我剛想起來，隔壁小妹妹花生過敏。產品經理：啊，這樣啊，那我幫你換掉。湯姆：謝謝！那我還要原味的...產品經理：好，原味的...湯姆：等，等下，我覺得還是橙子的吧產品經理：怪我手快...橙子的湯姆：嗯...好像我媽媽不讓我吃奶油，能不能幫我把第二層換成梅子的呢？好不好~產品經理：...好吧，看在你是我第一位顧客的份上，幫你換。湯姆：太感謝了！...哎呀！狗狗不能吃巧克力對吧？！產品經理：狗狗確實不能吃巧克力。湯姆：我怎麼忘了呢，要是我家布丁吃了巧克力死掉怎麼辦呢？產品經理：那就不要給狗狗吃呀。湯姆：那怎麼行，這么好吃的冰淇淋怎麼能讓它就這樣看著呢？幫我把巧克力換成抹茶的吧~叔叔~產品經理：...小兔崽子，怎麼學成這樣了，你爸也是個產品經理嗎？！湯姆：不，我爸是程序員。