一個需求分析做的不夠的案例

突然發現，這段時間被失敗的專案包圍著。其實認真想想，做了那麼多專案，成功的不太記得了，失敗的卻總是糾纏著你。

這個專案，要說它失敗呢。它還執行了2-3年，業務一直在用它在監控庫存，很依賴它來制定訂貨數量和時間。要說它成功呢，到現在業務部門還不斷地要求修這裡改那裡。

專案簡介：是一個庫存監控報警系統。系統每天計算那些東西的庫存量低於一個標準值（該值根據時間段內的發料情況來設定，系統自動計算），把需要報警的列在頁面上。業務人員每天檢視。但因為庫存保障這種東西，完全靠機器是靠不住的，因為有很多特殊情況。所以系統給的只能做參考，採購人員必須在基於系統給出的結果上，自己需要再檢視其他引數（系統也列出來），以及其他情況來確定採購的數量。

人員配置：一個人

架構和技術：struts1+spring+hibernate , oracle

開發情況：當時我剛進公司，稀裡糊塗領導就交了這個任務給我。於是我就乖乖地按照業務部門說的開發。其實這個專案也不困難，我自己一個人開發很快就完成了。

使用情況：開始用後，業務部門根據一些實際情況要求做出調整，因為我把所有的業務邏輯寫在儲存過程裡（我真感謝我當時的做法），所以改起來其實很方便。然後，業務部門領導換了，但後來的領導也湊合著用這個系統，但提出一些新的想法，我又按照他的新想法，修修補補了一下。然後，有一天，我覺得老系統不好用，應該做的更好。剛好我比較閒。我就重新寫了一個系統。把邏輯模組分的更清晰一些，並且為了減輕業務人員工作量，我做了一些功能輔助他們工作。

結果：讓我萬萬沒有想到的是，從此以後業務部門就瘋狂向我提需求，瘋狂到他們自己本部門的人都看不下去了。讓我有挫折感：以前那麼粗糙的系統，他們用起來還沒有那麼多問題，結果給他們做細了，反而問題多了。雖然我很煩，但是因為希望把事情做好，他們提出的需求，我基本上都滿足。

讓我重新思考這個系統的事件是：業務部門又提出一個新問題，他們以前沒有提過的。要求我修改程式，我思考後，覺得不應該修改程式，因為業務人員只需要少操作一下，就跟我修改程式的效果一樣。我跟業務人員說，結果他們很不高興，找各種各樣的理由。我突然意識到：不能改！因為，這樣修修改改，不但讓程式存在更多隱患，而且解決問題的效果很差。

然後我思考為什麼這個專案會那麼失敗呢？追溯到源頭，當時就沒有好好做需求，第二次改寫程式也沒有做需求（這完全是我的責任，第一次因為不清楚狀況；第二次因為自大造成，我覺得我對業務很瞭解，不需要跟他們談了）。結果就造成做好後，業務部門這個要加一下，那個要改一下，佔了我很多時間。是我做的最煩的一個專案。

解決方法：我打算找業務部門領導和我們領導，還有業務人員，一起討論怎麼解決這個問題。這個系統必須有個重點：要不讓業務人員工作輕鬆；要不就保障庫存。因為這兩點一起實現，會產生很多問題。把問題討論清楚，把專案範圍圈定，我再做工作計劃來重寫或者修改這個系統。

這又一次告訴我，需求是多麼重要。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/13353915/viewspace-610854/，如需轉載，請註明出處，否則將追究法律責任。