也許你是一位專案經理，也許你是一位專案骨幹成員，或者開發小組長。在我發表“如何提高 網頁設計 品質”的這一系列文章後，有許多網友都向我抱怨，說他無法把握整個項目組成員的網頁設計品質。我想，這也是所有項目組普遍存在的問題吧，它通常表現為以下幾個問題：
軟體專案普遍存在的問題
1）新手
任何專案組成員都不可避免地出現新手，他們往往是剛剛從大學畢業的學生。這些新手由於軟體發展時間太短，往往技術不成熟，沒有形成良好的開發習慣，所以編寫網頁設計品質較差，問題很多。他們常常成為項目組的“雞肋”，用多了項目品質無法得到保證，不用則又人手不夠。
2）人員變動
一個維護時間稍長一點兒的軟體專案，人員變動是在所難免的。老員工被調動到其他專案去了，由新員工來接替他們的工作。在我的項目組中，人員調動達到 了90%，唯一沒有調走的就是我自己。新員工在接替老員工進行網頁設計維護，甚至繼續進行新的開發的時，由於對原有網頁設計以及設計思路理解的偏差，也會 出現大量的低劣網頁設計。
3）不規範的網頁設計編寫
即使除去以上兩個問題的影響，項目組成員編寫的網頁設計同樣會出現問題。在專案開發之初，我們往往會制定一個網頁設計編寫的規範，但在專案開發過程 中，許多成員往往會忽視這些網頁設計規範而進行隨意的編寫。隨意地網頁設計編寫會降低網頁設計的可讀性、可維護性和易變更性。那麼，我們應當採用什麼樣的 管理措施，保證網頁設計的規範，提高網頁設計的品質呢？
以上問題，也是我在項目開發中不斷摸索和思考的問題，而一些有經驗的項目經理給出了他們的解決之道，那就是“網頁設計審視”。
什麼是網頁設計審視
網頁設計審視（Web Design Review），又叫“網頁設計審查”，其基本定義就是，在開發人員編寫完自己的網頁設計後，由其他人來審視他寫的網頁設計，從而有效地發現網頁設計中存 在的缺陷。網頁設計審視的一個基本理論就是，當我們越早發現網頁設計存在的缺陷，我們解決缺陷的代價就越低。網頁設計審視往往分成以下一個方面進行審查：
1）網頁設計風格
在項目開發之初，我們往往會制定一個網頁設計編寫的規範，實際上，這個網頁設計規範就包含了整個專案組的網頁設計風格。由於軟體發展人員的設計習慣 不同，如果不統一網頁設計風格，一個項目中的網頁設計將五花八門，如變數和常量的命名、介面與實現類的注釋、何時回車、怎樣縮進等等。一個五花八門的設計 風格，必將為日後的維護與改進帶來困難。我們通過網頁設計審視，一方面督促開發人員按照規範編寫網頁設計，另一方面也使開發人員自身形成良好的編程習慣。 網頁設計風格的審查，由於內容比較單一，我們常常可以通過一些網頁設計審視的工具來自動完成，提高審視的效率。
2）重大缺陷
在一些關於網頁設計審視的文章中，列出了一個常常的單子，描述了網頁設計審視應當著重注意的重大缺陷，它們包括：存在SQL寫入、易受跨站點漏洞攻 擊、緩存區溢出、託管網頁設計等等。項目組可以不斷積累重大缺陷的審查項目，並在每次審查中逐一檢查。重大缺陷審查是一個繁瑣而細緻的工作，如果能編寫或 使用一些審查軟體，可以大大提高我們的審查效率。
3）設計邏輯與思路的審查
我認為，這部分的審查是網頁設計審視中最核心、最有價值的部分。網頁設計風格與重大缺陷的審查，雖然重要但簡單而機械，可以通過軟體自動檢查；而設 計邏輯與思路的審查，卻是複雜而有深度的審查，需要有一定理論深度和編碼經驗的人才能完成，而且對新手尤其重要。前面提到，新手是任何專案組不可避免的問 題。但遺憾的是，許多項目經理的辦法是，只將一些簡單而少量的工作交給新手完成，而將大量複雜的工作交給人數不多的那些老手來完成。這樣的結果是，新手始 終是新手，他們沒有經過足夠的鍛煉；老手累死累活，無法指望新手予以分擔工作。
對於這個問題，我的辦法是，通過網頁設計審視，讓老手去指導新手，讓團隊整體素質得到提高。具體辦法就是，在新手完成編碼以後，讓老手去進行網頁設 計審視，指出新手的問題，指導新手設計。這樣的過程最初可能需要重構，甚至重新編碼。但經過這樣的過程，新手將逐漸熟練，迅速成為老手，使整體團隊素質提 高。
網頁設計審視的形式及優缺點
經過以上的描述，我們可以發現網頁設計審視的優點顯而易見。首先，通過對網頁設計風格與規範的審查，可以大大提高網頁設計的可讀性與可維護性。現在 的軟體，往往需要持續的維護與升級，人員變動也在所難免，因此網頁設計的可讀性與可維護性尤為重要。網頁設計審視是一種鞭策，因為它的存在，督促著開發人 員自覺地規範編碼，養成好的編碼習慣，提高網頁設計品質。一個值得注意的問題是，如果你不去讀別人的網頁設計，永遠不能深刻理解什麼是可讀的網頁設計，而 自己的網頁設計不讓別人去讀並且回饋，也永遠不知道自己的網頁設計是否可讀，即使你是一個編碼多年的老手。網頁設計審視恰恰解決了這個問題，值得你去嘗 試。
其次，網頁設計審視是一次程式師之間的交流。新手可以有更多的機會向老手學習和指導，提高自身的設計水準（應當說這對於他們是非常寶貴的）；老手通 過對新手的指導，整理和昇華自己的設計思路與理論，同時也是對自己另一方面的鍛煉與提高。另外，當你發現並指出了別人的一個問題以後，同時也是在警示自己 不要犯同樣的錯誤，這對審查與被審查者都是有益的。
雖然網頁設計審視有如此突出的優點，但它的缺點也是非常顯著的，那就是它需要付出如此巨大的代價。當一個人完成編碼以後，還需要另外的人去解讀和審 查，並要求編程人員完成相應的修改，甚至重構和重寫，這本身就是一種巨大的代價。這對於其本身就已經人員和時間非常緊張的軟體發展專案來說，無疑是一種雪 上加霜。時間、人力與網頁設計品質，其本身就是魚和熊掌不可兼得，關鍵是如何去權衡。正因為如此，不同公司選擇了不同的網頁設計審視策略。
前不久，我聽了韓國一家大型遊戲軟體公司談他們的網頁設計審視。由於這家公司在軟體發展時，最關鍵和緊要的問題不是時間和人力而是網頁設計品質，所 以他們採用了一種嚴格的網頁設計審視策略。嚴格的網頁設計審視策略，一種方式是由專人進行網頁設計審視。這種方式，在人員組織形式上，從軟體發展人員中單 獨提出了一些經驗豐富的人，組成一個網頁設計審視小組，專職對其他軟體發展小組進行網頁設計審視。這種方式，網頁設計審視小組以第三方的身份去審視各個專 案組的網頁設計，可以保證審視的公平公正，但壓力無疑是巨大的（想想他們要查看那麼多的網頁設計）。
另一種方式，是以一個專案開發小組為單元進行網頁設計互查，即一個人的網頁設計，要為小組所有成員進行審查。這種方式毫無疑問，其付出的代價太大 了。對這種方式的一種變通方式是將XP中的結對編程進行結合，然結對編程中的兩個人相互進行網頁設計互查。採用結對編程的專案組可以嘗試這樣方式，遺憾的 是目前國內採用結對編程的專案組實在太少了。以上兩種網頁設計審視的最大弊病就是責任制，即審查者沒有太多的責任去發現被審查者的問題，發現了問題對審查 者沒有任何好處，反倒與被審查者結怨；相反，審查者沒有發現問題也不會擔負任何責任。這樣的結果就導致了網頁設計審視流於形式：審查者草草審查，各方皆大 歡喜，問題依然存在。
綜上所述，雖然網頁設計審視優勢明顯，但以上幾種形式都不能為普通的軟體發展團隊所接受，就此我祭出了我的最佳實踐：以小組為單位，組長責任制的網頁設計審視形式。
網頁設計審視的最佳實踐
網頁設計審視是有代價的，甚至有時是巨大的，因此網頁設計審視不宜頻繁，最好一份網頁設計只審查一次。同時，網頁設計審視者應當對所審查的網頁設計 負有責任，即能夠大膽地審查並指出被審查者的問題，並要求被審查者限期整改。與此同時，被審查後的網頁設計如果還出現缺陷，審查者應當負有責任。只有滿足 了以上三個條件，網頁設計審視才能為我們所接受。毫無疑問，專案開發小組的組長來擔當此責任是最合適的。
一個專案開發組，根據其功能的劃分，可以劃分為多個小組，每個小組負責一個子模組。在這樣一個小組中，小組長無疑是最有經驗的開發人員，由他去負責 組織和指導其他成員是合適的。小組成員不要太多，往往是3~5人。小組長不要分配太多的開發任務，他的主要工作是指導和監督小組其他成員進行開發。將他從 繁重的開發任務中解脫出來，他可以有更多的精力去指導其他成員的設計，並且審視他們的網頁設計。最終，他要對小組所有成員的網頁設計品質負責，由項目經理 或品質管制員進行抽查，檢驗其整體情況。
如果你只是一個小型項目，人員總共在5人之內，那麼你不用這樣分組。作為專案經理的你就是那個小組長，指導和監督你的成員。這樣安排是因為在現代的管理理論中認為，一個人最多只能管理5個人，超過5個人就應當分組管理。而如果你在5人之內當然就不需要分開啦。
作為組長，你可以有效地審查和管理你的小組成員。同時，由於你負有責任，你也不得不認真有效地去完成審查工作。通過以上的組織形式，網頁設計審視可以簡便有效地在專案組中開展起來，從而從管理上有效地提高軟體發展的網頁設計品質。
轉貼來源：博客國
http://www.piece2ec.com.tw/news.asp?ID=1852
參考文獻：
1.伯德‧史密特（Bernd H. Schmitt）著、王育英譯（2000）。體驗行銷。台北：經典傳訊。
2.賴逸婷（2007）。網站體驗品質評估之研究。國立雲林科技大學視覺傳達設計研究所碩士論文，未出版。
3.張婷玥（2006）。顧客體驗與體驗品質之概念性研究。國立政治大學企業管理研究所碩士論文，未出版。
留言列表
