1998年，互聯網火了，新鮮出爐的網蟲在網上發郵件、上BBS，立刻成了新潮一派；
1999年，個人主頁火了，啃幾行HTML、扒弄點圖片，搗鼓出個人站點就成“大蝦”了；
2000年，Dotcom火了，門戶、聊天、游戲、社區花樣百出，混個斑竹網管當當，頓時風光無限；
2001年，網絡應用火了，買賣東西、拉拉客戶、管管財務，有點技術的家伙開始牛啦；
現在該怎么干？？？
A鏡頭：你被老板安排負責信息化建設，是不是像老虎咬刺猬一樣無從下口？
B鏡頭：你希望請別人設計一個網站，他們是不是會敷衍了事，蒙你一把？
C鏡頭：有一個誘人的項目擺在面前，到最后是不是搞得一團糟，反而倒貼老本？
到底該怎么辦？？？
從現在開始，一起出發去找我們的新奶酪吧。這個奶酪的名字叫“網站項目管理”。
網站項目：即以Web服務器為主體、瀏覽器為客戶端作為基本架構的項目。這樣的架構項目中包含Web 服務器、瀏覽器和網絡三個關鍵主體。網站項目可能是一個網站，也可能是各種Web應用程序，例如網上商店、虛擬郵局、網絡辦公管理系統、客戶關系管理系統等等。
網站項目管理：是圍繞著網站項目運用知識、技術、技能、工具和方法進行組織管理。其共同特征是：
● 管理由人實現，而非機器；
● 項目具有時間周期，包括啟動時間和結束時間；
● 項目受資源限制，包括人員、資金、場地、設備等；
● 需要計劃、實施和控制；
文章開頭的A鏡頭、B鏡頭和C鏡頭，都可以納入網站項目管理的范疇。以下是網站項目管理的幾個重要概念：
（1）角色：是指項目人員在管理過程中，在特定環境下參與設計的行為代表。
例如項目經理、數據庫工程師、界面設計師、文檔工程師等等。對于網站項目管理，最關鍵的角色是：項目經理，業務流程分析師，用戶界面工程師，系統分析員，編碼人員（程序員），質量控制工程師。根據項目的規模和開發的深度，由項目經理進行角色劃分。假如嚴格細分，一個大型項目的角色可能達到50個以上，以確保每個細節都有專業的人員進行負責和管理。
需要注意的是：角色不等于人。一個人可能充當多個角色，一個角色也可能由許多人組成。比如既是系統分析員，也是測試工程師，或者既是用戶界面工程師，又擔任文檔編寫和管理，一個項目管理小組可能只有三五個人，也可能三五百號人，項目組可大可小，但是項目管理流程需要細致的角色分工。
（2） 流程：在項目過程中執行的工作序列。
每個角色在流程中獲得和輸出相應的工作結果。例如在需求分析流程中，需要有客戶代表、業務員、業務流程分析師、用戶界面工程師等角色參與，業務員從客戶代表那里獲得需求，并形成需求報告；業務流程分析員從業務員那里獲得需求報告，分析生成項目模型報告；界面工程師得到項目模型后設計制作相應的模板和用戶界面原型，最終由客戶代表確認。
（3）業務主角：指與系統交互的各種不同角色。
例如一個網上商店系統，業務主角有普通訪客、下定單會員、管理會員及定單的業務員、網站的商品信息發布人員、商品供應廠家的業務管理人員，物流配送管理員等等。
不管面對多么復雜的網站項目，當我們開始接手時，都可以按照一定的規范和流程進行展開。
網站項目涉及的領域很多，狹義地講包括了網頁制作、美工設計、程序編碼、系統及網絡管理等專業技術，廣義上又包含了企業管理、市場營銷、心理學、廣告學等更多領域的知識，在項目進行過程中還涉及到項目管理工具、文檔和設計開發管理規范、開發及測試環境部署等特殊領域的問題，這對一個項目經理和小組來說是個嚴峻的考驗。
網站設計發展經歷了靜態網站、交互式網站、商業應用、特殊應用的過程，隨著企業對網絡應用的理解和認識，對網站的功能要求越來越復雜，如今網站項目的設計已經不能再僅僅簡單地利用靜態Html文件來實現，與前幾年網站設計由一兩名網頁設計師自由的創作相比，網站項目的設計和開發越來越像一個軟件工程，越來越復雜，網站項目的設計和開發進入了需要強調流程和分工的時代，建立規范的、有效的、健壯的開發機制，才能適應用戶不斷變化的需要，“網站即軟件！”，借鑒軟件工程的思想并可從中尋找出網站項目管理的規律和方法。
網站項目管理分成以下六個階段進行：
一) 需求分析及變更管理；
二) 項目模型及業務流程分析；
三) 系統分析及軟件建模；
四) 界面設計、交互設計及程序開發；
五) 系統測試、部署和文檔編寫；
六) 客戶培訓、技術支持和售后服務。
在每個階段，都必須建立“里程碑”，代表當前工作的階段性成果，并以此作為進入下一階段的標準，實現對項目質量的控制和管理。
第一階段：需求分析及變更管理
假如病人上醫院看病，醫生需要“望、聞、問、切”，耐心仔細地了解完情況后，確定病因后才敢開藥方。而我們在接手一個網站項目的時候，是否真的弄清楚客戶的“病因”？又有多少回等到項目做到一半的時候才發現客戶的需求根本不是這樣的？！
項目本來是為滿足客戶需求目標而進行的，然而結果往往并非如此，因為：“客戶也不知道自己的需求是什么！”在所有不成功的案例中，這句話也許是我們聽的最多的。事實的確如此，這很令人沮喪。慶幸的是網站項目和建筑工程最大的區別在于：大樓建到一半的時候，不可能重新澆注地基，只好推倒重來，但網站項目卻經常在頁面制作、交互設計已經完成的時候還可以更改核心，甚至重新架構。
做好需求分析并建立變更管理機制是保證項目順利完成的原始基礎。
● 重要角色：項目經理，業務員，客戶代表。
● 獲取文檔：通過與客戶的討論等各種渠道獲得需求。
● 里 程 碑：《需求分析報告》
● 注意事項：
☆ 技術是為客戶服務的，采用對用戶最有效和經濟的設計方法才是最好的，而非采用了最好的技術和配置就能設計出最好的方案。所謂最好的技術附帶的潛臺詞往往就是高昂的成本、漫長的開發周期和潛在的不穩定，切忌將客戶當作技術的試驗田。
☆ 記住“需求是一定會變的”，同時不要害怕客戶提需求。如果因為害怕看見大象的全貌而只摸摸大象的腿，怎么也不可能設計出客戶所需要的系統。
☆ 鎖定需求，學會放棄。對超出計劃和目標的需求可以通過制定升級計劃或二期工程，從當前的項目中轉移出去，否則系統可能永遠都在設計開發中，不斷修改和增加，則始終沒有可以發布的版本。
☆ 《需求分析報告》應得到客戶和全體項目小組的共同認同，切忌公說公的理，婆說婆的理，只有所有成員都對目標有清晰一致的認知后，才能最大地提高工作效率。
● 技巧和方法：
☆ 仔細聆聽，羅列客戶的所有要求；
☆ 將需求進行分析，確認可操作的系統模型；
☆ 利用最自然的語言對系統進行描述，使每個開發人員不會產生歧義；
☆ 迅速確定系統的業務主角；
☆ 分析確定每個角色的權限及可操作的功能；
☆ 制作流程圖和示意圖將需求表現出來；
☆ 讓客戶參與到示意圖的設計中，及時正確地反應出需求變更；
☆ 制作需求變更日志，保留升級版本，通過版本控制進行需求管理；
☆ 通過《需求分析報告》使每個參與人員看到共同的努力目標。
在這個階段，我們通過需求分析對項目得到一個初步的認識，并通過編寫《需求分析報告》得到一份客觀的可參照的重要文檔，這是個很好的起點。
客戶的需求基本清楚了，但是客戶并沒有教我們該怎么做。當客戶把球拋給了項目小組，看你如何把球接起來呢。
好吧，下面讓我們繼續……
第二階段：項目模型及業務流程分析
我們需要業務流程分析人員將客戶需求分解和優化，網絡技術的應用所產生的電子流程工作方式既不能徹底更改傳統的工作流程，也不是對傳統工作流程的簡單復制，而是需要對傳統的工作流程進行合理的優化、改進和重組。
用戶提出的需求通常是凌亂的、不完整的，甚至是不正確的，而且，更準確更精細的需求經常是在項目開發進行中才被挖掘發現的。缺乏經驗的項目人員往往在接受任務后迫不及待地進行系統分析和開發，而不愿意多一點時間在和客戶反復推敲項目需求和模型，開發過程中想當然地憑空為客戶做很多假想，只能是費了九牛二虎之力之后吃力不討好。
業務流程分析員重點需要協助客戶將需求進行歸納分析，查找出所有的業務主角，確定業務主角后，將每個主角的相關活動及流程清晰地制定出來，最終設計出業務邏輯圖。
為了使用戶更好地理解系統設計方案，在時間條件許可的情況下，為系統制作用戶界面原型圖是非常有效的辦法。在尚未進行開發之前，客戶就能對今后要完成的系統能夠直觀地看到效果，并能根據需要進行調整，將大大提高項目成功的可能性，同時可減設計過程中的更改工作量。
● 重要角色：業務流程分析師，用戶界面工程師，系統分析師。
● 獲取文檔：《需求分析報告》。
● 里 程 碑：《項目模型報告》、《用戶界面原型》、《設計開發計劃書》。
● 注意事項：
☆ 業務流程應符合客戶偏好和習慣，以客戶的環境和技能水平設計系統，切忌以項目小組的喜好隨意設計；
☆ 請客戶和用戶模擬操作，找出盲點和分歧點，問題越早發現越容易處理，損失越��；
☆ 制定性能和功能指標，作為下一階段測試工程師的工作依據�？蛻魧δ艿男枨笙鄬碚f比較敏感和直觀，但是對性能的需求很難提出具體的要求，這就需要系統分析師在這個階段進行明確，并作為系統設計的依據之一。
文章來源于領測軟件測試網 http://www.kjueaiud.com/