網站專案管理－如何做好需求分析

前言

    隨著技術的不斷髮展和使用者對網站功能性的需求不斷提高，如今網站項目的設計已經不能再僅僅簡單地利用靜態Html檔案來實現，與前幾年網站設計由一兩名網頁設計師自由的創作相比，網站項目的設計和開發越來越像一個軟體工程，也越來越複雜，網站項目的設計和開發進入了需要強調流程和分工的時代，建立規範的、有效、健壯的開發機制，才能適應使用者不斷變化的需要，達到預期的計劃目標。

    網站專案管理（WPM）的含義為WebbasedProjectManagement，即以Web應用程式為主要表現方式的架構來進行的項目設計及管理，這樣的架構中包含了瀏覽器、網路和Web伺服器等關鍵主體，主要體現在網站設計、以瀏覽器為用戶端的Web應用程式開發（例如資訊類網站、網上商店、虛擬郵局、客戶關係管理。）等專案管理中。

    在本文中，筆者將網站專案管理（WPM）與軟體工程的統一過程管理（RUP）進行參照比較，並結合實際工作經驗，力求將網站工程管理（WPM）的角色、分工、流程進行完整的闡述，使網站專案管理逐漸走向正常化。

    按照筆者的經驗，網站專案管理可以分為以下七個階段進行控制：
    1.需求分析及變更管理
    2.項目模型及商務程序分析
    3.系統分析及軟體建模
    4.介面設計、互動設計及程式開發
    5.系統測試和文檔編寫
    6.客戶培訓、支援人員和售後服務
    需要說明的是，這些階段雖然具有一定的延續性，但是並非完全隔斷的，例如需求變更管理和測試工作、文檔編寫都是貫穿整個項目過程的，許多工作時交叉進行或同時進行的。

    如何做好需求分析及變更管理？

    業務員與客戶進行的溝通，撰寫需求分析報告是項目展開的基礎。項目是以客戶的需求為中心，而不是為技術而遷就需求。
    本章包括以下內容：
    一.讓客戶暢所欲言，羅列出所有的需求
    二.透過現象分析潛在的需求
    三.利用自然的語言描述項目模型
    四.利用和圖表將使用者的需求表現出來。
    五.什麼人要看需求分析報告？
    六.建立需求變更日誌，製作新版本的需求分析報告。
    七.本階段重點工作角色
    八.總結
    
    一：讓客戶暢所欲言，羅列出所有的需求

    讓使用者將所有的想法儘可能的闡述清楚，並把所有的要求羅列出來，不要遺漏。這時候不應該害怕"勾引"起客戶的潛在需求而增加設計開發的工作量，從而被今後客戶無止境的變更拖入泥潭，直接明白地跟客戶把問題和要求一條條地列出來，把條理、歸納、分析先都扔到一邊去，將使用者最原始、最完整的要求準確地記錄下來就完成了第一步的工作。

    很明顯，假如客戶的需求做的都不完整，隨時可能會產生意想之外的變更，甚至這個變更會破壞已經做的模型及結構，那麼這個項目從開始就註定了會失敗；比如網站所有的功能都實現了，本地測試起來也沒有什麼問題了，但是你卻不知道客戶的系統是要承受每天100萬獨立IP的訪問，而你原來想當然的以為了不起就是1萬獨立IP訪問的訪問流量，稍微有經驗的開發人員都會明白這樣的設計是個災難，無論是應用伺服器、資料庫還是程式全部要重新開發！

    二：透過現象分析潛在的需求

    很多情況下客戶並非專業人士，在他們滔滔不絕的描述中不能指望他們協助我們整理出重點和技術難關，這需要我們去為客戶進行分析、歸納和整理，尤其是客戶談的不多卻又是技術上實現難度和強度很高的地方特別值得注意。

    客戶往往對需求的概念是非常模糊的，大多時候給出的需求都是籠統而且尺度難以控制的，這就要求業務人員在傾聽了客戶的詳細說明以後，協助客戶進行整理和分析，同時預測客戶在開發過程中變更及今後應用中可能進行修改升級的潛在需求。

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

    筆者曾負責一個大型新聞網站的設計，當客戶拿著將近五十頁厚的一本設計要求報告時，我發現有四十頁的內容對程式開發來說都是重複的，而在其中一頁的角落卻畫了個"搜尋其他網站相關新聞"的按鈕，並且沒有做任何說明，僅僅這10個字所完成的工作量完全頂的上其他整整四十頁重複贅述所做的工作，客戶完全不知道這個要求引發的問題實際就是一個搜尋引擎的開發，通過協商，客人同意了修改成站內搜尋的引擎。

    三：利用自然的語言描述項目模型

    在業務員與客戶進行溝通和調查時撰寫的需求分析，儘可能用自然的語言進行描述，雖然客戶的水平和資曆有所不同，但是最自然的描述能夠使項目開發的各個成員都能清楚地理解需求含義，不至於在理解上產生偏差。對客戶而言，這樣的模型描述最接近真實，容易參與修訂，並能以此為測試和驗收的依據。

    請比較以下兩份關於需求的描述，
    "使用者在訪問首頁的時候可以在點擊’客戶通道’按鈕，彈出填寫’使用者名稱’和’密碼’的視窗，輸入正確後在新視窗開啟客戶通道的首頁，在該頁顯示所有可操作的功能的導航條和最新的導讀新聞連結清單"
    "網站分為公開和加密兩種狀態，通過身分識別驗證機制使特有的使用者可以訪問到加密資訊，並提供不同於普通使用者的功能。"
    前段描述我們就很容易想象的出來設計完成的網站是什麼樣子，而後一段的描述可能會做出無數不同的版本，造成對需求理解的歧意。

    四：利用和圖表將使用者的需求表現出來。

    需求分析無論文字上怎麼樣表述都還是抽象的，對客戶而言理解畢竟是困難的，將基本確定的需求製作出是最直觀有效。

    製作可以有很多種方式，用PowerPoint或Visio製作流程示意，用Html文檔製作介面示意都是可行的，最簡單利用畫圖和Word表格方式也完全可以，關鍵是利用將客戶的需求和即將開始設計的系統體現起來，在進行系統分析和程式開發之前，雙方對今後要完成的產品就能夠有直觀的認識，換言之，就是在產品還沒有真正進入開發階段的時候，雙方就對工作的結果達成統一的意見，這將大大地減輕需求變更所帶來的困擾，同時客戶更容易地參與到項目的開發過程，保證項目往正確的方向進行。

    在RUP中有這樣的描述：
    "利用電影、卡通、圖片、表格和動畫片等製作開始，告訴我們使用者是誰，要發生什麼事情，如何發生。
    以方便使用的方式協助收集並改進使用者需求。
    鼓勵更有創造性、更加創新的設計解決方案。
    鼓勵團隊複審，並避免所有人都不希望出現的特徵。
    確保以可理解、直觀的方式實施特徵。
    使訪談過程變得輕鬆，避免出現訪談沒有結果的現象。
    簡單地說，製作就是使用工具向使用者(主角)說明（有時是動畫示範）系統如何適應組織的需要，並表明系統將如何運轉。協調員將初始示意板展示給小組，小組成員提供意見。之後，在舉辦研討班期間，示意板也進行"即時"演化。所以，您需要一種可以輕鬆更改示意板的畫圖工具。為了避免分散注意力，一般最好使用簡單的工具，比表、白板或PowerPoint。"

    五：什麼人要看需求分析報告

    專案經理、系統分析員、開發經理、互動設計師、測試人員、文檔人員包括客戶代表都應該看需求分析，並進行共同的討論，達成一致的意見。

    我們經常會遇到業務人員辛辛苦苦談下來的項目，對開發人員來說卻是難以實現的，而技術人員設計的產品卻常常得不到客戶的認可，甚至發生糾紛，因此參與項目開發的人員都應該對這份需求有統一清晰的認識，並根據自己的工作對需求提出意見，通過與客戶的溝通修訂，最終確定項目實現的目標。

    例如：
    專案經理通過需求分析才能組建所需要的團隊包括配置工作環境，制定開發週期。
    開發週期的限制和功能上的要求可能會影響到程式員採用什麼樣的語言和工具進行編寫；
    操作使用者的技能水平將影響到互動設計師進行前台設計時做到什麼樣的精度；
    介面設計人員根據項目的性質和定位確定表現方式。
    測試人員瞭解測試環境和條件後才能對項目品質進行跟蹤和檢測；
    通過下表，我們可以看的出不同角色根據需求的變更所進行的工作流程：
    

    六：建立需求變更日誌，製作新版本的需求分析報告

    儘管我們費了許多功夫在需求分析進行了最大可能的努力，但幾乎可以肯定的是，這份需求分析在開發過程中一定會發生變化，也許是出自客戶的遺漏，也可能是在開發過程中被激發出來的，這種變更有時是如此的頻繁和瑣碎，以至於往往不能將變更及時反饋到項目的各個角色中，那麼做好需求變更日誌就顯得非常重要。

    在需求分析後面附上變更日誌，並將修改後的需求分析製作成新版本，保留每次更改過的版本，而不是覆蓋，這樣就比較容易地跟蹤到需求變更過程中所帶來的工作調整。

    在新版本的需求分析中，將變更多部分用特殊方式表明出來，並在日誌中記錄變更多重的明細。
    關於需求分析和變更管理可以參照示意：
    

    七：本階段重點工作角色

    在需求分析和變更管理的過程中，工作量最大的角色為客戶代表、業務員和專案經理。

    客戶代表提出需求，業務員協助整理和分析，專案經理對整個項目進行評估。

    在實際工作中，很多項目失敗的起因都和需求分析有關。客戶代表和業務員通常並非從事技術開發的專業人員，在討論需求的時候往往對項目的技術難度、工作量、時間進度把握不準確，這時候需要專案經理或技術人員進行參謀。

    為了降低項目的風險，提高工作效率，有必要設計規範的需求管理計劃書，協助客戶代表和業務員更好的完成任務。以下提供一份需求管理計劃的模板可作為參考：
    
    

八：總結

    根據筆者的經驗，要儘快做好需求分析掌握以下要點，也許能事半功倍：
    仔細聆聽，羅列客戶的所有要求；
    將需求進行分析，確認可操作的系統模型；
    利用最自然的語言將系統進行描述，使每個開發人員不會產生歧意；
    迅速確定網站的使用者角色；
    比如訪客、會員、重要客戶、前台管理員、網站管理員、業務員等；
    分析確定每個角色的許可權及可操作的功能；
    比如會員可以查看特別資訊、修改個人資訊、退出登陸等；
    前台管理員能夠登入管理系統，能夠發布編輯修改資訊，能夠審查會員資格等；
    網站管理員可以更改欄目、修改網站介面等；
    製作流程圖和將需求表現出來；
    讓客戶參與到的設計中，及時正確的反應出需求變更。
    製作需求變更日誌，保留升級版本，通過版本控制進行需求管理；
    通過需求《管理計劃書》使每個參與人員看到共同的努力目標