創建一個典型的企業網站項目

　　簡介：這是一個真實的故事。故事中，我作為一個項目的負責人，因為初期過于迎合客戶，而放棄了對一些基本原則的堅持，最終導致項目進行中被迫進行大改動。而改動過程中，通過引入敏捷開發而將損失降到了最低。

　　項目背景

　　2006年年初，一位客戶聯系我的公司，希望能夠為其企業創建一個企業網站項目。根據客戶的簡單描述，這個項目本質上就是一個內容管理系統，并集成了論壇、FTP和電子郵件等功能，因此不算復雜。按照以往的經驗估計，最多一個月就可以完成這個簡單的項目。

　　需求分析

　　大體而言，該項目的主要功能包括新聞和文章發布、產品發布以及后臺的用戶管理和權限設置，還有外圍的論壇、FTP和電子郵件系統。應該是一個很簡單的Web應用程序，通常情況下寫一個簡單的概要性文檔，就可以安排開發人員進行實際編碼了。

　　但這個客戶是國有企業，所以簡單的概要性文檔是顯然不可能通過領導審核的。為此，我和客戶一起，將網站所有的功能整理成了列表，并標記出各個功能之間的關聯關系。功能和內在邏輯關系整理完畢后，客戶還和設計師一起將所有網頁的布局也畫成了圖表。最終，需求文檔多達50頁。

　　在整理需求文檔的過程中，我發現項目并不像客戶最開始描述的那樣簡單。因為客戶所在的企業有一百多個部門、車間，所以客戶要求按照部門和車間對網站的用戶進行管理。同時，權限管理是層層授權的。簡單來說就是上級部門可以，也只能給直接下級部門授權，而不能越級授權。獲得授權的用戶可以創建一個產品子類別。然后給子類別指定一個下級部門的管理員，然后再由該下級部門的管理員來創建更深層次的子類別或管理產品信息。

　　從表面上看，這種設計沒什么問題。但在實際操作中，這種設計要求對每一個部門的相關員工都進行培訓，讓其掌握系統的使用，增大了項目的應用成本。同時，由于繁瑣的授權模式，最終負責產品管理的人員反倒沒有充分的權力使用系統。

　　所以我對這些不合理的地方提出了自己的看法，希望采取更靈活更實用的設計方案。不幸的是，我沒能說服客戶接受我的意見。畢竟這是個金額較大的項目，客戶方負責人堅持己見，我也無可奈何。

　　雖然按照需求文檔，我把項目開發時間定為兩個月，但事實證明兩個月的時限過于樂觀。

　　原型系統開發和初步評審

　　文檔準備完畢后，我安排了開發人員和設計師進行此項目。而開發人員不到20天，就拿出了一個原型系統，雖然細節上還有不少需要完善的地方，但主要功能都已經具備了。原型系統開發完畢后，我們和客戶一起進行了初步評審。評審結果雙方都比較滿意，所以準備在余下來的時間中完善細節。

　　但我發現這個原型系統中權限部分實用性非常差，因此再次提出了修改意見。不過客戶顯然對于我這種“懷疑”他的做法很不愉快，最后用一句“這是我們行業特點決定的”來結束了討論。雖然我早已知道決定項目成敗的，“人”才是關鍵因素，但迫于客戶的壓力，我再次選擇了妥協。

　　許多開發者認為只要原型系統通過評審，整個項目就不會遇到大問題了。但實際情況有時候非常復雜。因為原型系統通常只是幾個人坐在一起簡單展示或者試用一下，和實際使用該系統的環境有著巨大區別。所以許多問題是根本不可能在原型展示階段暴露出來的。
<

原文轉自：http://www.anti-gravitydesign.com