除了催進度，PM平時還干點啥？

一些背景故事

坊間流傳著很多關于PM（Project Manager，項目經理）的笑話，在這些不無刻薄的笑話中，PM往往被描述成一個盲目應承客戶，不了解實際情況而又喜歡指手畫腳、專門坑開發的家伙。毋庸置疑，這些笑話當然出自那些“聰明的”開發（不過你得承認，這些笑話并非空穴來風）。

在智力工作中，對于開發的實際進度、開發速率等問題，具體著手做的人永遠比在背后指手畫腳的人更有發言權。軟件開發正是一項智力活動，優秀的軟件無法通過人力的堆積而產生。一個關于PM的經典的諷刺是：PM就是那些指望著9個女人在1個月內生出1個小孩的二貨。乍看上去，這個笑話還真是一針見血。

我記得在剛加入ThoughtWorks的時候，私底下經常聽到這種論調：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%）

再次，合理估算。有些時候，新人（來自于傳統管理環境的新人）可能會誤以為PM是一個管理的角色，或者處于某些考慮會在PM詢問進度時做出一些錯誤的回答。比如PM在迭代啟動會議上是問“這個迭代我們有沒有可能做完所有計劃內的任務？”作為一個負責任的開發，你需要在第一時間指出那些“非理性”的期望，以便PM進行更加準確的計劃。

• 明確告訴PM，有哪些需求是不可能按時交付的，PM會根據實際情況來重新定計劃，并和客戶確認

• 明確告訴PM一些可能的風險，團隊整體對交付負責，而不是PM，或者開發

按照經驗，項目從來就不會按照計劃進行，在做好一個粗略的計劃之后，PM的職責更多的是進行動態調整。所以團隊內部至少需要保持信息的流通，雖然可能短期來看可能會影響開發速度，但是從整體上來看，可以減少很多不必要的浪費。

簡而言之，要站在別人的角度考慮問題：如果換做是你，你會怎么做？