连载：Offshore时代的统筹人（4） 适可而止吧！-- 日本企业在中国不受欢迎的理由

连载：Offshore时代的统筹人（4）
原作：幸地 司 Ai-coach有限会社 2004/12/16 查看原文
翻译：kanji @ CSDN BLOG
*译者注：本系列名的“统筹人”一词原文中是“コーディネータ”（Coordinator），中文可译为“联络官 ,协调人,协作人”等。

适可而止吧！-- 日本企业在中国不受欢迎的理由

n 从中国企业的眼中打量一下日本企业。。。
在此之前，我们列举了一些日方眼中看到的中国外包开发的问题，在本系列的第一篇中，
我们介绍了一般企业直接做中国外包时如何消除不安的方法，还提到了如何顺利推动外包开发的交流方法。
在第二篇中，我们介绍了中国外包开发中实际发生过的失败事例以及从中得到的教训。进而在第三篇中，我们介绍了如何有效地实现外包项目立项的方法。

如果我们换个角度看看承接外包的中方企业所指出的一些问题的话，我们就会发现很多值得我们改善的问题。具体来看，比如：
1、 赴中国考察旅行时的一些礼节问题
2、 从项目意向开始到签约为止的耗时过的问题
3、 项目计划书与式样书的问题
4、 开发现场的交流问题
5、 日方轻视中方企业的问题
6、 日方负责人技术能力不足的问题
7、 责任分担暧昧造成的管理体制不健全问题
8、 日方缺乏管理层，问题过多依靠年轻社员，或者一股脑地扔给中方企业

这些问题很早开始中国企业就意识到了，但其中的大部分在中方的品质问题出现被忽略，
甚至几乎没有被怀疑过它们的存在。在本篇和下一篇中，我们要将这些中方看到的问题分为4个大类，分别进行解说。
① 式样总结能力不足
② 式样变更计划的混乱
③ 负责人的技术能力不足
④ 不讲理的条件压制

n 式样总结能力的不足 --- 只看一棵树，而看不到整个森林
中国企业那边传来最多的声音就是关于“式样总结”方面的不满。让我们来看一下其中
几个代表性的发言。

「全体的に仕様が確定しないまま、開発に着手せざるを得ない」
(在整体式样还未确定的情况下，就不得不着手进行开发)

「どの仕様が確定していて、どこが未確定なのかがあいまい」
（哪些式样已经确定，哪些还未确定？暧昧不清）

「全体構成と個別説明の対応が不明りょう」
（整体构成与个别说明件的对应关系不明确）

「要件の網羅性が悪く、論理的にすっきりまとまった資料が少ない」
（要件的网罗性差，缺乏系统、清晰的总结资料）

看到这里，希望你不要急着反驳道“由于式样不确定造成的失败不是外包开发固有的问题，日本国内的软件项目也一样的”。为什么这么说呢？或许读者们都有这样的经验，在日本国内的开发项目中，边设计边开发地将“暂定式样”固定下来的“日本式开发手法”下，的确有不少成功事例。
但是，为什么这样的“日本式开发手法”在外包的时候不能通用呢？“日本式”的情况下，发包方如果缺乏业务分析能力的话，委托开发的承接方企业或者人才派遣公司的SE来弥补这些不足之处是理所当然的。但是，开发的承接方换成中国企业也这么做的话，情况就不一样了。或者他们用日语写的式样书晦涩难懂；或者原先的老问题生出新问题，陷入恶性循环后，到最后弄不好项目经理自己都不知道该如何收摊了。
另一方面，式样书本身也存在问题。最近比较多的情况下，设计者忽视某些细分后的功能单位，缺乏逻辑性的思考，无法做到“不遗漏不重复”的设计标准。一些中方企业的项目负责人经常说，日本企业提供的式样书，大部分就是“只看一棵树，而看不到整个森林”。
日本企业经过长年的努力，已经做好了许多规范格式的模版，只要学会填空般地记述，谁都能轻而易举地写出式样书。但是，在这样的“标准化教育”的背后存在着一个陷阱。还是先别说“中国开发商做的“异常处理”以及数据“临界值/极限值”的处理问题太多”，实际上是日本方面的式样书里存在着各种遗漏，我们一定要认识到这一点。

某个中国IT企业内的风景
说一个我听说的事例：在某项外包项目中，日方提供的要件定义书完全派不上用场，然后日方特地赶去中国企业那边，在开发现场重做了一遍设计。日方调查原因时发现，由于日方几个SE分别作的要件部分中，USE CASE的精度不统一，所以根本无法将其翻译成中文后直接使用。类似这样的被无端浪费掉的工数，常常会成为外包项目预算超支的原因。
日本方面“只看树不看森林”，也就是那些缺乏“逻辑性思考”的设计书可谓不计其数。这些年WEB程序的外包项目逐渐成为主流，举一个这方面的例子来说明这个问题。
WEB程序的开发中，每一个画面都做一份对应的画面设计资料。如果不能将整体项目合理地分割成多个各个子项目的话，各式各样的矛盾就会因此发生。比较典型的有：
1、画面间的关联比较暧昧的话，整体的业务流程就难以把握。
2、需要共通化的处理在不同的设计书中散乱地出现，容易导致设计书的版本管理发生混乱。

如果发生这些问题的话，外国的SE一定会造成误解的。由于日方往往缺乏寻找自身问题的意识，所以在项目后期就会出现与外国企业在“责任追究”这个问题上纠缠不清的情况。这种情况发生后，两国企业的SE之间难免就会产生隔阂，最后往往会影响项目的进行。
除此之外，从中国企业那里常能听到这样的抱怨：
「同じミスが多い。日本側の類似見直しも足りない」
（相同的错误较多，日方缺乏举一反三修正错误的能力）

「提供されたサンプルのとおりに実装したら、仕様が違うといわれた（本来は、サンプルの提示ミス）」
（我们按照你们提供的Sample写代码，结果日方还说我们没按式样写）
*注：原因是日方提供的Sample本身有问题

以正确、易懂的方式传达式样
要是中国外包获得成功，除了在初期阶段要切实地把握好式样要是之外，还有一个大前提就是中方企业必须要拥有精通日语的管理层人才。此外，编写设计书时，还必须有意识地考虑到中方企业无法阅读某些暧昧的日语用词表现。不要光靠文章里文辞的表现形式，由余力的话，尽可能提供一些图解说明和Sample作为补充说明。

式样书制作和口头说明的窍门
所谓“窍门”其实就是要用“规范的书面语言”书写式样书，然后口头说明时正确地描述出来。比如：

明确记述正常处理与异常处理的式样
某项研究表明，系统开发时的异常处理部分，有70%是由程序员自己决定的。因此，在日本式的开发手法中，必须要注意不同式样书间的“网罗性”问题。日不，在制作外包项目的式样书时，必须是先明确哪些部分属于“暂定式样”，然后还要事先预备好将“暂定式样”转化成“明确式样”的时间和方式。

明确记述所有的处理条件
在判定条件与条件分歧的处理上，必须要将所有的内容明白无误地记述下来。即便某些内容对于日本人来说属于“常识性的问题”，但在外包项目中外国SE未必能准确地理解这些内容。具体来看，比如：
例1、判定条件：检索结果为1至99条记录，检索结果在1页画面中显示；
检索结果为100条记录以上，检索结果分2页画面显示。
问题点：检索结果为0条记录时的式样不明确；检索结果为200条以上记录时是否要分3页显示检索结果？

例2、判定条件：用户是“董事”的情况下，执行A处理；
用户是“部长”的情况下，执行B处理；
用户是“科长”的情况下，执行D处理；
除此以外的场合下，执行E处理。
问题点：“除此之外的场合”这一描述十分暧昧，比如“社长”“派遣社员”“打工”等职务的情况下要如何处理？用这种记述方法的话，必须要另外参考类似“用户权限定义”这样的文档，这就会造成误解的原因之一。（译者注：或许是原作者笔误，如果执行的处理是某个多态性的函数的话，是否存在一个“C处理”就成为问题了。）

预测发生错误时的处理
原则上，必须要事先预测程序交付使用后实际会遇到哪些故障情况。特别是日本的某些系统开发协议中，原本就签署了相关的“维护运用”协议，所以日方企业做设计时必须对“故障处理”的相关内容负责。

充分运用作为补充资料的Sample和数据
尽量避免“纯文章”形式的抽象说明，将内容细分后逐条描述，以及添加图文的说明方法都是十分重要的，将Sample或数据作为补充资料进行说明的话尤其有效。还有就是针对某些具体的业务流程（译者注：指软件要事先的业务流程）作单独说明的话也是十分可取的。

用词的统一
为了避免不必要的混乱，式样书中使用的语言必须“用词统一”。中国外包的情况下，要注意避免相同汉字不同含义的情况。比如：

用词	日语中的含义	中文中的含义
空白	空格	空格或NULL
空色	蓝色	容易误解为“无色透明”
年度末	3月末	12月末

中国企业看到的关于外包开发中的种种不足之处，最多的还是式样上的相关问题。因此，在作针对中国企业的外包项目设计书时，必须要时刻注意“具体性”和针对某些问题的“个别说明”。然后，在向中国企业传达式样的时候，日方应该避免“单行道”似地做说明，在做说明的同时还必须针对对方的理解度做口头上的确认。在做整理式样理解度的确认时，要着重对中国企业不擅长的“异常处理”“临界值/极限值”进行。请你一点要尝试一下这样做。

下回中，我们将探讨一下剩下的那几个日本企业自身的问题，“式样变更计划的混乱”、
“负责人的技术能力不足”、“不讲理的条件压制”。