摘　要：隨著(zhù)IT產(chǎn)業(yè)的發(fā)展，國內軟件項目越來(lái)越貼近客戶(hù)的現實(shí)需求，項目工程涉及多方面的集成，包括網(wǎng)絡(luò )、硬件、軟件平臺、行業(yè)軟件等的集成越來(lái)越緊密，軟件開(kāi)發(fā)細節上涉及專(zhuān)業(yè)軟件包的整合。同時(shí)客戶(hù)對定制化的需求及工期的需求也越來(lái)越高。

　　作為項目經(jīng)理，如何在滿(mǎn)足客戶(hù)需求，并在人力資源不足（員工成熟度不夠、隊伍不穩定、工程師工作積極性不高）、工期緊的情況下，有效的制定和執行項目計劃，是項目經(jīng)理一個(gè)重要的能力，而要完成這一進(jìn)度人員的組織非常重要。

　　本文作者通過(guò)項目經(jīng)理培訓，并結合多年軟件行業(yè)從業(yè)之經(jīng)驗，來(lái)研究和探討項目執行過(guò)程中任務(wù)的分解和執行中人員組織方面的思路，希望與正從事軟件項目管理的同行分享與共勉，力圖對后續的工作提供一些指導。

　　一個(gè)軟件項目必須滿(mǎn)足：目標、時(shí)間進(jìn)度和預算的要求。要完成這個(gè)項目而建立的軟件開(kāi)發(fā)組織是一個(gè)復雜系統。表面上看起來(lái)目標、時(shí)間進(jìn)度和預算，三者好像沒(méi)有任何一個(gè)單獨的問(wèn)題會(huì )導致困難，每個(gè)都能被解決，但是當它們相互糾纏和累積在一起的時(shí)候，特別是在實(shí)際工作中團隊的行動(dòng)就會(huì )變得越來(lái)越慢，往往可能導致項目進(jìn)度的不可控制，使成本上升，甚至導致項目的失敗。

　　在項目經(jīng)理培訓中，涉及的內容很廣泛。本文試圖僅僅從項目的任務(wù)分解和執行中人員的組織來(lái)進(jìn)行一些討論。主要有下面幾個(gè)方面來(lái)談我的理解。

　　1.問(wèn)題的提出：項目的進(jìn)度度量

　　1.1進(jìn)度不可控的原因

　　在實(shí)際的項目執行過(guò)程中 ，缺乏合理的時(shí)間進(jìn)度是造成項目滯后的最主要原因，原因是什么呢？

　　首先，對估算技術(shù)缺乏有效的研究，很多項目經(jīng)理對項目進(jìn)度過(guò)分樂(lè )觀(guān)的估計，它反映了不真實(shí)的假設——一切都將運作良好。

　　第二，采用的估算技術(shù)隱含地假設人力和工作量可以互換，錯誤地將進(jìn)度與工作量相互混淆。

　　第三，對自己的估算缺乏信心，軟件經(jīng)理通常不會(huì )有耐心持續地進(jìn)行估算這項工作。

　　第四，對進(jìn)度缺少跟蹤和監督。跟蹤技術(shù)和常規監督程序。

　　第五，當意識到進(jìn)度的偏移時(shí)，下意識的反應是增加人力。只會(huì )使事情更糟。

　　對于創(chuàng )造者，只有在實(shí)現的過(guò)程中，才能發(fā)現我們構思的不完整性和不一致性。在估計和進(jìn)度安排中，某個(gè)任務(wù)可以分解給參與人員，他們之間需要相互的交流。子任務(wù)之間需要相互溝通和交流的任務(wù)，必須在計劃工作中考慮溝通的工作量。

　　溝通所增加的負擔由兩個(gè)部分組成，培訓和相互的交流。每個(gè)成員需要進(jìn)行技術(shù)、項目目標以及總體策略上的培訓。因此工作量隨人員的數量呈線(xiàn)性變化：按照n（n-1）/2遞增。

　　1.2進(jìn)度的經(jīng)驗性安排

　　項目進(jìn)度和工作量的不同：工作量只是子任務(wù)的數量的簡(jiǎn)單分解。項目進(jìn)度依賴(lài)于順序上的限制，以及資源制約、培訓時(shí)間、管理成本等。

　　這里有一個(gè)基于經(jīng)驗的時(shí)間安排尺度。假設以一個(gè)項目的總體執行項目周期為 

　　1.對于軟件任務(wù)的進(jìn)度安排的經(jīng)驗法則：

　　1/3計劃

　　1/6編碼

　　1/4構件測試和早期系統測試

　　1/4系統測試，所有的構件已完成

　　除了系統測試，進(jìn)度基本能保證。不為系統測試安排足夠的時(shí)間簡(jiǎn)直就是一場(chǎng)災難。因為延遲發(fā)生在項目快完成的時(shí)候，問(wèn)題才出現在客戶(hù)和項目經(jīng)理面前。延誤發(fā)布，將付出相當高的商業(yè)代價(jià)。上述的二次成本遠遠高于其他開(kāi)銷(xiāo)。

　　因此，在早期進(jìn)度策劃時(shí)，允許充分的系統測試時(shí)間是非常重要的。開(kāi)發(fā)并推行生產(chǎn)率圖表、缺陷率、估算規則等等，而整個(gè)組織最終會(huì )從這些數據的共享上獲益。項目經(jīng)理需要挺直腰桿，堅持他們的估計。

　　當一個(gè)軟件項目落后于進(jìn)度時(shí)，加派人手可能產(chǎn)生的進(jìn)度災難。

　　要及時(shí)聘請到多么能干的新員工；

　　新員工需要接受培訓。有經(jīng)驗的職員將投入到原有進(jìn)度安排以外的工作中；

　　原先劃分為三個(gè)部分的工作，會(huì )重新分解成五個(gè)部分；

　　更多的交流成本、管理的工作；

　　某些已經(jīng)完成的工作必定會(huì )丟失，系統測試必須被延長(cháng)。

　　2.團隊的組織

　　大型項目的每一個(gè)部分由一個(gè)團隊解決，而并非一擁而上。由一個(gè)人來(lái)進(jìn)行問(wèn)題的分解，其他人給予他所需要的支持，以提高效率和生產(chǎn)力。

　　2.1協(xié)作成本

　　需要協(xié)作溝通的人員的數量影響著(zhù)開(kāi)發(fā)成本，因為成本的主要組成部分是相互的溝通和交流，以及更正溝通不當所引起的不良結果。所以并不是人越多越好，系統應該由盡可能少的人員來(lái)開(kāi)發(fā)。

　　2.2成員差異

　　程序員最好的和最差的表現在生產(chǎn)率上平均為10:1；在運行速度和空間上具有5:1的驚人差異。

　　2.3團隊組織關(guān)系

　　一個(gè)項目中的兩種角色安排的三種可能的關(guān)系，他們是：

　�。�1）產(chǎn)品負責人和技術(shù)主管是同一個(gè)人。這種方式非常容易應用在很小型的隊伍中，可能是三個(gè)或六個(gè)開(kāi)發(fā)人員。在大型的項目中則不容易得到應用。原因有兩個(gè)：第一，同時(shí)具有管理技能和技術(shù)技能的人很難找到。思考者很少，實(shí)干家更少，思考者－實(shí)干家太少了。第二，大型項目中，每個(gè)角色都必須全職工作，甚至還要加班。對負責人來(lái)說(shuō)，很難在承擔全部管理責任的同時(shí)，還能抽出時(shí)間進(jìn)行技術(shù)工作。對技術(shù)主管來(lái)說(shuō)，很難在保證設計的概念完整性，沒(méi)有任何妥協(xié)的前提下，擔任管理工作。

　�。�2）產(chǎn)品負責人作為總指揮，技術(shù)主管充當其左右手。這種方法有一些困難。很難在技術(shù)主管不參與任何管理工作的同時(shí)，建立在技術(shù)決策上的權威。顯然，產(chǎn)品負責人必須預先聲明技術(shù)主管的技術(shù)權威，在即將出現的絕大部分測試用例中，他必須支持后者的技術(shù)決定。要達到這一點(diǎn)，產(chǎn)品責任人和技術(shù)主管必須在基本的技術(shù)理論上具有相似觀(guān)點(diǎn)；他們必須在主要的技術(shù)問(wèn)題出現之前，私下討論它們；產(chǎn)品責任人必須對技術(shù)主管的技術(shù)才能表現出尊重。

　�。�3）技術(shù)主管作為總指揮，產(chǎn)品負責人充當其左右手。這種組合可以使工作很有效。不幸的是它很少被應用。不過(guò)，它至少有一個(gè)好處，即項目經(jīng)理可以使用并不很擅長(cháng)管理的技術(shù)天才來(lái)完成工作。

　　2.4團隊組成

　　在一個(gè)大型項目中，軟件項目經(jīng)理必須為成員良好的分工，組成有層次的結構。

　　系統結構師，從上至下地進(jìn)行所有的設計。要使工作易于管理，必須清晰地劃分體系結構設計和實(shí)現之間的界線(xiàn)，系統結構師必須一絲不茍地專(zhuān)注于體系結構。

　　首席程序員。他親自定義功能和性能技術(shù)說(shuō)明書(shū)，設計程序，編制源代碼，測試以及書(shū)寫(xiě)技術(shù)文檔。

　　程序職員。他負責維護編程產(chǎn)品庫中所有團隊的技術(shù)記錄。

　　編輯、秘書(shū)。首席程序員負責產(chǎn)生文檔。而編輯進(jìn)行分析和重新組織，提供各種參考信息和書(shū)目，對文檔多個(gè)版本進(jìn)行維護以及監督文檔生成的機制。

　　工具維護人員。測試人員。

　　3.團隊交流

　　3.1手冊、或者書(shū)面規格說(shuō)明

　　手冊是產(chǎn)品的外部規格說(shuō)明，它描述和規定了用戶(hù)所見(jiàn)的每一個(gè)細節；同樣的，它也是結構師主要的工作產(chǎn)物。

　　隨著(zhù)用戶(hù)和實(shí)現人員反饋的增加，規格說(shuō)明中難以使用和難以構建實(shí)現的地方不斷被指出，規格說(shuō)明也不斷地被重復準備和修改。然而對實(shí)現人員而言，修改的階段化是很重要的——在進(jìn)度表上應該有帶日期的版本信息。

　　手冊不但要描述包括所有界面在內的用戶(hù)可見(jiàn)的一切，它同時(shí)還要避免描述用戶(hù)看不見(jiàn)的事物。后者是編程實(shí)現人員的工作范疇，而實(shí)現人員的設計和創(chuàng )造是不應該被限制的。體系結構設計人員必須為自己描述的任何特性準備一種實(shí)現方法，但是他不應該試圖支配具體的實(shí)現過(guò)程。

　　規格說(shuō)明的風(fēng)格必須清晰、完整和準確。用戶(hù)常常會(huì )單獨提到某個(gè)定義，所以每條說(shuō)明都必須重復所有的基本要素，所以所有文字都要相互一致。這往往使手冊讀起來(lái)枯燥乏味，但是精確比生動(dòng)更加重要。

　　3.2周例會(huì )

　　周例會(huì )由所有的結構師，加上硬件和軟件實(shí)現人員代表和市場(chǎng)計劃人員參與，由首席系統結構師主持。

　　會(huì )議中，任何人可以提出問(wèn)題和修改意見(jiàn)，但是建議書(shū)通常是以書(shū)面形式，在會(huì )議之前分發(fā)。新問(wèn)題通常會(huì )被討論一些時(shí)間。重點(diǎn)是創(chuàng )新，而不僅僅是結論。該小組試圖發(fā)現解決問(wèn)題的新方法，然后少數解決方案會(huì )被傳遞給一個(gè)和幾個(gè)結構師，詳細地記錄到書(shū)面的變更建議說(shuō)明書(shū)中。

　　接著(zhù)會(huì )對詳細的變更建議做出決策。這會(huì )經(jīng)歷幾個(gè)反復過(guò)程，實(shí)現人員和用戶(hù)會(huì )仔細地進(jìn)行考慮，正面和負面的意見(jiàn)都會(huì )被很好地描述。如果達成了共識，非常好；如果沒(méi)有，則由首席結構師來(lái)決定。這需要花費時(shí)間，最終所發(fā)布的結論是正式和果斷的。

　　這種會(huì )議的卓有成效是由于：

　　1.每周交流一次。因此，大家對項目相關(guān)的內容比較了解，不需要額外培訓。

　　2.上述小組十分睿智和敏銳，深刻理解所面對的問(wèn)題，每個(gè)人都要承擔義務(wù)。

　　3.當問(wèn)題出現時(shí)，在界線(xiàn)的內部和外部同時(shí)尋求解決方案。

　　4.正式的書(shū)面建議強制了決策的制訂，避免了會(huì )議草稿紀要方式的不一致。

　　5.清晰地授予首席結構師決策的權力，避免了妥協(xié)和拖延。

　　3.3電話(huà)日志（交流日志，BBS等記錄）

　　隨著(zhù)實(shí)現的推進(jìn)，無(wú)論規格說(shuō)明已經(jīng)多么精確，還是會(huì )出現無(wú)數結構理解和解釋方面的問(wèn)題。顯然有很多問(wèn)題需要文字澄清和解釋?zhuān)�還有一些僅僅是因為理解不當。討論和解決，在BBS上做出記錄。問(wèn)題的答案（對問(wèn)題的認識或者想法記錄下來(lái)）必須是可以告知每個(gè)人的權威性結論。

　　3.4質(zhì)量會(huì )議

　　項目經(jīng)理最好的朋友就是他每天要面對的敵人——獨立的產(chǎn)品測試機構/小組。該小組根據規格說(shuō)明檢查機器和程序，充當麻煩的代言人，查明每一個(gè)可能的缺陷和相互矛盾的地方。每個(gè)開(kāi)發(fā)機構都需要這樣一個(gè)獨立的技術(shù)監督部門(mén)，來(lái)保證其公正性。

　　4.為變化組織架構

　　每個(gè)人被分派的工作必須是多樣的、富有拓展性的工作，從技術(shù)角度而言，整個(gè)團隊可以靈活地安排。

　　當系統發(fā)生變化時(shí)，管理結構也需要進(jìn)行調整。管理人員和技術(shù)人才的能力給予培養，使管理人員和技術(shù)人才具有互換性。

　　管理人員需要參與技術(shù)課程，高級技術(shù)人才需要進(jìn)行管理培訓。項目目標、進(jìn)展、管理問(wèn)題必須在人員整體中得到共享。