首先，我是一名程序員，寫了好些年的代碼，也跟好些個產品經理打過交道。
一、先來回顧下，別人家的程序員與產品經理打架的過程。
產品經理：這有個需求，老板已經決定了，馬上要做，就是APP的主題可以根據用戶的手機殼顏色來改變。
程序員：可以啊，那你給我接口。
產品經理：什么接口？
程序員：你不給我接口，我怎么知道你現在是什么顏色手機殼。
產品經理：你不能自動識別？
程序員：怎么識別，你告訴我。
產品經理：那我怎么知道，這個是你們開發的事。
程序員：等一下，你說的手機殼是市面上隨便都能買的手機殼，還是官方定制的？
產品經理：市面上隨便能買的手機殼。
程序員：這個做不了，沒辦法識別手機殼的顏色，我連他有沒裝手機殼都無法識別。
產品經理：都說了，識別是你們開發的事，識別不了就開發一個讓它識別。
程序員：md，你當app是狗啊，訓練一段時間，就能讓它識別紅色藍色。
產品經理：行了行了，都說是你的事了，我不管這些，我說這個功能，要上。
程序員：那你找別人吧。
產品經理：那行，那我找總監，說你完全不配合。
程序員：我配你ma！
干架中...
二、那么問題來了：產品經理又要加需求或改需求了，程序員該怎么辦？
答：不答應也不拒絕，直接讓他找你的領導，聽領導的安排。
為什么要這么做呢？
答：首先，答應了，你自身有任務和工期，你做了這個事情，誤了工期，功勞跟你有沒關系不知道，但延誤項目的鍋肯定是你的。直接拒絕，則顯得你不好相處。而推給領導，讓領導去協調，如果領導接受，增加了相應的時間，則皆大歡喜；如果領導沒增加時間，萬一到時候真的誤了工期，領導也知道緣由。
如果你自己就是決策者，馬上面臨決策，怎么辦？
答：千萬不要馬上答應，也千萬不要馬上給出工期。 重要的事情 說300遍 都不算多。很多需求，當你直接想的時候，覺得不難，但是真正落實下來才發現，就會發現在項目中會相互牽扯。所謂牽一發而動全身，說的就是這個事。 你給自己留點時間，詳細的考慮下，既是為你負責，也是對公司負責。
另外，要善於給對方制造沉沒成本。
動嘴皮子的事最容易，有時候產品經理幾句話，程序員就得干好幾天，甚至好幾十天。最終，如果做出來滿足他的需求，那還好說。如果做出來不是他想要的，他再懟一句：我當時明明說的不是這樣！
空口無憑，受傷的總是你。
因此，一定要善於給對方制作沉沒成本。他提一個需求，你一定要他寫需求文檔。在寫需求文檔的過程中，產品經理也會梳理整個功能的邏輯，有助於你后續的開發。同時，有些功能是產品經理異想天開，自己要加上去的。你給他來這一手，他可能會覺得麻煩，就放棄這個需求了。
三、如何與不同類型的產品經理的打交道。
-
市場出身的產品經理，這類產品經理的思維主要是面向市場需要，會根據市場反饋的信息，提出需求，其出發點就是更好的服務市場，而較少考慮，這樣做對程序的影響。這類的產品經理，由於缺少技術的思維，如果完全按照他的思路走，那么可能會被帶到坑里。但是其實你只要了解到：他需要解決什么問題。並且提出你覺得較好的替代方案，通常能解決問題。
-
技術出身的產品經理，這類產品經理的思維會較為體貼程序員，會理解需求變更對程序的影響，甚至會幫你想好，應該如何實現這個功能。如果遇到這類型的產品經理，那么恭喜你。
-
如果你遇到的是，既不懂市場，又不懂技術的產品經理，還tm固執己見的，那么趕緊撤吧。
四、總結
程序員天天對着電腦碼代碼，所以很多人覺得善不善於溝通都不重要。但其實你看，與你關系密切的，你的同事、你的領導、你的老板、產品經理，他們都是人。嘗試着，去理解你的同事、你的領導、你的老板，甚至產品經理，那么你的路才能越走越寬，而不是只是碼代碼的碼農。