1、前言

軟體專案的特殊性使其開發難度越來越大，各企業、團隊面臨的風險也越來越多，這直接導致目前國內軟體專案成功率較低。對於目前專案中存在的問題，影響比較大的主要有以下幾方面：

1、計劃及過程跟蹤不足

在開發活動中，專案計劃是專案啟動後的頭一件重大事件，但是經常被忽略或者得不到應有的重視。

專案計劃好比是一份專案的交通圖，指導專案準確的達到目標，即使它不是被形成提交客戶的正式檔案，也應該是專案組內的規範文件。可是專案計劃往往只是由專案管理者制定或是在專案管理者的腦子裡，只有專案管理者知道。這樣的專案計劃比較粗糙和模糊，同時由於專案計劃是由專案管理者制定的，專案組的其他成員只能被動的執行。而專案管理者既不可能是專案中的全才，也不可能代替其他成員工作，因此這種得不到成員認可的專案計劃就等於沒有制定專案計劃。

為什麼每個專案都需要一份專案計劃，並且要形成規範的文件呢？這是因為：

第一、通過制定計劃，使得小組成員，對專案有關事項，如資源配備、風險化解、人員安排、時間進度、內外介面等形成共識，形成事先約定，避免事後爭吵不清；

第二、通過計劃，可以使得一些支援性工作以及並行工作及時得到安排，避免因計劃不周造成各子流程之間的相互牽掣。比如測試工具的選擇，人員的培訓都是需要及早計劃和安排的。

第三、可以使專案組人員明確自己的職責，便於自我管理和自我激勵；

第四、計劃可以有效的支援管理，作為專案管理者、業務經理、QA經理、測試經理們對開發工作跟蹤和檢查的依據；

第五、做好事先計劃，就可以使注意力專心於解決問題，而不用再去想下一步做什麼。

第六、計劃是專案總結的輸入之一，專案總結其實就是把實際執行情況與專案計劃不斷比較以提煉經驗教訓的過程。通過計劃和總結，將專案過程中的經驗和教訓變成公司及專案組成員的知識積累。

同時，許多公司往往也制定了比較周密的計劃，但計劃是計劃，執行是執行。

計劃一旦制定出來，馬上束之高閣，或只作為應付使用者的工具，對於在實際執行中是否按照計劃及時執行，是否延期，是否超支等，採取的是走一步看一步，走到哪裡算哪裡的管理方法。

實際工作執行專案計劃常常遇到各種困難。有的組織文化中有種觀念認為計劃是一種約束，反正大家努力往前趕就對了，沒必要自己捆住手腳；另外一種情況是大家沒有按照計劃工作的習慣，計劃雖然做好了，做的時候還是我行我素，專案管理者也沒有維護計劃的習慣，專案開始沒多久，專案管理者就埋頭去解決具體的技術問題，將計劃完全撂到了一邊。

2、需求變更控制不足

作為軟體開發人員或者軟體系統客戶，相信我們都遭遇過因為需求變更而需要修改系統的情況，一般說來客戶會要求改變介面，改變操作方式，甚至改變業務，說，當時我是那樣要求的，不過現在我們的業務調整了…這時需要中斷正在進行的工作，需要查證以往的資料，需要修正計劃，需要……。

需求包括業務需求、使用者需求和功能需求。

業務需求（Business Requirement ）反映了組織機構或客戶對系統、產品高層次的目標要求，使用者需求（User Requirement ）描述了使用者使用產品必須完成的任務，功能需求（FunctionalRequirement ）定義了開發人員必須實現的軟體功能。在軟體系統開發過程中，有很多問題都是由於在需求分析階段沒有正確地收集、編寫、協商、修改產品真實需求而產生的，造成這樣的狀況有幾方面的原因:

第一、對需求的理解分歧，當客戶向需求分析人員提出需求的時候往往是通過自然語言來表達的，這樣的表達對於真實的需求來說是一種描述（甚至只是某個角度的描述），遠遠不能保證這樣的描述可以得到百分之百的正確理解，也許在同客戶交流的第一時刻就埋下了理解分歧的種子，打一個比方說客戶說我要的是大象，身子象一堵牆，耳朵象扇子，四條腿象四根柱子，尾巴象繩子，分析人員想，哦，牆、扇子、柱子、繩子這些我都知道，但是真的做出來的時候客戶當然會跳起來了！這是理解分歧的問題，有客戶表述責任、同時也體現了雙方的交流不夠，專案管理者工作中很重要的一項就是“溝通”。專案管理者應該不斷組織協調甚至參與和使用者的溝通。

第二、系統實施時間過長，一個大中型系統的建設可能要延續一段時間，當客戶提出要求之後，他當時並不能看到系統的執行情況，當雙方認為理解大概沒有分歧的時候（事實上還會有個Deadline ），開發方就開始工作了。當客戶拿到差不多可以試用的產品時他可以實際操作，這時候他就會對系統的介面、操作、功能、效能等有一些切身的體會，有可能提出需求變更要求；

第三、客戶具體情況不同，有可能客戶行業的競爭度高，需要隨時作出調整和反應，那麼他們自然會經常提出需求變更的要求；也有可能客戶所在的行業操作不規範，本身存在很多人為因素，這時候開發方更是需要隨時準備應變；開發本身要求有可能是來自開發方自身版本升級或效能改進、設計修正的要求出現需求變更，這時更是無法繞開這個問題的了！

所以說就算分析人員和客戶之間不存在理解分歧，客戶對於實際的系統還是會提出一些個人意見，就算沒有個人意見，他們自己的業務會變化或環境發生變化，這些都是無法避免的，所以我們不應該夢想客戶需求不變，當我們開始一個專案的時候就應該意識到，客戶需求變更一定會有的。

那麼對於這樣的現狀，我們該怎麼辦呢？客戶是上帝，難道我們就象以前一樣，跟著客戶的需求不停地修改軟體，到最後工期延長，員工疲憊，成本成倍增長，客戶滿意度降低，原來的設計也會改變得支離破碎，系統難以維護？

2、專案日誌

對於以上的問題，目前，已經有人提出了各種各樣的解決方案，這裡就不過多的加以描述了，在這裡，我只想提出，通過專案日誌，可以有效地降低開發風險，提高專案的成功率。

專案經理必須時刻對專案的狀態有詳細的瞭解，以至於其他人能夠知道專案延遲或者專案超支的原因，以及追加資源的必要性。編輯所有這些資料通常要花費大量時間，因此專案經理常常需要擠出時間來完成這項工作。

建立一個專案日誌是一件非常簡單的事情。你可以使用日誌作為跟蹤專案問題、行動條款、變更要求和風險的集中管理。專案團隊的所有成員都可以很容易的用一種標準的格式輸入資訊，生成報表和檢視資訊。

下面我就把我們在專案中實際用到的專案日誌模版做一個簡單的介紹。

在這個表中，在專案階段一欄中，專案階段從下面的階段中選擇：

專案結束之後，根據專案日誌，可以生成下面的總結表：

3、案例分析

專案計劃

1、專案計劃

在80天的時間裡，用15人的資源，開發出一種能實現企業產品的遠端智慧診斷的系統；要求把採集來的產品資料實時視覺化和進行診斷，並把資料存於資料庫中以進行進一步更新規則庫。

2、專案工作包分解

1、專案的進度計劃

在制定出系統的WBS之後，就可規劃系統的進度安排了。遠端智慧診斷系統的進度計劃如下表。

 4、專案進度控制

在建立了專案基準計劃之後，管理工作就是進行過程的監控，以確保一切按計劃行事。本專案控制過程包括每7天收集一次專案績效的資料，之後把世紀的績效與計劃績效相比較，如果實際比計劃差，則採取糾正措施，同時要縮短監控的時間間隔。如果實際進度滯後於基準計劃，則要更改基準計劃以確保計劃是切實可行的，是最新的。同時把更新的計劃反映到圖示中。

5、專案總結

遠端智慧診斷系統的專案總結包括專案經理主持的評估會議、專案經理與部分專案成員的私人會議和確定技術培訓事宜的活動三部分。會議討論的成果全部備案，以資後用。

在這個專案中，專案開發人員應填寫專案日誌，專案日誌如下：

4、結論

綜上所述，通過專案日誌等手段可以有效降低專案風險，提高專案成功率。