上週，又看見有程式和PM（產品經理）吵了起來，大致是因為晚上就要上線了，下午的時候PM來說要改點需求，但程式不願意。興許是天氣熱了，大家都很煩躁，於是一言不合就發飆了，最終還是程式老大介入才解決了問題。
程式和PM的最大矛盾應該就是需求：提需求、改需求。
但程式和PM一定是對立的雙方嗎？顯然不是，大家應該是同一個戰壕的戰友才對。回想起來，我也曾經和PM因為各種或大或小的原因有過爭執（還好，沒有打起來過 ）。事後想來，其實很蠢，因為爭吵根本不解決問題，反而引出新的問題。
那麼，程式和PM怎麼和諧相處呢，這其實需要大家刻意的去努力。本文記錄一下自己在這方便的感想。
本文地址：https://www.cnblogs.com/xybaby/p/10923990.html
和諧團隊必備要素
團隊不是個人的簡單疊加，團隊的良好協作需要團隊中的所有角色（PM、程式、互動、測試）的共同努力。
一致的目標
大了說，是公司的願景、使命；小了說，是團隊的近期目標。只有大家向著同一個方向努力，才能儘量避免1+1 < 2。作為一個職場人，一個很直觀的目標就是盡職盡責把產品（業務）做好。但這個看似很明確的目標，也是有歧義的，也許PM是想盡快上線，搶佔先機；而程式是想，把程式碼架構做得通用、可擴充套件，以便後續的需求更改。團隊負責人應該多和大家溝通專案的長遠目標和短期目標，消除歧義，只有當大家達成共識，才能勁往一處使，才會追求共贏。
平等、相互尊重
產品經理帶有“經理”二字，似乎有管理的問道，但其實和“程式猿”、“運維狗”一樣，都是來幹活的，只是分工不同而已。我是程式猿，並不十分了解有沒有PM自認為高人一等，但我確實知道一些老程式設計師會鄙視新人PM。PM和程式，任意一方太多強勢，都不一定是好事。
認可其專業性
團隊中，最忌諱的就是質疑他人的專業性。比如PM說：“這都做不了”，程式設計師說：“你啥都不懂，瞎逼逼”。如果出現了類似的話語，都會火大，誰還來解決問題。
如果你不是對方領域的資深人士，那麼最好是承認其他角色的專業性，常懷敬畏之心。相信你當前擁有的，都是最好的。當然，也會有真的很不專業的人存在，那麼找你的leader或者他的leader去反饋，不要直接人身攻擊。
有效溝通
溝通的重要性無需贅言，很多時候矛盾不是因為事件本身，而是溝通的方式不對。冷靜、友善；對事不對人；以解決問題為目標，應該是一些最基本的原則。
換位思考、同理心
換位思考，即主動站在對方的角度，用對方的思維方式去思考同樣的問題，這樣才能相互理解，相互寬容。
有了換位思考，就不難想到下面的每一點。
我所期待的PM
除了上面提到的通用準則，那麼從一個程式設計師的角度出發，我想與之合作的PM還應該有什麼特質呢
提需求表達問題而不是解決方案
有的PM會直接過來跟程式說要做什麼，但是不耐煩、或者不願意、或者根本沒有意識到要跟程式說說為什麼要這樣做。也就是說，PM表達的，經常是某種解決方案，而不是需要解決的問題。
誠然，PM在需求方面可能更專業，但開發也許會有更好、更便捷的方案來滿足需求。而且抱著一起解決問題的態度，而不是PM命令開發，也能激發開發人員的自主性，更愉快的去完成任務
改需求要有理有據，最好有資料
程式設計師最煩的就是改需求、反覆地改需求、上線之前改需求。改需求不可怕，關鍵是這些需求是否經過深思熟慮，最起碼，PM得先說服自己，而不是拍腦袋。
如果可以，最好用資料，用事實說話，程式設計師喜歡說“talk is cheap， show me the code”，那麼PM應該用資料說話。如果一個程式設計師知道這個修改可能增加多少點選率、轉化率的時候，我相信他是願意去修改的。
以最小的代價試錯
PM的需求來自市場或者說使用者，而開發的需求來自PM。相對來說，對PM的需求更模糊，對開發的需求更具體。這就導致，PM更難一次性把事情做對，PM很多時候沒法自己驗證自己的想法，需要藉助開發的力量。但是，一個合格的PM應該認識到，如果自己做錯了，那麼浪費的不僅是自己的時間，還有別人的時間。因此應該盡最大努力減少試錯的次數，保證交給開發的需求已經是經過足夠的市場、競品調研，有了充足的思考與討論。
跟進需求的進度
PM是專案或者某個功能的第一負責人，那麼應該實時瞭解進度。資訊在傳遞的過程中會失真，大家對同一句描述的理解也會有歧義。那麼程式設計師所理解的、所開發的內容是否符合PM最初的想法呢，這個就需要PM主動去了解、跟進了。最怕的就是，程式設計師辛辛苦苦幹了一個月，結果PM說做出來的東西不是自己想要的。
而且，在沒有實物參考之前，PM可能也沒徹底想清楚自己想要什麼，因此要儘早驗證自己的想法。
及時向上彙報
這一點跟上一點有相似之處。
有的時候，一個大專案會有多個產品經理，每人負責一部分功能，比如遊戲開發一般都會多個策劃。如果一個PM自知專業水平不是足夠高，或者說自己也想不清楚，那麼最好及早向直系老大負責彙報，在有完善的互動、或者一個可展示的demo時就像老大彙報。避免等程式做完之後，老大不滿意，導致推翻重來。
加分項：懂技術的PM
懂點技術的PM，首先不會提出變態的需求，如“APP的主題顏色能根據手機殼自動調整”，或者“五彩斑斕的黑”。另外，程式和你溝通起來也會暢快很多，自然也會對你刮目相看。
做一個合格的程式
之前寫過一個篇文章，怎樣才算得上合格的程式設計師。在這裡，簡單補充一下我覺得怎麼樣才能與PM和諧相處。
意識到技術服務於業務
對於開發者個人而言，也許專業技術是自己最重要的技能。但對於團隊或者給程式設計師開工資的公司來說，業務才是最重要的，再牛逼的技術如果不能支撐業務那都沒有什麼鳥用。
業務的發展會倒逼技術、架構的成長，反之則不能。
好的程式設計師，努力讓程式碼去適應業務，同時讓程式碼更具可讀性、更具擴充套件性、更加優美。但是萬一與業務需求衝突，那還是應該先滿足需求吧。
建議讀讀這篇很有意思的文章，PM 叫你去改一個 Bug，後來……
意識到需求迭代是無法避免的
程式設計師都知道，程式碼是不大可能一遍就寫好的，尤其是敏捷開發、快速迭代的模式，所以才會有程式碼的重構。我們也常聽大牛說，好的架構不是設計出來的，而是演化而來的。
要想一次性把事情做到完美，就是 one take,但可望不可即
度己及人，PM也很難一次就將需求提對，也需要實踐、驗證、改善，反覆迴圈。而程式應該做的是，參與到需求迭代中，用自己的專業知識縮短迭代的週期以及次數。
儘早交付，及時發現問題
上面提到，需求的迭代無可避免，為了減少浪費的時間，那麼程式設計師應該儘早互動，只要有可體驗的版本、甚至只是可見的介面，都應該讓PM來看看。雖然前面提到，PM應該主動及時跟進進度，但是程式設計師也應該主動參與，這也能為自己節省時間。
不要總是拒絕，也不要太快承諾
有的程式設計師總是習慣生硬地丟擲“做不了”這幾個字來拒絕PM，也許是真做不了，也許是自己不想做。首先，這樣說直接給PM當頭一棒，極不禮貌，至少應該先詳細解釋原因。其次，這樣的話說多了，在別人看來就是不負責、能力也不行。
當然，如果沒認真思考與評估，急於答應也不行，承諾了就要辦到，不要把事情搞砸，才能建立自己的信譽。
總結
說了這麼多，其實有些凌亂。
個人覺得，最重要的其實就是換位思考，換個立場，事情也許就會完全不一樣。我們常說，旁觀者清，當局者迷，但最重要的是我們要有意識從“當局者”切換到“旁觀者”視角。
另外，也許你很牛逼，但請用一個普通人的標準要求對方，嚴於律己，寬以待人。