網站專案管理－專案模型及業務流程分析（轉）

網站專案管理－專案模型及業務流程分析
網路技術的應用所產生的電子流程工作方式既不能徹底更改傳統的工作流程，也不是對傳統工作流程的簡單複製，而需要對傳統的工作流程進行合理的優化、改進和重組。

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

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

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

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

專案模型及業務流程分析

網路技術的應用所產生的電子流程工作方式既不能徹底更改傳統的工作流程，也不是對傳統工作流程的簡單複製，而需要對傳統的工作流程進行合理的優化、改進和重組。
本章包括以下內容：
一.編寫專案模型文件，使所有人都一目瞭然
二.業務流程分析員進行流程設計
三.介面工程師設計使用者介面原型
四.以使用者為中心的設計思考
五.製作設計計劃書
六.總結

一.編寫專案模型文件，使所有人都一目瞭然

為什麼要製作專案模型文件？
通常使用者提出的需求是凌亂的，不完整的，甚至是不正確的，而且更細緻的需求經常是在專案開發進行中才被挖掘發現的，這對於開發人員來說是個極其困擾的問題。那麼，在進行需求分析後製作專案模型文件，能在專案進入開發前，雙方對即將要開始完成的專案的結果有個共同的認識，並提早暴露可能出現的需求變更，那麼將大大提高開發的效率和質量。

缺乏經驗的專案人員往往在接受任務後迫不及待地進行系統分析和開發，而不願意多一點時間在和客戶反覆推敲專案需求和模型，開發過程中想當然地憑空為客戶做了很多假想，費了九牛二虎之力卻吃力不討好，可想而知，在不知道終點在哪裡的馬拉松比賽中，你會跑到哪裡去？！

因此在確認了客戶的初步需求以後，業務人員應該進行專案模型的設計描述。

首先，我們要定義一下詞彙表，並非每個客戶或者專案小組成員都能夠明白“使用者”、“角色”、“用例”之間的差別，也不見得都能很好地理解“通道”、“前臺”、“後臺”到底是什麼含義，為了讓專案模型文件使每個瀏覽者正確地理解，定義詞彙表是非常需要的，尤其是面對傳統行業初次進行資訊化設計的使用者。

模型描述採用最自然的語言進行描述，這份文件是對需求分析報告的進一步描述。使得客戶代表、專案經理、開發人員對即將展開的專案通過專案模型的描述產生最直觀的印象，並針對關鍵的問題進行討論並達成統一認識，比如功能要求、效能指標、執行環境、投資規模等等。

二.業務流程分析員進行流程設計

業務流程分析員的人員應該善於簡化工作，擔任此角色的人員中必須要有具備廣博的專業領域知識，並且具有良好的溝通技巧。

業務分析人員重點需要協助客戶將需求進行歸納分析，查詢出所有的業務主角，確定業務主角後，每個主角的相關活動及流程應清晰地制定出來，最終設計出邏輯檢視、使用者介面示意圖。比如一個電子商店系統，除了系統管理員、業務經理、業務員、物流配送員、客戶服務人員等角色以外，可能還存在外部協作單位的不同角色，比如供應商、分銷商、廣告客戶，還有購買使用者，甚至再細分為普通消費使用者、VIP消費使用者、集團消費使用者等等，每一類角色參與系統活動時的入口和流程都有所不同，通過邏輯圖和示意圖，業務流程分析員將系統的機構簡要明確地進行描述。

在進行業務流程設計，需要注意以下事項：
*調查使用者網路環境和配置，使架構設計師能夠制定合理可行的系統架構；
*調查使用者偏好和技能水平，這將直接影響到專案開發的深度和使用者介面的設計；
“雖然開發人員和管理人員很容易自認為他們瞭解使用者需要，但實際情況常常不是這樣。人們往往關注於使用者應該如何執行任務，而不是使用者偏好如何執行。多數情況下，偏好問題不僅僅是簡單地認為已掌握了使用者需要，儘管這本身就很值得研究。偏好還要由經驗、能力和使用環境決定。”
*預測並制定系統的效能指標，為測試人員編寫測試計劃提供依據。
許多專案設計中比較重視功能的實現，測試階段看似滿足了客戶的需求，但一旦投入使用的時候，便會發現效能上面臨著一個個瓶頸。客戶由於對專業知識的瞭解程度有限，也往往忽略了這方面要求，因此為了避免日後陷入糾紛，事先預測並制定效能指標是非常重要的。

三.介面工程師建立使用者介面原型

為了在實際系統開發投入之前，建立使用者介面模型是非常重要的，開發原型的成本遠遠低於實際開發的成本，在專案初期，建立完整的使用者介面揭示和測試系統的所有功能和可用性，並能夠使客戶代表參與討論及修改，可以大大提高專案的成功機率。

建立正確可行的原型以後，系統分析、設計及程式碼的編寫都必須遵照原型進行，確保構建的系統是正確的，測試人員和客戶也能夠在開發過程中即實時地參與檢查，可以有效地保障了專案的質量。

根據業務流程分析員所提供的流程分析邏輯圖及示意圖，介面設計工程師開始設計製作使用者介面原型，目前這個階段，對於介面設計人員來說還沒有進入精細設計的階段，所以最重要的是將業務流程完整地表現出來，並和客戶就設計風格，設計規範進行確認和定義。

介面工程師在充分理解客戶需求和所有的業務流程之後，利用合理的佈局設計使用者介面。比如網站的首頁風格、首頁需要顯示的各個元素、導航的分類和表現方法、各類業務角色的入口等等。

在此需要注意的是，使用者介面不僅僅是網站訪問者所瀏覽的介面，也包括了特殊使用者、管理員、業務夥伴等不同的使用者介面，甚至還有提示介面、警告介面、出錯介面等等，設計完整的使用者介面原型不僅能夠使客戶及測試人員更容易明確需求，也對專案的質量起到不可忽視的作用。
四.以使用者為中心的設計思考

無論專案設計開發人員的水平多麼精尖，畢竟不是系統的終端使用者，最大限度地滿足客戶的需要才是關鍵，系統設計人員往往口頭上掛著以使用者為中心的口號，而實際上工作中又在大量地假想，或是出於懶惰或是出於條件限制，對於將來使用系統的不同使用者來說都可能產生意想不到的障礙。

真正做到以使用者為中心，就要先放棄沉澱在腦子裡的經驗和想象，到客戶工作的地方去、觀察記錄客戶如何工作、然後與客戶談論他們的工作。

在團隊擴充訓練中有一項叫做“盲人方陣”的課程，可以想象一群什麼也看不見的人如何把一根長繩子拉成正方形景象嗎？目中無人的人會懂得傾聽和服從嗎？我們不能假設使用者到底是個健全人還是盲人，也不能假想使用者應該會怎麼做不該會怎麼做，只有去仔細觀察和溝通，才能制定出真正符合使用者需要的計劃。

有專家提出：開發人員應決定使用者的組成，並讓使用者儘可能早地涉入，並提出了幾種熟悉使用者、他們的任務以及需求的方法：
*與使用者交談
*到辦公地點拜訪使用者
*觀察使用者工作
*將使用者工作錄影
*瞭解工作組織
*自我嘗試
*使使用者在工作時邊想邊說
*讓使用者參與設計
*在設計小組中包括專家級使用者
*執行任務分析
*利用調查和問卷
*制定可測試的目標
在有可能的情況，在需求和流程設計中努力做到精確、客觀和細緻，不但能保證系統開發的質量和成熟度，也會使你得到客戶高度的滿意和信任，為今後更多的業務合作敞開大門。
五.製作設計計劃書

到了這個階段，可以說掌握了客戶的需求並對計劃實施的系統開發有了清楚地認識，與客戶之間達成了共識，那麼在進入下個階段的工作時，製作設計計劃書是非常必要的。

設計計劃書是全面描述整個系統的全貌，作為系統分析、測試人員工作的基礎，同時也是客戶驗收的標準，作為業務合同的內容之一，因此，應該仔細謹慎地撰寫設計計劃書。

根據專案的不同，設計計劃書的內容或許有所不同，以下筆者提供一份樣本供大家參考，該份樣本基本涵蓋了需要在計劃書中進行確認和描述的核心要素。

六.總結

在本階段的工作過程中，核心的任務是通過上個階段的需求分析，進行專案模型設計和業務流程分析，並製作使用者介面原型得到使用者的確認，最終完成雙方認可的《設計計劃書》，作為下一階段系統設計和軟體建模的依據。

如何高質量地完成業務流程分析階段的工作，筆者總結的經驗如下：
*真正以使用者為中心的設計，到客戶的實際工作環境中觀察和記錄；
*仔細查詢各種業務主角，並表述不同主角的各種操作流程步驟；
*簡化需求，將客戶的需求歸納整理，抓住核心問題；
*細化需求，針對核心問題，模擬使用者角色，進一步確認流程和規範；
*認真制定設計計劃書，為下階段的工作打好基礎；

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7942439/viewspace-21329/，如需轉載，請註明出處，否則將追究法律責任。