這一段時間，忙于在代碼和A公司之間奔波，所以日志也沒有時間來寫。
今天談談我近段時間在客戶實施的心得。
到現場實施情況是比較復雜的，所以從剛剛開頭我就沒有像專家一樣的到處都問（調研時可以像專家一樣告訴客戶一些大道理）。我們的程序是基于合同技術附件簽訂的，實施也就跟著簽字的需求和目標走。
由于前一段時間讓一群學生寫了一些代碼，雖然在質量上我有所“查閱”，但是問題最大的也就是在這里，在實施前只是把大致的錯誤進行了修改，就匆匆到現場實施。
核心代碼由于是自己的思想，也讓放心的手下寫了，但是還必須得測試和驗證其準確性。這是一個重要的工作，也可能會涉及到一些改變。
第一天，到了客戶現場，先是對其環境要求，確定完主機和數據庫后，就開始安裝布置，1個小時后全部搞定，基本上給客戶講了一遍怎么使用（很粗略，因為
以后我們有培訓）。接著就聯合PDM系統和ERP系統進行測試，還幸運（不相信迷信也這么寫），沒有出事，用戶的輸出結果也正確，呵呵，收工回家。
其實，里面的問題很多。只是用戶對這個陌生的事物還有好奇的心理，沒有深入去學習它。
第二天，接著實施，在不斷的測試過程當中，問題就出現了，很小的問題讓客戶對我的軟件產生了懷疑，比如供應商編碼和供應商PN號為什么輸出是一樣的？
員工ID為什么傳遞不過來？假如PDM發布同一個樹但有不同的組成結構時，做的處理不符合我們的實際業務？為什么不同層次的裝配件再次發布時，數量不相
加？假如我這一次發布錯了，能不能刪除？
客戶提出了很多問題，我知道我的程序開始讓用戶認可了，所以我的態度比較友好，（說實在的，哪時候真想找個替身），我把問題羅列出來后，做了歸類，并給客戶承諾完成時間，并態度友好、熱情、友善、和氣。。。。的給用戶出錯原因。當然心態必須是誠實。
一般客戶會提出這幾類問題。
一、軟件本身的BUG，是自己的責任，勇敢的承認自己的錯誤，合同都簽定了，還不讓修改一個BUG。
二、在實際需求時，考慮的不充分，或者是技術實現上有制約的地方
三、實際業務和輸出結果不符合。
這三類問題，前兩類我們很積極并承諾盡快得給用戶解決，就是不在合同之內的事也加入代碼實現，我們的目的就是先讓用戶使用起來。
第三類問題，不管用戶多么著急，我們也對之的實現優先級降低，同樣必須讓用戶書面提出需求我們再做。
后來的三兩天就是修改程序，不過這個時候我手下已經沒有人了，所以我自己這兩天很辛苦。同樣，也發現了很多錯誤，尤其是表現層，我真是恨這幫學生呀。害的我不得不對之進行修改。
再以后就是實施，就算是我的第二個階段吧。
這個階段里，我就象一只狗似的，看見客戶負責人就趕緊用舌頭去舔人家的腳，（想起了發廊的小M辛苦的為我按摩），晚上人家都下班了，為了趕進度只得自愿加班，晚上經常9點后回家。
這個階段里，是比較富有成果的，首先把客戶前一段時間的BUG和考慮不充分的地方進行了彌補，而且用戶對我修改的速度也很佩服。呵呵。（高興的我自己好象是一個偉大的。。嗯，實施家）
等到用戶測試結果正確，不，應該是準確（我的認為），而且從長期的測試來說，我心理比較塌實了，我進行第三個階段。修改需求并加入新的程序。
這個過程比一個階段好一些。我可以坐回公司來，上上網，聊聊天，喝口茶，再寫寫程序了，一兩的活兩天干，還能混吃兩頓飯。呵呵，目前就實施在這里。
對EAI產品本身我給用戶提供了一個規則，因為我的軟件當中有版本管理和BUG提交模塊，所以我每一次的修改就對版本有所影響，小的改動加小版本，大
的改動加大版本，說來也巧，等正式上線剛才從0.8上升到1版本。呵呵。同樣用戶的BUG管理只開放給系統管理員，我可以每天收集一下BUG，并及時進行
修改。
對TOMCAT中間件服務器和程序本身的性能優化是一個大問題，現在正在解決當中。
程序的穩定性和并發控制也準備在下一期進行修改。
請關注我的貼子。