对日软件外包的一点感受

一年多以前，自己开始参与到一个对日软件外包的项目中，现在将自己的一点感受写下来，希望对其他刚开始从事或者即将从事对日外包的同志有所帮助。

那是一个维护项目，关于医疗行业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.当然了，日方客户的式样内容方面，有时也说得不是很清楚，模棱两可，比较暧昧，这个不是式样格式的问题，是另外的话题。其实，无论什么客户，刚开始时对式样的描述都不可能面面俱到，这就需要我们不断和客户进行沟通与确认，通过双方的共同努力，逐步把项目做好。