上週，又看見有程式和pm（產品經理）吵了起來，大致是因為晚上就要上線了，下午的時候pm來說要改點需求，但程式不願意。興許是天氣熱了，大家都很煩躁，於是一言不合就發飆了，最終還是程式老大介入才解決了問題。
程式和pm的最大矛盾應該就是需求：提需求、改需求。
但程式和pm一定是對立的雙方嗎？顯然不是，大家應該是同乙個戰壕的戰友才對。回想起來，我也曾經和pm因為各種或大或小的原因有過爭執（還好，沒有打起來過 ）。事後想來，其實很蠢，因為爭吵根本不解決問題，反而引出新的問題。
團隊不是個人的簡單疊加，團隊的良好協作需要團隊中的所有角色（pm、程式、互動、測試）的共同努力。
一致的目標
大了說，是公司的願景、使命；小了說，是團隊的近期目標。只有大家向著同乙個方向努力，才能盡量避免1+1 < 2。作為乙個職場人，乙個很直觀的目標就是盡職盡責把產品（業務）做好。但這個看似很明確的目標，也是有歧義的，也許pm是想盡快上線，搶占先機；而程式是想，把**架構做得通用、可擴充套件，以便後續的需求更改。團隊負責人應該多和大家溝通專案的長遠目標和短期目標，消除歧義，只有當大家達成共識，才能勁往一處使，才會追求共贏。
平等、相互尊重
產品經理帶有「經理」二字，似乎有管理的問道，但其實和「程式猿」、「運維狗」一樣，都是來幹活的，只是分工不同而已。我是程式猿，並不十分了解有沒有pm自認為高人一等，但我確實知道一些老程式設計師會鄙視新人pm。pm和程式，任意一方太多強勢，都不一定是好事。
認可其專業性
團隊中，最忌諱的就是質疑他人的專業性。比如pm說：「這都做不了」，程式設計師說：「你啥都不懂，瞎逼逼」。如果出現了類似的話語，都會火大，誰還來解決問題。
如果你不是對方領域的資深人士，那麼最好是承認其他角色的專業性，常懷敬畏之心。相信你當前擁有的，都是最好的。當然，也會有真的很不專業的人存在，那麼找你的leader或者他的leader去反饋，不要直接人身攻擊。
有效溝通
溝通的重要性無需贅言，很多時候矛盾不是因為事件本身，而是溝通的方式不對。冷靜、友善；對事不對人；以解決問題為目標，應該是一些最基本的原則。
換位思考、同理心
換位思考，即主動站在對方的角度，用對方的思維方式去思考同樣的問題，這樣才能相互理解，相互寬容。
有了換位思考，就不難想到下面的每一點。
除了上面提到的通用準則，那麼從乙個程式設計師的角度出發，我想與之合作的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和諧相處。
意識到技術服務於業務
對於開發者個人而言，也許專業技術是自己最重要的技能。但對於團隊或者給程式設計師開工資的公司來說，業務才是最重要的，再牛逼的技術如果不能支撐業務那都沒有什麼鳥用。
業務的發展會倒逼技術、架構的成長，反之則不能。
好的程式設計師，努力讓**去適應業務，同時讓**更具可讀性、更具擴充套件性、更加優美。但是萬一與業務需求衝突，那還是應該先滿足需求吧。
建議讀讀這篇很有意思的文章，pm 叫你去改乙個 bug，後來……
意識到需求迭代是無法避免的
程式設計師都知道，**是不大可能一遍就寫好的，尤其是敏捷開發、快速迭代的模式，所以才會有**的重構。我們也常聽大牛說，好的架構不是設計出來的，而是演化而來的。
要想一次性把事情做到完美，就是 one take,但可望不可即
度己及人，pm也很難一次就將需求提對，也需要實踐、驗證、改善，反覆迴圈。而程式應該做的是，參與到需求迭代中，用自己的專業知識縮短迭代的週期以及次數。
盡早交付，及時發現問題
上面提到，需求的迭代無可避免，為了減少浪費的時間，那麼程式設計師應該盡早互動，只要有可體驗的版本、甚至只是可見的介面，都應該讓pm來看看。雖然前面提到，pm應該主動及時跟進進度，但是程式設計師也應該主動參與，這也能為自己節省時間。
不要總是拒絕，也不要太快承諾
有的程式設計師總是習慣生硬地丟擲「做不了」這幾個字來拒絕pm，也許是真做不了，也許是自己不想做。首先，這樣說直接給pm當頭一棒，極不禮貌，至少應該先詳細解釋原因。其次，這樣的話說多了，在別人看來就是不負責、能力也不行。
當然，如果沒認真思考與評估，急於答應也不行，承諾了就要辦到，不要把事情搞砸，才能建立自己的信譽。
說了這麼多，其實有些凌亂。
個人覺得，最重要的其實就是換位思考，換個立場，事情也許就會完全不一樣。我們常說，旁觀者清，當局者迷，但最重要的是我們要有意識從「當局者」切換到「旁觀者」視角。
另外，也許你很牛逼，但請用乙個普通人的標準要求對方，嚴於律己，寬以待人。
我不想當程式設計師
我是一名美麗可愛大方迷人的女程式設計師！不接受任何反駁 emmm 現在嘛，暫時也是一名在校大學生，不過很快我也即將步入社會洪流，開始漫漫地找工作之旅！作為乙個陝西女子我現在不僅要面向黃土大地，還要物件導向開發程式！先定乙個小目標吧，打好基礎是關鍵，我前期當然是要先學好語言，然後才能拓展，找個好工作，...
作為程式設計師的苦惱
我是乙個工作三年多的程式設計師，做了三年多的開發工作，也有很多感悟。因為本人喜歡網際網路，也喜歡站在 產品 的角度思考問題，考慮行業狀態，產品的盈利模式，產品的ui設計，產品的功能規劃等等。但是我發現我的想法越多，在工作中，我反而越痛苦。當我對產品的想法與 客戶 的想法衝突時，往往是以我的妥協結束，...
作為程式設計師，我們理應自豪
我們每個人都對自己的未來有所思量，因為我們每個人都懷揣著高遠的夢想，我們每天都在打理著我們的生活，日復一日，年復一年。有人說，人生最重要的不是努力，不是奮鬥，而是抉擇。那麼我想說，我們選擇程式設計師無悔這一生。對待工作 認真負責 試問哪個程式設計師不把自己變得非常有思想，非常有深度，讓自己的大腦始終...