項目經理是大傻B嗎？
一些背景故事
坊間流傳著很多關于PM（Project Manager，項目經理）的笑話，在這些不無刻薄的笑話中，PM往往被描述成一個盲目的承諾客戶需求變更，不了解實際情況而又喜歡指手畫腳的專門坑開發的家伙。毋庸置疑，這些笑話當然是那些聰明的開發發明的（不過你得承認，在很多團隊，這些笑話其實是實實在在每天都在發生著的）。
在智力工作中，對于開發的實際進度，開發速率等問題，具體著手做的人永遠比在背后指手畫腳的人更有發言權。軟件開發正是一項智力活動，優秀的軟件無 法通過人力的堆積而產生。一個關于PM的經典的諷刺是：PM就是那些指望著9個女人在1個月內生出1個小孩的二貨。從傳統的意義上來說，這個笑話還真是一 針見血。
我記得在加入ThoughtWorks不久的時候，私底下經常聽到這種論調：PM基本就是項目上被人鄙視（當然大家不會表現的那么明顯就是了）的角色，基本上負責團隊建設去哪兒這種雜事兒就行了，團隊的其他人員可以高度自治，并不需要被管理，項目就會如預期般按時交付。
這些論調在某些情況下可能是對的。但是如果在國內項目的這個上下文里，沒有一個專業的PM來協助項目，控制需求，劃定項目范圍，與客戶談判等等，沒有任何一個項目是可以真正成功交付的，指望高度自治的開發們來完成項目？咱們還是現實一些吧。
一個悲劇的事實是，開發人員往往都恃才傲物，有時還會帶著一幅要來拯救世界的心態來做項目，這事實上和客戶的期望，以及PM的期望是有很大出入的。 在項目啟動之初，PM會面臨重重困難：首先，團隊里的每個人都不好管，而且每個人都認為自己不需要被管理（當然這種想法在大部分時候都是錯誤的）；其 次，PM需要和客戶快速建立信任，并推動項目進入正軌；最后，往往留給PM自己的時間也非常有限，他們也需要學習大量的項目相關的上下文（業務上下文，人 員關系，資源協調等）。
除了催進度，PM平時還干點啥？
本質上開說，PM其實就是一個輪詢器：識別所有的項目風險，然后不斷跟進。項目風險可能是技術風險，比如某個技術上壓根搞不定的問題。也可能資源風 險，比如人手不夠，或者開發者很多，但是沒有足夠的設計師協助，這些風險都會導致項目無法按照時間交付。一個客觀事實是，所有項目都會變化，做完售前到需 求分析結束之后，需求可能會發生巨大變化，如果還按照報價來做項目很可能會虧本。
PM的一個重要職責就是在項目之初將項目范圍定下來，這個范圍的劃分非常依賴經驗：劃得少了團隊得天天加班，累得跟狗一樣，然后才能保證交付（據我 的經驗，雖然項目一般不會天天加班，但是總會有一些攻關，打補丁的事兒，最后還是會累成狗），劃得多了客戶不買單，意思是就這個小功能你要做兩個月，絕對 不行。PM需要協調這些不一致，還需要和銷售，客戶等方面不斷談判，寫方案，排計劃，簡而言之，也是累跟狗一樣（而且潛在的，還可能被那些天真幼稚的開發 坑 — 開發經常會高估自己的開發速度，反正我還沒遇到過低估的，你見過嗎？）。
我們每天看到的PM干的最多的事情就是：元芳，那個接口怎么樣了？什么時候能做完，有什么blocker？李柯，昨天說的代理的事情怎么樣了？小波，高保真什么時候出？何方，我們周三下午要showcase，麻煩你訂一下會議室吧……
除了寫代碼，Dev平時還干點啥？
如果脫離開PM的角度，做為一個孤傲的開發，時常會覺得PM為什么老是問我進度，是不是懷疑我的能力？為什么監視我的工作？相信我，其實他才不想監 視你。但是你設想一下：如果你不參與代碼編寫，每天只是看旁邊的哥們寫，你如何知道他實際的進度呢？而且眾所周知，開發很難準確的更新自己的工作進度，而 且遇到問題也很少積極主動的報告，通常都會自己埋頭嘗試解決。那么，輪詢顯然是一種成本最低，反饋最快的方法。
不主動更新進度是另外一個大問題，不過這個得單獨說。關于更新進度，典型的的場景是：早上站會的時候，開發目光呆滯的盯著某個卡片，努力回憶其中的 驗收條件以及自己的當前進度，如果恰好腦海中的技術細節和卡片的描述在某個點上匹配了，他會迅速的告訴你，目前進展良好，今天上午應該就可以做完。開發在 更新進度時，不是盲目樂觀，就是跳進太細節的地方進行討論，最后討論的結果就是：跟沒更新一樣，除了浪費了10分鐘時間。但是別忘了，PM會在15分鐘之 后再來輪詢一次。
PM每周都需要匯總很多數字，比如本迭代完成的點數，剩余的點數，總體進度如何，有沒有人有請假計劃，遇到什么blocker，每個blocker的具體原因，每個風險點的最終日期是何時，等等等等。他肯定不能記住這些數字，所以可能一天之內向你詢問數次。
PM的其他職責/技能
上邊說到的其實只是描述PM的辛苦，而最微妙，最考驗PM的是其“察言觀色”的技能。這絕對是一個工作經驗在10年之內完全無法獲得的技能（而且是 在中國的項目上工作10年）。比如，在showcase的時候，有個客戶說，嗯，挺好，整個流程就是這樣的，后續你們的UI是不是還會美化？如果你遇到這 個情況，請問，這個客戶是什么意思？
如果你能回答上這個問題（而不是提出問題），那說明你還離PM差十萬八千里。成熟的PM會先判斷，問這個問題的人是什么角色，以及他在系統中的話語權如何，還有其他人就此問題的反應如何等等因素，然后找到一個合適的答案。
PM另一個絕技是扯皮（不是貶義），開發會花一個下午（我是說10分鐘）去跟客戶討論需求的范圍嗎？或者會為5個人天來討價還價嗎？我想開發大概會說，尼瑪，找其他供應商吧，老子不伺候了。
一個項目的成功，需要多方合作，這里說的合作并不局限在甲方和乙方之間，即使乙方的團隊之中，也需要很緊密的合作。比如項目經理和開發，設計師之間 的合作。如果僅僅從開發的角度來看，PM有時候看起來就是和客戶站在一起來整開發的一樣，比如催進度，過分保守的估算人天（導致團隊加班趕工）。PM需要 釋放團隊中的負面情緒，保證團隊士氣，還需要他做一些開發不屑于做的瑣碎的事情。
設身處地，提他人著想
本質來來說，每個項目都是一次生意。在去掉那些繁雜的流程和形式之后，做一個項目和你去菜市場買菜其實并無二致。舉個例子，根據傳統，軟件開發界特 別喜歡找建筑行業做類比，我也找個建筑方面例子。裝修房子的時候，我們會要求施工方提供圖紙（水電改造，基本設計等），按期交付（確定工期），同時會界定 項目范圍（比如刷墻，貼地磚，吊頂，封陽臺等等），會要求工人按時來上班，正常出勤，認真工作，直到項目結束。過程中我們還會討價還價，比如捎帶著把欄桿 拆除，捎帶著敲掉一面隔離墻等等。在過程中，我們還會敲敲地磚，檢查過門石，檢查吊頂，測試水電等等。作為甲方，這些活動相信沒有人會覺得過分。
但是一旦我們做乙方，也就是施工方的時候，情況就全變了。比如客戶要求打卡，有人會覺得不爽，客戶要求代碼review，有人會覺得不爽，要求代碼 有設計文檔，有人會覺得不爽，要求設計有多個備選方案，有人會覺得不爽。大多數情況下，這都是虛無縹緲的虛榮在作祟，這種情況所在多有，不過還不致命。一 旦涉及到討價還價（不是商務上的討價還價，而是和客戶就工作量達不成一致，或者就某個技術方案達不成一致之后），開發全部歇菜，一言不合，轉身就走，壓根 不具備討價換件的能力，這樣還怎么做生意啊？設身處地想一下，如果你是甲方，當提出了一些合理的要求（比如需要一方提供驗收標準，通過驗收測試等），結果 施工方還一臉的“我不跟你說了，你就是以大傻B”，你能樂意嗎？
如何合作？
說了這么多，這兩種角色在同一個項目上要如何合作呢？我想，作為開發來說，有這樣幾點可能：
首先，理解PM的工作。在很多時候，開發會有莫名其妙的優越感（其實每個角色都會有了，比如銷售看不上技術人員，技術Lead看不上PM等等），主要原因其實是坐井觀天，對其他角色的辛苦和工作不清楚。然后錯誤的認為別人的工作都很low。
之前聽一個同事講過一個小session，里面有一點我印象非常深刻：不要因為一個人不會某個技術而鄙視他。就好比你不應該因為不會彈鋼琴，而被一個會彈鋼琴的人鄙視一樣。道理很簡單，但是開發在長期的“宅”生涯或者坐井觀天中，進化出了這種非理性的觀點：如果一個人連vim（此處的vim可以換成任何其他技術）都不會，就壓根不足以談人生。
其次，學習如何報告進度。PM催你的根本原因是進度不明確，如果每一個潛在的風險都清楚的顯示著進度，而且有明確的負責人，PM就會降低輪詢的頻率。這需要開發經過刻苦的練習才能達到：
- 站會前自己花3分鐘整理一下昨天做的工作
- 根據story的驗收條件（最好有和BA/QA一起的討論需求），進行合理的任務劃分（tasking技能）
- 可以借助便簽紙等工具，幫助自己明確進度（劃分了5個子任務，昨天完成了3個，那么可以粗略的估計為60%） </ul>
- 明確告訴PM，有哪些需求是不可能按時交付的，PM會根據實際情況來重新定計劃，并和客戶確認
- 明確告訴PM一些可能的風險，團隊整體對交付負責，而不是PM，或者開發 </ul>
再次，合理估算。有些時候，新人（來自于傳統管理環境的新人）可能會誤以為PM是一個管理的角色，或者處于某些考慮會在PM詢問進度時做出一些錯誤 的回答。比如PM在迭代啟動會議上是問這個迭代我們有沒有可能做完所有計劃內的任務，作為一個負責任的開發，你需要在第一時間指出那些“非理性”的期望， 以便PM進行更加準確的計劃。
按照經驗，項目從來就不會按照計劃進行，在做好一個粗略的計劃之后，PM的職責更多的是進行動態調整。所以團隊內部至少需要保持信息的流通，雖然可能短期來看可能會影響開發速度，但是從整體上來看，可以減少很多不必要的浪費。
簡而言之，要站在別人的角度考慮問題：如果換做是你，你會怎么做？
</div> 來自： http://icodeit.org/2015/07/is-project-manager-a-fool/