簡介：這是一個真實的故事。故事中，我作為一個項目的負責人，因為初期過於迎合客戶，而放棄了對一些基本原則的堅持，最終導致項目進行中被迫進行大改動。而改動過程中，通過引入敏捷開發而將損失降到了最低。
項目背景
2006年年初，一位客戶聯系我的公司，希望能夠為其企業創建一個企業網站項目。根據客戶的簡單描述，這個項目本質上就是一個內容管理系統，並集成了論壇、FTP和電子郵件等功能，因此不算復雜。按照以往的經驗估計，最多一個月就可以完成這個簡單的項目。
需求分析
大體而言，該項目的主要功能包括新聞和文章發布、產品發布以及後台的用戶管理和權限設置，還有外圍的論壇、FTP和電子郵件系統。應該是一個很簡單的Web應用程序，通常情況下寫一個簡單的概要性文檔，就可以安排開發人員進行實際編碼了。
但這個客戶是國有企業，所以簡單的概要性文檔是顯然不可能通過領導審核的。為此，我和客戶一起，將網站所有的功能整理成了列表，並標記出各個功能之間的關聯關系。功能和內在邏輯關系整理完畢後，客戶還和設計師一起將所有網頁的布局也畫成了圖表。最終，需求文檔多達50頁。
在整理需求文檔的過程中，我發現項目並不像客戶最開始描述的那樣簡單。因為客戶所在的企業有一百多個部門、車間，所以客戶要求按照部門和車間對網站的用戶進行管理。同時，權限管理是層層授權的。簡單來說就是上級部門可以，也只能給直接下級部門授權，而不能越級授權。獲得授權的用戶可以創建一個產品子類別。然後給子類別指定一個下級部門的管理員，然後再由該下級部門的管理員來創建更深層次的子類別或管理產品信息。
從表面上看，這種設計沒什麼問題。但在實際操作中，這種設計要求對每一個部門的相關員工都進行培訓，讓其掌握系統的使用，增大了項目的應用成本。同時，由於繁瑣的授權模式，最終負責產品管理的人員反倒沒有充分的權力使用系統。
所以我對這些不合理的地方提出了自己的看法，希望采取更靈活更實用的設計方案。不幸的是，我沒能說服客戶接受我的意見。畢竟這是個金額較大的項目，客戶方負責人堅持己見，我也無可奈何。
雖然按照需求文檔，我把項目開發時間定為兩個月，但事實證明兩個月的時限過於樂觀。
原型系統開發和初步評審
文檔准備完畢後，我安排了開發人員和設計師進行此項目。而開發人員不到20天，就拿出了一個原型系統，雖然細節上還有不少需要完善的地方，但主要功能都已經具備了。原型系統開發完畢後，我們和客戶一起進行了初步評審。評審結果雙方都比較滿意，所以准備在余下來的時間中完善細節。
但我發現這個原型系統中權限部分實用性非常差，因此再次提出了修改意見。不過客戶顯然對於我這種“懷疑”他的做法很不愉快，最後用一句“這是我們行業特點決定的”來結束了討論。雖然我早已知道決定項目成敗的，“人”才是關鍵因素，但迫於客戶的壓力，我再次選擇了妥協。
許多開發者認為只要原型系統通過評審，整個項目就不會遇到大問題了。但實際情況有時候非常復雜。因為原型系統通常只是幾個人坐在一起簡單展示或者試用一下，和實際使用該系統的環境有著巨大區別。所以許多問題是根本不可能在原型展示階段暴露出來的。
做好後的系統卻徹底失敗
從需求文檔准備好到實際開發工作進行還不到一個半月，整個系統就非常完善了。期間由於客戶方負責人出差，客戶企業的其他聯系人要麼沒有決策權，要麼說不知道此事（國企通病），所以我們只有在沒有獲得進一步反饋意見的情況下繼續按照需求文檔進行開發。不過完善後的系統倒是“很順利”的通過了客戶的檢查，開始部署到服務器上進行試運行。
但就像火山一樣，系統中存在的問題超過臨界點就會爆發。短短一周以後，上門為客戶提供培訓的技術支持人員就帶回來了一份詳細的修改意見文檔和反饋意見。而我僅僅看了這些文檔幾分鐘，就明白這個項目將要進行重大修改，否則不可能投入實際應用。
修改意見文檔的內容主要集中在權限系統上，具體而言就是權限系統的設計太復雜、太死板。首先，層層授權太過繁瑣，有時候改變產品類別的名字也要找到上級管理員才行。其次，由於系統限定不能給一個管理人員分配多級產品分類的權限，所以必須每個產品分類層次都要設置不同的管理帳號。
客戶企業有10多個大類，100多個小類，上千種型號的產品。但實際上根本沒有那麼多人願意負責管理工作，最後就成了一個人用幾個帳號，當初設想的嚴格權限管理形同虛設。而且由於使用太麻煩，實際的管理工作逐漸向少部分人集中，導致這些人怨聲載道，開始對系統提出各種各樣的負面看法。
在這種情況下，我公司和客戶企業領導進行了多次會議，初步決定兩條腿走路。一方面用最短的時間修改現有系統，保證客戶企業新產品發布時，網站能夠正式推出。另一方面重新做一套新系統來替換現有系統。
重新開始，該如何抉擇？
對於軟件公司來說，一個項目如果重做，損失和影響是非常大的。因為不但其他的開發計劃要被打亂，而且公司投入的成本也要成倍增加。這個時候，如何降低損失就是最重要的事情了。好在和和客戶經過進一步協商後，客戶承擔了一半的損失。而完全重做也改為只重做權限系統部分。
根據這個目標，我首先安排開發人員對系統進行修改。砍掉了權限系統（實際上就是這一塊導致了整個系統的重做），並按照其他項目的成功經驗，對多處功能進行了修改。修改完成後的系統雖然缺乏權限管理，但其他功能經過客戶企業員工使用都反映良好。而且這樣簡化後的系統大部分功能都可以直接搬到重新開發的新系統中，最大程度的降低了成本。
同時，在我的強烈要求下，客戶企業決定安排專人負責此項目。這樣我才能保證新系統的開發不至於重蹈覆轍。
