從過完年後就一直在爲公司內部開發企業管理系統，我坦然並不在行，雖然之前自己做過ERP的實施顧問，對SQL Server 也有一定的掌握。但是，我擔心的是業務，更頭痛的是無窮無盡、糾結不清的業務需求！
當前只有我和另外一個同事一起開發，其實在去年就已經有個初步的系統原型出來了，但是年底提交給其它部門試運行時竟然沒有人去理會，沒有人認真測試過系統是否符合本部門的業務需求。
現在又繼續開發，目的是爲了從一個銷售訂單確定下來後，從生產計劃安排到採購物料入庫這個前期的流程能走下去。爲了應對之前的情況，我決定採用原型開發模式，首先針對某個部門瞭解本部門的關鍵需求，確定哪些工作可以由系統來進行，哪些始終要人爲來完成。然後我們會開發一個最基本的界面，隨意加載一些示例數據，然後就直接在這個部門進行系統演示，當然，由於我們自己對業務本身不瞭解，很多時候會出現系統實現與實際的業務情況不一致的情況。
例如，我們當前進行的品質部，系統爲了實現單據流轉，從採購下了採購單後，直到物料到了公司就會產生一個來料單，那麼，採購部會將這個來料單轉發給品質部進行來料檢驗。一開始我們認爲品質部可以根據這張來料單對物料進行品質檢驗，然後在系統中填寫檢驗人、檢驗日期、檢驗數量等，最後生成一份來料檢驗記錄。
我們出現了一個較爲嚴重的設計錯誤：我們的檢驗人和一些檢驗結果判斷是對整張來料單進行的，但經過在品質部進行演示才知道：“一般一張來料單裏有不同的物料，我們品質部裏的任何人可以對任何一組物料進行檢驗和判斷。並不是對整張來料單進行判斷的！”
我們所做的並不是客戶所要的！！！
我們在設計的時候錯誤的認爲只要是品質部裏的人檢驗物料就可以了，並不關心誰檢驗，但是品質部裏的又說：“這會涉及到責任問題，因爲如果這批物料你判斷爲合格，如果到真正使用的時候才發現有質量問題，那就要追究品質人員的責任了，所以來料檢驗還需要一步檢驗的審覈才行！”
我們又一次忽略了···
再次思考這個問題：“我們所做的，就是客戶所要的！”，有多少軟件能真正做到這個？到底我們的命中率是多少？
有人或許會說：“那是因爲你前期的需求工作沒做好！”，但問題是，需求何時才稱得上做好了？，有一個標準嗎？我也看過《人月神話》，也知道敏捷開發方法，但實際的工作環境每個公司都有所不同，具體來說應該是每個人都不同，有不同的需求，有不同的期望！
在面對開發時間和實現功能的壓力下，很多時候根本無法獲取完整的需求，而客戶自己很多時候都不知道自己具體需要軟件實現哪些功能，只有在他們真正看到軟件跑起來後，有個界面給他看看，這時他纔會說：“哦，你這樣做是不行的，我們要的是實現這樣的功能···”。
我們所做的，就是客戶所要的！！！
