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不通過重寫文檔到後來的一次通過，比攻克一個技術難題更有成就感。
　　商業系統開發發展必然朝越來越模式化的發展，這樣企業承擔的成本也許高點，但大大降低了失敗的機率，因為整個項目的成敗靠的整個團隊而不是個人。
　　兩個項目，五年的日本開發經驗，讓我獲益良多，但是我還是決定回廣州⋯⋯

　　2007年，五月從公司組織的富士山旅遊回來後，終於迎來了我在日本的第一個項目。地點在横浜，從我當時住的東京都江東区去需要有一個多小時的電車，這意味著我每天需要七點十五分就要出門。現在回想起來，的確有點遠，但當時初生牛犢，沒多想就接下了公司的這個任務。
　　項目的老大是一個愛吃糖的日本老頭，每次邊吃著糖邊和坐在旁邊的leader聊著項目的事情，幾乎我們面前正經吃過飯。leader是一個很友善的日本人，經常“呵呵”大笑，而且和我也有共同語言—ガンダム。其他成員還有四個日本人，八個中國人，總共十四人的團隊。
　　項目是日立製作所的一個不動產的管理系統，客戶是東急リバブル，我們十四個人負責的是物件模塊，負責待售、待租房屋信息的管理。
　　我是從基本設計階段加入的，第一個任務就是看圖說故事，參照設計原型，寫出設計文檔，讓開發人員知道這些頁面是做什麼的，互相有什麼聯繫。本以為直接寫代碼的活，沒想到是從設計開始！？讓非科班出身的日語一級的我有點措手不及，來日本快半年了，第一次有挫折感，＞＜。不過還好有朝鮮族的同事，他們的日語都頂呱呱，幫了我不少，而且後來我也發現竅門，設計文檔其實挺死板的，老大們的要求就是言簡意賅，把事情說清楚就好，也不需要你寫得多漂亮，所以參照已經寫好的文檔，修修改改也基本完成了七、八成，剩下的自己再發揮一下。總體來說，設計這部分當時我的確沒做得太好，也就是勉強及格，主要是做得太慢。一個多月後就進入了開發階段，我的show time即將開始了。
　　show time誇張了點，但進入開發階段確實順手多了，我在團隊裡面的作用開始發揮出來了。設計的時候，是我把未完成的部分交給其他同事完成，而開發的時候卻恰恰相反，是其他同事未完成的交給我，有時候還需要幫他們debug。原因很簡單，因為團隊十四個人裡面，有java經驗的人包括我只有三個中國人，日本成員和其他中國成員都沒接觸java的，都是現學現做，而這個項目主要用java實現，少部分批處理是用COBOL實現。
　　有好的設計，開發就沒太多難度了，而且技術使用的是日立自己的解決方案，一個在struts1基礎上二次開發的框架，為這個項目又擴展了部分功能，因此在技術上沒遇到多少困難。就是有個自動解壓縮的功能稍微查了一下java文檔，其他基本就是逼著眼睛就把代碼寫好了。
　　基本設計、開發、單元測試，在這期間不斷像日立總部反饋再修改，n個來回後，到九月分被告知第一階段已經完成，剩下的工作需要到東京大森的總部和其他模塊匯合，一起開發。終於可以結束每天幾乎三個小時的電車生涯了:–)
　　來到大森後完全是另一番景象，第一次感到日本的工作壓力。
　　我們這個項目其實總共分四大模塊，加上統籌的日立總部團隊，總共分成五個團隊。出了我們物件團隊外，還有負責顧客管理的顧客團隊，大概7、8人左右；負責契約管理的契約團隊，因為是整個項目中最重要的模塊，光設計就至少十幾人，開發是外包的中國的一家公司，開發人員都是從中國直接請到日本集中開發，整個團隊估計至少應該有三、四十人；最後就是為各個模塊提供api和技術支持的共通團隊。
　　在大森的主要任務的就是系統測試。自己寫文檔，自己開發測試，很順利，沒發現什麼問題，但一旦和其他模塊一起測試，就各種問題都來了。而且在大森還有來自客戶東急リバブル的負責人，客戶自己也組織自己的員工加入測試，本以為工作地點近了，可以輕鬆點，但真正的挑戰才剛開始。每天光自己測試就問題一大堆，還要兼顧其他團隊和客戶測出來bug，加上每天各種進度會，各種壓力無限大。不過對比最大的契約團隊我們算是輕鬆多了，估計是他們之前在中國時候開發的時候溝通不夠好，問題特別多，所以最後索性把人都叫到日本直接和設計團隊一起開發，看著他們的bse夾在設計和開發之間那種著急啊，沒法形容。迫於進度上的壓力，我們團隊最後也沒辦法也請了外援－－韓國測試團。
　　日本人開會，中國人開發，韓國人測試。這樣大約又折騰了半年，慢慢的，契約團隊的中國開發人員慢慢撤走了，我們的韓國測試團也退場了，項目終於上線進入保守階段，最後我也退出了項目。
　　牛刀初試，一絲不苟的工作態度是這個團隊教會我最寶貴的東西。