http://kang.iteye.com/blog/228525

一年多以前，自己開始參與到一個對日軟體外包的專案中，現在將自己的一點感受寫下來，希望對其他剛開始從事或者即將從事對日外包的同志有所幫助。

那是一個維護專案，關於醫療行業web站點方面的。使用的是Java語言，Struts框架和Tomcat伺服器。我方的工作主要是幫日方改bug、增加新功能什麼的。

-》使用Tomcat作為Web伺服器（20090506追加）。

剛開始時，按照日方的要求，我們這邊構築環境，要與日方客戶的環境保持一致（連目錄結構都已經規定好了）。環境構築好之後（包括各人本地開發環境和server測試環境），開始測試，每個人都要測試，每條case都要仔細測，將測試結果填到測試式樣書中，一條case測試通過則填OK，否則是NG。這恐怕也是日方客戶對我方最開始的也是最小的考驗。

關於測試，請注意：對於測試式樣書中的想定結果與實際測試結果，哪怕只是一個字母或者符號什麼的不一樣，也要填NG，這一點有時讓我們比較鬱悶，發發牢騷，但同時又不得不佩服日本人做事的仔細和嚴謹。

後來，經過一段時間的合作後，一般的工作流程如下：

日方先發式樣書（絕大部分都是excel格式）過來，告訴我們他們想做個什麼東西出來或者說他們在哪邊發現了一個什麼樣的bug。

-》關於為什麼使用Excel格式作為式樣書的模板，也有新人問過。這個問題，我想主要原因是Excel檔案可以貼圖（而Word中的貼圖就差多了）（日方式樣書中圖片是不可缺少的，日本人非常注重頁面這種表面上的東西），也可以寫說明文字。（20090506追加）

我們這邊開始調查，尋找大概的解決方案，進行見積もり，預估工作時間（多少個人日）。

我們把預估出的時間彙報給日方，日方或者同意或者討價還價後同意。

我們這邊開始啟動，分工協作，有人調查source，有人寫詳細設計書，有人寫測試式樣書，等等。

-》一般都是調查sorce的人做code工作，詳細設計書也是這個人來寫，因為他最熟悉。（20090506追加）

對於我們提出的解決方案，也要提交給日方(一般是詳細設計書)，他們確認後，就開始實施。實際情況是有時是同步進行的。

程式碼編出來或者修正後，由其他同事review，上頭也要review。最後先在本地做測試，可能需要好幾個人分別做測試，儘可能地發現bug。

本地測試完成後，再將程式碼什麼的更新到server上，做server端測試。

由於日方做事謹慎，合作的初期，還要求我們對測試結果進行截圖，作為證據。

-》關於截圖問題，後期參加的專案經驗表明，不僅僅是合作初期（對我們不太信任），就算是合作時間較長，雙方都很熟悉和信任後，一般server測試結果都要截圖（不僅僅是作為測試結果的證據，也為了將來出現問題時能更好地找出問題原因並解決掉）。（20090506追加）

我們當時的客戶對手機這一塊也要實現，所以手機也要測，用模擬器進行測試。順便提一句，感覺日本的手機應用比我們更先進一些更深入一些，PC上能實現的功能很多在攜帯上也能跑得起來。

-》但兩者也有區別，有些情況下，在PC上是能正常顯示的，而在手機模擬器上顯示得就不是很自然了（比如亂碼）。還有個問題要注意，手機web應用是要計算流量的，所以儘可能不要將多餘的無用資訊發往客戶端（比如JSP頁面，寫註釋時，要使用伺服器端註釋<%- -%>，而不要使用客戶端註釋<!- ->）。從這個例項中，也可以看出，日方客戶做事，確實是為他的客戶考慮的，並且考慮得很仔細很周到。（20090506追加）

Server測試完成後，假如沒什麼問題，我們將相關的程式碼和文件發給日方，叫做納品。

日方自己在日本再做測試，有bug就返回來改正；沒問題的話，他們承認，這個式樣也就算結束了。

期間，日方可能對我們的詳細設計書和測試式樣書指摘多次，我們這邊也要不停地修正。

->關於式樣書的修正問題，有一點特別要注意，就是日方指摘出的，我們這邊一定要按照他們的要求修改掉（假如有疑惑或者有新的提案，也可以發QA進行詢問或者討論）。日方客戶特別反感的一件事是：他指摘出來的問題，我們在新發過去的式樣書中沒有體現（沒有修改），也沒有提出QA，讓他感覺我們根本不重視他的指摘，這個會讓日方客戶很不爽。所以，一般情況下，我們內部在進行review時，會對照日方的指摘一條一條地來確認。大多數情況下，我們也會將修改點和對應的指摘點對應著標註出來，更便於日方客戶進行review。（20090506追加）

關於式樣，特別是對應的初期，有很多不清楚的地方，那就需要不停地跟客戶進行溝通和確認，填寫QA。

-》關於QA的回答，感覺這個客戶不如後面幾個客戶的反饋快。（20090506追加）

關於解決方案，有時需要提供好幾個不同的方案給日方，讓他們選擇。

-》儘量提出高質量的提案，那樣可以讓日方客戶更加相信我們，更加離不開我們。（20090506追加）

關於bug，解決bug的同時也要填寫bug票。不同公司的bug票格式也不怎麼一樣，但大致內容一致。我看過NTT Data的bug票，感覺那不是一般的規範，那是相當的規範。

關於合作方式：我們與日方的合作合同簽了一年，按照人頭收費（難聽點，但事實如此），一個人FTE工作一天，日方付我們多少錢，M個人工作N天，依此類推。

-》我們是labo給日方客戶的，這一年內，我們專案組就為他們服務。說得難聽點，我們就是包身工。（20090506追加）

關於加班：剛開始時，由於任務緊，我們經常要加班，8點下班很正常，有時還要接近9點，後來日方客戶看我們加班多了，他們的Cost也多了，後來也不怎麼允許我們加班了，具體說是不怎麼允許我們提加班申請了。日方客戶的想法很怪也很精：既想讓我們加班多幹活，又不想付加班費。後來，我們也適應了，再提高8小時的工作效率，加班也越來越少了。

關於交流，我們每天都要發日報，早上發出勤日報，說明今天計劃要做哪些工作；晚上下班離開前發退勤報告，彙報今天的實際工作成果並說明明天的工作計劃。專案經理每週與日方客戶開一次電話會議，討論問題，彙報進展。每週五下班前還要發週報，彙報本週的工作情況和下週的工作計劃。

-》關於日報，並不是所有的日方客戶都要求我們發出勤報告和退勤報告。有的日方客戶只要求發退勤報告（由於加班嚴重，好多次過了凌晨，這種情況下，我們專案組不能保證早上按時上班）。（20090506追加）

關於我方與日方客戶的關係，談一點個人感想：

跟一個新的日方客戶合作的話，剛開始我們中方是被動些；日本人做事一向比較苛刻的，更何況他們是客戶。

但是，我們也不是永遠處於什麼絕對的被動地位，剛開始時是被動些，但也可以提出高質量的提案給他們，在規定時間裡以較高質量完成任務，讓我們的地位往主動的方向不斷前進。

等合作一段時間，等穩定了，他們也離不開我們了，那時就是真正的合作關係了。


20080816中午補充四點：

1.關於式樣書，一般都是excel格式，裡面把相關情況（想實現的機能或者發現的bug等等）說明清楚。特別要說明的是，日方的畫面設計做的比較仔細，機能想做成什麼樣的都畫得清清楚楚。

2.關於對應過程中的程式碼修改，一般日方都不允許修改他們既有的函式什麼的，他們擔心影響其他功能，一般都是要求新規。現在想想，這樣做，也算符合軟體開發過程中的開閉原則。

-》關於這個問題，我們前後經歷過好幾個專案，日方客戶都是這樣要求的。（20090506追加）

3.關於測試，有一點要說明一下：假如我方已經開始使用最新的經過日方客戶認可了的測試式樣書進行測試時，如果發現了問題（比如說程式是對的，是測試式樣書的case寫錯了），這時是不能擅自修改測試式樣書的，需要將實際測試結果如實填寫，可以在備考欄中說明一下相關情況，彙報給日方，經他們同意後再修改測試式樣書。因為日方自己做測試時是按照經他們認可的測試式樣書進行測試的，假如我們不彙報就把已經經日方客戶認可的測試式樣書修改了，會導致雙方的測試式樣書不同步不一致，那測出來的結果也不一樣了，問題也就出來了。

4.關於每天日報的出退勤時間問題，日方客戶也“摳”得比較嚴。打個比方，日報是9：01分（系統時間）發出的，那麼出勤時間也要寫成9：01，就不能寫9：00；晚上下班時也要18：01之後才能發退勤報告。總之，給我們的感覺是：日方的時間觀念很強！

-》日本人的時間觀念很強！（20090506追加）

20080816下午再補充兩點：

1.關於文件，日方客戶對文件的要求近乎“苛刻”，舉個例子，連每個sheet中字型顯示大小和顯示比例什麼的，日方對此都有要求，甚至還要求每個sheet開啟時，游標應該在最左上角的那個單元格位置。當然了，他們自己做的文件也是有板有眼的，比如式樣書，格式上面一條一條清清爽爽。還有就是環境構築手順書，寫得很仔細，一步一步怎麼做，說得清清楚楚。

-》日方對文件確實比較“摳”，比如連列印設定都設定好（對方拿到文件就能直接列印）。（20090506追加）

從文件就可以看出我們中國與日本在軟體行業方面的差距，我們國內大部分是程式碼都寫完了或者寫得差不多的時候再去補文件，而日本基本上都是把文件作為各個階段的成果物之一，作為一種標誌。

2.當然了，日方客戶的式樣內容方面，有時也說得不是很清楚，模稜兩可，比較曖昧，這個不是式樣格式的問題，是另外的話題。其實，無論什麼客戶，剛開始時對式樣的描述都不可能面面俱到，這就需要我們不斷和客戶進行溝通與確認，通過雙方的共同努力，逐步把專案做好。

以上是我這一年多來對日軟體外包方面的一點感受，現在就想到這麼多，先寫到這，以後有機會再寫。