日式外包与国人 博客分类： 生活 软件测试项目管理企业应用Excel工作
1.不管我们对日本怎样的厌恶，日本人还是给我留下了非常细心、要求严格的印象，工作中不论项目的大小，都需要我们非常细心。做出的设计文档要格式统一，甚至细小到页边距、字体等我们通常认为不重要的地方；对于程序的质量那就要求得更加严格了，画面上文字的错误也算一个bug。虽然这样的要求近乎苛刻，但是既然我们是乙方，日本公司是甲方，这种要求我认为还是更高的要求自己，尽量做到细心，这样会给日本留下对方对质量要求高的感觉，有利于日后的沟通和收到更多的项目。我们从事对日项目的目的之一不就是想得到更多的项目嘛，细心一点对我们自己也有好处，何乐而不为呢。
2.日本对于软件技术的发展比我们确有高超之处。我们国内也有许多高水平的软件人才，但大多是单打独斗，要么就是陷于项目之中无法研究软件的发展。而日本的大公司如NEC、富士通等因为项目众多、同类项目也多的缘故，在软件开发的过程中积攒了相当多的经验，并开发出了许多针对程序开发人员使用的工具，也提出了许多好的开发流程和方法，不仅节省了大量的开发成本，也显著的提高了程序的质量，缩短了开发周期。感触最深的就是日本在J2EE框架上建立的开发体系和一系列工具丝毫不比欧美的（例如Status）差，而且更加实用、更加方便，而J2EE的框架标准是由欧美企业最先提出的；另一点是日本在开发过程中制定了先进的开发流程和标准，虽然与欧美提倡的CMM标准叫法不同，但它们两者对软件开发流程的规定却相当的类似，这是日本在长期的开发中总结出的公司内部经验，从这两点可以看出日本在软件发展上的实力和前瞻的眼光。
我们国内虽然高水平的软件人员很多，但是却没有高水平的公司，我们虽然从内心里厌恶日本，但却不能忽视日本软件上的高水平（当然日本也有数量众多的低水平公司，但我指的是象NEC、富士通等的大公司），我们可以通过大量对日开发的学习，缩短与日本之间的差距，借助他们好的研究成果，来更快地发展我国的软件开发水平。
吃奶油与啃骨头
―目前对日外包的一些看法
?
最近连着2个项目都做砸了，一直闷闷不乐，大家原因分析来分析去也没个头绪．整个项目亏本了不说；弟兄姐妹们也天天加班，忙得个昏头转向；客户还很不满意，整天向老板告状，说这里不好那里又不好，搞得天天争争吵吵，又吵不出个结果来，一句话就是郁闷啊．
干脆早点回家，上上网看看新闻，无独有偶，在日经BP社也报道了近来日本对外发注的软件多有失败的情况，文章很短，但切中要害，现抄录如下：
日本对海外软件开发敲响警钟
【日经BP社报道】日本企业在将开发工作外包给亚洲软件公司时出现问题而失败的例子层出不穷。“日方发包者不经意间将自己的做法强加于人，这种态度引发了很多问题”——从事软件开发管理与质量管理研究的日本武藏工业大学工学院信息系统工程专业的兼子毅讲师对此敲响了警钟。
兼子毅于9月份访问了中国，就软件开发问题分别听取了日本发包方与中国承包方的意见分歧。在某一软件开发案例中，当描述软件标准的文件交给中国工程师时，由于没提出任何疑问，日本发包者觉得很放心，但最后却发现中国工程师的理解大相径庭。“中国工程师认为，主要原因是文件不完整、条理不清。而在日本，即使表述不清晰，也常常可以通过相互关系补充完整。但此次仍带着这种习惯交到中国，没有进行提醒与确认”（兼子毅）。“此外，对于发包方大量更改标准，有的中国工程师也觉得非常吃惊。如果标准更改很多的话，就必须从一开始就讲清楚”（兼子 毅）。
在发生这种问题时，“中国的工程师就会据理力争，指出发包方的文件不清楚，标准变更的界限不明确等”（ 兼子毅）。
此外，兼子毅还指出：“许多中国工程师都希望软件开发过程能够体系化”。并担心“在日本并不希望软件开发形成体系。这样做的人似乎也非常少”。
向中国等亚洲各国进行软件发包失败时，“有相当多的日本人都认为是文化差异造成的，从而陷入了思维僵局 ”（兼子 毅）。并呼吁“应当重新审视基本的开发进程”。
兼子毅担任“第22届软件生产质量管理专题讨论会”（12月4～5日举行，由日本科学技术联盟主办）的委员长。在主题讨论会上，将提出“在与亚洲一起进行产品制作时，希望能找到一个取长补短的途径”（兼子毅）。（记者：安保 秀雄）
文章很显明地提出了两个原因：一个是文件不完整，条理不清晰．另外一个就是文化差异．
再笔者近几年从事的对日软件项目来看，大多数项目失败的原因就在于需求不明确，反应到文档上就是文件不完整，条理不清晰，有时候可以这样理解，有时候又可以那样理解，给中国程序员造成的印象就是不知道怎么理解．实际上在与国内的项目一样，失败的因数大多数是在项目启动的时候就埋下的．
日本对外发包的软件大多数是采用瀑布式模型开发流程，一般说来，在需求分析和详细设计阶段的工作是在日本完成，这中间有可能会要求中方的程序员一起参加完成．然后工作重心就转到中国或者是其他劳动力价格比较低廉的国家来做，有时候日方也会来到中国一起完成Coding，UT和SI的工作．做完SI后的具体工作又转回到日本，由日本的工程师做PT和RT的工作（主要是针对实际环境的测试和验收测试,不同的公司做法也许略有不同）,这个时候在中国程序员的任务就是BUG对应,修改测试阶段发现的BUG以及设计的变更.在做完一系列测试后就是具体的运用阶段,这个时候就基本上算是项目结束了.
这样做最大的好处就流程非常容易理解，管理起来方便，外包出去也界限明显，在设计阶段做完后以式样的方式将文档交到中国，中国公司做完后把代码及相关的测试文档交还给日方．在项目比较小的时候条理就非常清楚，成功的概率也很大．然而就系统分析的角度来说这未必是件好事，在绝大多数情况下，用户是没有办法完全说明清楚他到底想要做些什么事情，中间就必须要经过许多反复和叠达．如果项目比较大的话，这些变更点的记录以及针对记录的管理工作就是一件非常可怕的事情.在笔者最近的项目中，设计方不是最终用户，很多事情也没有办法做决定，于是许多联络票传来传去，短短半年的项目就有近千张联络票，甚至有时候根本就不知道联络票在谁手上，出现了所有的人都在等对方的回答的情况．特别是在项目后期，相关的确认就不计其数．
在和日本客户交流的时候，中日文化之间的差距会很大一部分地影响沟通的效果。首先不得不提的就是民族感情问题，中日双方都有一些人藐视对方，就是一些中国人瞧不起日本人，而一些日本人瞧不起中国人。在讨论具体问题的时候，如果把这种情绪带到桌面上来就很有可能是言辞过于激烈，双方针尖对麦芒，互相不让步，甚至于造成沟通的中断，更影响了以后的沟通。
技术向导与质量向导。记得一次在东京的朋友聚会上，有位值得尊敬的前辈谈到中国的工程师和日本的工程师时就指出：中国工程师是以技术为向导的，日本工程师是以质量为向导的。中国程序员特别注重项目中技术的应用，也关心在项目中能不能学到什么新技术。在开发中，如果解决了一个新的技术问题，很多程序员会有一种自然而然的成就感。这是好的一面，反过来，很多时候就会犯“技术镀金”的问题，将一些可以简单化的问题做得很复杂，使得控制难度加大，客户又时候也很难接受这些，经常会发出“本来不要多少时间的东西怎么要做这么久”之类的疑问；还有一个特点就是不重视容易解决的问题，在一个项目中曾经出现了一个这样的事情：
一个有Login的画面，“Login”这个字符串被错误地写成了“登录”，然而在日语中“登录”是保存数据到数据库中的意思，于是客户指出这是一个BUG，要求承包方修改。问题发到承包方后，负责修改的程序员S表示这个很容易修改，几分钟就改好了。然而等到客户拿到新版本后仍然发现这个问题，问起原因来，S回答忘了。客户很生气，认为这是一个很严重的质量问题，于是顺着BUG的控制流程，从文档的管理，代码的修正，测试，及后来的review，从头到尾查了个遍。S很不理解：“不就是改个字符串，用得着这么兴师动众吗？”
相对来说，也许是终身事业制的关系吧，日本员工和企业的前途是绑在一起的，日本人很重视质量，出现了一个问题首先想到是不是质量上的问题，会不会影响公司的形象等等。而对于中间采用了什么技术反而不太关心，实现了就可以了。
日本人的推诿和中国人的浮躁。也许同样是终身事业制的原因，日本大公司内部吃大锅饭的现象很明显，在工作中日本人之间相互扯皮和推诿，从上面到下面，没有一个人愿意做决定，最后不得已开会讨论，经过漫长的马拉松会议后，得出的结论往往是先问问用户，按照用户的意见做。这样经常浪费勒了不少时间，也会把不少应该是在设计阶段解决的问题带到coding阶段，给后期工作带来很多麻烦。与此相反的就是中国企业的某些浮躁现象，东西做了80%就认为差不多够了。往往我们开发出来的软件基本功能是实现了，但小问题一大堆，离真正的优秀产品差的远。
目前，日本方面也开始对这些问题进行了反省，有些公司开始冷静地考虑将软件发包到中国是否能够真地节省费用，带来更好的利润．有一种值得注意的倾向就是招聘中国的程序员直接到日本工作，而不是将项目发包出去，这样费用或许会高一些，但就产品的质量来说容易控制多了．
记得几年前和某个软件公司的老总闲谈的时候，他意气风发地评论当时对日外包的市场，说正是吃蛋糕上的奶油的时候，不知道他有没有想到：奶油吃多了会坏牙齿的．看来几年后的今天应该是吃蛋糕的时候，随着市场的成熟，啃骨头的日子也很快就要到了．我们的软件公司是否准备好了？我们的程序员是否准备好了呢？
?
日本外包流程
不知道这个网站上做软件外包的人是不是很多。我只能说说工作这两年，我做对日软件外包的经验。一般接的日本外报是从pd设计开始的，所谓的dd设计书已经写好了。日本人很喜欢用excel，所以设计书的格式多为excel和owepoint格式。
所谓的dd设计一般由资深的系统工程师完成，像那些在日工作的中国人可能会担当这部分工作，还有一种可能是日本公司的工程师完成dd设计（也就是详细设计）.其实dd设计完成了，日方也大致会提供一个简单的框架，这样程序的框架也定下来了。我们的工作是从写程序设计书(PD)开始的，pd书按照dd书写就行了，在写pd书的过程中主要是为了让程序员熟悉业务，并且尽可能地找出其中的设计错误，特别是严重的逻辑错误。
pd书写完了，会有一个pd review会议，目的是为了检查pd是否合格。
写程序的时候到了，通常写程序花不了许多时间。
更多的时间留给的是测试。测试很重要。UT测试必须达到某种覆盖密度，比如多少行代码对应多少个测试项目表呀都有严格的规定。UT测试完成了，那么开始集成（SI）测试吧。联调才是麻烦的开始。一般 SI测试都有好几轮。
测试的文档要求很严格，比如找到一个bug，必须对应一张bug票，还必须有相应的测试项目表。
交货的时候到了，这才是真正磨人的时候，一般说今天交货，肯定提前一个或者两个星期就准备好，但是客户不满意，这中间就不停的返工，修改再修改，经常加班是常事！
当然中间的沟通，比如说dd设计失误才是最麻烦的事情。需要联络票，并且与dd设计者沟通，请求他们修正dd书，然后你改代码，改测试代码，改测试文档。
上面大概就是对日外包的一个过程。中间好多时候都很烦，特别是遇到无法沟通和持续加班的时候！
当然我站的角度比较低，如果是一个项目经理来写做日本外包的经验就很不一样了