《專案管理之美》第1章

Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE1章 專案管理簡史（以及您應該關注於此的原因）

在很多組織中，帶領專案的人員並沒有“專案經理”（project manager）這一職位。但這沒什麼影響。實際上，無論是獨自工作，還是帶領一個團隊，每個人在日常工作中都在管理專案。這裡，我們暫不關心這些差別。我的目的是獲取如下資訊：是什麼使專案成功？成功帶領專案的人員是怎樣做的？實際上，這些原則並不限於特殊的階層、工作職位或方法。因此，如果你正在參與一個專案，並且對專案結果承擔一定的責任，那麼下面的內容將適用於您。如果您的名片上恰好印著“專案經理”，那麼您將受益更多。

本書的作用透過如下三種方式體現：作為主題明確的短文合集，作為長篇連續故事，作為常見問題的參考手冊。每一章將關注一個高層任務，提供一個基本的框架，並提供成功完成該任務的方法。但是，對於本章有些不同：為了便於講述本書後面的內容，我們下面提出三個更廣泛的主題。

第一個主題是專案簡史以及為什麼我們應該從他人的做法中學習。第二個主題是關於各種專案管理風格的背景，包括我在微軟工作時積累的經驗。第三個主題是探索專案管理領域的挑戰，以及如何應對這些挑戰。雖然這些內容在後面將非常有用，但是對於我們理解本書後面各章，這些不是必需的。因此，如果您覺得本掌內容太寬泛了，您可以立刻翻到第2章，進入本書的核心內容。

利用歷史

專案管理作為一種思想，可以追溯到很久之前。如果考慮一下人類文明歷史上曾建立的所有事物，可以供我們學習的專案經驗已經有數千年的歷史了。對於我們現在的軟體開發人員畫出的虛線，如果向前回顧，埃及金字塔的建造者和羅馬溝渠的設計師在當時就是這樣使用的。無論是古代，還是現代，專案管理者都在扮演著類似的角色，將技術用在各自時代關心的問題上。但是，直到今天，當很多人想要改善Web開發和軟體開發的專案管理時，卻很少會去注意過去的歷史教訓。在專案管理知識發展的時間軸中，今天比古代的進步不大，這實在是不該。

工程專案的歷史說明大多數的專案都非常類似。它們都涉及需求、涉及和限制。它們都依賴於溝通、作決策、創新思維和邏輯思維的結合。專案一般都包括進度、預算和客戶。最重要的是，專案的中心任務是將不同人的工作結合起來，形成單一完整的、對人類或客戶有價值的產物。對於構建專案，無論是透過HTML、C++，還是水泥和鋼鐵，都存在一套不可否認的、大多數專案所共享的核心概念。

為了探尋帶領Web開發和軟體開發專案的更好方式，我為此花費了大量的精力。我研究了其他領域，以瞭解它們是怎樣解決專案中的關鍵問題。我想知道像哈勃太空望遠鏡和波音777這些專案是如何設計和構建的？是否可以複用這些專案中複雜的規格說明和計劃過程？或者，當在紐約建造克萊斯勒大廈，以及在雅典建造帕臺農神殿時，專案領導者計劃和評估專案的方式是否和我們軟體開發者一樣？有哪些顯著差異？透過研究這些差異，我們可以獲取什麼？

對於報紙的編輯們，在實現網路出版夢想前的很長一段時間內，都需要進行多媒體（圖片和文字）內容創作工作，他們是如何組織和計劃每天的資訊產品的？故事片電影是如何生產的？阿波羅13是如何發射的？透過研究這些問題，我瞭解了帶領專案組的新方法。

但是，這些調查並不總是能夠提供明顯的答案。我不能保證您立刻領會，或者立刻作出完美的計劃，因為本書提供的建議將受很多因素的影響。我發現，當我從其他環境回到軟體世界中，我採用的過程和工具已經完全不同了。概括來說，我發現，在我大學電腦科學研究過程中，我已經不再提及那些過去有益的方法和比喻。無論是技術會議，還是為商業雜誌編寫的材料，都不再討論它們了。

透過對過去歷史的調查，我得出如下三項關鍵的收穫：

1. 專案管理和軟體開發不是什麼神聖的藝術。對於漫長的造物史而言，任何現代的工程專案都是一種新的出現。技術和技能可能會改變，但那些造成工程難題的關鍵挑戰依然存在。無論是程式語言，還是開發方法，它們在某些方面是獨一無二的，而在其他方面則是從其他事物衍生而來的。但是，如果我們想要儘可能多地複用已有的知識，在與過去進行比較時，必須以開放的態度來考慮知識的唯一性和衍生性。

2. 對於您所做的事情瞭解的越少，您就有越多的精力去完成它。如果我們對工作有一個簡單的瞭解，我們就能夠從製造其他身邊已有事物的過程中發現有益的類比。歷史上曾有很多的例子和教訓，可以供現代工業來借鑑、比較、對照。這類似於日語單詞shosshin所表述的概念，即習武規則的最重要之處——初學者態度1或開放態度。保持求知和開放的態度才能取得進步，同時還需要實踐來維持這種心態。只要不斷學習，我們就可以避免走入歧途，安全地考慮我們所做的事情。

註釋1：初心是禪宗的基本概念。其經典的故事是以空杯作比喻：如果你執著於杯中之物，那麼你的杯子將沒有空間容納新知識。請參考鈴木俊隆禪師所著的Beginner’s Mind（Weacherhil出版，1972年）。

3 簡單並不等於容易。優秀的運動員、作家、程式設計師以及經理人都有這種認識，認為他們所做的事在本質上很簡單，但同時也非常困難。要記住，簡單與容易並不相等。例如，跑馬拉松是個簡單的事。你開始跑，跑了26.2英里後就停下來。有什麼比這更簡單的？跑完馬拉松很困難的這個事實，並無損其簡單性。領導力和管理也很困難，但其本質是很簡單的，就是以特定方式朝特定目標把事情做好。

我在很多章節中都會提到這些概念。所以，如果我的比喻超出了軟體開發的範疇，希望你能瞭解我這麼做的理由。此外，當我提到決策和進度控制是簡單的管理工作時，我會假定你知道這些事並不容易做到。

從失敗中學習

“人類是萬物之靈，有能力學習他人的經驗，卻也最容易對他人經驗視若無睹。”

——Douglas Adams

當研究專案歷史時，會引發一個簡單的問題：既然我們可以避免，為什麼還有人願意去經歷錯誤和失望？如果古代及現代工程史都是公開的，而且無論靈感來自何處，我們也因做些聰明的事而領取薪水，為什麼少有組織獎賞那些從過去獲取經驗的人？每天都有專案完成或取消（許多開發專案都以此結束2），但少有人從中吸取經驗。大多陣列織中的經理人似乎很少獎賞那些尋找這類知識的人。也許是害怕他們找出來的東西（害怕必須為此負責），或者也可能對此缺乏興趣。當我們花費時間來開展新專案時，沒有人願意回顧痛苦或令人沮喪的經驗。

註釋2：CHAOS報告（Standish Group出版）是一份經常被引用的文獻，內容關注於軟體專案的預算、進度以及常見失敗上。請參考。

Henry Petroski在其To Engineer Is Humman: The Role of Failure is Successful Design（Vintage Books出版，1992年）一書中提及：許多工程的突破都來源於失敗的結果。產生這種現象的部分原因在於，失敗會使我們集中注意力，重新檢查我們忘卻的假設（當原型燒起來時，很難假裝一切正常）。正如Karl Popper3所說的，只存在兩種理論：錯誤的理論和不完整的理論。如果沒有失敗，我們就會變得驕傲，忘記了我們對事物的瞭解實際上並不像我們所想象的那樣周全。

註釋3：Karl Popper是20世紀著名的哲學家。請參考。

因此，竅門就是儘可能從他人的失敗中學習。我們應該利用他人的經驗來應對未來的挑戰。雖然失敗的表象對於不同專案有很大的差異，但引發這些問題的根本原因或團隊行動也許可以借鑑（並且是可用避免的）。即使是我們自己的專案，也要避免逃避失敗的習慣。相反，我們應該視之為學習機會。失敗的因素是什麼？哪些因素可能很容易減少或消除？根據Petroski的說法，只要我們有勇氣仔細檢查發生過的事情，從實際失敗中學得的實踐知識，將是我們取得進步的最有力的源泉。

也許這就是為什麼波音公司——全球最大的飛機設計和製造公司之一，會留著一本黑皮書，來記載從過去的設計和製造失敗中獲取的經驗教訓。4自從波音公司成立，就一直儲存著這份檔案，用來幫助現代設計師從，從過去的經歷中吸取經驗。任何這樣做的組織，都可用增加專案成功的機率，同時也有助於建立一種可以公開討論、面對失敗的環境，而非否認和隱藏失敗。看起來，軟體開發人員也需要儲存他們自己的黑皮書。

註釋4：引自James R. Chiles所著的Inviting Disaster: Lessons from the Edge of Technology（HarperBusiness出版，2002年）。

Web開發、廚房及急診室

歷史的一個問題就是並不總是能和現實產生關聯。要把幾十年前的經驗用到如今差別似乎很大的事情上，又要維持同理性，的確很難。另一種做法是，對當代幾種有趣的專案進行比較。雖然沒有工程史的莊嚴感，不過，卻讓人可用親身體驗和觀察。通常，親眼所見是能給人充分資訊的唯一辦法，只有透過這些資訊，才能在眾多概念間建立聯絡。

例如，我知道有位Web開發人員，他認為自己的工作和宇宙史上的任何事物都不一樣。他之所以會這麼覺得，是因為Web開發需要他作複雜的工程決策，其中包括各種設計和協調工作，以及在幾個小時甚至幾分鐘內就得完成的驗證修改是否正確、然後就對世界釋出的工作。因此，他認為他的專案及任務管理不同於以前看到的事物。對那些他所精通的CSS、XHTML、Flash、Java以及其他技術朗朗上口，他覺得很自豪，認為自己強過50年前那些最聰明的人。我確信，在你的經歷中，一定遇到過這樣的人。或者，你曾經在這樣的環境下工作，好像宇宙中任何人都沒有能力來處理像你現在正在解決的、如此複雜的問題。

我建議這位開發人員朋友，在餐館忙碌的一天，去餐館的後廚去看看。走進廚房是很有趣的（請參考Anthony Bourdain所寫的好書Kitchen Confidential，Ecco出版，2001年），這有很多種原因，但是，我的焦點是生產力。任何人在第一次看到發生在忙碌的專業廚房中所採取的快速的任務管理和協調後，都可能會重新思考自己的工作到底有多難。烹飪時，通常要同時應付數個油炸中的平底鍋，它們有著各有不同的先後次序和完成狀態；同時，還得在廚房各角落的爐火間四處穿梭；此外，侍者進進出出，傳達客戶更改的選單和各類問題。

這一切都放生在窄小擁擠的廚房內，頭頂是刺眼的日光燈。儘管每隔幾秒就出一道菜，但新選單進來的速度同樣很快。有時候，出菜後會被退回，或者，像軟體專案那樣，要做點定製工作和最後一分鐘的改變（比如，一號桌不喜歡乳糖，二號桌要一些醬汁等）。大型忙碌的廚房看起來實在令人驚訝。乍看起來似乎一團混亂，但是，偉大的廚房卻以一種緊張而精確的水平運作著，大多數開發團隊都不如此。

主廚和副廚就是烹飪的專案經理，或者如Bourdain所說的，他們是空中交通管理員（另一個自省時可考慮的職業）。雖然廚房員工的工作規模比較小，也不及軟體開發團隊經理那樣受人稱讚，但是，就每日工作的緊張程度而言，二者無從比較。如果懷疑我，那麼下一次，你可以到一個忙碌的午餐地點，詢問服務員是不是可以看看廚房。他也許不會同意，但是，如果他同意，你將不會失望（某些時尚的餐館和酒吧有開放式的廚房。如果你發現這種地方，可用盡可能坐在靠廚房近一些的位置。然後，盯著某人人看幾分鐘。注意檢視怎麼下選單、怎麼跟蹤選單、怎麼烹飪菜餚以及怎麼上菜。如果你找忙碌的一天去，那麼，對於如何發現、如何跟蹤以及如何修復軟體bug這些問題，你就會有不同的想法）。

關於專案管理的另一個有趣的領域經驗來自於醫院的急診室。我看過《探索》頻道以及PBS（Public Broadcasting Service）頻道的節目，其中，由專業醫生、護士以及專家組成的專案組協同工作，來處理來到醫院的各式各樣、有時是異乎尋常的醫療病例。發明的分類處理是一種專業，這一點也不奇怪，軟體專案經常使用分類處理這一術語，來按優先順序分類問題和缺陷（第十五章會再次討論）。

對於團隊合作、高壓下的決策制定以及每天影響到許多人的專案成果，醫療環境（尤其是外傷的情況）為其提供了很好的比較（關於這種環境與其他工作環境的比較，請參見圖1-1）。這正如Atul Gawande在其著作Complications: A Surgeon’s Notes on an Imperfect Science（Picador USA出版，2003年）中所說的那樣。

我們希望醫學是關於知識和過程的有條理的專業。但實際並非如此，醫學是不完美的科學，是由不斷更新的知識、不確定的資訊以及容易犯錯的個人共同組成的，同時，又要按規則操作。是的，我們所做的事情有科學的做法，但同時也有習慣、直覺以及偶爾的單純經驗猜測。我們所知道的與我們持續追求的目標之間存在著差距，該差距把我們所做的一切都複雜化了。

電影	前期製作	拍攝	後期製作
軟體開發	需求	設計	編碼	測試
Web開發	前期工作	開發	維護	評估
急診室	診斷	治療	評估
廚房	點菜	烹調	上菜

圖1-1 從抽象層次看，許多領域都有相似的過程，都把時間用在計劃、執行以及改進（但是，你絕不會去廚房求醫或者到急診室找吃的東西。）

這一點，以及在Gawande的那本引人醒悟的書中所談到的許多其他事情，對軟體開發一樣有效。Fred Brooks在其軟體工程經典著作The Mythical Man-Month（Addison-Wesley出版，1995年）中，同樣也透過外科醫生團隊和程式設計師團隊進行類似的比較。儘管在開發網站或資料庫時，很少有生命危險的情況，但是，這些不同團隊的人遠都必須面對許多相似的挑戰。

專案管理的角色

專案管理可視為一種專業、一種工作、一種角色或一項活動。有些公司有專案經理，其職責是管理200人的整個專案。其他公司把這個職位當成高階經理，每位專案經理負責大專案中的一小部分。根據組織的結構、文化以及專案目標，專案管理可以是非正式的角色（“一有需要，就找人來做”），或者也可以是明確定義的角色（“Vincent、Claude以及Raphael都是全職專案經理”）。

本書中，我主要使用“專案經理”，或PM這個詞彙來指那些涉及到專案領導和管理活動的人員。對於“專案管理活動”，我主要是指如下活動：領導整個團隊以瞭解專案工作（計劃、進度安排以及收集需求）、帶領專案進行設計和開發工作（溝通、決策以及中期策略）、以及驅動完成整個專案（領導力、風險管理以及終局策略）。

如果這類工作在你所處的環境中沒有那麼正式，就把專案經理或PM看作是“負責專案管理任務的人，即使這不是他的主要工作”，或者將其視作“整體考慮專案的人”。我看到，不同的團隊有著不同的方式來組織專案管理活動，但是，本書的建議對他們沒有什麼大的差異。本書不關注工作職稱和形式，而是在意怎樣把事情做好，讓事情進展。不過，為了表達方便，我還是會使用專案經理或PM這個詞彙。

有時，沒有專職的的專案經理也工作得很好。程式設計師和他們的老闆會控制進度和工程計劃（如果有的話），業務分析師或市場營銷人員作專案計劃和需求工作。任何可視為專案管理的工作，都被分散在整個團隊人員身上。也許，團隊成員應聘更重要的原因是興趣，而不只是編寫程式碼。他們也許不在意早期計劃、使用者介面設計或者業務策略。以這種方式工作，也會達到很好的效果。只要每個成員都願意承擔工作職責之外的、協調整個專案的額外責任，分擔應該由專職專案經理為團隊承擔的任務，團隊就不需要增加人員。保持效率和簡單都很好。

但是，有時沒有專案經理會造成困難。如果沒有人專職控制整體專案，個人的偏見和利益考慮會影響團隊的方向。技術人員和業務人員之間會形成很大的矛盾，使得進度落後，並影響每個參與人員的心情。考慮一下醫院的急診室，醫生會負責病人的治療過程。這樣可以讓迅速開展各項工作，使外傷團隊中每個角色都能明確自己的職責。對於專案管理型別的事情，如果沒有這種清晰的授權，開發團隊將陷入麻煩。如果沒有明確的人負責專門分類bug，或者沒有專人檢查專案進度和標識的重要問題，這些任務可能會危險地被延遲，落後於以程式設計為中心的活動。

我想，很多優秀程式設計師對專案管理都非常瞭解，會自行這樣做，他們也能體會到，由優秀的專職人員來承擔專案經理角色所帶來的獨特價值。

微軟的程式和專案管理

在20世紀80年代後期，微軟遇到了問題，每個部門都不知道如何在工程方面的成果與市場、業務之間進行協調（有人可能會說，這仍然是微軟和許多其他公司面臨的問題）。有個叫Jabe Blumenthal的聰明人，意識到可以設立一個同時參與這兩種功能的特殊職位，這是個同時扮演領導和協調人的角色。他從專案開始計劃的那一天參與進來，直到測試的最後一天。這個人不但需要有一定的技術能力，使得他可用與程式設計師共事並獲得尊敬；同時，他還要具有很好的能力和興趣，來參與產品的開發過程。

為了讓這個角色有效工作，他必須樂於把時間花在各種任務上，例如編寫規格說明書、檢查市場計劃、制定專案進度表、領導團隊、作策略計劃、進行bug分類、培養團隊士氣以及做好任何需要做但沒有人正在做的事情。在微軟把這個新角色稱為程式經理（program manager）。團隊中的人員並非都直接報告給他，但程式經理被賦予很高的許可權，來領導並推動專案（在管理理論中，這類似於矩陣式組織（matrix organization），5每個人有兩條報告路線：一條以職能為基礎，另一條以專案為基礎。因此，對於一個程式設計師或測試員，可能有兩種報告關係：主要的報告關係是他的職能角色，次要但更重要的報告關係就是他所參與的專案）。

註釋5：關於矩陣和其他組織型別的總結，可參考Steven A. Silbiger’s所著的The Ten-Day MBA（William Morrow and Company出版，1993年）一書中的第139-145頁。不過，幾乎任何關於管理理論的書籍都會包含這個主題。

Jabe在一項稱為Multiplan（後來演變成Microsoft Excel）的產品中扮演這個角色，而且做得不錯。隨著技術團隊與業務團隊之間溝通質量的改善，工程和開發過程也隨之改善，在整個產品開發過程中，大家都很高興。經過多次的備忘錄和會議討論後，公司內大多數團隊開始逐漸採用該角色。說出你對最終產品的看法，無論好壞，都有其價值。透過定義一個不是小職員也不是僕人的專職通才角色來作為領導者和掌舵者，使得微軟內部開發團隊的工作情況徹底地發生了改變。這種程式經理角色，就是我在微軟職業生涯中所擔任的，我參與過的產品團隊有Internet Explorer、MSN以及Windows。最好，我甚至管理了一群擔任這個角色的團隊。

知道現在，我都沒有聽說過，有多少公司對專案管理進行大的改變，重新定義並形成專案管理的特殊方式。在我和其他Web及軟體開發公司的很多交往中，很少碰到過擔任類似的角色（通常，不是工程人員就是商務人員，有時也許會是較少見的設計人員）。許多公司使用團隊結構進行組織工作，但少有公司會專門定義橫跨工程和業務領域的角色。今天，微軟有5000名程式經理（員工總數超過80000名）。雖然專案管理這個概念的力量已經減弱，有時也會被誤用，但其核心精神在公司內的許多團隊都會看到。

但是，無論我的名片上印著什麼，或者，無論你是否相信微軟的故事，作為程式經理，我每日的職責就是專案管理。簡而言之，就是我負責使專案及參與專案的人員獲得最大限度地成功。本書各章講述的都是與達成這專案標有關的核心任務，從早期計劃（第3、4章）、規格說明書撰寫（第7章）、決策（第8章）、到實現管理及釋出（第14、15章）。

在這些技巧下，某些態度和性格特質也開始起作用。對任何領導或管理專案的人，忽視這些都極為不利。

專案管理的平衡之道

很難找到好的專案經理，因為他們需要保持態度的平衡。Tom Peters在其“Pursuing the Perfect Project Manager”一文中，6把這些互相矛盾的態度稱之為悖論或困境。這樣的說法很恰當，因為不同的環境需要不同的做法。這意味著，專案經理不但要有這些特性，還要具有在特定時期應該採取何種行動的直覺。這就是專案管理被視為藝術的原因：他需要直覺、判斷以及經驗，並有效運用這些力量。下列關於特性的列表大致上是從Peters的文章中推衍而來的：

註釋6：請參考。

自我/無我：由於責任重大，專案經理通常可從工作中獲得極大的滿足。對於專案經理為所做之事投注的極大的個人情感，很容易理解。對多數人來說，這種情感聯絡正是他們維持充沛能量的原因。但同時，專案經理必須避免把個人利益放在專案利益之前，他們必須願意把重要或有趣的任務分配出去，和整個團隊共享成功。適當的自我意識是一種激勵，但好的專案經理必須認識到，他的自我意識是否變成了一種障礙。

獨裁/委派：在某些情況下，最重要的事情就是明確的授權以及快速的反應時間。專案經理必須有自信，有足夠的魄力控制並強迫團隊執行特定行動。但是整體而言，應該避免這些極端情況出現。管理良好的專案應該建立一種環境，使得工作可被委派出去，同時又能互相有效合作。

忍受模糊/追求完美：任何專案的初期都是高度開放與變化的，未知的事物遠比已知的事物重要。正如我們在第5、6章將會討論的那樣，控制模糊是可以產生優秀想法的關鍵。專案經理如果不去管理他，就必須尊重它。但在其他時期，特別是專案後期，規範和精確是最重要的。要聰明地分辨何時值得去追求完美，何時採用普通或應急的解決方法就足夠了（請參閱第8章的“發現並權衡各種選擇”一節）。

口頭/書面：雖然多數軟體開發組織以電子郵件為中心進行溝通，口語技巧對於專案管理依然十分重要。總是要有開會、協商、閒暇討論以及頭腦風暴討論，專案經理在面對面瞭解和溝通想法方面必須有效率。組織或專案規模越大，書寫技巧就越重要。無論專案經理個人喜好如何，他都必須認識到書寫或口頭溝通在特定時刻哪個更為有效。

承認複雜/擁護簡單：許多人會成為複雜性的犧牲品。但他們面對複雜的組織或工程挑戰時，就會迷失於細節而忘了整體。其他人則由於沒有充分了解細節，只是否認複雜性，而作出不良的決策。這裡，平衡的做法是要認識到有哪個專案觀點對解決當前問題或作決策最有用，同時，還要能在兩者間自由轉換，或者同時記在心中（頭別爆了）。專案經理必須有足夠說服力，讓團隊為他們所做的工作努力的目標簡單，而不要把編寫優良可靠的程式程式碼所牽涉的複雜性最小化。

不耐煩/有耐心：大多時候，專案經理是推動他人集中工作的人員。但是在某些情況下，不耐煩會對專案不利。有些政治性、跨組織或官僚的活動，是不可避免的時間陷阱：要某人在房間裡，或者要某人參加電話會議，而且要有耐心。所以，知道何時該推動問題、何時該退讓一步讓事情發生，是專案經理必須培養的能力。

勇氣/恐懼：美國文化最大的誤區就是勇者無懼。這完全是謊言。勇者是感到害怕但依然選擇採取行動的人。專案經理必須對所有可能做錯的事情保持適度重視，把這些事視為完全可能發生。同時，專案經理也必須要有接受挑戰的勇氣來面對這些風險。

相信/懷疑。受人景仰並且相信自己的領導者，就是團隊鬥志的最大來源。專案經理對所做的事要有信心，而且看得見即將達成的目標的真正價值，這些很重要。同時，也必須對事情的進展以及事情的做法保持懷疑（而非譏笑）。必須有人去調查和提問，揭開假設，使困難問題浮現出來。平衡的做法是熱情地提問，挑戰他人的假設，但決不動搖團隊對所做事情的信念。

如同Peters在他的文章中所指出的：很難找到具備所有這些技能的人員，更別提對這些能力作適當的平衡。PM所犯的許多錯誤，都牽涉到對平衡一個或多個衝突力量的失算。然而，每個人都可以改善自己的能力，以平衡這些力量。所以，雖然我不會再多談這些自相矛盾的悖論列表（雖然以後會再碰到幾次），但這是值得參考的。看著這份衝突但卻是必要的力量列表，可幫助你後退一步，重新思考你在做的事情及其原因，然後做出更為精明的決策。

壓力和分心

專案管理新手的恐懼之一就是成功需要改變。新專案建立的目的是要藉著修改、構造或摧毀某些事物來改變世界的狀態。維持現狀不是成功的結果——除非由於某種奇怪的原因而將此定為目標。世界一直在變，如果和去年相比，專案已經沒那麼好，這通常就意味著落後了，因為目標被誤導或者專案的執行在某些方面失敗了。

擔任專案經理意味著必須承受壓力，這很難視而不見，但是這個領域就是這樣。但不要只是坐視，要做得更好。總是會有新的思考方法、新的學習和應用主題或者新的流程，使工作更有趣或更有效率。也許這種責任與領導力更相關，和管理關係要弱一些，但是兩者區別不大。無論你怎麼區分，要想管理得好都需要領導技能。任何參與專案管理的人對於這兩者都有某些職責，無論他的工作介紹如何描述。

但是，回到壓力的問題上，我見過很多經理人迴避施展領導力的時機（例如，團隊/專案需要有人採取果斷行動的時候），退縮到只是追蹤其他人的績效，而不是為他們的工作帶來便利或是參與其中。如果某人所做的事就是記錄分數和站在邊界線上看，他也許比較適合財務部門。如果某人擔任領導角色，對壓力的反應是避開爭論，那麼他不是在領導，而是在逃避。無效率或抗壓性不良的PM，會傾向於關注於專案的次要部分，這使得他們只能貢獻少許價值。

流程與目標相混淆

在這種情況下，某些PM會經常去量化一些不需要量化的事物。由於不確定該做什麼其他的事情，或者害怕去做那些本來最需要做的事，他們最終將時間花費在次要的事情。隨著PM和專案之間的隔閡逐漸變大，放在不必要的圖、資料表、檢查列表以及報告上的注意力就會增多。在某一時刻，PM開始相信資料和流程就是專案，這是有可能的。他們把焦點放在次重要且容易做的事情上（電子表格或報告），而不是重要且有挑戰性的事情上（程式設計成果或進度）。他們也許會自欺說，如果照著特定流程執行，做好檢查列表上的事，就可以保證專案成功（或者比較諷刺地說，對於任何可能發生的失敗，在技術上都不是他們的錯）。

為了把混淆的可能性減到最小，優秀的專案經理不會在他們願意做和不願意做的事情間劃出明確的界限。他們會避免在專案管理任務和專案本身之間劃下明確的分隔線。堅持檢查列表意味著存在明確的可以保證獲取特定成果的流程，但從來都不是這樣。實際上，總是有三件事：目標、一堆工作以及一群人。定義明確的角色（參考第9章）可能有助於這些人分派工作，但是，建立角色並非目標。檢查列表也許有助於這些人以滿足目標的方式做事，但檢查列表也不是目標。把流程和目標混淆，是管理層最大的錯誤之一。我知道這個，我就曾犯過這種錯誤。

在幾年前做Internet Explorer 4.0專案時，我是幾個大範圍使用者介面的PM。我感受到巨大壓力：這是我接過的最大的任務。為了做好這個專案，我想到一個原則：如果可以把一切都寫在檢查列表上，就不會失敗。雖然專案的各個事項都必須仔細追蹤，但我做得太過頭了。我做了一份細緻的電子表格，以各種形式顯示資料；同時，我辦公室的幾個大型白版也貼滿了表格和列表（並且還在準備其他白板）。

我的上司放手讓我去做，因為專案進展順暢。直到他發現我花在檢查列表和流程的時間超過我和團隊相處的時間——這就是大紅旗插下的時刻了（警告標記）。有一天，他來到我的辦公室，看著我在辦公室裡每個平面上貼著的可笑的由檢查列表和表格組成的大矩陣，說：“Scott，這些東西不錯，但你的專案是你的團隊，管理好團隊，而不是檢查列表。如果檢查列表有助於管理團隊，那非常好。但如果你這樣做下去，不久之後，你就需要你的團隊來幫助你管理檢查列表。”

所以，專案經理不應把焦點放在流程和方法上，應該把焦點放在他們的團隊上。簡單的計劃或追蹤系統當然還是要使用，但他必須符合專案的複雜度和團隊的文化。更精確地講，計劃和追蹤應該支援團隊達成專案目標，而不是阻礙他。我相信，只要PM注意這一點，並贏得團隊信賴，那麼任何漏掉的任務、流程、報告、檢查列表或其他專案管理組織所需的事物，都會在問題惡化前清晰地浮現出來。

就如我們將在第10章中討論的，只是有本書或有位領導說要做某事，或者在上個月或去年採用了某項技術，並不能表示今天依然適用。每個團隊和專案都不同，通常都有很好的原因質疑過去的判斷。對方法和流程保守的原因是，不必要的事情會像滾雪球般地越來越多，把團隊拖進舉步艱難的焦油坑——正如Fred Brook在其《人月神話》（The Mythical Man-Month）一書中所說的那樣。如果管理流程也需要流程，就很難知道實際的工作在哪裡。通常，正是團隊領導或專案經理推動了團隊的官僚主義，或者更為諷刺地，把團隊送進永無止境的過程和會議討論的，也正是這些人。

適度參與

從財富500強的管理人員到運動團隊的教練，所有管理者都很容易過度參與。他們也知道可能過頭了，強迫式的參與是一種方便的補救辦法（雖然是負面）。這部分地解釋了為何有這麼多小經理：對於軟弱的經理，採取的最簡單的措施就是對下屬濫用權力（在極端情況下，同時責怪下屬能力不足，需要他花這麼多的精力）。這種沒安全感的管理者，採用工業革命的術語，源自於他不在生產線上的事實。他們沒有親手做事，與那些實際做事的人不同。

工廠或軟體公司的經理，不像受聘的工人或程式設計師那樣產生線性的工作量。相反地，領導者和經理的受聘用來增強周圍每個人員的價值。增加這種價值的方法和在生產線上的工作不同。但是，因為很多經理人以前都是程式設計師，都是從生產線提拔到管理層，因此，對於這些人，通常自己編寫程式程式碼比領導和管理那些編寫程式碼的人員更有信心和技巧。

就像棒球教練那樣，經理的出現應該貢獻一些有別於增加另外一名球員所獲的東西。有時候，這可能是解決爭論或者讓讓球隊遠離政治；其他時候，是提供優秀的、高水平的計劃，或者是尋找聰明的解決方法以處理意外狀況。由於這些貢獻難以估量，很多PM都為所處角色的模糊而掙扎。身為經理，他們很容易成為責難的物件，而且沒什麼地方可躲。身為團隊領導者，必須將信念、自信和自覺結合起來，以同時獲得效率和快樂。

利用好你的觀點

尋找平衡點的最好方法就是利用不在生產線所能獲得的心理差異。PM的職責自然使他會花比其他人更多的時間，來和團隊中不同的人相處，因此，可以有更多資訊來源，並對專案有更廣闊的視野。PM會同時熟悉專案的業務視角以及技術視角，在需要時，可以協助這兩個團隊進行溝通。這種廣闊的視角，使得在適當時機將重要資訊傳送給適當的人成為可能。雖然這種力量的影響很廣，不過接下來的小故事，會以一種綜合的方式協助說明這個觀點。

作為習慣，我總是在走廊上走來走去，看見程式設計師的門開著，就走進去。我通常只是隨便聊聊，儘量讓他們為某事發笑，並讓他們為我展示他們正在做的工作成果，如果他們有這些，我就會看他們的演示。每隔幾天做一次，甚至每隔幾分鐘，這樣通常可以讓我對專案的實際狀態有很好的瞭解（我們會在第9章討論這種走動式管理的實踐）。

例如，在做IE5.0專案時，有天早上，我走進Fred的辦公室。他正和另一名程式設計師Steve在爭論，關於如何讓新的Listview控制元件正常工作——這是當天早上才發現的、預料之外的一個相容性問題。他們兩個都不想做這項工作。根據我所聽到的內容，這將會花半天或更久才能解決。我走近他們，想確認他們討論的內容，他們點了點頭，好像在說：“是啊，關你什麼事？”然後，我告訴他們可用去走廊盡頭和Bill討論一下。他們又問為什麼，認為這是很特殊的架構問題，不是我能輕易理解的。我笑著說：“因為我剛剛離開他的辦公室，他新做的樹狀控制元件在他的計算機上工作很好。他昨晚也遇上這個問題，並把它當成另一工作任務給解決了。”

當然，在這個小故事裡，我不是在拯救世界或避開一場大災難。如果我沒替他們牽線，也只會浪費幾小時或半天而已（不過，我們在第8章將會討論，進度一般會稍稍落後）。但這不是重點。優秀專案經理的職責就是要知道關於團隊狀態、關於環境狀態的所有有用的事情，並將其應用於其他場合，協助他人完成工作。就是這些微不足道並能實時傳達的資訊，正如這個故事中的場景，使平凡團隊變成優秀團隊、使優秀團隊變成偉大團隊。沒有任何專案或bug跟蹤系統能夠完全替代人員彼此交談關於專案的進展，因為社會網路總是強於科技網路（有時候會更快）。像專案遠景、功能列表以及進度這些大挑戰，總是會變成許多小挑戰，知識和資訊如果能夠輕易在團隊中流通，將對這些挑戰產生積極的影響。關於能否順暢地流通，專案經理扮演了關鍵的角色。

但是，無論大事還是小事，經理所做的行動和決策，對整個團隊都應該有明確的效益。這也許要花一個星期或一個月才看得出成效，但優秀的專案經理會對工作成果的質量產生正面影響，而且通常也影響到相關人員的生活質量。人們對工作會有不同感受，會公開談論他們對所做工作及他們選擇該工作的原因有更深刻的理解，同時和從前比較，通常對即將面對的工作也會有更好的感覺。這類改變通常只會發生在一次會議、一個決策或一次討論，但經歷整個專案過程，這種共鳴和能量會急劇地轉變和提高。

專案經理創造獨特價值

因此，優秀的經理和領導者通常會贏得與那些其打交道的程式設計師、測試員、設計師、市場人員以及文件人員的特殊的尊敬。PM應該能夠透過思考、策略以及領導力等各種比其他人多的方式，來積極影響團隊。通常，這包括為日常工作流程尋找快捷和聰明的最佳化辦法，或者在適當時機以適當方式給予他人幫助或激勵。想做好這件事，他們不必當超人，也不用特別聰明（對此，我完全同意）。他們只需理解他人觀點的好處，然後對其善用即可。

有一項簡單明瞭的事實：專案經理或領導者與團隊中與他人相處的時間多於任何人，他們需要開更多的會議、進入更多的辦公室、和成員進行更多的會談。在組織中，他們所作的決策或對決策的影響也比任何人多。如果專案經理高興、難過、積極或失望，那麼，這些情緒多少會影響他每天遇到的每個人。PM帶給專案的東西，無論好壞，都會傳播給團隊的其他人。

所以，如果專案經理可以專心、堅定、積極而且有能力獲取成功，那麼每個人也具有同樣行為的機率就會增加。任何型別的經理都有類似的潛力，在大多數工作環境中，沒有多少具有很大價值的平衡點。這意味著，如果有可能培養我所談的態度和想法，再也沒有比領導者和經理更適合作為投資的物件了。這不是說專案經理必須是非常有魅力的英雄人物，只有聳聳肩就，能帶領程式設計師團隊投入戰爭（請參閱第11章的“英雄情結”一節）；取而代之，他只要誠心幫助團隊成員做好彙報之事，並讓結果更為成功即可。

最後，我相信的核心觀念就是：只要沒有人受傷（可能除了對手），參與的人都走正確的路，做出好的成果，那麼其它的都不重要。只要結果是好的，有多少想法來自於你還是來自於其他人，並不重要。專案管理是以任何所需的方法，來增加實現積極結果的機率和速度。我每天所用的一句箴言是：讓好事發生。人們會看見，我在走廊上或者白板邊和程式設計師討論，如果有人問：“嘿，Scott，你在做什麼？”我會笑著說：“讓好事發生。”這已成為我每天工作的主要部分。而且，當我管理其他專案時，這種態度也擴充套件出去，傳播到整個團隊。隨著深入本書各個主題集中的章節，我希望你會感受到這種態度，本章的核心觀點將逐漸得以展現。

摘要

本書每章結尾都有重點摘要，幫助你複習：

專案管理隨處可見，而且歷史悠久。

如果你保持初學者之心，你將更有機會進步。

專案管理可以是工作、角色或活動（無論你如何定義，本書的建議都適用於你）。

程式經理是微軟強力定義的專案管理角色，它源自於矩陣式組織的思想。

領導力和管理需要對幾個常見悖論的理解及直覺：包括自我/無我、獨裁/委派，以及勇氣/恐懼。

注意你在管理活動中的自負和過度參與。流程應支援團隊，而不是以其他方式影響團隊。

如果你是專職經理，要尋找合適的方式來利用你關於團隊和專案的觀點。

練習

A. 找幾個與你工作領域不同的好朋友，問問他們是如何管理專案的？是否專門設立了專案領導這個特殊職位？還是將專案管理工作分配到多個人？

B. 作為優秀的PM，需要對各種觀點進行平衡，PM如何決策才能不在某個方向走得過遠？PM如何才能獲取他人幫助，使其保持平衡。

C. 編造一個理由來推掉一次聚會。（從本書的第1章中倖免於難，這個理由充分嗎？）當你從醉酒中恢復之後，並且當你將朋友從拘留所保釋出來之後，考慮如下問題：聚會和專案有哪些不同？比較一下，作為聚會組織者和作為一個工作專案的專案經理，都有哪些挑戰和利益？哪些是不同點？哪些是相同點？

D. 考慮你失敗過的一個專案。你從中學到了什麼？怎麼學的？列出你曾犯過的錯誤，以及後來為了避免其再次發生，你是如何做的？回答本問題的過程將迫使你更小心地思考，並從這些經歷中獲得更多的見識。

E. 你能想象到一種不需要專案管理的工作嗎？如果存在，在其領域，他們如何組織和計劃工作？缺少組織會產生哪些限制？同時又帶來哪些機會？

F. 你能建立領導力時刻嗎？還是隻有當那些脫離控制的事件發生時，該時刻才出現？如果你想增加展現領導力的時機，你需要怎樣做？

G. 想像一下，如果一個團隊，僅以人員對流程和規範的遵守程度，而不是完成目標，作為獎勵標準。工作質量會如何？專案管理角色會如何？這說明，專案經理可以帶來哪些可能的危險？

H. 中層管理者，或者管理經理的人員，由於處於組織的中間位置，尤其願意過度參與工作，並建立不必要的流程。作為一個聰明的中層管理者，如何避免過細管理以及建立過多的規則？