连载：Offshore时代的统筹人（6） -- 中国外包开发中生产效率与品质的平衡

连载：Offshore时代的统筹人（6）

原作：幸地 司 Ai-coach有限会社 2005/02/15 查看原文

翻译：kanji @ CSDN BLOG

*译者注：本系列名的“统筹人”一词原文中是“コーディネータ”（Coordinator），中文可译为“联络官 ,协调人,协作人”等。

 

中国外包开发中生产效率与品质的平衡 

 

　　在这个以“Offshore时代的统筹人”为主题的系列中，我们以“中国”为主要话题，通过一些事例来回答那些平日困扰着读者们的疑问和误解。

    这次，我们将谈谈外包开发中的一个重要课题 ---- 品质管理，看看在这个问题上作为“外包开发统筹人”必须发挥哪些作用。

 

n       中国人不认真洗盘子？

在东京某个同时拥有日本人和中国人的打工者的中国菜餐馆里，店主正在满腹牢骚。

   “认真洗盘子的是日本人。中国人全都不行！”

    在这家店里，打工者的工资是按照小时来计算的。也就是说，工作时间相同的情况下，无论洗盘子数量的多少都能得到同样的酬劳。在这样的情况下，店主嘴里的中国人打工者就成了这个样子：

    “店主稍留神看，他们就马上开始偷懒”

    “不会事先做好各种准备”

    “不作声地，仅仅做好自己的那部分”

 

     在这里我提一个问题：要让这家餐馆里的中国人打工者提高工作效率的话，有什么好办法吗？

     有人会说：“工资不要按时计费，而采用结合工作成果的制度。”

     如果这家店改变“按时计酬”而换成“统计工作成果”的方法话，恐怕当店主宣布“现在开始不再看时间，以后要根据你们洗盘子的数量来定工资”的瞬间，那个平时一直干活偷懒的中国人打工者会立刻埋头于洗洁精的泡沫中，展现出另一番工作态度。

 

    但是，这里有一个注意事项。

    或许有些反应快的读者已经意识到了，那就是必须要事先约定好洗盘子的“品质标准”。不然的话会怎样呢？恐怕那个中国人打工者会很努力，尽可能多的洗盘子 ---- 出现“工作速度优先”的情况。

    这样一来，起初就会既出现干净的盘子，又出现脏盘子的情况。这时就会对某些盘子打上问号“他到底有没有认真洗盘子啊~ ”。如果这个时候店主忽视了及时提点一下的话，洗盘子的“品质标准”就会慢慢的降低。尽管如此，如果在不加任何注释的情况下施行这种“工作成果制”的话，到头来恐怕所有的盘子都要不合格了。

 

教训：

   要提高洗盘子的中国人打工者的生产效率，最好的方法是根据洗盘子的数量来制定酬劳。在使用这种酬劳方式的时候，必须要设定一个能防止品质下降、明确的“合格标准”（或“品质标准”）。

 

    考虑到中国外包开发的生产效率与品质的问题，向大家介绍了以上的这个饶有趣味的事例。接下去让我们看看中国外包开发能从这个教训中得到什么样的启示。

 

中国外包开发中品质管理的困难

    与中国菜餐馆里洗盘子的情况不同，软件的品质是肉眼不能直接看到的。软件的相关国际标准中，一般对软件品质的分6个部分作评价，即功能性，信赖性，使用性，效率性，维护性，移植性。这些都是原本应该在式样书中明确记载的事项，但许多企业在多年的“日本式开发手法”的作用下，已经没有行之有效的方法使得这些要点在式样书中体现出来。

    一般情况下，要采用以下这些对策来弥补这些式样书中存在的不足，从而实现“尽可能提高软件品质”的目的。

1、 早期的设计审查

2、 通过使用统一格式的文档确保正确的交流

3、 整备“开发标准规定”与“编程规则”

 

在众多的品质管理方法中，针对偏好“明确的数值指标”的中国企业，笔者认为在测试工程中明确“测试数量”“BUG发生率”等项目的软件品质基准尤其有效。在笔者调查的多数中国外包开发事例中发现，被日本国内的多数软件开发商所采用的软件工程学上的“标准化的知识”，事实上并没有在中国外包的项目中得到充分运用，这点确实很遗憾。

在率先一步从事中国外包开发的企业中，已经将设计审查阶段的“审查项目”“指出问题”等标准化了。在本连载第2篇的“充满不信任感的代码评审”中，我们提到过日中双方对“评审”这个问题的考虑方法上存在的根本性的差别。在这个背景下，一般的中国人认为“错误 = 不好”的这种特质会被隐藏起来。与多数日本人“蒙羞”时感到反感一样，中国SE对于被指出“存在BUG”也会有本能的抵触情绪。另外，“接受评审”本身也以为着“要被他人指出自己的不足之处”，对于指出问题和接受问题的双方来说，或许都有点紧张的部分。

 

　　因此，我们就常能从参与外包开发的日本人那里听到这样的话。

中国でデザインレビューを実施したが、指摘事項がゼロだった

（中方实施了设计评审，但最后被指出的问题为零）

 

中国のテスト結果を見ると、バグがほとんど摘出されていない

（看到中方的测试结果，BUG大部分都没有被指出）

 

しかも、中国は『バグが少ないから品質が良い』と主張する

（而且，中国以至强调“因为BUG少，所以品质好”）

     让我们通过设定关于“设计评审”的品质基准，缓和中方对“评审指责”的本能抵触情绪，促进“设计评审”跟有效地实施吧。

 

理解日本的品质意识需要2周？

    上面提到了这样的“品质保证活动”属于日方的“标准化知识”。于此同时，上面我们也提到的中方企业说到“道理我们懂，但还是不能实施”这样的情况还会不断出现。在实际的开发现场，这样的对话每天都在重复着。

 

◇日本人担当者

「当初のテスト実施計画では、システム規模○○に対してチェックリストを△△件、バグ摘出目標値が××件だった。ところが貴社のテスト実施報告によると、実際には約束したバグ摘出目標値より少ない。潜在バグがあるはずだ。いったいどういうことだ。その根拠を説明せよ」

（日方负责人：

在当初制定的测试计划中，“系统规模” ○○的时候“测试列表”需要有△△条内容，BUG目标数要达到XX件。可看了贵公司的测试实施报告，实际的BUG发现目标比我们约定的数目要少。这样的话肯定存在“潜在BUG”。究竟这是怎么一回事，请说明原因）

 

●中国側リーダー

「単体テスト用のテストクラスを作成しながらコーディングしたので、単体テスト時のバグ摘出件数は少ない。もちろん、コーディング中にはたくさんのバグを修正した。しかし、意味がないのでまったく記録していない（何か問題あるか？）」

（中方PL：因为我们一边制作单体测试用的测试CLASS一边写代码，所以单体测试时发现的BUG比较少。当然，在写程序时已经修正了不少BUG，但这些BUG没什么意义所以就没有记录下来，这样有什么问题吗？）

 

◇日本人担当者

「……」

（日方负责人：……）

 

    在中国外包开发中，与某些问题上“说了”和“不说”的争执一样，“计划与实际情况的差异”也会频繁地出现。虽然有时需要根据情况作调整，但笔者一直认为品质问题上需要日方企业掌握主导权。对于中方企业的做法哪怕有一丁点的疑问，那些疑问的内容实际开发中必然会被表面化。这与著名的“玛菲法则”是一致的。（译者注：本人能力有限，无法弄清“玛菲法则”究竟是指什么。希望有经验的朋友指教一下）

    从日本人的感觉上来看中国SE的话，感觉他们有不考虑前后因果，喜欢即“兴发挥式”工作的倾向。因此，在变化因素较多的中国外包开发过程中，我们也必须仔细考察事先计划好的品质标准是否被切实执行。作为外包开发项目“统筹人”的一个重要任务，就是与日方项目经理共同监督这个问题。作为“统筹人”，需要让中方企业理解日方的品质标准为什么如此重要，在这个基础上，针对具体问题有时还需要做出相应的指示。正因为这样，“统筹人”这一角色在项目中必须要有相当强力的权限。

    在与中国打交道时经常会有“即使书面化了某些约定事项，但中方企业也不接受”的情况。这个事例中，或许中方的见解某种程度上存在一些道理，但长远来看我们还是优先采用那些“循规蹈矩”的做法吧。

    负责这个项目的中方企业负责人精通日语，而且品质意识也非常优秀。但即使是这样一个被认为“层次较高”的中方负责人，对于日方严格的品质标准也似乎无法完全对应。起初这个问题在开发过程中多次争论过，始终无法达成共同认识。最后，加上中方企业的高层负责人，前后总共花了2周时间才得以解决。因此或许可以得出这样一个结论：让中方企业理解日本的品质标准，需要2周时间。

    本篇中，主要介绍了项目管理为中心的若干话题。下次笔者打算介绍“组织性的项目推进机能”这个问题。敬请期待。