`
kang
  • 浏览: 474611 次
  • 性别: Icon_minigender_1
  • 来自: 上海
社区版块
存档分类
最新评论

对日软件外包的一点感受

阅读更多

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

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

 

 

以上是我这一年多来对日软件外包方面的一点感受,现在就想到这么多,先写到这,以后有机会再写。

 

 

1
0
分享到:
评论
5 楼 qbqopen 2008-12-22  
我们称EXCEL为鬼子的国粹
现在一说国粹就是EXCEL
4 楼 aqining 2008-08-20  
发到国内做的活,一般都比较正规。日本现场开发,大都也比较正规,但是哪里都有胡来的人,胡来的公司。

其实也可以不按照客户的要求做,前提是你取得了客户的信任,而且自己有一套管理体制,譬如CMM。

开发的,好多客户的需求不明确或者说不清楚,你得快速做出原型,然后再让客户去提出具体的要求
3 楼 jubin2002 2008-08-16  
恩,看完很有感触
2 楼 kang 2008-08-16  
是啊,在做事的严谨和认真方面,我们是要向人家学习!那样,我们中国会进步得更快!
1 楼 xieye 2008-08-16  
所以日本人的成功都不是偶然的,有必然因素。
国内能有多少单位部门这样做事呢?

相关推荐

    对日软件外包需求工程

    在IT行业中,对日软件外包是一项重要的业务领域,它涉及到为日本公司开发和维护软件解决方案。这个主题涵盖了一系列技术和管理层面的知识点,包括但不限于需求工程、项目管理、跨文化交流、软件开发过程、质量保证和...

    软件外包行业深度分析

    尽管网上已经有很多关于软件外包的信息,但是这些信息很多都是媒体记者的报道,他们只是从旁观者的角度看待软件外包,缺乏一定的深度和实践感受。还有一些来自非软件外包的人士,基于他们主观的理解和推测,认为软件...

    对日软件外包项目的项目管理

    刚刚结束的大连对日软件大会,主题资料,个人认为非常好。

    软件外包 软件 软件外包 软件

    在IT行业中,软件外包是一种常见的业务模式,它涉及到企业将软件开发、维护或升级等任务委托给外部的专业公司或个人来完成。这种模式在全球范围内广泛采用,尤其在韩国这样的国家,由于其高度发达的IT产业,软件外包...

    对日软件外包 日语IT词汇介绍

    对日软件外包 日语IT词汇介绍 常用词汇

    对日外包软件开发常用日语

    在对日软件外包开发中,以上词汇和句型是开发人员必须掌握的基础知识。这些词汇覆盖了从基本编程概念到具体的技术实施,再到项目管理和用户交互等方面。良好的日语沟通能力可以显著提高项目的成功率,减少误解和沟通...

    高校对日软件外包Java Web项目开发人才培养.pdf

    "高校对日软件外包Java Web项目开发人才培养" 通过对高校对日软件外包Java Web项目开发人才培养的研究,我们可以总结出以下几点关键知识点: 1. Java Web项目开发技术:Java Web项目开发需要掌握Java语言、Java ...

    日语软件开发词汇 对日外包 Java

    Java 日语软件开发词汇 对日外包 软件开发词汇

    对日软件外包面试时的自我介绍

    在对日软件外包面试中,自我介绍是展现个人能力和经验的关键环节。这不仅是一次语言能力的测试,更是展示你专业技能、项目经验以及沟通能力的机会。以下是一份详细的自我介绍模板,你可以根据自己的情况进行调整,...

    对日外包 软件开发 全真式样书

    真正的式样书,想从事对日外包的可以看下。

    对日外包详细设计

    对日外包的详细设计,名称为服务端管理软件详细设计书

    在日企及对日软件外包公司工作的十条原则

    在日企及对日软件外包公司工作,遵循一定的工作原则是至关重要的,这些原则不仅体现了专业素养,也是尊重日本企业文化的方式。以下是对标题和描述中所述的十条原则的详细解释: 1. 出勤时间:比正式上班时间提前10...

    个人软件外包合同模板

    随着技术的进步和市场需求的多样化,个人开发者或小型开发团队与需求方之间通过合作开发特定软件项目的案例日益增多。为了规范双方的合作关系,明确各自的权益与义务,一份详尽的个人软件外包合同显得尤为重要。本文...

    日企就业 对日软件外包公司日语面试问题集

    【日企就业对日软件外包公司的日语面试问题集】主要关注的是求职者在日语能力和软件开发经验方面的准备。以下是对这些知识点的详细说明: 1. **自我介绍(自己紹介)**:这是面试的开场白,要求简洁明了地介绍自己...

    对日软件外包

    对日软件外包学习总结,以及学习的内容等资料。

    对日外包软件工程师日语面试用语.doc

    【对日外包软件工程师日语面试用语】是指在应聘对日外包软件开发职位时,需要掌握的日语面试技巧和常用表达。这类职位通常需要工程师不仅具备扎实的编程能力,还要能够有效地用日语沟通,确保与日本客户或团队间的...

Global site tag (gtag.js) - Google Analytics