(转)Offshore时代的统筹人---8

连载： Offshore 时代的统筹人（ 8 ）
原作：幸地 司 Ai-coach有限会社 2005/04/ 1 6   查看原文
翻译：kanji @ CSDN BLOG
*译者注：本系列名的“统筹人”一词原文中是“コーディネータ”（Coordinator），中文可译为“联络官 ,协调人,协作人”等。
 “适合”与“不适合”进行中国外包开发的业务 

本连载一直以在外包开发中大展身手的“开发统筹人”为话题展开，在第 7 篇中我们提示了在成功的外包开发中必不可少的“组织性问题解决手法”。充分运用这样的“组织性问题解决手法”，可以改善原本过渡依赖项目经理个人能力的开发体制（译者注：原文为“虚弱体制” ）。

但是，从实际情况中看，不少外包项目在开始之前就注定了要以失败而告终。可以列举的原因有，先是错误地选择中方开发商，然后在合同交涉过程中暧昧，接着又错误地划分外包对象（系统、发包规模、发包范围、发包工程等），还有错选 Bridge SE ，不完善的开发体制等等。

这次我们将解说一下“适合”与“不适合”进行外包开发的项目的特征。在后半部分，将列举一个嵌入式开发的外包事例，向大家介绍一下在理想与现实的落差间困惑着的某日本企业的心声。

n       适合进行中国外包开发的项目
有些中方企业的成长速度着实令人惊叹。 2 年前第一次打交道时还是步履蹒跚的起步初期，今年却告诉我他们已经获得了 CMM3 的认证。

但无论是取得着实成长的中方企业，还已经在外包开发上上了轨道的日本企业，都似乎没有意识到这样一个问题 ---- 并不是所有的开发项目都适合做中国外包。比如，至今还不存在“金融应用项目或生产管理系统，容易在中国外包中获得成功”这样明确的定论。

另一方面，我们换一个切入点来考量外包开发时，就能发现那些适合进行外包开发的业务。

在中国实施外包开发的大致有如下 4 个种类的业务。
1、  研究开发（技术调查，原形设计 * ） （ * 译者注： prototyping ）
2、  套装软件开发
3、  业务应用软件开发
4、  嵌入式开发

第一种的“研究开发”主要是指与中国的大学进行共同研究，或者与大学合办企业，从事高端技术的开发研究等事例
所谓“套装软件开发”，主要是指类似微软的“ Microsoft Office ”的海外开发，以及日本 ERP 软件在中国进行改良、升级的事例。

根据一些软件品质专家的意见（译者注：原文此处略有广告色彩 ），以上四种业务实施中国外包的难易度是逐渐上升的。即，嵌入式软件开发是外包项目中最难的一种。

翻开日本的软件外包开发历史，最早可以追溯到上世纪 70 年代。当时，日本以获得美国的先进技术为目的，以硬件产业为中心向海外进军。此后的 80 年代里，软件产业的也扩展到了海外市场。如今以成本削减为目标的外包，据说是与韩国的贸易投资过程中发展起来的。

90 年代中期开始的印度，以及 2000 年后的中国外包开发逐渐崭露头角。日本的外包开发历史，可以说是顺着上文中提到的 4 种外包业务的类型的变化而逐渐发展起来的。

说个题外话，如今的一些信件的地址输入或者呼叫中心等业务的外包正在中国全面展开，或许这也预示着将来 IT 行业内全方位的服务内容会逐渐向中国转移。

n       嵌入式软件开发的现状
前段时间，在笔者开办的 外包开发的电子杂志 里做了一次嵌入式软件开发的读者调查。让笔者感觉印象最深刻的是，有效问卷中 7 成以上的读者认为“在中国做嵌入式开发很困难”。

嵌入式软件开发与业务应用软件的开发相比，由于在开发环境以及过程上有所区别，所以恐怕不能直接进行单纯的难易度比较。但即便这样，那些参与了读者调查的众多相关人士，他们似乎也都体验到了中国外包与嵌入式开发之间“相互感冒”的部分。

在问卷回答中，有不少读者在 BBS 里留下了非常详细的评语，我来介绍一下其中的部分内容。

　組み込み系のソフト開発といっても、最近は昔と異なって、内容を分けて考えた方がよいと思います。例えば、ハード制御に近い部分と、ユーザーインターフェイスに関連する部分です。CPUの性能向上や集積度のアップ、価格の低下などにより、組み込み系の開発も、昔のようにアセンブラでの調整を要する部分は随分減ってきています。C言語で開発する部分が大半を占めるようになっているでしょう。
即便说是嵌入式开发，如今也与过去不同了，我认为需要将区分内容后来加以考量。比如，可以分为“硬件控制”的部分，以及“用户接口及其关联”部分。随着 CPU 性能以及集成度的提高，加上价格下降等因素，过去的那些需要在汇编级别调整的部分如今已经大量减少了。可以说，如今 C 语言已经占了其中的大半部分。

　 しかし、ハードとの絡みの部分については、デバッグにおいてターゲットのハード環境を必要とすることから、オフショアしづらい点が出てくるのだろうといえます。
但是，跟硬件相连接的部分，在调试的时候就需要提供目标对象的硬件环境，这个问题常会给外包开发带来一些困难。

　 問題発生時におけるハードとソフトの原因の切り分けの部分は、出しにくいでしょう。しかし、開発環境として、エミュレート環境で開発可能な部分もあります。その部分については、オフショア先に出しても問題ないところだと思います。
在问题发生时，往往很难区分问题原因究竟是硬件还是软件上。但是，开发环境中也有部分是靠模拟器（ emulate ）实现的。这部分发包给中方企业做应该没有问题。

　 ミドルウェアを介在して動作する、純粋なアプリケーション部分であれば、大丈夫でしょう。ただし、最終確認では実機が必要となります。そこをどう考えるのかによるといえるでしょう。
某些依靠中间件运作的纯粹的应用程序应该问题不大，但最终验收时需要在实际环境中确认。这点上，就看你发包的时候是如何考虑的了。

　 最終的な動作環境が汎用機でない点が、組み込みが業務系と異なり難しい点だといえると思います。場合によってはICE（In-Circuit Emulator）を使う必要もありますからね。実際のところ国内でも組み込み系の技術者は不足してきているのが現状です。
嵌入式与一般应用程序相比，最终不是在通用 PC （译者注：原文为“（氵凡）用机”， kanji 这方面没有经验，但一直理解为 IBM 小型机，也不知道对不对）上运行，这点既是区别也是难点。有的时候还需要使用 ICE（In-Circuit Emulator） 吧。实际上，日本国内的现状也是缺乏嵌入式开发的技术者。

　 そこで、ソフトを部品化して、ICEを使う必要があるような部分と、エミュレータでPCだけや、実機確認だけで何とかなる部分とを分けて、担当を変えるなど、プロジェクト上の工夫が必要となります。その辺りのノウハウを持ったブリッジSEが必要ということになるのではないでしょうか。
因此，将软件拆分后（译者注：原文为“部品化”，即“零件化”），将需要使用 ICE 的部分，已经可以用模拟机在 PC 上实现“实际环境模拟”的部分分开，然后调整负责人，在项目安排上下功夫。在这方面，我觉得需要一个有这方面业务经验的 Bridge SE 的参与。

　 また、実機の貸し出しに関する機密管理の問題も、業務系とは違って出てきます。
另外，如果把实际环境的机器（硬件）借给中方的话还会存在一个机密管理的问题，这也是与一般业务型应用软件开发的不同之处。

去年在东京都内举办的一次研修班上，笔者听到一段发言，大致意思是“在中国嵌入式开发（译者注：指外包开发）的相关业务上，过去开始就有很大的市场”。于是饶有兴趣地问了一些细节后才发现，原来都是一些与“外包”无关的，诸如“地图信息系统”的数据输入等内容。

之后，“兴趣至上”的我又在网络上检索了一下中国的求职信息，发现了 18 家日本企业在招聘能讲中文的 SE ，其中只有一家明确地提到了“嵌入式”这个字眼。

一位在中国某大型企业工作的日本人这样说道，“嵌入式开发的外包项目还很不成熟，但正因为这样，这个领域今后的发展才更令人期待。”但实际上，由于日本方面有注重开发速度的倾向，所以不少企业还是主张“不应该去冒风险做外包开发”。

现在，一些已经在中国进行嵌入式开发的日本企业的基本方针都注重“放眼今后”，除了软件以外，通过合作相互建立商品销售路线、商品的共同研发、以及合资等形式都是其中的对象。

那些嵌入式软件开发始终难以成功的公司，喜欢在“外包实绩”等方面大作文章。却对“式样变更”或“开发环境的含糊不清”等细节问题逼之不谈，难言之隐可见一斑。（译者注： kanji 能力有限，手头暂时也没有砖头字典，只能试图意译原文，不当之处还望见谅）

最近，向笔者的公司咨询嵌入式软件开发的事例突然增多。过去这样的咨询往往集中在“希望寻找嵌入式开发的外包可能性”或“想收集一下中国的信息”等问题上，最近更多的则是“发包”为前提，希望在地域以及开发商选择上得到相关咨询的事例。

至少从中长期的发展上来看，嵌入式开发的中国外包项目比重逐渐扩大的情况是个不争的事实。

n       嵌入式开发难做的理由

究竟为什么中国外包开发与嵌入式软件开发之间会“相克”呢？在考虑这个问题之前，首先让我们简单整理一下所谓“嵌入式开发”究竟是什么。

简单地来说，嵌入式软件是指“在专用设备上运行的所有软件”。专用设备则是指，手机、汽车导航器、车载设备、汽车 / 交通工具相关设备、读卡器及周边等各类设备。专用设备大致具备一下特征：
1、  比较依赖于硬件，输入输出设备较容易受限制。
2、  OS 、开发环境、开发语言多种多样。
3、  难以在产品交付后进行程序修正。

嵌入式开发与外包开发“相克”的一个关键字就是“产品固有”（译者注：原文为“制品固有”）。在这里，我们只是介绍了一下两者之间“相克”的具体症状，下一次我们将介绍嵌入式软件实施外包开发中的一些具体课题。

教训

1、  嵌入式开发中与硬件相关联的部分最困难
2、  不要将嵌入开发的调试 / 测试环境交给中国方面
3、  嵌入式软件的关键字是“产品固有”

继续来介绍一下读者调查中得到的一些读者感想。

組み込み系ソフトウェア開発の場合は、中国にデバッグ／テスト環境を渡せないと思った方が良いです。実際、これまで渡せたことは1度もありません。ましてや実機など、とても無理です（ハードができておらず、日本側にもないのが普通）。
在嵌入式开发的场合下，我认为还是不要把调试 / 测试环境交给中国方面为好。实际上，目前为止我们一次也没能交过。更别说是实际的真实设备了，那实在是不可能（原因主要是开发时用到的硬件还没做出来，这种情况在日本也很普通）。

私は日本で働いている中国人ブリッジSE です。最近は会社の戦略的なプロジェクトとして、組み込み系もオフショア開発に移行しました。しかし、もらった仕様書を何回見ても、「何をやるか？」という部分はなんとなく分かってきましたが、どうやって実現するのかイメージできません。工数見積もりを出してみましたが、顧客からの予期工数の2倍になってしまいました。
我是在日本工作的中国人 Bridge SE 。最近，作为公司的战略项目，需要向嵌入式的外包开发上转移。但是，我把拿到的式样书反复看了多次，“要做什么？”方面多少看出了些眉目，但具体要如何实现却毫无头绪。预算报价也提交出去了，结果是客户的预期工数的 2 倍…

例えば、普通にキーを押すと問題なくても、連打するとおかしな動きをするとか、組み込みならではの問題が発生します。これはシミュレータを使った開発では分からないポイントだと思います。また、開発機能によっては、ソフト開発であってもハードの知識が必要であったりするため、よほど分業とサポート体制の整った環境でないと組み込みのオフショア開発は難しいのではないでしょうか。
比如说，一般情况下按一个键没有问题，但如果连续按键就会出现奇怪的现象。这些都是嵌入式开发特有的问题。我想这是模拟器上虚拟的环境中无法发现的一个问题点。还有，根据功能的不同，有时即便是软件开发也需要一些相关的硬件知识，在相关领域的分工以及支援体制尚不具备的情况下进行潜入是软件的外包开发是很困难的。

n       蚂蚁地狱与意大利面（ Spaghetti ）状态
据上海的某日资企业的专家介绍，将嵌入式软件开发项目进行外部委托（外包）时一般不会是一个全新的项目，绝大部分情况是对某个基本成形的产品进行个性化配置。而且，随着功能的提高以及客户要件（需求）的多样化，“个性化”后继续“个性化”的情况经常出现。而且，在该产品的生命周期结束之前，这样的循环会一直继续，项目往往会陷入下述的“泥潭状态”

「誰が作ったのか分からない不良資産を受け継がなくてはいけない」
“不得不继承连原作者是谁都不知道的不良资产”
 
「誰にも聞けないので、ほかの場所には手が触れられない」
“谁都问不了，所以别的地方也不能出手碰”

「なぜ動いているのか、開発者自身でも分からない」
“开发者自己都不知道程序为什么会这样运行”

这样的现象，当然在其他的业务性应用程序开发过程中也会产生，但在嵌入式软件开发的时候会特别明显。

因此，随着时间的推移，项目对某些特定的技术者的依存度也会逐渐提高。如果某个通过长期实践终于可以独当一面的中国人技术者突然辞职了的话，项目一度陷入休克状态的情况也屡见不鲜。 Java 或 .Net 的相关专家的话，在中国人才市场上可以说要多少有多少，但如果指名要寻找精通□□公司的△△△设备的 SE 的话，几乎是不可能完成的任务。在公司职员安定律较低的中国软件业，这样的问题会逐渐深刻化。

n       嵌入式开发，所谓的“谁都能行”是……
嵌入式软件的开发过程中，通过长期教育而培养出的人才，以及如何提高这些人才的工作士气是两个重要的课题。再进一步说，这先都是确保“硬件 / 软件”双面的开发环境能顺利整合所必不可少的条件。

“ 要说我们公司才有的事情…… ”
这么说的，是一位在中国设立了合资公司的某日本企业的经理，他用冷静的语调继续说着，
“嵌入式软件的外包开发，失败原因主要是在日本方面”
果然还是这里啊！后来这位经理告诉我的，正是一些在业务型应用软件开发是也发生的问题。在本连载中，我们一直带点自嘲地叫做“日本式开发手法”。

在考虑嵌入式软件开发的一些课题后，给我留下深刻印象的是“在中国实施的大部分潜入十开发谁都能做，并不特别依赖某些很在行的技术者”。
“谁都能行”这句话，或许雇主听了会很高兴，但对于技术者本人来说或许会觉得烦恼。虽然对每个职员所要求的技术水平很低，但需要牢记的“产品谷邮”的知识却多而杂乱。也就是说，在这个公司学会的东西，去了别的公司就未必能适用了。如此情形下，弄不好就只能培养出一批“三脚猫技术者”。

另一方面，雇主也不能忘记，培养一些能独当一面的嵌入式技术者所需要花费的高额成本。

“一般的中国人技术者信息共享的意识比较薄弱，所以有几个技术者如果辞职了的话就糟了”刚才提到的那位经理说道这里脸上浮现出悲壮的表情。

那即便现实如此严峻，日本公司为什么还要推进嵌入式软件的中国外包呢？调查结果告诉我们，除了单纯地削减成本之外，还有“工作量大得仅靠日本已经无法全部做完”、“公司自身得开发流程改革过程中，要变成真正的整合方案供应商，中国方面的开发力量是必不可少的”等答案。

外包开发的秘诀之一就是从过去的失败案例中找经验。这点是非常重要的，所以笔者想强调一下。在平日的工作中，笔者经常提到“要把外包开发当作企业的新事业来做”。对于企业而言，实施外包开发的目的和目标会千差万别，外包这个领域，没有对任何企业都有效的“万能的成功法则”（ How to ）。应该说，从过去的失败经验中学习，然后避免一些明确的失败原因，这或许是外包开发走向成功的一条近路。

而且，这个原则在嵌入式软件的中国外包方面也能够适用。虽然各个公司自生的课题也都堆积如山，但外包事业需要到达的目标（事业目标）是明确的，至少（这个原则）能给我们带来一线希望的曙光。不要为眼前的起伏不定而时喜时忧，拥有强烈的意志以及对环境变化的适应能力是相当重要的。

不仅仅是中国，软件开发的基础就是人才的有效利用。如果您也调查一下中国外包开发的话，不妨考虑一下这些问题。
不实施外部委托而保持现状地发展下去，企业是否能在未来的市场中生存？
自己公司的人才培养体制，还能保证多少年安定的人才供应？ 3 年， 5 年， 10 年， 20 年？