房地產(chǎn)項目管理軟件
當前位置：工程項目OA系統(tǒng) > 房地產(chǎn)OA系統(tǒng) > 相關系統(tǒng) > 房地產(chǎn)項目管理軟件
網(wǎng)站項目管理
前言
隨著技術的不斷發(fā)展和用戶對網(wǎng)站功能性的需求不斷提高，如今網(wǎng)站項目的設計已經(jīng)不能再僅僅簡單地利用靜態(tài)Html文件來實現(xiàn)，與前幾年網(wǎng)站設計由一兩名網(wǎng)頁設計師自由的創(chuàng)作相比，網(wǎng)站項目的設計和開發(fā)越來越像一個軟件工程，也越來越復雜，網(wǎng)站項目的設計和開發(fā)進入了需要強調(diào)流程和分工的時代，建立規(guī)范的、有效的、健壯的開發(fā)機制，才能適應用戶不斷變化的需要，達到預期的計劃目標。
網(wǎng)站項目管理（WPM）的含義為Web-based Project Management，即以Web 應用程序為主要表現(xiàn)方式的架構(gòu)來進行的項目設計及管理，這樣的架構(gòu)中包含了瀏覽器、網(wǎng)絡和Web
服務器等關鍵主體，主要體現(xiàn)在網(wǎng)站設計、以瀏覽器為客戶端的Web應用程序開發(fā)（例如信息類網(wǎng)站、網(wǎng)上商店、虛擬郵局、客戶關系管理。）等項目管理中。
在本文中，筆者將網(wǎng)站項目管理（WPM）與軟件工程的統(tǒng)一過程管理（RUP）進行參照比較，并結(jié)合實際工作經(jīng)驗，力求將網(wǎng)站工程管理（WPM）的角色、分工、流程進行完整的闡述，使網(wǎng)站項目管理逐漸走向規(guī)范化。
按照筆者的經(jīng)驗，網(wǎng)站項目管理可以分為以下l六個階段進行控制：
1. 需求分析及變更管理
2. 項目模型及業(yè)務流程分析
3. 系統(tǒng)分析及軟件建模
4. 界面設計、交互設計及程序開發(fā)
5. 系統(tǒng)測試和文檔編寫
6. 客戶培訓、技術支持和售后服務
需要說明的是，這些階段雖然具有一定的延續(xù)性，但是并非完全隔斷的，例如需求變更管理和測試工作、文檔編寫都是貫穿整個項目過程的，許多工作時交叉進行或同時進行的。
（一）如何做好需求分析及變更管理？
業(yè)務員與客戶進行的溝通，撰寫需求分析報告是項目展開的基礎。項目是以客戶的需求為中心，而不是為技術而遷就需求。
本章包括以下內(nèi)容：
一. 讓客戶暢所欲言，羅列出所有的需求
二. 透過現(xiàn)象分析潛在的需求
三. 利用自然的語言描述項目模型
四. 利用示意圖和圖表將用戶的需求表現(xiàn)出來。
五. 什么人要看需求分析報告？
六. 建立需求變更日志，制作新版本的需求分析報告。
七. 本階段重點工作角色
八. 總結(jié)
一：讓客戶暢所欲言，羅列出所有的需求
讓用戶將所有的想法盡可能的闡述清楚，并把所有的要求羅列出來，不要遺漏。這時候不應該害怕"勾引"起客戶的潛在需求而增加設計開發(fā)的工作量，從而被今后客戶無止境的變更拖入泥潭，直接明白地跟客戶把問題和要求一條條地列出來，把條理、歸納、分析先都扔到一邊去，將用戶最原始、最完整的要求準確地記錄下來就完成了第一步的工作。
很明顯，假如客戶的需求做的都不完整，隨時可能會產(chǎn)生意想之外的變更，甚至這個變更會破壞已經(jīng)做的模型及結(jié)構(gòu)，那么這個項目從開始就注定了會失??；比如站點所有的功能都實現(xiàn)了，本地測試起來也沒有什么問題了，但是你卻不知道客戶的系統(tǒng)是要承受每天100萬獨立IP的訪問，而你原來想當然的以為了不起就是1萬獨立IP訪問的訪問流量，稍微有經(jīng)驗的開發(fā)人員都會明白這樣的設計是個災難，無論是應用服務器、數(shù)據(jù)庫還是程序全部要重新開發(fā)！
二：透過現(xiàn)象分析潛在的需求
很多情況下客戶并非專業(yè)人士，在他們滔滔不絕的描述中不能指望他們幫助我們整理出重點和技術難關，這需要我們?nèi)榭蛻暨M行分析、歸納和整理，尤其是客戶談的不多卻又是技術上實現(xiàn)難度和強度很高的地方特別值得注意。
客戶往往對需求的概念是非常模糊的，大多時候給出的需求都是籠統(tǒng)而且尺度難以控制的，這就要求業(yè)務人員在傾聽了客戶的詳細說明以后，幫助客戶進行整理和分析，同時預測客戶在開發(fā)過程中變更及今后應用中可能進行修改升級的潛在需求。
比如在為客戶設計辦公自動化系統(tǒng)的時候，也許就要為客戶預留將來與他們的業(yè)務單位進行交互的通道；在設計郵件系統(tǒng)的時候要考慮可能會需要廣告管理服務器；設計網(wǎng)絡電子商店時今后增加庫存產(chǎn)品進銷存統(tǒng)計分析等等；限于時間財力的考慮，客戶通常能夠接受分階段實施的開發(fā)過程，在需求分析時，提早為客戶設想到今后的需求變更除了使項目開發(fā)更加順利以外，也為今后業(yè)務的進一步深入打下了更好的基礎。
筆者曾負責一個大型新聞網(wǎng)站的設計，當客戶拿著將近五十頁厚的一本設計要求報告時，我發(fā)現(xiàn)有四十頁的內(nèi)容對程序開發(fā)來說都是重復的，而在其中一頁的角落卻畫了個"搜索其他網(wǎng)站相關新聞"的按鈕，并且沒有做任何說明，僅僅這10個字所完成的工作量完全頂?shù)纳掀渌氖撝貜唾樖鏊龅墓ぷ鳎蛻敉耆恢肋@個要求引發(fā)的問題實際就是一個搜索引擎的開發(fā)，通過協(xié)商，客人同意了修改成站內(nèi)搜索的引擎。
三：利用自然的語言描述項目模型
在業(yè)務員與客戶進行溝通和調(diào)查時撰寫的需求分析，盡可能用自然的語言進行描述，雖然客戶的水平和資歷有所不同，但是最自然的描述能夠使項目開發(fā)的各個成員都能清楚地理解需求含義，不至于在理解上產(chǎn)生偏差。對客戶而言，這樣的模型描述最接近真實，容易參與修訂，并能以此為測試和驗收的依據(jù)。
請比較以下兩份關于需求的描述，
"用戶在訪問首頁的時候可以在點擊’客戶通道’按鈕，彈出填寫’用戶名’和’密碼’的窗口，輸入正確后在新窗口打開客戶通道的首頁，在該頁顯示所有可操作的功能的導航條和最新的導讀新聞鏈接列表 "
"站點分為公開和加密兩種狀態(tài)，通過身份驗證機制使特有的用戶可以訪問到加密信息，并提供不同于普通用戶的功能。"
前段描述我們就很容易想象的出來設計完成的網(wǎng)站是什么樣子，而后一段的描述可能會做出無數(shù)不同的版本，造成對需求理解的歧意。
四：利用示意圖和圖表將用戶的需求表現(xiàn)出來。
需求分析無論文字上怎么樣表述都還是抽象的，對客戶而言理解畢竟是困難的，將基本確定的需求制作出示意圖是最直觀有效的。
制作示意圖可以有很多種方式，用PowerPoint或Visio制作流程示意，用Html文檔制作界面示意都是可行的，最簡單利用畫圖和Word表格方式也完全可以，關鍵是利用示意圖將客戶的需求和即將開始設計的系統(tǒng)體現(xiàn)起來，在進行系統(tǒng)分析和程序開發(fā)之前，雙方對今后要完成的產(chǎn)品就能夠有直觀的認識，換言之，就是在產(chǎn)品還沒有真正進入開發(fā)階段的時候，雙方就對工作的結(jié)果達成統(tǒng)一的意見，這將大大地減輕需求變更所帶來的困擾，同時客戶更容易地參與到項目的開發(fā)過程，保證項目往正確的方向進行。
在RUP中有這樣的描述：
"利用電影、卡通、圖片、表格和動畫片等制作示意圖開始，告訴我們用戶是誰，要發(fā)生什么事情，如何發(fā)生。
以用戶友好的方式幫助收集并改進用戶需求。
鼓勵更有創(chuàng)造性、更加創(chuàng)新的設計解決方案。
鼓勵團隊復審，并避免所有人都不希望出現(xiàn)的特征。
確保以可理解、直觀的方式實施特征。
使訪談過程變得輕松，避免出現(xiàn)訪談沒有結(jié)果的現(xiàn)象。
簡單地說，制作示意圖就是使用工具向用戶 (主角) 說明（有時是動畫演示）系統(tǒng)如何適應組織的需要，并表明系統(tǒng)將如何運轉(zhuǎn)。協(xié)調(diào)員將初始示意板展示給小組，小組成員提供意見。之后，在舉辦研討班期間，示意板也進行"實時"演進。所以，您需要一種可以輕松更改示意板的畫圖工具。為了避免分散注意力，一般最好使用簡單的工具，比如圖表、白板或
PowerPoint。"
五：什么人要看需求分析報告
項目經(jīng)理、系統(tǒng)分析員、開發(fā)經(jīng)理、交互設計師、測試人員、文檔人員包括客戶代表都應該看需求分析，并進行共同的討論，達成一致的意見。
我們經(jīng)常會遇到業(yè)務人員辛辛苦苦談下來的項目，對開發(fā)人員來說卻是難以實現(xiàn)的，而技術人員設計的產(chǎn)品卻常常得不到客戶的認可，甚至發(fā)生糾紛，因此參與項目開發(fā)的人員都應該對這份需求有統(tǒng)一清晰的認識，并根據(jù)自己的工作對需求提出意見，通過與客戶的溝通修訂，最終確定項目實現(xiàn)的目標。
例如：
項目經(jīng)理通過需求分析才能組建所需要的團隊包括配置工作環(huán)境，制定開發(fā)周期。
開發(fā)周期的限制和功能上的要求可能會影響到程序員采用什么樣的語言和工具進行編寫；
操作用戶的技能水平將影響到交互設計師進行前臺設計時做到什么樣的精度；
界面設計人員根據(jù)項目的性質(zhì)和定位確定表現(xiàn)方式。
測試人員了解測試環(huán)境和條件后才能對項目質(zhì)量進行跟蹤和檢測；
通過下表，我們可以看的出不同角色根據(jù)需求的變更所進行的工作流程：
六：建立需求變更日志，制作新版本的需求分析報告
盡管我們費了許多功夫在需求分析進行了最大可能的努力，但幾乎可以肯定的是，這份需求分析在開發(fā)過程中一定會發(fā)生變化，也許是出自客戶的遺漏，也可能是在開發(fā)過程中被激發(fā)出來的，這種變更有時是如此的頻繁和瑣碎，以至于往往不能將變更及時反饋到項目的各個角色中，那么做好需求變更日志就顯得非常重要。
在需求分析后面附上變更日志，并將修改后的需求分析制作成新版本，保留每次更改過的版本，而不是覆蓋，這樣就比較容易地跟蹤到需求變更過程中所帶來的工作調(diào)整。
在新版本的需求分析中，將變更多部分用特殊方式表明出來，并在日志中記錄變更多重的明細。
關于需求分析和變更管理可以參照下圖示意：
七：本階段重點工作角色
在需求分析和變更管理的過程中，工作量最大的角色為客戶代表、業(yè)務員和項目經(jīng)理。
客戶代表提出需求，業(yè)務員幫助整理和分析，項目經(jīng)理對整個項目進行評估。
在實際工作中，很多項目失敗的起因都和需求分析有關。 客戶代表和業(yè)務員通常并非從事技術開發(fā)的專業(yè)人員，在討論需求的時候往往對項目的技術難度、工作量、時間進度把握不準確，這時候需要項目經(jīng)理或技術人員進行參謀。
為了降低項目的風險，提高工作效率，有必要設計規(guī)范的需求管理計劃書，幫助客戶代表和業(yè)務員更好的完成任務。
以下提供一份需求管理計劃的模板可作為參考：
文字
隨著技術的不斷發(fā)展和用戶對網(wǎng)站功能性的需求不斷提高，如今網(wǎng)站項目的設計已經(jīng)不能再僅僅簡單地利用靜態(tài)Html文件來實現(xiàn)，與前幾年網(wǎng)站設計由一兩名網(wǎng)頁設計師自由的創(chuàng)作相比，網(wǎng)站項目的設計和開發(fā)越來越像一個軟件工程，也越來越復雜，網(wǎng)站項目的設計和開發(fā)進入了需要強調(diào)流程和分工的時代，建立規(guī)范的、有效的、健壯的開發(fā)機制，才能適應用戶不斷變化的需要，達到預期的計劃目標。
網(wǎng)站項目管理（WPM）的含義為Web-based Project Management，即以Web 應用程序為主要表現(xiàn)方式的架構(gòu)來進行的項目設計及管理，這樣的架構(gòu)中包含了瀏覽器、網(wǎng)絡和Web
服務器等關鍵主體，主要體現(xiàn)在網(wǎng)站設計、以瀏覽器為客戶端的Web應用程序開發(fā)（例如信息類網(wǎng)站、網(wǎng)上商店、虛擬郵局、客戶關系管理。）等項目管理中。
在本文中，筆者將網(wǎng)站項目管理（WPM）與軟件工程的統(tǒng)一過程管理（RUP）進行參照比較，并結(jié)合實際工作經(jīng)驗，力求將網(wǎng)站工程管理（WPM）的角色、分工、流程進行完整的闡述，使網(wǎng)站項目管理逐漸走向規(guī)范化。
按照筆者的經(jīng)驗，網(wǎng)站項目管理可以分為以下l六個階段進行控制：
1. 需求分析及變更管理
2. 項目模型及業(yè)務流程分析
3. 系統(tǒng)分析及軟件建模
4. 界面設計、交互設計及程序開發(fā)
5. 系統(tǒng)測試和文檔編寫
6. 客戶培訓、技術支持和售后服務
需要說明的是，這些階段雖然具有一定的延續(xù)性，但是并非完全隔斷的，例如需求變更管理和測試工作、文檔編寫都是貫穿整個項目過程的，許多工作時交叉進行或同時進行的。
（一）如何做好需求分析及變更管理？
業(yè)務員與客戶進行的溝通，撰寫需求分析報告是項目展開的基礎。項目是以客戶的需求為中心，而不是為技術而遷就需求。
本章包括以下內(nèi)容：
一. 讓客戶暢所欲言，羅列出所有的需求
二. 透過現(xiàn)象分析潛在的需求
三. 利用自然的語言描述項目模型
四. 利用示意圖和圖表將用戶的需求表現(xiàn)出來。
五. 什么人要看需求分析報告？
六. 建立需求變更日志，制作新版本的需求分析報告。
七. 本階段重點工作角色
八. 總結(jié)
一：讓客戶暢所欲言，羅列出所有的需求
讓用戶將所有的想法盡可能的闡述清楚，并把所有的要求羅列出來，不要遺漏。這時候不應該害怕"勾引"起客戶的潛在需求而增加設計開發(fā)的工作量，從而被今后客戶無止境的變更拖入泥潭，直接明白地跟客戶把問題和要求一條條地列出來，把條理、歸納、分析先都扔到一邊去，將用戶最原始、最完整的要求準確地記錄下來就完成了第一步的工作。
很明顯，假如客戶的需求做的都不完整，隨時可能會產(chǎn)生意想之外的變更，甚至這個變更會破壞已經(jīng)做的模型及結(jié)構(gòu)，那么這個項目從開始就注定了會失??；比如站點所有的功能都實現(xiàn)了，本地測試起來也沒有什么問題了，但是你卻不知道客戶的系統(tǒng)是要承受每天100萬獨立IP的訪問，而你原來想當然的以為了不起就是1萬獨立IP訪問的訪問流量，稍微有經(jīng)驗的開發(fā)人員都會明白這樣的設計是個災難，無論是應用服務器、數(shù)據(jù)庫還是程序全部要重新開發(fā)！
二：透過現(xiàn)象分析潛在的需求
很多情況下客戶并非專業(yè)人士，在他們滔滔不絕的描述中不能指望他們幫助我們整理出重點和技術難關，這需要我們?nèi)榭蛻暨M行分析、歸納和整理，尤其是客戶談的不多卻又是技術上實現(xiàn)難度和強度很高的地方特別值得注意。
客戶往往對需求的概念是非常模糊的，大多時候給出的需求都是籠統(tǒng)而且尺度難以控制的，這就要求業(yè)務人員在傾聽了客戶的詳細說明以后，幫助客戶進行整理和分析，同時預測客戶在開發(fā)過程中變更及今后應用中可能進行修改升級的潛在需求。
比如在為客戶設計辦公自動化系統(tǒng)的時候，也許就要為客戶預留將來與他們的業(yè)務單位進行交互的通道；在設計郵件系統(tǒng)的時候要考慮可能會需要廣告管理服務器；設計網(wǎng)絡電子商店時今后增加庫存產(chǎn)品進銷存統(tǒng)計分析等等；限于時間財力的考慮，客戶通常能夠接受分階段實施的開發(fā)過程，在需求分析時，提早為客戶設想到今后的需求變更除了使項目開發(fā)更加順利以外，也為今后業(yè)務的進一步深入打下了更好的基礎。
筆者曾負責一個大型新聞網(wǎng)站的設計，當客戶拿著將近五十頁厚的一本設計要求報告時，我發(fā)現(xiàn)有四十頁的內(nèi)容對程序開發(fā)來說都是重復的，而在其中一頁的角落卻畫了個"搜索其他網(wǎng)站相關新聞"的按鈕，并且沒有做任何說明，僅僅這10個字所完成的工作量完全頂?shù)纳掀渌氖撝貜唾樖鏊龅墓ぷ鳎蛻敉耆恢肋@個要求引發(fā)的問題實際就是一個搜索引擎的開發(fā)，通過協(xié)商，客人同意了修改成站內(nèi)搜索的引擎。
三：利用自然的語言描述項目模型
在業(yè)務員與客戶進行溝通和調(diào)查時撰寫的需求分析，盡可能用自然的語言進行描述，雖然客戶的水平和資歷有所不同，但是最自然的描述能夠使項目開發(fā)的各個成員都能清楚地理解需求含義，不至于在理解上產(chǎn)生偏差。對客戶而言，這樣的模型描述最接近真實，容易參與修訂，并能以此為測試和驗收的依據(jù)。
請比較以下兩份關于需求的描述，
"用戶在訪問首頁的時候可以在點擊’客戶通道’按鈕，彈出填寫’用戶名’和’密碼’的窗口，輸入正確后在新窗口打開客戶通道的首頁，在該頁顯示所有可操作的功能的導航條和最新的導讀新聞鏈接列表 "
"站點分為公開和加密兩種狀態(tài)，通過身份驗證機制使特有的用戶可以訪問到加密信息，并提供不同于普通用戶的功能。"
前段描述我們就很容易想象的出來設計完成的網(wǎng)站是什么樣子，而后一段的描述可能會做出無數(shù)不同的版本，造成對需求理解的歧意。
四：利用示意圖和圖表將用戶的需求表現(xiàn)出來。
需求分析無論文字上怎么樣表述都還是抽象的，對客戶而言理解畢竟是困難的，將基本確定的需求制作出示意圖是最直觀有效的。
制作示意圖可以有很多種方式，用PowerPoint或Visio制作流程示意，用Html文檔制作界面示意都是可行的，最簡單利用畫圖和Word表格方式也完全可以，關鍵是利用示意圖將客戶的需求和即將開始設計的系統(tǒng)體現(xiàn)起來，在進行系統(tǒng)分析和程序開發(fā)之前，雙方對今后要完成的產(chǎn)品就能夠有直觀的認識，換言之，就是在產(chǎn)品還沒有真正進入開發(fā)階段的時候，雙方就對工作的結(jié)果達成統(tǒng)一的意見，這將大大地減輕需求變更所帶來的困擾，同時客戶更容易地參與到項目的開發(fā)過程，保證項目往正確的方向進行。
在RUP中有這樣的描述：
"利用電影、卡通、圖片、表格和動畫片等制作示意圖開始，告訴我們用戶是誰，要發(fā)生什么事情，如何發(fā)生。
以用戶友好的方式幫助收集并改進用戶需求。
鼓勵更有創(chuàng)造性、更加創(chuàng)新的設計解決方案。
鼓勵團隊復審，并避免所有人都不希望出現(xiàn)的特征。
確保以可理解、直觀的方式實施特征。
使訪談過程變得輕松，避免出現(xiàn)訪談沒有結(jié)果的現(xiàn)象。
簡單地說，制作示意圖就是使用工具向用戶 (主角) 說明（有時是動畫演示）系統(tǒng)如何適應組織的需要，并表明系統(tǒng)將如何運轉(zhuǎn)。協(xié)調(diào)員將初始示意板展示給小組，小組成員提供意見。之后，在舉辦研討班期間，示意板也進行"實時"演進。所以，您需要一種可以輕松更改示意板的畫圖工具。為了避免分散注意力，一般最好使用簡單的工具，比如圖表、白板或
PowerPoint。"
五：什么人要看需求分析報告
項目經(jīng)理、系統(tǒng)分析員、開發(fā)經(jīng)理、交互設計師、測試人員、文檔人員包括客戶代表都應該看需求分析，并進行共同的討論，達成一致的意見。
我們經(jīng)常會遇到業(yè)務人員辛辛苦苦談下來的項目，對開發(fā)人員來說卻是難以實現(xiàn)的，而技術人員設計的產(chǎn)品卻常常得不到客戶的認可，甚至發(fā)生糾紛，因此參與項目開發(fā)的人員都應該對這份需求有統(tǒng)一清晰的認識，并根據(jù)自己的工作對需求提出意見，通過與客戶的溝通修訂，最終確定項目實現(xiàn)的目標。
例如：
項目經(jīng)理通過需求分析才能組建所需要的團隊包括配置工作環(huán)境，制定開發(fā)周期。
開發(fā)周期的限制和功能上的要求可能會影響到程序員采用什么樣的語言和工具進行編寫；
操作用戶的技能水平將影響到交互設計師進行前臺設計時做到什么樣的精度；
界面設計人員根據(jù)項目的性質(zhì)和定位確定表現(xiàn)方式。
測試人員了解測試環(huán)境和條件后才能對項目質(zhì)量進行跟蹤和檢測；
通過下表，我們可以看的出不同角色根據(jù)需求的變更所進行的工作流程：
六：建立需求變更日志，制作新版本的需求分析報告
盡管我們費了許多功夫在需求分析進行了最大可能的努力，但幾乎可以肯定的是，這份需求分析在開發(fā)過程中一定會發(fā)生變化，也許是出自客戶的遺漏，也可能是在開發(fā)過程中被激發(fā)出來的，這種變更有時是如此的頻繁和瑣碎，以至于往往不能將變更及時反饋到項目的各個角色中，那么做好需求變更日志就顯得非常重要。
在需求分析后面附上變更日志，并將修改后的需求分析制作成新版本，保留每次更改過的版本，而不是覆蓋，這樣就比較容易地跟蹤到需求變更過程中所帶來的工作調(diào)整。
在新版本的需求分析中，將變更多部分用特殊方式表明出來，并在日志中記錄變更多重的明細。
關于需求分析和變更管理可以參照下圖示意：
七：本階段重點工作角色
在需求分析和變更管理的過程中，工作量最大的角色為客戶代表、業(yè)務員和項目經(jīng)理。
客戶代表提出需求，業(yè)務員幫助整理和分析，項目經(jīng)理對整個項目進行評估。
在實際工作中，很多項目失敗的起因都和需求分析有關。 客戶代表和業(yè)務員通常并非從事技術開發(fā)的專業(yè)人員，在討論需求的時候往往對項目的技術難度、工作量、時間進度把握不準確，這時候需要項目經(jīng)理或技術人員進行參謀。
為了降低項目的風險，提高工作效率，有必要設計規(guī)范的需求管理計劃書，幫助客戶代表和業(yè)務員更好的完成任務。
以下提供一份需求管理計劃的模板可作為參考：
文字