失敗的項目經歷

做項目的總有成功和失敗，成功了需要總結，失敗的更需要總結。以下要說的一個 Case 是我經歷過的一個失敗的項目，寫出來，大家指點一下。

首先介紹一下背景，這個項目的客戶是企業內部顧客，應用的范圍是為用戶收集第三方的意見與建議提供一個渠道和工具，并給 Manager 層的領導提供必要的信息視圖，以方便直觀地把握問題的種類和問題的數量。

項目在啟動以前，用戶曾打過我談，說他們在別的分公司看到了一套系統，非常適合他們應用，希望能移植過來，并希望越快搭建越好。考慮到用戶對該系統需求的緊迫性，我們做了初步評估行動:

[] 與分公司熟悉系統的人進行初步了解，弄清楚系統的設計背景以及應用情況，得知本地客戶需要的系統是一個大系統中的一部分。另，該系統是out sourcing 開發的沒有開發人員的支持，現任的治理員對系統的了解程度有限。

[] 向分公司同事要帳號，希望進一步了解系統的功能，同時與客戶聯系，嘗試與客戶一起來了解系統以方便客戶確認，是否該系統就是用戶需要的系統，功能是否能滿足。得到的回復是客戶已經用過這套系統。因為有客戶的確認，于是直接進入系統引入安裝階段

[] 了解了系統的軟硬件需求，向分公司要來系統Copy，試安裝:存在以下安裝問題:

{} 沒有數據庫初始化腳本，只有數據庫設計文檔，與分公司同事交涉，未果，只好根據設計文檔自己寫出數據庫初始化腳本

{} 數據庫腳本運行成功，但是運行系統發現缺少視圖，向分公司同事要其它的視圖以及 table 的腳本因為有異地溝通存在，和其它項目的同時進行，時間到此已經過去大約一周

{} 數據庫預備完成，讓用戶熟悉系統，提更改需求初步收到更改需求，因為我們對系統并不熟悉，嘗試獲得分公司同事的援助，將更改需求發到分公司同事處，請他幫忙確認系統修改的可行性。這里我們主要擔心的是系統的更改會不會比重新做一個系統還要復雜?

這樣的更改需求，實際上就是對原有系統的需求變更，在對原系統以及業務流程不了解的情況下，做系統變更的風險很大

分公司同事認為不會影響到系統的流程，在多次溝通后，分公司同事還針對每個修改點粗略地標注好了需要修改的文件和注重事項。這里要說明的是，該同事對該系統其實也并不是很熟悉。這是后話

有分公司同事的確認和一份比較詳盡的修改說明，我們開始修改工作，項目進行到正式實施階段。初步認為修改只需要兩到三天時間。此時時間距離客戶找我們第一次談已經過了兩周左右。

但是很不幸，系統修改過以后，發現有一個功能不能正常工作，而該功能是這個系統的核心。于是開始嘗試熟悉系統，做 deep dig 的工作，時間過得很快，一個星期又過去了，最后確認該系統的可移植性很差，很多 hard code 存在，一些修改后以為正常的地方都有隱患存在。

開始意識到，需要了解系統的業務流程，盡管是拿過來的系統，也需要一份客戶的需求說明書。時間流失太多，馬上著手與客戶溝通，希望能盡快地坐下來一起談談需求。考慮到客戶不態愿意寫需求書的特性，自己根據原有系統，編寫了一份初步的需求說明書，請客戶確認，但是得到的答復是我們要的就是原有的系統，你照著改就可以了。當我再想細一步向客戶確認系統角色的種類時，得到出人意外的答案，客戶說他其實只用過該系統很少一部分功能，對系統中的很多東西都不熟悉。所以并不知道原系統定的那些角色有什么用。

于是問題開始升級，向 Manager 求助，要求 Manager 出面一起與客戶溝通，試圖說服客戶從談需求開始走軟件開發流程。強烈建議從客戶需求出發，以滿足客戶需求為核心目標來構建系統。在討論過程中碰到一些困難，客戶認為，原有的系統運行過了很多一段時間，所以比較穩定功能也會比較完善，從頭開始談需求沒有這個必要。但是對于我們來說，沒有需求就成了盲人沒有目標，我們怎么知道要去做什么? 最后達成一致意見，與客戶部門的 Manager 協商，爭取客戶部門的 Manager 同意從頭做起。

但是事情出現很大的變化，最后，客戶部門的 Manager 自己動手寫了一個小工具來幫助他們完成相應的工作。

客戶寧愿犧牲自己的時間，也不愿意坐下來談需求。客戶其實知道自己的需求，但是卻處在混沌狀態，我們沒能很好的引導客戶，讓客戶將需求描述出來，這一點我覺得很失敗。