1、前言
軟件項目的特殊性使其開發難度越來越大，各企業、團隊面臨的風險也越來越多，這直接導致目前國內軟件項目成功率較低。對於目前項目中存在的問題，影響比較大的主要有以下幾方面：
1、計劃及過程跟蹤不足
在開發活動中，項目計劃是項目啓動後的頭一件重大事件，但是經常被忽略或者得不到應有的重視。
項目計劃好比是一份項目的交通圖，指導項目準確的達到目標，即使它不是被形成提交客戶的正式文件，也應該是項目組內的規範文檔。可是項目計劃往往只是由項目管理者制定或是在項目管理者的腦子裏，只有項目管理者知道。這樣的項目計劃比較粗糙和模糊，同時由於項目計劃是由項目管理者制定的，項目組的其他成員只能被動的執行。而項目管理者既不可能是項目中的全才，也不可能代替其他成員工作，因此這種得不到成員認可的項目計劃就等於沒有制定項目計劃。
爲什麼每個項目都需要一份項目計劃，並且要形成規範的文檔呢？這是因爲：
第一、通過制定計劃，使得小組成員，對項目有關事項，如資源配備、風險化解、人員安排、時間進度、內外接口等形成共識，形成事先約定，避免事後爭吵不清；
第二、通過計劃，可以使得一些支持性工作以及並行工作及時得到安排，避免因計劃不周造成各子流程之間的相互牽掣。比如測試工具的選擇，人員的培訓都是需要及早計劃和安排的。
第三、可以使項目組人員明確自己的職責，便於自我管理和自我激勵；
第四、計劃可以有效的支持管理，作爲項目管理者、業務經理、QA經理、測試經理們對開發工作跟蹤和檢查的依據；
第五、做好事先計劃，就可以使注意力專心於解決問題，而不用再去想下一步做什麼。
第六、計劃是項目總結的輸入之一，項目總結其實就是把實際運行情況與項目計劃不斷比較以提煉經驗教訓的過程。通過計劃和總結，將項目過程中的經驗和教訓變成公司及項目組成員的知識積累。
同時，許多公司往往也制定了比較周密的計劃，但計劃是計劃，執行是執行。
計劃一旦制定出來，馬上束之高閣，或只作爲應付用戶的工具，對於在實際執行中是否按照計劃及時執行，是否延期，是否超支等，採取的是走一步看一步，走到哪裏算哪裏的管理方法。
實際工作執行項目計劃常常遇到各種困難。有的組織文化中有種觀念認爲計劃是一種約束，反正大家努力往前趕就對了，沒必要自己捆住手腳；另外一種情況是大家沒有按照計劃工作的習慣，計劃雖然做好了，做的時候還是我行我素，項目管理者也沒有維護計劃的習慣，項目開始沒多久，項目管理者就埋頭去解決具體的技術問題，將計劃完全撂到了一邊。
2、需求變更控制不足
作爲軟件開發人員或者軟件系統客戶，相信我們都遭遇過因爲需求變更而需要修改系統的情況，一般說來客戶會要求改變界面，改變操作方式，甚至改變業務，說，當時我是那樣要求的，不過現在我們的業務調整了…這時需要中斷正在進行的工作，需要查證以往的資料，需要修正計劃，需要……。
需求包括業務需求、用戶需求和功能需求。
業務需求（Business Requirement ）反映了組織機構或客戶對系統、產品高層次的目標要求，用戶需求（User Requirement ）描述了用戶使用產品必須完成的任務，功能需求（FunctionalRequirement ）定義了開發人員必須實現的軟件功能。在軟件系統開發過程中，有很多問題都是由於在需求分析階段沒有正確地收集、編寫、協商、修改產品真實需求而產生的，造成這樣的狀況有幾方面的原因:
第一、對需求的理解分歧，當客戶向需求分析人員提出需求的時候往往是通過自然語言來表達的，這樣的表達對於真實的需求來說是一種描述（甚至只是某個角度的描述），遠遠不能保證這樣的描述可以得到百分之百的正確理解，也許在同客戶交流的第一時刻就埋下了理解分歧的種子，打一個比方說客戶說我要的是大象，身子象一堵牆，耳朵象扇子，四條腿象四根柱子，尾巴象繩子，分析人員想，哦，牆、扇子、柱子、繩子這些我都知道，但是真的做出來的時候客戶當然會跳起來了！這是理解分歧的問題，有客戶表述責任、同時也體現了雙方的交流不夠，項目管理者工作中很重要的一項就是“溝通”。項目管理者應該不斷組織協調甚至參與和用戶的溝通。
第二、系統實施時間過長，一個大中型系統的建設可能要延續一段時間，當客戶提出要求之後，他當時並不能看到系統的運行情況，當雙方認爲理解大概沒有分歧的時候（事實上還會有個Deadline ），開發方就開始工作了。當客戶拿到差不多可以試用的產品時他可以實際操作，這時候他就會對系統的界面、操作、功能、性能等有一些切身的體會，有可能提出需求變更要求；
第三、客戶具體情況不同，有可能客戶行業的競爭度高，需要隨時作出調整和反應，那麼他們自然會經常提出需求變更的要求；也有可能客戶所在的行業操作不規範，本身存在很多人爲因素，這時候開發方更是需要隨時準備應變；開發本身要求有可能是來自開發方自身版本升級或性能改進、設計修正的要求出現需求變更，這時更是無法繞開這個問題的了！
所以說就算分析人員和客戶之間不存在理解分歧，客戶對於實際的系統還是會提出一些個人意見，就算沒有個人意見，他們自己的業務會變化或環境發生變化，這些都是無法避免的，所以我們不應該夢想客戶需求不變，當我們開始一個項目的時候就應該意識到，客戶需求變更一定會有的。
那麼對於這樣的現狀，我們該怎麼辦呢？客戶是上帝，難道我們就象以前一樣，跟着客戶的需求不停地修改軟件，到最後工期延長，員工疲憊，成本成倍增長，客戶滿意度降低，原來的設計也會改變得支離破碎，系統難以維護？
2、項目日誌
對於以上的問題，目前，已經有人提出了各種各樣的解決方案，這裏就不過多的加以描述了，在這裏，我只想提出，通過項目日誌，可以有效地降低開發風險，提高項目的成功率。
項目經理必須時刻對項目的狀態有詳細的瞭解，以至於其他人能夠知道項目延遲或者項目超支的原因，以及追加資源的必要性。編輯所有這些數據通常要花費大量時間，因此項目經理常常需要擠出時間來完成這項工作。
創建一個項目日誌是一件非常簡單的事情。你可以使用日誌作爲跟蹤項目問題、行動條款、變更要求和風險的集中管理。項目團隊的所有成員都可以很容易的用一種標準的格式輸入信息，生成報表和查看信息。
下面我就把我們在項目中實際用到的項目日誌模版做一個簡單的介紹。
|
項目日誌 |
||||
|
項目名稱： |
|
編號： |
|
|
|
項目經理： |
|
日期： |
|
|
|
項目階段： |
|
|||
|
進展情況： |
□按計劃進行 □超前計劃 □滯後計劃 |
|||
|
工作量： |
工時 |
|||
|
工作內容： |
|
|
||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
客戶需求 |
回覆 |
|||
|
1 |
|
1 |
|
|
|
2 |
|
2 |
|
|
|
3 |
|
3 |
|
|
|
4 |
|
4 |
|
|
|
5 |
|
5 |
|
|
|
問題： |
|
|||
|
備註： |
|
|||
|
相關文檔： |
|
|||
在這個表中，在項目階段一欄中，項目階段從下面的階段中選擇：
|
項目階段 |
工作內容 |
|
項目範圍規劃 |
確定項目範圍 |
|
|
確定項目資源 |
|
|
項目範圍規劃完成 |
|
需求分析 |
明確需求分析範圍 |
|
|
需求分析調研 |
|
|
起草初步的需求分析報告 |
|
|
項目組審閱需求分析報告 |
|
|
修改需求分析報告 |
|
|
客戶認可需求分析報告 |
|
|
修改項目計劃 |
|
|
項目組審閱項目計劃 |
|
|
客戶認可項目計劃 |
|
|
分析工作完成 |
|
設計 |
制定功能規範 |
|
|
根據功能規範開發原型 |
|
|
審閱功能規範 |
|
|
根據反饋修改功能規範 |
|
|
設計工作完成 |
|
開發 |
審閱功能規範 |
|
|
確定模塊化/分層設計參數 |
|
|
分派任務給開發人員 |
|
|
編寫代碼 |
|
|
開發人員測試(初步調試) |
|
|
開發工作完畢 |
|
測試 |
根據功能規範制定單元測試計劃 |
|
|
根據功能規範制定整體測試計劃 |
|
|
審閱模塊化代碼 |
|
|
測試組件模塊是否符合產品規範 |
|
|
找出不符合產品規範的異常情況 |
|
|
修改代碼 |
|
|
重新測試經過修改的代碼 |
|
|
單元測試完成 |
|
|
測試模塊集成情況 |
|
|
找出不符合規範的異常情況 |
|
|
修改代碼 |
|
|
重新測試經過修改的代碼 |
|
|
整體測試完成 |
|
培訓 |
制定針對最終用戶的培訓規範 |
|
|
制定針對產品技術支持人員的培訓規範 |
|
|
確定培訓方法 |
|
|
編寫培訓材料 |
|
|
研究培訓材料的可用性 |
|
|
對培訓材料進行最後處理 |
|
|
制定培訓機制 |
|
|
培訓材料完成 |
|
文檔 |
制定“幫助”規範 |
|
|
開發“幫助”系統 |
|
|
審閱“幫助”文檔 |
|
|
根據反饋修改“幫助”文檔 |
|
|
制定用戶手冊規範 |
|
|
編寫用戶手冊 |
|
|
審閱所有的用戶文檔 |
|
|
根據反饋修改用戶文檔 |
|
|
文檔完成 |
|
部署 |
確定最終部署策略 |
|
|
確定部署方法 |
|
|
獲得部署所需資源 |
|
|
培訓技術支持人員 |
|
|
部署軟件 |
|
|
部署工作完成 |
|
總結 |
將經驗教訓記錄存檔 |
|
|
編寫項目總結報告 |
|
|
建立軟件維護小組 |
|
|
總結完成 |
項目結束之後，根據項目日誌，可以生成下面的總結表：
|
項目日誌分析表 |
|||
|
項目名稱： |
|
項目編號： |
|
|
項目經理： |
|
日期： |
|
|
項目開始時間： |
|
項目結束時間： |
|
|
階段 |
工作量 |
進展情況 |
|
|
項目範圍規劃 |
|
|
|
|
需求分析 |
|
|
|
|
設計 |
|
|
|
|
開發 |
|
|
|
|
測試 |
|
|
|
|
培訓 |
|
|
|
|
文檔 |
|
|
|
|
部署 |
|
|
|
|
總結 |
|
|
|
3、案例分析
本項目是要在一家電信運營企業構建遠程智能診斷系統。具體的軟件體系結構如下圖所示：
項目計劃
1、項目計劃
在80天的時間裏，用15人的資源，開發出一種能實現企業產品的遠程智能診斷的系統；要求把採集來的產品數據實時可視化和進行診斷，並把數據存於數據庫中以進行進一步更新規則庫。
2、項目工作包分解
爲了分發任務及進行管理，把項目按項目範圍進行詳細分解是必要的步驟。系統的WBS是信息溝通的共同基礎，同時也是系統綜合與控制的手段。遠程智能診斷系統的WBS如下圖所示。
1、項目的進度計劃
在制定出系統的WBS之後，就可規劃系統的進度安排了。遠程智能診斷系統的進度計劃如下表。
4、項目進度控制
在建立了項目基準計劃之後，管理工作就是進行過程的監控，以確保一切按計劃行事。本項目控制過程包括每7天收集一次項目績效的資料，之後把世紀的績效與計劃績效相比較，如果實際比計劃差，則採取糾正措施，同時要縮短監控的時間間隔。如果實際進度滯後於基準計劃，則要更改基準計劃以確保計劃是切實可行的，是最新的。同時把更新的計劃反映到圖示中。
5、項目總結
遠程智能診斷系統的項目總結包括項目經理主持的評估會議、項目經理與部分項目成員的私人會議和確定技術培訓事宜的活動三部分。會議討論的成果全部備案，以資後用。
在這個項目中，項目開發人員應填寫項目日誌，項目日誌如下：
|
項目日誌 |
||||
|
項目名稱： |
遠程智能診斷系統 |
編號： |
2003-002 |
|
|
項目經理： |
XXX |
日期： |
2003年-7-26 |
|
|
項目階段： |
開發 |
|||
|
進展情況： |
□按計劃進行 □超前計劃 □滯後計劃 |
|||
|
工作量： |
32工時 |
|||
|
工作內容： |
調整html頁面 |
|
||
|
編寫後臺類模塊 |
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
客戶需求 |
回覆 |
|||
|
1 |
要求增加分析模塊 |
1 |
需要改動設計，延後工期，不增加 |
|
|
2 |
要求界面修改 |
2 |
可以修改 |
|
|
3 |
|
3 |
|
|
|
4 |
|
4 |
|
|
|
5 |
|
5 |
|
|
|
問題： |
由於XXX離職，導致界面部分無人負責，應儘快增加人員，否則將延誤工期。 |
|||
|
備註： |
|
|||
|
相關文檔： |
|
|||
4、結論
綜上所述，通過項目日誌等手段可以有效降低項目風險，提高項目成功率。