如何做成功的專案經理（轉）

如何做成功的專案經理
要想成為一個好的專案經理，您需要弄清專案經理所面臨的問題、機會和期望，明白專案團隊將會有衝突，弄清誰是利益的關係者，明白判斷專案成功的四個標準：預算、進度、效績標準和客戶滿意，還要為組建一個和諧的團隊，充當教練、領隊和衝突仲裁人。不能因為專案中的挫折而止步不前，更不能安於現狀。你在整個專案實施中，是領導也是小兵。那麼，做一個成功的專案經理究竟要做哪些事情，這裡作者總結了軟體專案實施過程中的一些經驗，希望與讀者共享。

如何組織開發團隊

如何構建軟體開發團隊取決於可供選擇的人員、專案的需求以及組織的需求。本文闡述了專案實施過程中各種團隊組織的策略。

有效的軟體專案團隊由擔當各種角色的人員所組成。每位成員扮演一個或多個角色；可能一個人專門負責專案管理，而另一些人則積極地參與系統的設計與實現。常見的一些專案角色包括：分析師、策劃師、資料庫管理員、設計師、操作／支援工程師、程式設計師、專案經理、專案贊助者、質量保證工程師、需求分析師、主題專家（使用者）、測試人員。

作為一個專案經理人，您是如何組織專案團隊的？是採用垂直方案、水平方案還是混合方案？以垂直方案組織的團隊由多面手組成，每個成員都充當多重角色。以水平方案組織的團隊由專家組成，每個成員充當一到兩個角色。以混合方案組織的團隊既包括多面手，又包括專家。

一個重要的考慮因素是可供選擇的人員的性質。如果大多數人員是多面手，則您往往需要採用垂直方案，同樣，如果大多數人員是專家，則採用水平方案。如果您正引入一些新人，即使這些人員都是合同工，則仍然需要優先考慮您的專案和組織。本文描述了形成團隊組織的垂直、水平和混合方案，並指出了它們各自的優缺點。本次討論的一個重要含意是您的團隊組織和用於管理專案的手段之間應構成默契；任何方法上的失諧都很可能導致專案產生問題。

垂直團隊組織

垂直團隊由多面手組成。用例分配給了個人或小組，然後由他們從頭至尾地實現用例。

優點

● 以單個用例為基礎實現平滑的端到端開發。
● 開發人員能夠掌握更廣泛的技能。

缺點

● 多面手通常是一些要價很高並且很難找到的顧問。 　
● 多面手通常不具備快速解決具體問題所需的特定技術專長。
● 主題專家可能不得不和若干開發人員小組一起工作，從而增加了他們的負擔。
● 所有多面手水平各不相同。

成功因素

● 每個成員都按照一套共同的標準與準則工作。
● 開發人員之間需要進行良好的溝通，以避免公共功能由不同的組來實現。
● 公共和達成共識的體系結構需要儘早在專案中確立。

水平團隊組織

　　水平團隊由專家組成。此類團隊同時處理多個用例，每個成員都從事用例中有關其自身的方面。

優點

● 能高質量地完成專案各個方面（需求、設計等）的工作。
● 一些外部小組，如使用者或操作人員，只需要與瞭解他們確切要求的一小部分專家進行互動。

缺點

● 專家們通常無法意識到其它專業的重要性，導致專案的各方面之間缺乏聯絡。
● “後端”人員所需的資訊可能無法由“前端”人員來收集。
● 由於專家們的優先權、看法和需求互不相同，所以專案管理更為困難。

成功因素

● 團隊成員之間需要有良好的溝通，這樣他們才能彼此瞭解各自的職責。
● 需要制定專家們必須遵循的工作流程和質量標準，從而提高移交給其他專家的效率。

混合團隊組織

混合團隊由專家和多面手共同組成。多面手繼續操作一個用例的整個開發過程，支援並處理多個使用例中各部分的專家們一起工作。

優點

● 擁有前兩種方案的優點。
● 外部小組只需要與一小部分專家進行互動。
● 專家們可集中精力從事他們所擅長的工作。
● 各個用例的實現都保持一致。

缺點

● 擁有前兩種方案的缺點。
● 多面手仍然很難找到。
● 專家們仍然不能認識到其他專家的工作並且無法很好地協作，儘管這應該由多面手來調節。
● 專案管理仍然很困難。

成功因素

● 專案團隊成員需要良好的溝通。
● 需要確定公共體系結構。
● 必須適當地定義公共流程、標準和準則。

專案團隊士氣是專案成功的一個因素

大部分專案成功的定義說的是專案如何按時完成、是否在預算內以及是否滿足使用者的需要。但是，在如今要找到好的軟體專業人員都非常困難，更不用說留住他們的這種情況下，還需要將專案成功的定義擴充套件為包括專案團隊的士氣。可能在努力完成一個軟體專案後，不料卻因為壓榨他們過度而失去了重要的開發人員，這樣做可能會符合組織的短期需要，但它對構建一個高效的軟體部門的長遠利益來說肯定是有害的。衡量專案成功與否的一個重要手段是專案結束後團隊的士氣。在專案結束之際，專案團隊的各個成員是否覺得他們從自己的經歷中學到了一些知識、是否喜歡為這次專案工作，以及是否希望參與組織的下一個專案都是非常重要的。

專案規劃技巧

專案計劃技巧對於現今的軟體開發人員來說是必需的。這裡有一些幫助您有效地計劃下一個專案的建議。

認識到信心來自規劃的過程，而不是計劃本身。

建立專案計劃會迫使您早在編寫程式碼之前就考慮如何構建您的系統——減少專案的風險，因為您已經考慮了各種策略和方法並且已經選擇了最有意義的一項。您的目的不應該只是不花氣力產生一個計劃；它應該是一個實際可行的計劃，您可以根據它來成功管理您的專案。

軟體過程推動計劃的開發

每個軟體過程都有一個不同的集合，它包括組織團隊的活動方法以及規劃專案常用的技術。由於這個原因，基於 Rational Unified Process (RUP)的專案規劃不同於OOSP專案的規劃，而OOSP專案的規劃也不同於eXtreme Programming (XP) 專案的規劃。不同的過程有不同的計劃。

從粗粒度的計劃開始

在專案將要開始時，應該制定一個粗粒度的、確定專案高階活動和預期里程碑的計劃。粗粒度的計劃將組織成迭代——根據專案的大小和性質，每次迭代通常在三週到八週之間發生（四周到六週為更佳）。其中一些迭代將集中在專案初期，而很多迭代將集中在整個應用的功能部分開發，還有一些迭代集中在將您的系統轉變成產品。

實施者應該是計劃人員

建立專案計劃的最佳人員是負責實施該計劃的人員。當規劃由一個人建立而由另一個人實施時，如果專案不能按時完成或超出預算，他們不太會相信計劃，而很有可能會責備它。也就是說，參與專案的每個人都應該投入到專案計劃的開發和進展中。

不要忘記“不該忘記的事”

計劃不僅要反映需求設計、建模、程式設計和測試的“真實”工作，而且還應該反映輔助活動（然而仍是重要的），它包括：休假和法定假日、培訓和教育、專案管理活動（如規劃和人員管理）、開銷（如系統當機時間、會議和回覆電子郵件）、體系結構定義、測試之後的系統返工、系統交付、與重用相關的活動（如普遍化 ）。

將任何設想和約束編入文件

規劃時您總要作一些假設，如能夠及時獲得應用程式伺服器的新發行版，或可以得到熟悉您正在應用的技術和技巧的開發人員。同時，您將在一些約束下工作，如影響計劃的強制截止期限或資源限制。將這些假設和約束編入文件，這樣，當您實施專案的任何時候更新計劃時，都可以記起您先前做出的一些“不尋常”決定。

認識到不同的資源意味著不同的計劃

十名有經驗的開發人員組成的團隊創造出的成效要遠遠多於十名初學者組成的團隊所創造的成效。要想更加實際的話，您的計劃必須反映專案可使用的資源的真實情況。

建立現實的計劃

專案組必須相信其專案的目的、估價和時間表。要做到這點，您必須真實地規劃，避免規劃超出您能理解的範圍。僅當您打算研究未知事項時，才能容忍無知。

只規劃有價值的事

IBM DeveloperWorks 網站提供了許多可應用於您專案的最佳實踐。然而，根據專案的性質，不是所有這些技術都將適合於您的獨特情況。要將這些最佳實踐簡單地看作是您放置在“專案管理工具箱”中的工具，您可以根據需要適當使用這些工具。

適當使用專案管理工具

一些專案管理工具，如 Microsoft Project，提供了重要功能， 如Gantt圖表（活動時間表）的開發、規劃與實際結果的比較、PERT 圖表（網路圖表）的開發、任務的定義、任務之間相關性的定義、對任務的資源分配和資源平衡。所有這些事情似乎象是一個好主意，並且它們通常是好主意——但它們還需要許多精力來建立和維護，而且很少為專案組提供實際價值。的確，它讓一些專案管理人員感到富有成效。的確，高階管理喜歡看見您有一個計劃。但是，沒有一行程式碼是由所有這個活動產生的。規劃是有價值的活動；但投入大量的時間來建立規劃圖表通常不是有價值的活動。

謹慎應用技術方案處理管理問題

對於在專案中遇到的問題，您確信需要用技術來解決嗎？本文改編自作者所著的Process Patterns 的第五章，Scott Ambler建議改進管理，而不是新技術，可能就是您的解決方案。

還沒有一種點能表明用部署最新技術中來解決通過改變管理實踐去解決問題的（請參閱參考資料中 The Squandered Computer）。事實上是，您不應該將所有商業過程所得的好處都歸功於支援這些更改的軟體專案。沒有這些新的軟體或硬體，您可能會得到同樣的好處。

將技術解決方案識別成非技術問題是經常重複發生在資訊科技界的常見錯誤。這種經常發生的錯誤將其看成是稱作 Apply Technical Solution to Non-Technical Problem（將技術解決方案應用到非技術問題）自身的過程反模式（過程反模式是一種已證明在實際執行當中並不是行之有效的方法）。

技術解決方案僅適用於解決技術問題。例如，“網路計算機”的概念仍然是計算機界中熱衷的時尚。其基本概念就是通過網路計算機來替代個人計算機，組織就可以大大縮減支援計算機軟硬體的開支。

研究表明，如果包括培訓和支援這些計算機費用的話，那每年支援一臺個人計算機的平均開支大約在 $5,000 到 $30,000 之間。網路計算機（也稱之為 Java 終端，因為它們僅執行已經打包成 Java 位元組程式碼的程式）理論上將縮減開支，因為它們僅需要簡單的維護和支援。儘管做了大量的廣告宣傳，但迄今為止，網路計算機的銷售量十分可憐。從表面上看，網路計算機試圖解決的問題看起來是技術性的。但當您想到這一點的時候，問題實際已經成為管理問題之一了。

一些組織一年要花費 $30,000來支援計算機的原因不是因為個人計算機，而是由於對個人計算機的誤用。這些組織不是由具有資格的專業人員來安裝公共配置，而是讓使用者選擇和安裝他們自己的軟體。一旦使用者遇到了麻煩，組織的開支就飛漲。另外還有檔案格式不相容的問題。若沒有公共的軟體套件，使用者得浪費大量時間在同一供應商所提供的不同軟體版本之間轉換檔案，或從不同供應商所提供的不同軟體之間轉換檔案。基於類似的原因，當使用者購買他們自己的裝置時，硬體培訓和支援也變得更加困難。

在這種情況下所發生的問題是與過程相關：個人計算機軟硬體的管理不當。因而購置網路計算機這一技術解決方案是否能夠解決問題值得懷疑。技術解決方案適用於技術問題，管理解決方案適應於管理問題，而過程解決方案則適用於過程問題。在談完了所有內容之後，我真正的意思也許僅僅是在工作中要使用正確的工具。

基於需求的規劃策略：按優先次序排序

成功的專案組認識到不能等同地建立所有的需求，因此，需要對需求進行優先次序排序並按此順序操作。

某些需求比其它需求重要得多。例如，對於聯機銀行的需求來說，對帳戶間資金轉移的支援要比銀行每月宣告的 Elbonian語言版本重要得多。成功的軟體團隊將首先集中精力構建最重要的功能，儘可能地滿足使用者需求中關鍵的功能，而那些次關鍵性功能留到以後處理。需求排序使您的團隊能夠為組織的軟體利潤作出最大貢獻。然而，要有效地對需求進行優先次序排序，必須考慮幾個因素：商業價值、交付成本、交付日期、交付複雜程度、風險（請參閱提示“控制風險：不讓風險控制您”）、與其它需求的關係、何時需要該需求。

可能的優先順序別範圍

只要明確的定義了優先順序並且在應用上保持一致，那麼使用什麼優先順序別範圍是無關緊要的。一般的優先順序別範圍包括：

● 高階、中等、低階

● 必需的、條件的、可選的

● 數字的（例如，1、2、3）

如何對需求按優先次序排序

您應該讓授權的個人或小組來建立並確認指派的優先權。對需求的優先順序進行優先次序排序通常是一個協商的過程，它涉及到許多專案參與者，包括您的使用者、使用者管理、高階管理、開發人員、操作人員和支援部門。

大多數專案小組將組織成一個“配置控制委員會 (CCB)”——有時稱為“更改控制委員會”或“專案籌劃指導委員會” ——它由系統中關鍵的並且希望是知識淵博的參與者組成。通常由該小組定期開會決定任何新需求的優先順序和指派（對於系統的釋出或者對於在現有開發成果中的重複）。

為何對需求進行優先次序排序？

需求排序列表是輸入進專案定界過程中的關鍵因素。專案早期，需要認識到，最困難的事之一是不要打算能交付專案參與者要求的每個功能。專案範圍定義了專案組將要交付的範圍。這是很重要的，因為它有助於避免“超出範圍”，即，專案進展的附加的新需求。已定義的專案範圍使您能協商是否有責任交付新確定的需求，並判斷新需求對於交付日期／成本的增加的合理性以及討論是否應該在後續發行版中交付該需求。缺少確定的範圍，專案組將承擔無法交付的風險，因為經常要向正在構建的專案中新增“再多一條功能”。

規劃迭代：及時開發詳細計劃

專案不斷進行時，需要詳細規劃即將實施的迭代活動。在當今日新月異的環境中，提前幾個月甚至幾年做詳細規劃是毫無價值的，但您可以對下幾周（典型的迭代的時間跨度）進行成功地詳細規劃。

專案規劃的普遍且難以置信的有效方法是從粗略的專案規劃開始（請參閱“專案規則技巧”），即從專案開始時開發，然後在完成構成專案的各種迭代時緩慢發展形成。隨著專案不斷進展，需要更新整個粗略的專案規劃，更新它以反映近來努力的實際成果以及您的團隊將繼續從事的下一個（或兩個）迭代的規劃細節。在為單一迭代開發細緻的規劃時，應該執行這些步驟。

實行真實性檢查

通過詢問並且回答一些難題來開始詳細的規劃工作：專案是否仍在按計劃進行？您的方法是否仍有意義？您的團隊是否由合適的人員組成？您是否仍有資金管理者支援？如果其中任何一個問題的答案是否，則需要解決問題，這可能意味著新（且非常短）迭代使您的團隊回到正常軌道上。對處於困境的專案進行大計劃是毫無價值的。

標識詳細的任務

在專案開始時，體系結構和轉移迭代只是列出需要實現的任務列表。然而，要規劃迭代，必須評估已為它指定的需求（請參閱“基於需求的規劃策略”）。隨著專案發展，您將對於對個別需求有更好理解。您可能會發現，現在需要更改給迭代指定的原始需求，這些需求最初是有意義的。或許已經標識並新增了新的需求；或許已經擴充套件或縮減了需求；或許已經更改了優先順序。不管什麼原因，您會發現您需要重新定義打算在該迭代中實現的內容。根據需求，標識需要實現的任務。

標識任務相關性

某些任務取決於其它任務。例如，在部署原始碼之前，必須先編寫它。測試案例的開發可以在編碼之前開始。實際程式碼的測試必須等待，直到已經編寫了某些程式碼（儘管或許不是所有程式碼）為止。問題是某些任務必須在其它任務完成之後才能開始；某些任務必須等待，直到另一個任務開始了為止，它才可以開始；某些任務不能完成，直到另一個任務完成為止；某些任務不能完成，直到另一個任務開始了為止。

均衡資源

需要緊記的重要事情是，每個人一次只可處理那麼多工，並且在工作的那一天只有那麼多時間。這個概念稱為資源均衡，確保任務分派是合理的。 指定用 10% 的時間完成 10 項任務很可能無法完成任何任務， 而且指定用 50% 的時間完成 5 項任務的人員也不可能完成這些任務。確保現實的規劃的最好方法是，讓執行計劃的人員參與計劃開發。

保持迭代短小

迭代週期應該保持比較短。應該將大於 8 周的迭代分割，以便讓您迅速將軟體交付給使用者。因為正在嘗試彌補在先前迭代中跳過的工作（如文件編制），或者因為您的需求正在增加而沒有新增新的迭代來反映這一事實，所以當專案進展時迭代長度增長是一種趨勢。執行真實性檢查並按照它們的結果行動，將幫助您使迭代週期保持簡短。

考慮並行開發

分幾個子團隊來同時進行系統的不同部分始終是一種有效的辦法，尤其對於系統縱向片段的開發。並行開發可以大大地縮短產品的上市時間，這是當今高度市場競爭性的一個重要因素，儘管它以增加協調工作為代價。共同的體系結構、共享知識視野、共同的開發實踐、定期團隊會議及共享工作場地使並行開發成為可能。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7942439/viewspace-21113/，如需轉載，請註明出處，否則將追究法律責任。