做爲程序員，不再想和PM幹架了

上週，又看見有程序和PM（產品經理）吵了起來，大體是由於晚上就要上線了，下午的時候PM來講要改點需求，但程序不肯意。興許是天氣熱了，你們都很煩躁，因而一言不合就發飆了，最終仍是程序老大介入才解決了問題。

程序和PM的最大矛盾應該就是需求：提需求、改需求。

但程序和PM必定是對立的雙方嗎？顯然不是，你們應該是同一個戰壕的戰友纔對。回想起來，我也曾經和PM由於各類或大或小的緣由有過爭執（還好，沒有打起來過 ）。過後想來，其實很蠢，由於爭吵根本不解決問題，反而引出新的問題。

那麼，程序和PM怎麼和諧相處呢，這其實須要你們刻意的去努力。本文記錄一下本身在這方便的感想。

本文地址：http://www.javashuo.com/article/p-xfoaeata-bb.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當頭一棒，極不禮貌，至少應該先詳細解釋緣由。其次，這樣的話說多了，在別人看來就是不負責、能力也不行。

固然，若是沒認真思考與評估，急於答應也不行，承諾了就要辦到，不要把事情搞砸，才能創建本身的信譽。

總結

說了這麼多，其實有些凌亂。

我的以爲，最重要的其實就是換位思考，換個立場，事情也許就會徹底不同。咱們常說，旁觀者清，當局者迷，但最重要的是咱們要有意識從「當局者」切換到「旁觀者」視角。

另外，也許你很牛逼，但請用一個普通人的標準要求對方，嚴於律己，寬以待人。