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

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

那是一個維護項目，關于醫(yī)療行業(yè)web站點方面的。使用的是Java語言，Struts框架和Tomcat服務器。我方的工作主要是幫日方改bug、增加新功能什么的。

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

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

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

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

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

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

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

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

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

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

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

代碼編出來或者修正后，由其他同事review，上頭也要review。最后先在本地做測試，可能需要好幾個人分別做測試，盡可能地發(fā)現bug。

本地測試完成后，再將代碼什么的更新到server上，做server端測試。

?

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

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

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

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

Server測試完成后，假如沒什么問題，我們將相關的代碼和文檔發(fā)給日方，叫做納品。

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

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

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

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

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

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

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

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

?

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

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

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

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

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

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

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

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

等合作一段時間，等穩(wěn)定了，他們也離不開我們了，那時就是真正的合作關系了。


20080816中午補充四點：

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

2.關于對應過程中的代碼修改，一般日方都不允許修改他們既有的函數什么的，他們擔心影響其他功能，一般都是要求新規(guī)?，F在想想，這樣做，也算符合軟件開發(fā)過程中的開閉原則。

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

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

?

4.關于每天日報的出退勤時間問題，日方客戶也“摳”得比較嚴。打個比方，日報是9：01分（系統時間）發(fā)出的，那么出勤時間也要寫成9：01，就不能寫9：00；晚上下班時也要18：01之后才能發(fā)退勤報告?？傊?#xff0c;給我們的感覺是：日方的時間觀念很強！

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

?

?

20080816下午再補充兩點：

?

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

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

?

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

?

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

?

?

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

總結

以上是生活随笔為你收集整理的对日软件外包的一点感受的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。