不想當將軍的士兵不是好士兵

拿破崙有句話說的好：不想當將軍的士兵不是好士兵！

很多人都聽說過，也有很多人想過，但卻只有極少數的人是做到，因此成功者居少。

 

隨着年齡的增長，越來越多的IT從業人員，對於將來的職業規劃，更多的就是側重技術/項目管理類的工作轉變。首先，你要弄清項目經理所面臨的問題、機會和期望，明白項目團隊將會有衝突，弄清誰是利益的關係者，明白判斷項目成功的四個標準：預算、進度、效績標準和客戶滿意，還要爲組建一個和諧的團隊，充當教練、領隊和衝突仲裁人。不能因爲項目中的挫折而止步不前，更不能安於現狀。你在整個項目實施中，是領導也是小兵。那麼，做一個成功的項目經理究竟要做哪些事情，這裏作者總結了軟件項目實施過程中的一些經驗，希望與讀者共享。

 

如何組織開發團隊

 

如何構建軟件開發團隊取決於可供選擇的人員、項目的需求以及組織的需求。

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

 

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

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

 

垂直團隊組織

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

優點

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

缺點

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

成功因素

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

 

水平團隊組織

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

優點

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

缺點

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

成功因素

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

 

混合團隊組織

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

優點

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

缺點

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

成功因素

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

 

項目團隊士氣是項目成功的一個因素

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

 

項目規劃技巧

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

 

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

 

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

 

軟件過程推動計劃的開發

每個軟件過程都有一個不同的集合，它包括組織團隊的活動方法以及規劃項目常用的技術。由於這個原因，基於 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 周的迭代分割，以便讓您迅速將軟件交付給用戶。因爲正在嘗試彌補在先前迭代中跳過的工作（如文檔編制），或者因爲您的需求正在增加而沒有添加新的迭代來反映這一事實，所以當項目進展時迭代長度增長是一種趨勢。執行真實性檢查並按照它們的結果行動，將幫助您使迭代週期保持簡短。

 

考慮並行開發

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