導語：網站項目管理分析論文一文來源于網友上傳，不代表本站觀點，若需要原創文章可咨詢客服老師，歡迎參考。

1網站項目管理的特點

網站項目是以Web服務器為主體、瀏覽器為客戶端作為基本架構的項目。這樣的架構項目中包含Web服務器、瀏覽器和網絡三個關鍵主體。網站項目可能是一個網站，也可能是各種Web應用程序，例如網上商店、虛擬郵局、網絡辦公管理系統、客戶關系管理系統等等。網站項目管理就是圍繞著網站項目運用知識、技術、技能、工具和方法進行組織管理。其特點表現在以下幾個方面：

1）涉及的領域很多。狹義地講，網站項目包括了網頁制作、美工設計、程序編碼、系統及網絡管理等專業技術，廣義上又包含了企業管理、市場營銷、心理學、廣告學等更多領域的知識，在項目進行過程中還涉及到項目管理工具、文檔和設計開發管理規范、開發及測試環境部署等特殊領域的問題。這對參與項目管理的人員提出了很高的要求。

2）參與項目的角色很多，水平可能參差不齊。對于網站項目管理，最關鍵的角色是項目經理、業務流程分析師、用戶界面工程師、系統分析員、編碼人員（程序員）和質量控制工程師等。根據項目的規模和開發的深度，由項目經理進行角色劃分。假如嚴格細分，一個大型項目的角色可能達到50個以上，以確保每個細節都有專業的人員進行負責和管理。其中需求分析過程中主要角色有客戶代表、業務員、業務流程分析師、用戶界面工程師，另外還有項目經理、數據庫工程師、文檔工程師等參與。

3）網絡應用的開發技術在日新月異地進步，從而使網站應用系統的開發模式具有多種選擇性，達到同樣的目標可以采用很多不同的方式，現代的應用系統越來越成為一個龐大的集成方案，需要考慮不同的操作平臺、不同的應用服務器、不同的數據庫、不同的編程語言、不同的傳輸介質等等，項目管理人員必須了解各種技術的利弊，幫助用戶選擇高效、廉價并富有前瞻性的方案。

2需求分析在網站項目管理中的作用及要求

需求分析是一個項目的開端，也是項目建設的基石。由于以上提出的網站項目的特殊性和行業覆蓋的廣闊性，以及需求分析的高風險性，網站項目需求分析的重要性是不言而喻的，在以往建設失敗的項目中，80％是由于需求分析的不明確而造成的。因此一個項目成功的關鍵因素之一，就是對需求分析的把握程度。

在需求分析流程中，需要有客戶代表、業務員、業務流程分析師、用戶界面工程師等角色參與，業務員從客戶代表那里獲得需求，并形成需求報告；業務流程分析員從業務員那里獲得需求報告，分析生成項目模型報告；界面工程師得到項目模型后設計制作相應的模板和用戶界面原型，最終由客戶代表確認。需求分析所形成的文檔最終達到如下要求。

1）正確性：每個功能必須清楚描寫交付的功能。

2）可行性：確保在當前的開發能力和系統環境下可以實現每個需求。

3）必要性：功能是否必須交付，是否可以推遲實現，是否可以在削減開支情況發生時被“砍”掉。

4）簡明性：不要使用專業的網絡術語。

5）檢測性：如果開發完畢，客戶可以根據需求檢測。

3網站項目需求分析的一般方法

根據以往的工程經驗，需求分析工作方法，應該定位在“三個階段”（也稱“三步法”）。

第一階段：“訪談式”。這一階段是和具體用戶方的領導層、業務層人員的訪談式溝通，主要目的是從宏觀上把握用戶的具體需求方向和趨勢，了解現有的組織架構、業務流程、硬件環境、軟件環境、現有的運行系統等等具體情況和客觀信息，建立起良好的溝通渠道和方式。針對具體的職能部門以及各委辦局，最好能指定本次項目的接口人。

實現手段：訪談、調查表格。

輸出成果：調查報告、業務流程報告。

第二階段：“誘導式”。這一階段是在承建方已經了解了具體用戶方的組織架構、業務流程、硬件環境、軟件環境、現有的運行系統等等具體實際和客觀信息的基礎上，結合現有的硬件、軟件實現方案，做出簡單的用戶流程頁面，同時結合以往的項目經驗對用戶采用誘導式、啟發式的調研方法和手段，和用戶一起探討業務流程設計的合理性、準確性，界面的便易性、習慣性。用戶可以操作簡單演示的DEMO，來感受一下整個業務流程的設計合理性、準確性等等問題，及時地提出改進意見和改進方法。

實現手段：拜訪（誘導）、原型演示。

輸出成果：調研分析報告、原型反饋報告、業務流程報告。

第三階段：“確認式”。這一階段是在上述兩個階段成果的基礎上，進行具體的流程細化、數據項的確認階段，這個階段承建方必須提供原型系統和明確的業務流程報告、數據項表，并能清晰地向用戶描述系統的業務流設計目標。用戶方可以通過審查報告來提出反饋意見，并對已經可接受的報告、文檔簽字確認。

實現手段：拜訪（回顧、確認），提交業務流程報告、數據項表；原型演示系統。

輸出成果：需求分析報告、數據項、業務流程報告、原型系統反饋意見（后三者可以統一歸入需求分析報告中，提交用戶方、監理方進行確認和存檔）。

整體來講，需求分析的三個階段是需求調研中不可忽視的一個重要部分，三個階段或者說三步法的實施和采用，對用戶和承建方都同樣提供了項目成功的保證。

4網站項目需求分析的注意事項和技巧

項目的整體風險往往表現在需求分析不明確、業務流程不合理，導致用戶不習慣或不愿意去用承建方的軟件。承建方和客戶方都要重視需求分析的重要性。為更好地把握用戶的需求和方向，應該采用必要的手段和方法來進行需求調研。

4.1挖掘用戶需求

鼓勵用戶將所有的想法盡可能地闡述清楚，并把所有的要求羅列出來。這時候不必擔心引起客戶的潛在需求而增加設計開發的工作量，應直接明白地跟客戶把問題和要求一條條地列出來，把條理、歸納、分析先都放到一邊，將用戶最原始、最完整的要求準確地記錄下來。

很多情況下客戶并非專業人士，在他們的描述中很難凸現重點和技術難關，這需要我們去為客戶進行分析、歸納和整理，尤其是客戶談的不多卻又是技術上實現難度和強度很高的地方特別值得注意。客戶往往對需求的概念是非常模糊的，大多時候給出的需求都是籠統而且尺度難以控制的，這就要求業務人員在傾聽了客戶的詳細說明以后，幫助客戶進行整理和分析，預測客戶在開發過程中變更及今后應用中可能進行修改升級的潛在需求。

比如在為客戶設計辦公自動化系統的時候，也許就要為客戶預留將來與他們的業務單位進行交互的通道；在設計郵件系統的時候要考慮可能會需要廣告管理服務器；設計網絡電子商店時需考慮今后增加庫存產品進銷存統計分析等等；限于時間和財力的考慮，客戶通常能夠接受分階段實施的開發過程，在需求分析時，提早為客戶設想到今后的需求變更除了使項目開發更加順利以外，也為今后業務的進一步深入打下了更好的基礎。

4.2利用自然的語言和圖表描述項目模型

在業務員與客戶進行溝通和調查時撰寫的需求分析，盡可能用自然語言或形式化語言來描述，還可以添加圖形表述方式和模型表征方式。雖然客戶的水平和資歷有所不同，但是最自然的描述能夠使項目開發的各個成員都能清楚地理解需求含義，不至于在理解上產生偏差。對客戶而言，這樣的模型描述最接近真實，容易參與修訂，并能以此為測試和驗收的依據。制作示意圖可以有很多種方式，關鍵是利用示意圖將客戶的需求和即將開始設計的系統體現出來。在進行系統分析和程序開發之前，雙方對今后要完成的產品就能夠有直觀的認識，換言之，就是在產品還沒有真正進入開發階段的時候，雙方就對工作的結果達成統一的意見，這將大大地減輕需求變更所帶來的困擾，同時客戶更容易地參與到項目的開發過程中。

4.3需求分析要共同參與各施其職

項目經理、系統分析員、開發經理、交互設計師、測試人員、文檔人員包括客戶代表都應該看需求分析，并進行共同討論，達成一致意見。參與項目開發的人員都應該對這份需求有統一清晰的認識，并根據自己的工作對需求提出意見，通過與客戶的溝通修訂，最終確定項目實現的目標。這樣可以盡量避免業務人員與開發人員、承建方和客戶方之間發生不必要的糾紛。

例如：項目經理通過需求分析才能組建所需要的團隊包括配置工作環境，制定開發周期；開發周期的限制和功能上的要求可能會影響到程序員采用什么樣的語言和工具進行編寫；操作用戶的技能水平將影響到交互設計師進行前臺設計時做到什么樣的精度；界面設計人員根據項目的性質和定位確定表現方式；測試人員了解測試環境和條件后才能對項目質量進行跟蹤和檢測。

4.4將需求變更置于可控狀態

需求的變更幾乎是不可避免的，也許是出自客戶的遺漏，也可能是在開發過程中被激發出來的。如何以可控的方式管理網站項目需求的變更，對于項目的順利進行有著重要的意義。如果匆匆忙忙地完成用戶調研與分析，則往往意味著不穩定的需求。所以需求管理要保證需求分析各個活動都得到了充分的執行。

為了將變更及時反饋到項目的各個角色中，做好需求變更日志就顯得非常重要。在需求分析后面附上變更日志，并將修改后的需求分析制作成新版本，保留每次更改過的版本，而不是覆蓋，這樣就比較容易地跟蹤到需求變更過程中所帶來的工作調整。在新版本的需求分析中，將變更部分用特殊方式表示出來，并在日志中記錄變更明細。

4.5評審需求文檔

需求文檔完成后，需要經過正式評審，以便作為下一階段工作的基礎。一般的評審分為用戶評審和同行評審兩類。用戶和開發方對于軟件項目內容的描述，是以需求規格說明書作為基礎的；用戶驗收的標準則是依據需求規格說明書中的內容來制訂，所以評審需求文檔時用戶的意見是第一位的。而同行評審的目的，是在軟件項目初期發現那些潛在的缺陷或錯誤，避免這些錯誤和缺陷遺漏到項目的后續階段。

5總結

隨著互聯網的飛速發展，Web技術應用日益廣泛，網站的規模和復雜性不斷增加，網站項目的設計和開發進入了需要強調流程和分工的時代，軟件工程方法將越來越多地介入到網站項目的設計和開發中。建立規范的、有效的、健壯的開發機制，特別是打好網站項目管理的基石，強化項目的需求分析，將有利于高效、高速、高質量地完成開發任務。