中国外包开发成功与失败的“实态”

引子

上一篇中提到一个观点，要让中国外包获得成功，必须要明确“外包要做什么”这一目的。这次要给大家介绍一些中国外包的失败事例，以及通过研究这些事例获得的教训。

n       为什么日本在中国总是失败？

为什么很多日本企业在中国的外包开发一直失败呢？

至今为止，日本企业在众多的外包开发候选名单中选择了中国。如今的IT行业，无论

你个人喜欢与否，与中国和印度为代表的海外IT企业间的相互依存已经是不可缺少的了。如今已经是这样一个时代，即便日本企业的负责人不直接飞去中国，中方的企业代表也能来到日本，用日语做一次精彩的Presentation。

    

   让我们从这些事例开始研究失败的原因吧。

充满不信任感的代码评审（Source code review）

    某个中国外包开发项目的验收结果出来了。很遗憾，因为发现了几个BUG，所以验收没有一次通过。仔细分析一下原因，发现了有若干处的代码，并没有按照“编程规则”来编写。中国企业那边早就应该国做过好几次代码评审了……

    日方企业的开发负责人（统筹人）必须要追究BUG的成因，然后寻找避免重复发生问题的方法。于是，日方的负责人与中国企业的负责人之间，有了如下一段对话。

（译者注：对话日语内容有不少实用的地方，所以采用中日文对照的方式写下去）

日本 ：　「中国側のソースコードレビューはどうなっているのですか？先日報告されたソースコードレビューの報告書を読みましたが、何をどのようにレビューしたのか、よく理解できませんでした」

（中国方面的代码评审到底怎么做的？之前我看了你们提交的代码评审报告书，我看不懂你们是“针对什么问题”从而“如何做的评审”。） 

中国 ：　「ソースコードレビューで重点を置くのは、コーディング規約の確認です。ソースコードレビューは、別部署のリーダーである李さんに応援してもらい、既に3回も実施しました。李さんは、当社でも特に技術力に優れている人物です」

（代码评审的重点是确认是否遵照“编程规则”来写代码。评审的过程中，得到了另一个项目的PL小李的协助，总共实施了3次评审。小李是我们公司技术非常优秀的人物。）

   可是，对于中国方面的回答，日方负责人的脑海里出现了几个疑问。

1、  明明使用了专用工具对代码进行测试，为什么还会发生违反编程规则的情况？

2、  在代码评审会议上发言的，为什么只有小李一个人？

日方的负责人开始怀疑中方的代码评审工作是否只是形式上的了。他感到，在尽心尽力逐行做代码评审方面，中方的能力明显不足。由于代码不能一次通过验收，所以日方负责人要求中方再度实施代码评审。可这时，却得到了中方出人意料的回答。

日本：「コーディング規約を準拠しているかを再度見直すとともに、机上でのデバッグをもう1度実施してください」 

（请你们再仔细检查一下是否按照编码规则来书写代码，请在桌子上重新做一次检查。）

*译者注：在桌子上做检查的意思为“将代码打印出来逐行”

中国 ：「ご要望は分か りました。しかし、机上でのデバッグですが、その作業工数は非常に多いと思います。通常、当社では実施しません。紙の上でソースコードを追いながら要求仕 様を確認する方法などは、コーディングやり直しと実質的に変わりません。要求仕様の確認は、PC画面上からのテストで検証するものです。本当に必要でしょ うか？」

（您的希望我们十分理解。但是，打印出的东西作Debug本身就十分耗费工数，通常我们公司不会这样做。如果一边在纸面上逐行确认代码，一边确认代码是否符合式样要求，这样的做法与重写代码没有实质上的区别。关于式样要求的确认，应该通过画面上的测试来证实的。所以，您提案的方法真的有这个必要吗？）

     随后，中方的解释还在继续。

中国：「検収で見つかっ たバグはもうすぐ修正されるので、プログラムは安定稼動します。したがって、わざわざ追加費用をかけてもう1度ソースコードレビューを実施しても、その効 果には疑問があります。もし、机上のレビューだけですべてのバグは防止できるとなると、バグ摘出目標を上げる品質指標値の意味がないですね」

（因为验收过程中发现的问题我们会马上修正，所以能保证程序的稳定运转。因此，加入继续投入经费重做一次代码评审的话，我们十分怀疑是否能得到预期的效果。如果把代码打印出来看一遍就能防止BUG的话，那些写着BUG统计值之类的“品质指标值”不就没有意义了吗？）

    

    虽然他们的解释也情有可原，但日方的负责人始终无法接受这样的观点。日方正准备反驳之时，中方开发商的负责人又继续“阐述”他的观点。

中国：「当社の方針では、最も重要なのは納期を守ること、そして品質を確保することです。品質保証はプログラムの動作確認テストが効果的です。画面上から動作確認するテストが最も優れていると思います。

　テスト項目を増やし、何度も繰り返してテストするとバグ摘出率は高くなります。ソースコードの仕様チェックの概念はいいと思いますが、効率は良くないのではないでしょうか。例えば、あるプログラムを1時間かけてテストすると、効率よくバグが発見できるでしょう。

　ところが、机上でのデバッグとなると、レビュー者と担当プログラマが2人で一緒にソースコードレビューしなければなりません。2人で半日かけてレビューしても、バグの発見は難しいのではないでしょうか。

　また今回のプログラムには、複雑な計算アルゴリズムなどはありませんから、その観点での机上でのデバッグは必要ないと思います。

　従って、当社としては動作確認テストを優先し、もし時間に余裕があれば、後からソースコードの仕様チェックを行う。これでよろしいでしょうか？」

(我们公司的方针是，通过多次重复的测试来提高BUG统计值。通过审核代码来检查是否满足式样的观点是好的，但效率不就差了吗？比如，某个程序用1小时来做测试，能够高效率地发现问题。

可是，如果打印出来做一次检查的话，至少需要1名负责人与2名PG一起参与。而且，几个人做了半天也恐怕很难找到什么BUG。 

尤其是这次的程序，没有什么特别复杂的算法，从这个观点上我们认为完全没有打印出来作评审的必要。

因此，我们公司将优先采用“动作确认测试”，有余力的情况下做代码的评审。这样是否可以？)

以上就是中国外包的一个实例。

n       中国外包开发的教训

教训：囫囵吞枣般地看报告的项目负责人

    有一种说法，说在与中国打交道的日本人不能成功的原因之一就是“过度信赖对方”。在中国的外包开发中，囫囵吞枣般地接受对方的报告，听到对方说「すべて確認しました。もう大丈夫です！（都确认过了，已经没问题了）的时候，就属于这种情况。

     外包开发成功的企业中，项目统筹人必须存在能敏锐地洞察到对方国家的文化与交流方式的倾向。具有敏锐的洞察力的项目统筹人，需要从失败的事例中找到教训，是能将日本式的项目管理手法与外包开发委托方的企业文化巧妙相融的人物。

n       教训：经验不足加上文化背景相异，没有胜算

中国的软件公司里，项目负责人往往是20岁后半或30岁左右的青年SE。他们中的大部分

技术优秀，但在在沟通能力方面还略显不足。有时在系统交付后出现重大BUG等紧急情况时，即便日方严重抗议，他们也不会主动将问题的严重性汇报给他们的上级。

    中方软件企业内的信息不通畅，主要是由信息管理制度的不健全造成的，另一个重要的理由就是“技术者的责任感”（译者注：原文中为“技术者的气质”）这一问题。但这绝不是说，“中方品质意识地下”或者“中方不够聪明”，这完全是两个层次的问题。单纯地来看，日本式的开发手法中有极为绵密的“报告”“联络”“商量”的过程，而中国开发商这方面却十分欠缺。

　　让我们回过头去看一下先前提到的那个“代码评审”的事例，中方对于“评审”（Ｒｅｖｉｅｗ）的认识与日本软工教科书中的认识之间，究竟存在怎样的差异。

　　　

日本

中国

代码评审的目的

与式样要求的整合性等方方面面的问题，严密地检查代码的细节部分

指导与确认“编程规则”与编程技巧等

评审手法

由下至上（Bottom-Up方式）的改善过程

从下至下（Top-Down）的指示

评审实施者

相关所有人员

理解程度较高的某一人

评审结果的信息交换方法 

所有成员都聚在一起讨论问题，所以当场就能共享信息

技术较高者将他自己的审核结果转达给相关的担当者。相关信息没有实现项目组内的共享。

   

    鉴于以上这些教训，我整理了一下这些失败事例的相关对策。

1、  针对日本式的开发过程进行强化指导说明

2、  不忽视结果报告的细节，对开发中的各个过程实施状况做彻底检查

n       其他的一些事例

中国外包开发失败例

1、考虑到中国开发商希望从上流设计开始承接项目的愿望，所以日方企业从基本设计开始向中国发包。但实际上从开始到最后始终需要日本人SE常驻中国，所以几乎没有实现成本削减的目标

（译者注：由于日本公司制度的原因，日方员工赴中国出差的情况下，从食宿到津贴各方面的成本非常高）

2、缔结合约的时候，日方企业向中方提供了开发标准手册。但是，后来才发现这份手册是10多年前制定的，当时的老系统环境的开发标准在开放源代码的开发中完全没有参考价值。

3、试验性的小规模发包获得了成功，所以紧接着就将一个大规模项目发包去中国。可是，之前的一个中方项目负责人突然辞职，一切又要从头开始了……

4、在与中方开发商签约时，要求中方出示过去开发项目的文档。结果他们将记载着客户名称的设计文档直接复印给我们……似乎他们完全没有保密意识。

（译者注： 对日项目中常常会被要求签订“机密信息保持协议”，日本项目大多为企业订制项目，加上日本企业对自身信誉的重视，所以这是一个他们是否看重保守机密这个问题）

5、大连的某个公司，传说有大量精通日语的职员。但后来发现，事实上都是同一个人以不同人的名义给各个客户公司回复MAIL。

6、从中方的企业招聘了几个研修生来日本，工作的时候遇到项目里的几个中国人留学生，在得知留学生们的工资后，他们到处诉说自己对收入差距的不满。最后失去积极性的他们搅乱了整个项目的协调，在项目未完的时候便强制总他们回国。事后，还听说他们回国后就跳槽了。

7、因为发生了式样变更，所以使用专用的“联络票”进行详细说明，对方回答“了解しました”（明白了）之后便放心了。可是，过了很久之后发现程序当时并没有被修改。日方对发生这样的BUG表示抗议（译者注：作为日本企业的习惯，如果没有及时对应式样变更的内容就会被认为是BUG），可中方企业也针锋相对地回答道“当時は連絡票で説明を受けたが、正式に仕様書が修正されていない。だから仕様変更の依頼は受け付けていない”（当时我们收到了联络票，但正式的式样书并没有被修正。所以我们没有接受这个式样变更的要求。）

８、日方企业里出于培养年轻社员的目的，名义上说给年轻社员磨练“国际化感觉”的机会，但实际别说是外语能力，甚至连基本的项目管理知识都不具备的年轻人担任外包项目的联络工作。结果，中方企业不把这个年轻社员当回事，项目最终破裂失败。

n       中国外包的成功事例

     当然，还有相当多的中国外包成功经验。比如说：

1、  从业务应用程序到嵌入式开发，在多个开发领域削减了成本，日方项目组改善了效益

2、  有意识地认识到对方是中国企业，从而提高了自身的设计书质量和设计水平

3、  通过外包项目对中方企业的指导，提高了自己企业对外包项目的领导能力

4、  以外包为契机磨炼出了“国际感觉”，从而进一步实现了海外市场的开拓与投资

n       生鱼片文化和麻婆豆腐文化

（译者注：与本BLOG最初的译文以题目相同，但文章出处有所不同。在本文中原作者在对这个论点有了一些补充和内容也略有调整）

    前几天，我在东京都内的的某个中国人社长那里听来一段话，是针对中日两国文化的差异打了个比方，我来介绍给大家看一看。

日本式文化：生鱼片文化

    日本是生鱼片文化。

    所谓生鱼片，不用多做说明大家就知道，就是将鲜鱼切成生鱼片。这种料理方法恐怕几千年前就在日本存在了吧。到了21世纪的今天，从北海道到冲绳，无论你在日本的什么地方，生鱼片基本的口味和形状几乎没有任何区别。当然，即便在日本以外的地区，即便鱼的种类不同，生鱼片的口感依然让你觉得“生鱼片就是这个味道”。还有，一部分精致的生鱼片，甚至上升到了艺术的高度。

中国文化：麻婆豆腐文化

     另一方面，中国文化就是麻婆豆腐文化了。

     同一道麻婆豆腐，如果你在四川，正宗的川菜之“辣”绝对会超乎你的想象；如果你在北京，味道却会变得醇厚起来；如果你在东京，甚至还会听到在日的中国人说它“不够味”。也就是说，不同地域的麻婆豆腐，会因为当地人的口味而调整“辣”的程度。

     更有趣的是，有一种著名的说法认为“麻婆豆腐是种偶然的产物”（关于麻婆豆腐的起源有很多种说法）。我去四川的时候还曾经听人说过，“豆腐的制作方法也是一个偶然带来的”。看来，麻婆豆腐真是一道比较“随意”的菜肴（译者注：原文中为“いいかげん”表示“适度”）。

     这个比喻告诉我们了一个中国 外包开发的关键问题。日本人重视“规律”“过程”“美感”；中国人重视最后的结果，擅长随机应变。在麻婆豆腐文化下的中国，虽然外包项目中呈现出种种品质 管理的问题，但他们却拥有日本不具备的发达的火箭发射技术。如果理解了“目标”，并将切实的目标“可视化”之后，在软件工程的领域里也能正确完成高精度的 工作。

     或许我的部分读者中有过本文 前半部分提到的失败经验。但即使你们强调你们有过切身的失败经历，我也能认同你们的部分观点，比如“中国开发上品质观念落后”“中国是个软件工业的落后国 家”等等。因为，你们的观点无非也就是我们共同的“生鱼片文化”中强调的“一切均一”的表现。

     我认为，最重要的还是要讨论 日本和中国不同的“文化土壤”这个问题。要准备好谁都看得明白的，并具有“客观性”的数据，在双方都能接受之前要充分要换意见。软件领域中，论项目管理的 经验的话，日本还是略微领先的，所以就毫无顾虑地提出你们的要求吧。左右外包开发成功与否的关键，并不仅仅是看最终结果，最重要的是在开发过程中的时时考 察各个开发环节是否按照要求正确实施。

    如果不松懈相互间的过程确认，我相信过去很多的失败事例能防范于未然。