基于軟件開(kāi)發(fā)項目進(jìn)度控制常見(jiàn)問(wèn)題解析

　　要有效地進(jìn)行進(jìn)度控制，必須對影響進(jìn)度的因素進(jìn)行分析，事先或及時(shí)采取必要的措施，盡量縮小計劃進(jìn)度與實(shí)際進(jìn)度的偏差，實(shí)現對項目的主動(dòng)控制。軟件開(kāi)發(fā)項目中影響進(jìn)度的因素很多，如人為因素、技術(shù)因素、資金因素、環(huán)境因素等等。在軟件開(kāi)項目的實(shí)施中，人的因素是最重要的因素，技術(shù)的因素歸根到底也是人的因素。軟件開(kāi)發(fā)項目進(jìn)度控制常見(jiàn)問(wèn)題主要是體現在對一些因素的考慮上。常見(jiàn)的問(wèn)題有以下幾種情況：
 

 

　　一、80-20原則與過(guò)于樂(lè )觀(guān)的進(jìn)度控制

　　80-20原則在軟件開(kāi)發(fā)項目進(jìn)度控制方面體現在：80%的項目工作可以在20%的時(shí)間內完成，而剩余的20%的項目工作需要80%的時(shí)間。這個(gè)80%的項目工作不一定是在項目的前期，而可能是分布在項目的各個(gè)階段，但是剩余的20%左右的項目工作大部分是在后期。所以軟件開(kāi)發(fā)在進(jìn)入編碼階段后會(huì )給人一種“進(jìn)展快速”的感覺(jué)，使得項目經(jīng)理、項目團隊成員、用戶(hù)以及高層領(lǐng)導產(chǎn)生了過(guò)于樂(lè )觀(guān)的估計。有些領(lǐng)導看到軟件交付給用戶(hù)了，就一塊石頭落地“總算交差了”，同時(shí)又可能撤出一些被認為不必要的人力資源。但很多情況下這是為了對付用戶(hù)不合理的交付期限要求而采用的不得已的措施。這樣的結果是拖延了后期的工作，同時(shí)如果軟件還不成熟的話(huà)，會(huì )給用戶(hù)造成不好的影響。

　　二、范圍、質(zhì)量因素對進(jìn)度的影響

　　軟件開(kāi)發(fā)項目比其他任何建設項目都會(huì )有更經(jīng)常的變更，大概是因為軟件程序是一種“看不見(jiàn)”又“很容易修改”的東東吧，用戶(hù)是想改就改，造成需求的蔓延，項目經(jīng)理有時(shí)還不知如何拒絕，加上要說(shuō)“我能”的心理因素，一般都會(huì )答應修改。這樣集少成多，逐漸影響了項目進(jìn)度。

　　如果某項工作在進(jìn)度上表面上達到目標了，但經(jīng)檢驗其質(zhì)量沒(méi)有達到要求，則必然要通過(guò)返工等手段，增加人力資源的投入，增加時(shí)間的投入，實(shí)際上是拖延了進(jìn)度。不管是從橫向或縱向來(lái)看，部分任務(wù)的質(zhì)量會(huì )影響總體項目的進(jìn)度，前面的一些任務(wù)質(zhì)量中會(huì )影響到后面的一些任務(wù)質(zhì)量。

　　三、資源、預算變更對進(jìn)度的影響

　　資源，最主要的還是人力資源，有時(shí)某方面的人員不夠到位，或者在多個(gè)項目的情況下某方面的人員中途被抽到其他項目、或身兼多個(gè)項目、或在別的項目不能自拔無(wú)法投入本項目。還有一個(gè)很重要的資源，就是信息資源，如某些國家標準、行業(yè)標準，用戶(hù)可能提供不了，而是需要去收集或購買(mǎi)，如果不能按時(shí)得到，就會(huì )影響需求分析、設計或編碼的工作。其他資源，如開(kāi)發(fā)設備或軟件沒(méi)有到貨，也會(huì )對進(jìn)度造成影響。

　　預算其實(shí)就是一種資源，它的變更會(huì )影響某些資源的變更，從而對進(jìn)度造成影響。

　　四、低估了軟件開(kāi)發(fā)項目實(shí)現的條件

　　低估軟件開(kāi)發(fā)項目實(shí)現的條件表現在低估技術(shù)難度、低估協(xié)調復雜度、低估環(huán)境因素這樣幾個(gè)方面。

　　首先是低估技術(shù)難度。軟件開(kāi)發(fā)項目團隊成員，有時(shí)甚至是企業(yè)的高級項目主管也經(jīng)常低估項目技術(shù)上的困難。低估技術(shù)難度實(shí)際上也就是高估人的能力，認為或希望項目會(huì )按照已經(jīng)制定的樂(lè )觀(guān)項目計劃順利地實(shí)施，而實(shí)際則不然。軟件開(kāi)發(fā)項目的高技術(shù)特點(diǎn)本身說(shuō)明其實(shí)施中會(huì )有很多技術(shù)的難度，除了需要高水平的技術(shù)人員來(lái)實(shí)施外，還要考慮為解決某些性能問(wèn)題而進(jìn)行科研攻關(guān)和項目實(shí)驗;

　　其次，低估了協(xié)調復雜度，也低估了多個(gè)項目團隊參加項目時(shí)工作協(xié)調上的困難。軟件開(kāi)發(fā)項目團隊成員比較強調個(gè)人的智慧、強調個(gè)性，這給項目工作協(xié)調帶來(lái)更多的復雜度。當一個(gè)大項目由很多子項目組成時(shí)，不僅會(huì )增加相互之間充分溝通交流的困難，更會(huì )增加項目協(xié)調和進(jìn)度控制上的困難。

　　另外，企業(yè)高級項目主管和項目經(jīng)理也經(jīng)常低估環(huán)境因素，這些環(huán)境因素包括用戶(hù)環(huán)境、行業(yè)環(huán)境、組織環(huán)境、社會(huì )環(huán)境、經(jīng)濟環(huán)境。低估這些條件，既有主觀(guān)的原因，也會(huì )有客觀(guān)的原因。對項目環(huán)境的了解程度不夠，造成沒(méi)有做好充分的準備。

　　五、項目狀態(tài)信息收集的情況

　　由于項目經(jīng)理的經(jīng)驗或素質(zhì)原因，對項目狀態(tài)信息收集的的掌握不足，及時(shí)性準確性完整性比較差。另外其它一些原因也會(huì )造成這種現象。某些項目團隊成員報喜不報憂(yōu)，不希望別人知道自己工作的不好的情況，例如軟件程序的編制，可能會(huì )先編制一些表面的東西，現有界面，看起來(lái)好像完成任務(wù)了，實(shí)際上只是一個(gè)“原型系統”或演示系統。給領(lǐng)導造成比較樂(lè )觀(guān)的感覺(jué)。

　　如果項目經(jīng)理或者管理團隊沒(méi)有及時(shí)地檢查發(fā)現這種情況，將對項目的進(jìn)度造成嚴重的影響。當然，如果出現這種需要時(shí)時(shí)刻刻都互相提防的氛圍，管理人員就應該從管理的角度，從制度的角度檢討一下，進(jìn)行改進(jìn)，讓大家實(shí)事求是地進(jìn)行溝通。溫伯格說(shuō):“無(wú)論你多么聰明，離開(kāi)了信息，對項目進(jìn)行成功的控制就是無(wú)源之水、無(wú)本之木。”

　　六、執行計劃的嚴格程度

　　沒(méi)有把計劃作為項目過(guò)程行動(dòng)的基礎，而是把計劃放在一邊，比較隨意去做。例如對于項目團隊內部溝通或外部溝通，在計劃中要說(shuō)明清楚人員、周期、方式、方法，不能遺漏，但在實(shí)際項目過(guò)程中，可能出現溝通沒(méi)有按時(shí)或沒(méi)有完整地達到所有項目干系人的情況。

　　若項目計劃本身有錯誤，執行錯誤的計劃肯定會(huì )產(chǎn)生錯誤。如，計劃制訂者在計劃系統框架設計考慮上的錯誤、進(jìn)度安排上的失誤等。實(shí)際的項目實(shí)施中，除了這種錯誤之外，還可能因為項目執行上的錯誤，造成項目的麻煩。例如，項目的客戶(hù)及其他項目干系人沒(méi)有及時(shí)為項目中出現的情況采取必要的措施或者所采取的措施的不適合具體的情況、沒(méi)有效果或者有副作用等。另外，如果在項目中的某項工作(如某個(gè)子系統或模塊、組件)被轉包給第三方開(kāi)發(fā)后，不能進(jìn)行有效的管理，也會(huì )造成進(jìn)度上的延誤。

　　七、計劃變更調整的及時(shí)性

　　漸近明細是項目的特點(diǎn)，特別是對于軟件開(kāi)發(fā)項目，并不是一個(gè)一成不變的過(guò)程。開(kāi)始時(shí)的項目計劃可以先制定得比較粗一些，隨著(zhù)項目的進(jìn)展，特別是需求明確以后，項目的計劃就可以進(jìn)一步的明確，這時(shí)候應該對項目計劃進(jìn)行調整修訂，通過(guò)變更手續取得項目干系人的共識。計劃應該隨著(zhù)項目的進(jìn)展而逐漸細化、調整、修正。沒(méi)有及時(shí)調整的計劃或者是隨意的不負責任的計劃的項目是難以控制的。在高技術(shù)行業(yè)，日新月異是主要特點(diǎn)，因此計劃的制定需要在一定條件的限制和假設之下采用漸近明細的方式，隨著(zhù)項目的進(jìn)展進(jìn)行不斷細化、調整、修正、完善。

　　對于較為大型的軟件開(kāi)發(fā)項目的工作分解結構可采用二次甚至多次 WBS 方法。即根據總體階段劃分的總體 WBS ，需求調研階段結束、概要設計完成后專(zhuān)門(mén)針對詳細設計或編碼階段的二次 WBS 。由于需求的功能點(diǎn)和設計的模塊或組件之間并不是一一對應的關(guān)系，所以只有在概要設計完成以后才能準確地得到詳細設計或編碼階段的二次 WBS ，根據代碼模塊或組件的合理劃分而得出的二次 WBS 才能在詳細設計、編碼階段乃至測試階段起到有效把握和控制進(jìn)度的作用。有些項目的需求或設計做得不夠詳細，無(wú)法對工作任務(wù)的分解、均衡分配和進(jìn)度管理起參考作用，因此要隨著(zhù)需求的細化和設計的明確，對項目的分工和進(jìn)度進(jìn)行及時(shí)的調整，使項目的計劃符合項目的變化，使項目的進(jìn)度符合項目的計劃。
 

 

　　八、未考慮不可預見(jiàn)事件發(fā)生造成的影響

　　假設、約束、風(fēng)險等考慮“不周”造成項目進(jìn)度計劃中未考慮一些不可預見(jiàn)的事件發(fā)生。例如軟件開(kāi)發(fā)項目還會(huì )因為項目資源特別是人力資源缺乏、人員生病、人員離職、項目團隊成員臨時(shí)有其他更緊急的任務(wù)造成人員流動(dòng)等不可預見(jiàn)的事件對項目的進(jìn)度控制造成影響(即項目按時(shí)完成是基于如下假設：人力資源不會(huì )缺乏、人員不會(huì )生病、人員不會(huì )流動(dòng))。企業(yè)環(huán)境、社會(huì )環(huán)境、天災人禍等事件對項目的進(jìn)度控制造成影響。對項目的假設條件、約束條件、風(fēng)險及其對策等對于進(jìn)度的影響在項目計劃要進(jìn)行充分的考慮，在項目進(jìn)展過(guò)程中也要不斷地重新考慮有沒(méi)有新的情況，新的假設條件、約束條件、潛在風(fēng)險會(huì )影響項目的進(jìn)度。假設是通過(guò)努力可以直接解決的問(wèn)題，而這些問(wèn)題是一定要解決才能保證項目按計劃完成;約束一般是難以解決的問(wèn)題，但可以通過(guò)其他途徑回避或彌補、取舍，如犧牲進(jìn)度、質(zhì)量等等;假設與約束是針對比較明確會(huì )出現的情況，如果問(wèn)題的出現具有不確定性，則應該在風(fēng)險分析中列出，分析其出現的可能性、造成的影響、采取的措施。實(shí)際上像沒(méi)有考慮人的疾病、人員流動(dòng)這些情況本身也不是什么問(wèn)題，因為任何人都不可能把所有以外的情況都考慮完整，實(shí)際上也沒(méi)有必要。但有些諸如下班或節假日的加班時(shí)間都被安排用于項目工作的情況就會(huì )造成更多的項目不確定性。在可能的情況下當然要對所有可能情況都做到有備無(wú)患，但是有的時(shí)候也要冒一定的風(fēng)險，同時(shí)對于風(fēng)險的防范也需要考慮如果防范的成本大于風(fēng)險本身造成的損失和影響，則這種防范是沒(méi)有必要的。

　　九、程序員方面的因素對進(jìn)度的影響

　　程序員方面有兩種常見(jiàn)的心態(tài)影響了進(jìn)度的控制：一是技術(shù)完美主義、二是自尊心。

　　技術(shù)完美主義的常見(jiàn)現象是，有些程序員由于進(jìn)度壓力、經(jīng)驗等方面的原因，會(huì )匆忙先做編碼等具體的事情，等做到一定程度后會(huì )想到一些更好的構思，或者看到一些更好的技術(shù)的介紹，或者是覺(jué)得外部構架可以更加美化，或者是覺(jué)得內部構架可以更加優(yōu)化，這樣他們會(huì )私下或公開(kāi)對軟件進(jìn)行調整，去嘗試一下新的技術(shù)。而是否使用這些新的技術(shù)對完成項目本身的目標并沒(méi)有影響，相反可能帶來(lái)不確定的隱患。這種做法不是以用戶(hù)的需求為本、或以項目團隊的總體目標為本，可能對軟件開(kāi)發(fā)進(jìn)度造成較大的影響。

　　自尊心的常見(jiàn)想象是，有些程序員在遇到一些自己無(wú)法解決的問(wèn)題時(shí)，傾向于靠自己摸索，而不愿去問(wèn)周?chē)切┙?jīng)驗更為豐富的人。有些人也許會(huì )通過(guò)聊天室等方式匿名地向別人求教。如果運氣好會(huì )很快地解決，否則要花很多實(shí)踐摸索。而如果向周?chē)娜饲蠼?，可能摸索幾天的?wèn)題別人早就解決了。

　　十、未考慮軟件開(kāi)發(fā)過(guò)程的循環(huán)、迭代特性

　　對軟件開(kāi)發(fā)的各個(gè)過(guò)程分類(lèi)過(guò)于精細，制定進(jìn)度計劃時(shí)各項工作過(guò)于緊湊、沒(méi)有彈性，造成的后果是，定期提交項目進(jìn)度階段報告的制度只有在表面上起到效果，按照計劃的時(shí)間表提交階段成果也只是在表面上起到效果。因為“上有政策、下有對策”，強行的規定會(huì )使人產(chǎn)生一些錯誤的認識：如在項目計劃中“規定”某個(gè)時(shí)間只能做某某類(lèi)別的事情，那么嚴格執行的后果就是編碼階段就不能修改文檔;另外錯誤的“里程碑”概念可能會(huì )使大家輕易地相信上一個(gè)階段的工作成果都是“通過(guò)評審”最終定稿了，而實(shí)際上可能只是因為時(shí)間到了該提交的人提交、該評審的人評審了。

　　如果上下階段是不同的人就根本不會(huì )去檢查其中是否還有錯誤;如果上下階段是同一個(gè)人，就可能非正式地修改上一階段的錯誤，但占用的時(shí)間和精力卻是下一階段的，并且這樣的修改時(shí)沒(méi)有記錄的。這樣關(guān)于階段進(jìn)度控制的措施實(shí)際上只是在表面上有效。最為普遍的情況是，用戶(hù)在合同中限定了提交軟件系統的時(shí)間，實(shí)際上這個(gè)時(shí)間對完成項目任務(wù)來(lái)說(shuō)是遠遠不夠的，但計劃只能按照合同來(lái)進(jìn)行，所以要不用戶(hù)讓步，要不只能按照時(shí)間的約定提交實(shí)際上還未完成的軟件系統，完成系統的安裝，但這時(shí)候的“完成階段任務(wù)”只是一個(gè)表面現象，系統雖然安裝了，但可能是沒(méi)有經(jīng)過(guò)嚴格徹底測試的，也可能是只完成了部分的功能，省略了某些功能，有些是整塊功能省略，有的是省略了某些功能的某個(gè)過(guò)程，如數據錄入里面隱含的數據錄入前缺省值設置、數據錄入檢驗等功能，而是實(shí)現了比較粗糙的功能。這樣，系統交付并不意味著(zhù)項目的完成，而在項目交付之后還要花更多的時(shí)間。

　　十一、其他因素

　　以上這些因素是影響項目進(jìn)度的幾個(gè)主要方面，除此之外還有很多其他的影響因素。其實(shí)最主要的因素還是人的因素，這里的人包括所有與項目相關(guān)的人。項目經(jīng)理的素質(zhì)、管理者的水平、用戶(hù)的因素、項目成員的因素等等，都會(huì )對項目進(jìn)度造成影響，這是因為由于軟件開(kāi)發(fā)的特性。因為篇幅有限無(wú)法一一列舉，只能在此分析一些常見(jiàn)的因素。

　　不可否認，軟件開(kāi)發(fā)項目進(jìn)度可控性還是帶有一定運氣成分的。特別是需要用戶(hù)配合的那些軟件開(kāi)發(fā)項目，其可控性與用戶(hù)的成熟度、軟件應用領(lǐng)域的成熟程度和行業(yè)標準規范的完備程度有很大關(guān)系。關(guān)于可控性方面會(huì )涉及到一些與客戶(hù)打交道經(jīng)驗，雖然我們說(shuō)，顧客是上帝、以顧客為中心，但并不是說(shuō)我們要把主導權交給他們，而關(guān)鍵是我們如何去主導、引導、把握。因此，項目控制的好壞與相關(guān)人員人際關(guān)系方面的經(jīng)驗也有關(guān)系。

　　盡管存在很多不可控的因素，我們的任務(wù)是首先分清哪些是可以控制的，哪些是我們不能控制的。項目經(jīng)理一是要盡量擴大可控的領(lǐng)域，減少不可控的領(lǐng)域，二是不要在“不可控”上花太多時(shí)間，而是多花一些時(shí)間把可控的工作控制好，做好防范措施，減輕不可控因素對項目進(jìn)度的影響。

　　項目進(jìn)入實(shí)施階段后，項目經(jīng)理的幾乎所有的活動(dòng)都是圍繞進(jìn)度展開(kāi)的。進(jìn)度控制的目標與成本控制的目標和質(zhì)量控制的目標是對立統一的關(guān)系。項目的進(jìn)度、質(zhì)量和成本構成一個(gè)相互制約的三角關(guān)系，需要項目經(jīng)理去平衡。