2008年，還是日立製作所的項目，客戶是更難纏的JCB，注定了這個項目是個難啃的骨頭。我加入的時候項目已經做了一年多，已經處於系統測試階段，之前開發的整個團隊由於各種原因已經撤走，只剩下文檔和代碼由我們接手，系統三個月後上線⋯⋯
　　三個月內，用最短的時間熟悉系統，用最短的時間查找並修改測出來的bug，這些也都還好，最麻煩的由於客戶是JCB，整個開發文檔一點都馬虎不得，大大小小從設計到單元測試的文檔全都需要經過客戶review。修改bug的過程更令人髮指，也許只是修改一行代碼，但卻要提交十幾頁的測試結果文檔作為審查，首先是團隊review然後是日立review，沒問題放服務器測試後在整理n張客戶能看懂的測試結果文檔，客戶確認後再發佈到正式服務器。
　　要件設計—>基本設計—>詳細設計—>編寫代碼—>單元測試—>結合測試—>系統測試—>發佈後確認。不管是修改bug或者追加功能，不管時間多麼緊，層層review一步都不能少。過程看似死板，但是就是這種紀律性讓我們的團隊在這麼困難的情況下生存了下來，系統上線後，新版本的升級順理成章的還是由我們來負責，而且慢慢也把更多的模塊委託給我們。
　　我剛去的時候團隊只有7個人，最終發展為三十個人的團隊，中日成員大概對半分，上面一個tl一個pm，再分兩個小團隊，一個負責人機互動頁面，一個負責外部數據的交換和處理，我們所屬的是中期審查模塊。系統另外還分為初期審查、online（臨時審查）三部分，再加上一個業務的團隊，一個運維團隊，總共五team人，總共有100多人。
　　這個系統是JCB基幹系統JENIUS下面的一個子系統ramda，主要負責信用卡用戶信用度管理，為基幹系統提供信用度參考。用戶的信用數據來源主要來自第三方和JCB自己的數據庫，因此這次項目的重點是第三方和JCB的數據整合。第三方機構就有四家，而JCB的數據也分散在好幾個子系統裡面，測試數據做起來異常的費勁。由於涉及的外部系統接口眾多，而且稍有點錯誤，也許就會讓客戶蒙受巨大損失，沒有如此苛刻的開發流程是根本保證不了質量的。
　　日立的項目，用的是日立自己的解決方案Justware，不過數據庫就用了更出名oracle，整個框架還是那麼的實而不華，開發人員不需要專注技術細節，只需把握業務細節，不能說很有效率，但是很實用，把犯錯的機會降到最低。部署起來也算方便，圖形化，簡單直接。
　　整個項目做了兩年多，經歷了三次大的版本升級，直到我2011年回國的的時候，還在做，不夠已經大部份轉為保守了，幾乎沒新功能的追加了。
　　乘风破浪，項目的難度本身並不高，但是要求卻一點不低，深深的感受到日本人追求細節的那種令人髮指的執著，哪怕空格是用全角還是半角都會仔細檢查。從開始無數次的review不通過重寫文檔到後來的一次通過，比攻克一個技術難題更有成就感。
　　商業系統開發發展必然朝越來越模式化的發展，這樣企業承擔的成本也許高點，但大大降低了失敗的機率，因為整個項目的成敗靠的整個團隊而不是個人。
　　兩個項目，五年的日本開發經驗，讓我獲益良多，但是我還是決定回廣州⋯⋯