強化網(wǎng)站項目管理的需求分析
當(dāng)前位置:點晴教程→知識管理交流
→『 技術(shù)文檔交流 』
1 網(wǎng)站項目管理的特點 [br]網(wǎng)站項目是以web服務(wù)器為主體、瀏覽器為客戶端作為基本架構(gòu)的項目。這樣的架構(gòu)項目中包含web服務(wù)器、瀏覽器和網(wǎng)絡(luò)三個關(guān)鍵主體。網(wǎng)站項目可能是一個網(wǎng)站,也可能是各種web應(yīng)用程序,例如網(wǎng)上商店、虛擬郵局、網(wǎng)絡(luò)辦公管理系統(tǒng)、客戶關(guān)系管理系統(tǒng)等等。網(wǎng)站項目管理就是圍繞著網(wǎng)站項目運用知識、技術(shù)、技能、工具和方法進行組織管理。其特點表現(xiàn)在以下幾個方面: [br]1)涉及的領(lǐng)域很多。狹義地講,網(wǎng)站項目包括了網(wǎng)頁制作、美工設(shè)計、程序編碼、系統(tǒng)及網(wǎng)絡(luò)管理等專業(yè)技術(shù),廣義上又包含了企業(yè)管理、市場營銷、心理學(xué)、廣告學(xué)等更多領(lǐng)域的知識,在項目進行過程中還涉及到項目管理工具、文檔和設(shè)計開發(fā)管理規(guī)范、開發(fā)及測試環(huán)境部署等特殊領(lǐng)域的問題。這對參與項目管理的人員提出了很高的要求。 [br]2)參與項目的角色很多,水平可能參差不齊。對于網(wǎng)站項目管理,最關(guān)鍵的角色是項目經(jīng)理、業(yè)務(wù)流程分析師、用戶界面工程師、系統(tǒng)分析員、編碼人員(程序員)和質(zhì)量控制工程師等。根據(jù)項目的規(guī)模和開發(fā)的深度,由項目經(jīng)理進行角色劃分。假如嚴(yán)格細分,一個大型項目的角色可能達到50個以上,以確保每個細節(jié)都有專業(yè)的人員進行負責(zé)和管理。其中需求分析過程中主要角色有客戶代表、業(yè)務(wù)員、業(yè)務(wù)流程分析師、用戶界面工程師,另外還有項目經(jīng)理、數(shù)據(jù)庫工程師、文檔工程師等參與。 [br][br]3)網(wǎng)絡(luò)應(yīng)用的開發(fā)技術(shù)在日新月異地進步,從而使網(wǎng)站應(yīng)用系統(tǒng)的開發(fā)模式具有多種選擇性,達到同樣的目標(biāo)可以采用很多不同的方式,現(xiàn)代的應(yīng)用系統(tǒng)越來越成為一個龐大的集成方案,需要考慮不同的操作平臺、不同的應(yīng)用服務(wù)器、不同的數(shù)據(jù)庫、不同的編程語言、不同的傳輸介質(zhì)等等,項目管理人員必須了解各種技術(shù)的利弊,幫助用戶選擇高效、廉價并富有前瞻性的方案。 [br]2 需求分析在網(wǎng)站項目管理中的作用及要求 [br]需求分析是一個項目的開端,也是項目建設(shè)的基石。由于以上提出的網(wǎng)站項目的特殊性和行業(yè)覆蓋的廣闊性,以及需求分析的高風(fēng)險性,網(wǎng)站項目需求分析的重要性是不言而喻的,在以往建設(shè)失敗的項目中,80%是由于需求分析的不明確而造成的。因此一個項目成功的關(guān)鍵因素之一,就是對需求分析的把握程度。 [br]在需求分析流程中,需要有客戶代表、業(yè)務(wù)員、業(yè)務(wù)流程分析師、用戶界面工程師等角色參與,業(yè)務(wù)員從客戶代表那里獲得需求,并形成需求報告;業(yè)務(wù)流程分析員從業(yè)務(wù)員那里獲得需求報告,分析生成項目模型報告;界面工程師得到項目模型后設(shè)計制作相應(yīng)的模板和用戶界面原型,最終由客戶代表確認。需求分析所形成的文檔最終達到如下要求。 [br]1)正確性:每個功能必須清楚描寫交付的功能。 [br]2)可行性:確保在當(dāng)前的開發(fā)能力和系統(tǒng)環(huán)境下可以實現(xiàn)每個需求。 [br]3)必要性:功能是否必須交付,是否可以推遲實現(xiàn),是否可以在削減開支情況發(fā)生時被“砍”掉。 [br]4)簡明性:不要使用專業(yè)的網(wǎng)絡(luò)術(shù)語。 [br]5)檢測性:如果開發(fā)完畢,客戶可以根據(jù)需求檢測。 [br]3 網(wǎng)站項目需求分析的一般方法 [br]根據(jù)以往的工程經(jīng)驗,需求分析工作方法,應(yīng)該定位在“三個階段”(也稱“三步法”)。 [br]第一階段:“訪談式”。這一階段是和具體用戶方的領(lǐng)導(dǎo)層、業(yè)務(wù)層人員的訪談式溝通,主要目的是從宏觀上把握用戶的具體需求方向和趨勢,了解現(xiàn)有的組織架構(gòu)、業(yè)務(wù)流程、硬件環(huán)境、軟件環(huán)境、現(xiàn)有的運行系統(tǒng)等等具體情況和客觀信息,建立起良好的溝通渠道和方式。針對具體的職能部門以及各委辦局,最好能指定本次項目的接口人。 [br]實現(xiàn)手段:訪談、調(diào)查表格。 [br]輸出成果:調(diào)查報告、業(yè)務(wù)流程報告。 [br]第二階段:“誘導(dǎo)式”。這一階段是在承建方已經(jīng)了解了具體用戶方的組織架構(gòu)、業(yè)務(wù)流程、硬件環(huán)境、軟件環(huán)境、現(xiàn)有的運行系統(tǒng)等等具體實際和客觀信息的基礎(chǔ)上,結(jié)合現(xiàn)有的硬件、軟件實現(xiàn)方案,做出簡單的用戶流程頁面,同時結(jié)合以往的項目經(jīng)驗對用戶采用誘導(dǎo)式、啟發(fā)式的調(diào)研方法和手段,和用戶一起探討業(yè)務(wù)流程設(shè)計的合理性、準(zhǔn)確性,界面的便易性、習(xí)慣性。用戶可以操作簡單演示的demo,來感受一下整個業(yè)務(wù)流程的設(shè)計合理性、準(zhǔn)確性等等問題,及時地提出改進意見和改進方法。 [br]實現(xiàn)手段:拜訪(誘導(dǎo))、原型演示。 [br]輸出成果:調(diào)研分析報告、原型反饋報告、業(yè)務(wù)流程報告。 [br]第三階段:“確認式”。這一階段是在上述兩個階段成果的基礎(chǔ)上,進行具體的流程細化、數(shù)據(jù)項的確認階段,這個階段承建方必須提供原型系統(tǒng)和明確的業(yè)務(wù)流程報告、數(shù)據(jù)項表,并能清晰地向用戶描述系統(tǒng)的業(yè)務(wù)流設(shè)計目標(biāo)。用戶方可以通過審查報告來提出反饋意見,并對已經(jīng)可接受的報告、文檔簽字確認。 [br][br]實現(xiàn)手段:拜訪(回顧、確認),提交業(yè)務(wù)流程報告、數(shù)據(jù)項表;原型演示系統(tǒng)。 [br]輸出成果:需求分析報告、數(shù)據(jù)項、業(yè)務(wù)流程報告、原型系統(tǒng)反饋意見(后三者可以統(tǒng)一歸入需求分析報告中,提交用戶方、監(jiān)理方進行確認和存檔)。 [br]整體來講,需求分析的三個階段是需求調(diào)研中不可忽視的一個重要部分,三個階段或者說三步法的實施和采用,對用戶和承建方都同樣提供了項目成功的保證。[br]4 網(wǎng)站項目需求分析的注意事項和技巧 [br]項目的整體風(fēng)險往往表現(xiàn)在需求分析不明確、業(yè)務(wù)流程不合理,導(dǎo)致用戶不習(xí)慣或不愿意去用承建方的軟件。承建方和客戶方都要重視需求分析的重要性。為更好地把握用戶的需求和方向,應(yīng)該采用必要的手段和方法來進行需求調(diào)研。 [br]4.1 挖掘用戶需求 [br]鼓勵用戶將所有的想法盡可能地闡述清楚,并把所有的要求羅列出來。這時候不必擔(dān)心引起客戶的潛在需求而增加設(shè)計開發(fā)的工作量,應(yīng)直接明白地跟客戶把問題和要求一條條地列出來,把條理、歸納、分析先都放到一邊,將用戶最原始、最完整的要求準(zhǔn)確地記錄下來。 [br]很多情況下客戶并非專業(yè)人士,在他們的描述中很難凸現(xiàn)重點和技術(shù)難關(guān),這需要我們?nèi)榭蛻暨M行分析、歸納和整理,尤其是客戶談的不多卻又是技術(shù)上實現(xiàn)難度和強度很高的地方特別值得注意??蛻敉鶎π枨蟮母拍钍欠浅D:?,大多時候給出的需求都是籠統(tǒng)而且尺度難以控制的,這就要求業(yè)務(wù)人員在傾聽了客戶的詳細說明以后,幫助客戶進行整理和分析,預(yù)測客戶在開發(fā)過程中變更及今后應(yīng)用中可能進行修改升級的潛在需求。 [br]論文強化網(wǎng)站項目管理的需求分析來自 [br][br]比如在為客戶設(shè)計辦公自動化系統(tǒng)的時候,也許就要為客戶預(yù)留將來與他們的業(yè)務(wù)單位進行交互的通道;在設(shè)計郵件系統(tǒng)的時候要考慮可能會需要廣告管理服務(wù)器;設(shè)計網(wǎng)絡(luò)電子商店時需考慮今后增加庫存產(chǎn)品進銷存統(tǒng)計分析等等;限于時間和財力的考慮,客戶通常能夠接受分階段實施的開發(fā)過程,在需求分析時,提早為客戶設(shè)想到今后的需求變更除了使項目開發(fā)更加順利以外,也為今后業(yè)務(wù)的進一步深入打下了更好的基礎(chǔ)。 [br]4.2 利用自然的語言和圖表描述項目模型 [br]在業(yè)務(wù)員與客戶進行溝通和調(diào)查時撰寫的需求分析,盡可能用自然語言或形式化語言來描述,還可以添加圖形表述方式和模型表征方式。雖然客戶的水平和資歷有所不同,但是最自然的描述能夠使項目開發(fā)的各個成員都能清楚地理解需求含義,不至于在理解上產(chǎn)生偏差。對客戶而言,這樣的模型描述最接近真實,容易參與修訂,并能以此為測試和驗收的依據(jù)。制作示意圖可以有很多種方式,關(guān)鍵是利用示意圖將客戶的需求和即將開始設(shè)計的系統(tǒng)體現(xiàn)出來。在進行系統(tǒng)分析和程序開發(fā)之前,雙方對今后要完成的產(chǎn)品就能夠有直觀的認識,換言之,就是在產(chǎn)品還沒有真正進入開發(fā)階段的時候,雙方就對工作的結(jié)果達成統(tǒng)一的意見,這將大大地減輕需求變更所帶來的困擾,同時客戶更容易地參與到項目的開發(fā)過程中。 [br]4.3 需求分析要共同參與各施其職 [br]項目經(jīng)理、系統(tǒng)分析員、開發(fā)經(jīng)理、交互設(shè)計師、測試人員、文檔人員包括客戶代表都應(yīng)該看需求分析,并進行共同討論,達成一致意見。參與項目開發(fā)的人員都應(yīng)該對這份需求有統(tǒng)一清晰的認識,并根據(jù)自己的工作對需求提出意見,通過與客戶的溝通修訂,最終確定項目實現(xiàn)的目標(biāo)。這樣可以盡量避免業(yè)務(wù)人員與開發(fā)人員、承建方和客戶方之間發(fā)生不必要的糾紛。 [br]例如:項目經(jīng)理通過需求分析才能組建所需要的團隊包括配置工作環(huán)境,制定開發(fā)周期;開發(fā)周期的限制和功能上的要求可能會影響到程序員采用什么樣的語言和工具進行編寫;操作用戶的技能水平將影響到交互設(shè)計師進行前臺設(shè)計時做到什么樣的精度;界面設(shè)計人員根據(jù)項目的性質(zhì)和定位確定表現(xiàn)方式;測試人員了解測試環(huán)境和條件后才能對項目質(zhì)量進行跟蹤和檢測。 [br]4.4 將需求變更置于可控狀態(tài) [br]需求的變更幾乎是不可避免的,也許是出自客戶的遺漏,也可能是在開發(fā)過程中被激發(fā)出來的。如何以可控的方式管理網(wǎng)站項目需求的變更,對于項目的順利進行有著重要的意義。如果匆匆忙忙地完成用戶調(diào)研與分析,則往往意味著不穩(wěn)定的需求。所以需求管理要保證需求分析各個活動都得到了充分的執(zhí)行。 [br]為了將變更及時反饋到項目的各個角色中,做好需求變更日志就顯得非常重要。在需求分析后面附上變更日志,并將修改后的需求分析制作成新版本,保留每次更改過的版本,而不是覆蓋,這樣就比較容易地跟蹤到需求變更過程中所帶來的工作調(diào)整。在新版本的需求分析中,將變更部分用特殊方式表示出來,并在日志中記錄變更明細。 [br]4.5 評審需求文檔 [br]需求文檔完成后,需要經(jīng)過正式評審,以便作為下一階段工作的基礎(chǔ)。一般的評審分為用戶評審和同行評審兩類。用戶和開發(fā)方對于軟件項目內(nèi)容的描述,是以需求規(guī)格說明書作為基礎(chǔ)的;用戶驗收的標(biāo)準(zhǔn)則是依據(jù)需求規(guī)格說明書中的內(nèi)容來制訂,所以評審需求文檔時用戶的意見是第一位的。而同行評審的目的,是在軟件項目初期發(fā)現(xiàn)那些潛在的缺陷或錯誤,避免這些錯誤和缺陷遺漏到項目的后續(xù)階段。
該文章在 2010/7/3 16:15:49 編輯過 |
關(guān)鍵字查詢
相關(guān)文章
正在查詢... |