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

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

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

[]?與分公司熟悉系統的人進行初步了解，弄清楚系統的設計背景以及應用情況，得知
本地客戶需要的系統是一個大系統中的一部分。另，該系統是out?sourcing?開發的
沒有開發人員的支持，現任的管理員對系統的了解程度有限。
[]?向分公司同事要帳號，希望進一步了解系統的功能，同時與客戶聯系，嘗試與客戶一起來了解系統
以方便客戶確認，是否該系統就是用戶需要的系統，功能是否能滿足。得到的回復是客戶已經用過
這套系統。因為有客戶的確認，于是直接進入系統引入安裝階段?
[]?了解了系統的軟硬件需求，向分公司要來系統Copy，試安裝:
存在以下安裝問題:
{}?沒有數據庫初始化腳本，只有數據庫設計文檔，與分公司同事交涉，未果，
只好根據設計文檔自己寫出數據庫初始化腳本
{}?數據庫腳本運行成功，但是運行系統發現缺少視圖，向分公司同事要其它的視圖以及?table?的腳本
因為有異地溝通存在，和其它項目的同時進行，時間到此已經過去大約一周
{}?數據庫準備完成，讓用戶熟悉系統，提更改需求

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

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

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

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

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

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

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

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

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

轉載于:https://www.cnblogs.com/Color/archive/2004/03/12/2909.html

總結

以上是生活随笔為你收集整理的[转]项目失败的经验的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。