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

一些背景故事

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

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

我記得在剛加入ThoughtWorks的時候，私底下經(jīng)常聽到這種論調(diào)：PM基本就是項目上被人鄙視的角色，基本上負責(zé)團隊建設(shè)去哪兒這種雜事兒就行了，團隊的其他人員可以高度自治，并不需要被管理，項目就會如預(yù)期般按時交付。

這些論調(diào)在某些情況下可能是對的。但是如果放在國內(nèi)項目的這個上下文里，倘若沒有一個專業(yè)的PM來協(xié)助項目、控制需求、劃定項目范圍、與客戶談判等等，沒有任何一個項目是可以真正成功交付的，指望高度自治的開發(fā)們來完成項目？咱們還是現(xiàn)實一些吧。

一個悲劇的事實是，開發(fā)人員往往都恃才傲物，有時還會帶著一幅要拯救世界的心態(tài)做項目，這事實上和客戶以及PM的期望是有很大出入的。在項目啟動之初，PM會面臨重重困難：首先，團隊里的每個人都不好管，而且每個人都認為自己不需要被管理（當(dāng)然這種想法在大多都是錯誤的）；其次，PM需要和客戶快速建立信任，并推動項目進入正軌；最后，他們也需要了解大量與項目相關(guān)的上下文（業(yè)務(wù)上下文，人員關(guān)系，資源協(xié)調(diào)等），最后留給自己的時間也非常有限。

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

本質(zhì)上來說，PM其實就是一個輪詢器：識別所有的項目風(fēng)險，然后不斷跟進。項目風(fēng)險可能是技術(shù)風(fēng)險，比如某個技術(shù)上壓根搞不定的問題。也可能資源風(fēng)險，比如人手不夠，或者開發(fā)者很多，但是沒有足夠的設(shè)計師協(xié)助，這些風(fēng)險都會導(dǎo)致項目無法按時交付。一個客觀事實是，所有項目都會變化，從售前到需求分析結(jié)束，項目的需求都在持續(xù)變化，如果不對報價做相應(yīng)的調(diào)整，極有可能會虧本。

PM的一個重要職責(zé)就是在項目之初將項目范圍定下來，這個范圍的劃分非常依賴經(jīng)驗：劃得少了團隊得天天加班，累得跟狗一樣才能保證交付（據(jù)我的經(jīng)驗，雖然項目一般不會天天加班，但是總會有一些攻關(guān)、打補丁的事兒，最后還是會累成狗），劃得多了客戶不買單，意思是就這個小功能你要做兩個月，絕對不行。PM需要協(xié)調(diào)這些不一致，還需要和銷售、客戶等方面不斷談判、寫方案、排計劃，簡而言之，也是累的跟狗一樣。在此過程中，還可能被那些天真幼稚的開發(fā)坑 — 開發(fā)經(jīng)常會高估自己的開發(fā)速度，反正我還沒遇到過低估的，你見過嗎？

我們每天看到的PM干的最多的事情就是：元芳，那個接口怎么樣了？什么時候能做完，有什么blocker？李柯，昨天說的代理的事情怎么樣了？小波，高保真什么時候出？何方，我們周三下午要showcase，麻煩你訂一下會議室吧……

除了寫代碼，Dev平時還干點啥？

如果脫離PM的角度，做為一個孤傲的開發(fā)，時常會覺得“PM為什么老是問我進度？是不是懷疑我的能力？為什么監(jiān)視我的工作？”相信我，其實他才不想監(jiān)視你。但是你設(shè)想一下：如果你不參與代碼編寫，每天只是看旁邊的哥們寫，你如何知道他實際的進度呢？而且眾所周知，開發(fā)很難準(zhǔn)確更新自己的工作進度，而且遇到問題也很少積極主動的報告，通常都會自己埋頭嘗試解決。那么，輪詢顯然是一種成本最低，反饋最快的方法。

不主動更新進度是一個大問題，這個得單獨說。關(guān)于更新進度，典型的場景是：早上站會的時候，開發(fā)目光呆滯的盯著某個卡片，努力回憶其中的驗收條件以及自己當(dāng)前的進度，如果恰好腦海中的技術(shù)細節(jié)和卡片描述在某個點上匹配了，他會迅速的告訴你，目前進展良好，今天上午應(yīng)該就可以做完。開發(fā)在更新進度時，要么盲目樂觀，要么就跳進太細節(jié)的地方進行討論，最后的結(jié)果就是：跟沒更新一樣，白白浪費了10分鐘。但是別忘了，PM會在15分鐘之后再來輪詢一次。

PM每周都需要匯總很多數(shù)字，比如本迭代完成的點數(shù)、剩余的點數(shù)、總體進度如何、有沒有人準(zhǔn)備請假、遇到什么blocker、每個blocker的具體原因、每個風(fēng)險點的最終日期是何時等等等等。他肯定不能記住這些數(shù)字，所以可能一天之內(nèi)向你詢問數(shù)次。

PM的其他職責(zé)/技能

上邊說到的其實只是描述PM的辛苦，而最微妙，最考驗PM的是其“察言觀色”的技能。這絕對是一個工作經(jīng)驗在10年之內(nèi)完全無法獲得的技能（而且是在國內(nèi)項目上工作10年）。比如，在showcase的時候，有個客戶說，“嗯，挺好，整個流程就是這樣的，后續(xù)你們的UI是不是還會美化？”如果你遇到這個情況，請問，這個客戶是什么意思？

如果你能回答上這個問題（而不是提出問題），那說明你還離PM差十萬八千里。成熟的PM會先判斷，提出這個問題的人是什么角色，以及他在系統(tǒng)中的話語權(quán)如何，還有其他人就此問題的反應(yīng)如何等，然后找到一個合適的答案。

PM另一個絕技是扯皮（不是貶義），開發(fā)會花一個下午（我是說10分鐘）去跟客戶討論需求的范圍嗎？或者會為5個人天來討價還價嗎？我想開發(fā)大概會說，“尼瑪，找其他供應(yīng)商吧，老子不伺候了。”

一個項目的成功，需要多方合作，這里說的合作并不局限在甲方和乙方之間，即使在乙方的團隊之中，也需要很緊密的合作。比如項目經(jīng)理和開發(fā)、設(shè)計師之間的合作。如果僅僅從開發(fā)的角度來看，PM有時候看起來就像和客戶站在一起來整開發(fā)的一樣，比如催進度，過分保守的估算人天（導(dǎo)致團隊加班趕工）。PM需要釋放團隊中的負面情緒，保證團隊士氣，還需要做一些開發(fā)不屑于做的瑣碎事情。

設(shè)身處地，替他人著想

從本質(zhì)來說，每個項目都是一次生意。在去掉那些繁雜的流程和形式之后，做一個項目和你去菜市場買菜其實并無二致。根據(jù)傳統(tǒng)，軟件開發(fā)界特別喜歡找建筑行業(yè)做類比，我也找個建筑方面例子。裝修房子的時候，我們會要求施工方提供圖紙（水電改造，基本設(shè)計等），按期交付（確定工期），同時會界定項目范圍（比如刷墻，貼地磚，吊頂，封陽臺等等），會要求工人按時來上班，正常出勤，認真工作，直到項目結(jié)束。過程中我們還會討價還價，比如捎帶著把欄桿拆除，捎帶著敲掉一面隔離墻等等。在過程中，我們還會敲敲地磚，檢查過門石，檢查吊頂，測試水電等等。作為甲方，這些活動相信沒有人會覺得過分。

但是一旦我們做乙方，也就是施工方的時候，情況就全變了。比如客戶要求打卡，有人會覺得不爽，客戶要求代碼review，有人會覺得不爽，要求代碼有設(shè)計文檔，有人會覺得不爽，要求設(shè)計有多個備選方案，有人會覺得不爽。大多數(shù)情況下，這都是虛無縹緲的虛榮在作祟，這種情況在所難免，不過還不致命。一旦涉及到討價還價（不是商務(wù)上的討價還價，而是和客戶就工作量達不成一致，或者就某個技術(shù)方案達不成一致之后），開發(fā)全部歇菜，一言不合，轉(zhuǎn)身就走，壓根不具備討價換件的能力，這樣還怎么做生意??？設(shè)身處地想一下，如果你是甲方，當(dāng)提出了一些合理的要求（比如需要一方提供驗收標(biāo)準(zhǔn)，通過驗收測試等），結(jié)果施工方還一臉的“我不跟你說了，你就是以大傻B”，你能樂意嗎？

如何合作？

說了這么多，這兩種角色在同一個項目上要如何合作呢？我想，作為開發(fā)來說，有這樣幾點可能：

首先，理解PM的工作。在很多時候，開發(fā)會有莫名其妙的優(yōu)越感（其實每個角色都會有，比如銷售看不上技術(shù)人員，技術(shù)Lead看不上PM等等），主要原因是坐井觀天，對其他角色的辛苦和工作內(nèi)容不清楚，錯誤的認為別人的工作都很low。

之前聽一個同事講過一個小session，里面有一點我印象非常深刻：不要因為一個人不會某個技術(shù)而鄙視他。就好比你不應(yīng)該因為不會彈鋼琴，而被一個會彈鋼琴的人鄙視一樣。道理很簡單，但是開發(fā)在長期的“宅”生涯或者坐井觀天中，進化出了這種非理性的觀點：如果一個人連vim（此處的vim可以換成任何其他技術(shù)）都不會，就壓根不足以談人生。

其次，學(xué)習(xí)如何報告進度。PM催你的根本原因是進度不明確，如果每一個潛在的風(fēng)險都清楚的顯示著進度，而且有明確的負責(zé)人，PM就會降低輪詢的頻率。這需要開發(fā)經(jīng)過刻苦的練習(xí)才能達到：

• 站會前自己花3分鐘整理一下昨天做的工作

• 根據(jù)story的驗收條件（最好有和BA/QA一起的討論需求），進行合理的任務(wù)劃分（tasking技能）

• 可以借助便簽紙等工具，幫助自己明確進度（劃分了5個子任務(wù)，昨天完成了3個，那么可以粗略的估計為60%）

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

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

• 明確告訴PM一些可能的風(fēng)險，團隊整體對交付負責(zé)，而不是PM，或者開發(fā)

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

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