吃奶油与啃骨头―目前对日外包的一些看法

日本对海外软件开发敲响警钟

【日经BP社报道】日本企业在将开发工作外包给亚洲软件公司时出现问题而失败的例子层出不穷。“日方发包者不经意间将自己的做法强加于人，这种态度引发了很多问题”——从事软件开发管理与质量管理研究的日本武藏工业大学工学院信息系统工程专业的兼子毅讲师对此敲响了警钟。

兼子毅于9月份访问了中国，就软件开发问题分别听取了日本发包方与中国承包方的意见分歧。在某一软件开发案例中，当描述软件标准的文件交给中国工程师时，由于没提出任何疑问，日本发包者觉得很放心，但最后却发现中国工程师的理解大相径庭。“中国工程师认为，主要原因是文件不完整、条理不清。而在日本，即使表述不清晰，也常常可以通过相互关系补充完整。但此次仍带着这种习惯交到中国，没有进行提醒与确认”（兼子毅）。“此外，对于发包方大量更改标准，有的中国工程师也觉得非常吃惊。如果标准更改很多的话，就必须从一开始就讲清楚”（兼子 毅）。

在发生这种问题时，“中国的工程师就会据理力争，指出发包方的文件不清楚，标准变更的界限不明确等”（ 兼子毅）。

此外，兼子毅还指出：“许多中国工程师都希望软件开发过程能够体系化”。并担心“在日本并不希望软件开发形成体系。这样做的人似乎也非常少”。

向中国等亚洲各国进行软件发包失败时，“有相当多的日本人都认为是文化差异造成的，从而陷入了思维僵局 ”（兼子 毅）。并呼吁“应当重新审视基本的开发进程”。

兼子毅担任“第22届软件生产质量管理专题讨论会”（12月4～5日举行，由日本科学技术联盟主办）的委员长。在主题讨论会上，将提出“在与亚洲一起进行产品制作时，希望能找到一个取长补短的途径”（兼子毅）。（记者：安保 秀雄）

文章很显明地提出了两个原因：一个是文件不完整，条理不清晰．另外一个就是文化差异．

再笔者近几年从事的对日软件项目来看，大多数项目失败的原因就在于需求不明确，反应到文档上就是文件不完整，条理不清晰，有时候可以这样理解，有时候又可以那样理解，给中国程序员造成的印象就是不知道怎么理解．实际上在与国内的项目一样，失败的因数大多数是在项目启动的时候就埋下的．

日本对外发包的软件大多数是采用瀑布式模型开发流程，一般说来，在需求分析和详细设计阶段的工作是在日本完成，这中间有可能会要求中方的程序员一起参加完成．然后工作重心就转到中国或者是其他劳动力价格比较低廉的国家来做，有时候日方也会来到中国一起完成Coding，UT和SI的工作．做完SI后的具体工作又转回到日本，由日本的工程师做PT和RT的工作（主要是针对实际环境的测试和验收测试,不同的公司做法也许略有不同）,这个时候在中国程序员的任务就是BUG对应,修改测试阶段发现的BUG以及设计的变更.在做完一系列测试后就是具体的运用阶段,这个时候就基本上算是项目结束了.

这样做最大的好处就流程非常容易理解，管理起来方便，外包出去也界限明显，在设计阶段做完后以式样的方式将文档交到中国，中国公司做完后把代码及相关的测试文档交还给日方．在项目比较小的时候条理就非常清楚，成功的概率也很大．然而就系统分析的角度来说这未必是件好事，在绝大多数情况下，用户是没有办法完全说明清楚他到底想要做些什么事情，中间就必须要经过许多反复和叠达．如果项目比较大的话，这些变更点的记录以及针对记录的管理工作就是一件非常可怕的事情.在笔者最近的项目中，设计方不是最终用户，很多事情也没有办法做决定，于是许多联络票传来传去，短短半年的项目就有近千张联络票，甚至有时候根本就不知道联络票在谁手上，出现了所有的人都在等对方的回答的情况．特别是在项目后期，相关的确认就不计其数．

在和日本客户交流的时候，中日文化之间的差距会很大一部分地影响沟通的效果。首先不得不提的就是民族感情问题，中日双方都有一些人藐视对方，就是一些中国人瞧不起日本人，而一些日本人瞧不起中国人。在讨论具体问题的时候，如果把这种情绪带到桌面上来就很有可能是言辞过于激烈，双方针尖对麦芒，互相不让步，甚至于造成沟通的中断，更影响了以后的沟通。

技术向导与质量向导。记得一次在东京的朋友聚会上，有位值得尊敬的前辈谈到中国的工程师和日本的工程师时就指出：中国工程师是以技术为向导的，日本工程师是以质量为向导的。中国程序员特别注重项目中技术的应用，也关心在项目中能不能学到什么新技术。在开发中，如果解决了一个新的技术问题，很多程序员会有一种自然而然的成就感。这是好的一面，反过来，很多时候就会犯“技术镀金”的问题，将一些可以简单化的问题做得很复杂，使得控制难度加大，客户又时候也很难接受这些，经常会发出“本来不要多少时间的东西怎么要做这么久”之类的疑问；还有一个特点就是不重视容易解决的问题，在一个项目中曾经出现了一个这样的事情：

一个有Login的画面，“Login”这个字符串被错误地写成了“登录”，然而在日语中“登录”是保存数据到数据库中的意思，于是客户指出这是一个BUG，要求承包方修改。问题发到承包方后，负责修改的程序员S表示这个很容易修改，几分钟就改好了。然而等到客户拿到新版本后仍然发现这个问题，问起原因来，S回答忘了。客户很生气，认为这是一个很严重的质量问题，于是顺着BUG的控制流程，从文档的管理，代码的修正，测试，及后来的review，从头到尾查了个遍。S很不理解：“不就是改个字符串，用得着这么兴师动众吗？”

相对来说，也许是终身事业制的关系吧，日本员工和企业的前途是绑在一起的，日本人很重视质量，出现了一个问题首先想到是不是质量上的问题，会不会影响公司的形象等等。而对于中间采用了什么技术反而不太关心，实现了就可以了。

日本人的推诿和中国人的浮躁。也许同样是终身事业制的原因，日本大公司内部吃大锅饭的现象很明显，在工作中日本人之间相互扯皮和推诿，从上面到下面，没有一个人愿意做决定，最后不得已开会讨论，经过漫长的马拉松会议后，得出的结论往往是先问问用户，按照用户的意见做。这样经常浪费勒了不少时间，也会把不少应该是在设计阶段解决的问题带到coding阶段，给后期工作带来很多麻烦。与此相反的就是中国企业的某些浮躁现象，东西做了80%就认为差不多够了。往往我们开发出来的软件基本功能是实现了，但小问题一大堆，离真正的优秀产品差的远。

目前，日本方面也开始对这些问题进行了反省，有些公司开始冷静地考虑将软件发包到中国是否能够真地节省费用，带来更好的利润．有一种值得注意的倾向就是招聘中国的程序员直接到日本工作，而不是将项目发包出去，这样费用或许会高一些，但就产品的质量来说容易控制多了．

记得几年前和某个软件公司的老总闲谈的时候，他意气风发地评论当时对日外包的市场，说正是吃蛋糕上的奶油的时候，不知道他有没有想到：奶油吃多了会坏牙齿的．看来几年后的今天应该是吃蛋糕的时候，随着市场的成熟，啃骨头的日子也很快就要到了．我们的软件公司是否准备好了？我们的程序员是否准备好了呢？