连载：Offshore时代的统筹人（5）
原作：幸地 司 Ai-coach有限会社 2005/01/12 查看原文
翻译：kanji @ CSDN BLOG
*译者注：本系列名的“统筹人”一词原文中是“コーディネータ”（Coordinator），中文可译为“联络官 ,协调人,协作人”等。
（续）适可而止吧！-- 日本企业不讲理的态度
n 式样变更计划的混乱 – 不经意间的低级错误
首先，我们介绍一下中国企业中不满意率较高的“式样变更计划混乱”这一问题。
“希望他们在设计早期阶段预测式样变更的可能性，并做出今后‘易于调整’的设计”
这个问题可谓是中国外包开发中最大的一个难关。实现中方企业所要求的“易于调整的设计”这个问题，不该误解为中方对设计“说三道四”，而应该意识到这是系统开发中的一个“永恒的课题”。
让我们看看为什么中方企业对这个问题如此不满吧。首先，有些项目的开发中，尽管遵照预先约定的规则作了式样变更，但最后还是问题重重。另一方面，尽管设计错误完全是日方的责任，但针对式样变更还是暧昧地采用了“结果没问题就一了百了”(译者注：原文中直译为“回味良好”) 的态度。
“边走边看”地逐步明确“要件式样”这种做法是典型的日本式的开发手法，除此之外的“责任分担不明确”以及“拘泥于旁支末节”之类的问题，则是这种日本独特的商业习惯的衍生。
最糟糕的是，还有不少日本企业对这种做法已经习已为常，不觉得有任何问题。在外包开发中遇到问题时，有些不明白“日本式开发手法弊害”的日方负责人，会忽视自身问题的存在，而将责任归罪于中方企业“品质不好”或“不理解日本的常识”云云。
“式样变更”的名义下，大多还是“式样问题”
“摆出发包方的强硬的姿态，对承接方发出无理的要求。”
或许在你周围也听到过这样的传闻，在中国做外包时，日本企业多数要发挥指导作用，但是如果日本方面连续发生一些低级错误的话，就会丧失中国企业对日方的信用。式样变更本身存在问题的情况很少，我们必须注意到的问题是“式样变更后的对应”。
“中方没有自觉意识到式样变更”
“出现的问题全都是中方的责任”
如果你在用这种态度的话，无疑就丧失了中国企业对你的信任。如果合作双方的信赖关系上有了伤痕，那外包开发项目恐怕就要以失败而告终了。
“即使发生了式样变更，连道歉的话也没有”
日本企业对于中国企业要求的“费用追加请求”有一些“过敏反应”的倾向。从笔者经历过许多外包项目的开发，感觉中日两国企业坦率地说“非常抱歉”的情况下，很少是关于费用方面的纠纷造成的。因此，如果发生了式样变更的话，日本企业请坦率地承认自己的责任吧。
如今的中国企业中，也充分认识到了“式样变更的多发问题”属于“日本特有的商业习惯”，所以有“式样变更”引起的费用上的纠纷已经大为减少。过去如果遇到这样的情况，中方企业最多的态度则是“不管有过什么错，责任始终都不在我”。所以说，以后的商业交往中，日方企业可以要求中方“以更加成熟的态度来对应”。
“无论我们如何诚恳地对应式样变更，到头来一句感谢的话都没有”
如果中方企业做好了式样变更的对应工作，无论变动本身有多大，都请你对他们表示感谢或称赞一下吧。从笔者的经验来看，稳妥地做好式样变更对应的要诀就是，日方企业必须将“自觉承担责任”和“表明谢意”这两点牢记心上。或者通过发散思维，进一步认识到“式样变更是于中方企业加强双方信任关系的好机会”的话就更好了。
在日方工作积极性较低的项目中，一些“非正式的交流”会极度减少。
“对应这样的式样变更是理所当然的”
像这种在*内作开发时理所当然的考虑方法，在如今外包开发的全盛期里恰恰需要改变一下。
一旦发生了式样变更，只有遵守原先计划好的操作顺序来对应。但是，外包开发中的一个难点就是“照章办事”的死规矩有时无法很好地解决问题。“可变管理”的一个要点就是“人类情感的管理”，也就是说双方的项目组之间建立了信赖关系，即便出现一些矛盾，也能在双方负责人的协调下解决。不要吝啬那一点点支出而毁了更重要的项目，请大家抱着责任感去解决“式样变更”的问题。
负责人技术能力不足 – 沟通能力不足
日本企业在选择Bridge SE的时候，重点往往放在“是否会日语”（或者“是否会中文”）上面，对于该人选的能力问题却很少涉及。即使缺乏技术能力，只要语言沟通没问题就可以被任命为Bridge SE。毋庸置疑，这样的简易评判标准下选择的Bridge SE将会直接影响到外包项目的成功与否。
另一方面，还有不少情况是选用技术能力突出，但管理能力与沟通能力相对欠缺的人担任Bridge（或，统筹人）的角色。这种情况时很悲惨的。别说管理*无法建立，优秀的中国人技术者在无能的日方Bridge指挥下，弄不好还会因为失去信心而辞职。
接下去让我们看看几个关于负责人技能能力不足的意见。
由于没有理解详细设计，所以无法继续对话
这种情况下可以考虑两种可能性。第一种是一些技术上尚未成熟的年轻社员负责与中方企业交涉（Bridge角色）的情况。这种情况下本来需要一个由上司或者“先辈社员”来辅佐年轻社员的*，但由于种种原因不得不让年轻社员直接肩负这个责任。这样的企业里往往有这些个理由，“没有赚么负责支援外包开发的部署”“会被上层视为言行不一致”“失败了就很难重新开始”“对中国企业有偏见”等。
第二种情况是Bridge角色的交流能力不足。负责人或许拥有理解详细设计的技术水平，可他缺少与外国人SE交流的“异文化交流能力”。
交流能力不足的问题细分的话还能有两种可能。第一种是“对话中缺少感情”的类型，另一种则是“书面语能力不足”造成无法正确传达意图的情况。正对这样的“交流能力不足”的问题，笔者所在的公司开发了一套针对外包开发负责人的“业务强化课程”。这套课程着眼于中国人与日本人的价值观差异，通过案例教学的方式教授实用的“交流手段”。（译者注：这部分应该算作原作者的广告。不过译者手头也有一份该讲座的教案，确实很有参考价值）
“即便我们在技术上有困难，也无法获得日方有用的指导信息”
这种事例往往是日方企业忽略自身的技术劣势，却一味地批判中国企业的情况。还有就是适用于那些习惯于“一股脑发包”的日本企业。过去曾有这样一个例子。
中国企业向日方提出一个问题：“为了确保程序性能，测试数据的变化形式需要增加多少？” 但日方的负责人却一刀切地拒绝了回答这个问题：“你们是‘专业人士’的话就应该自己做测试。那不是我的责任范围，我可不是照看孩子的角色。”
这个例子中的错误观点可以说是太过分了。要引领外包项目获得成功，我们不能吝惜任何的努力。
“尽管是日方的单纯错误，但日方确自以为是地指责我们”
这是一个典型的“日本人价值观”在作祟，给中方企业填麻烦的事例。自以为是地指责中方企业“看看式样书就明白了”，但实际上不管参考什么文档都无法找到正确答案。
即便是由于日方的错误造成的返工，日方也不承认自身的责任，却口口声声地说：“看看详细设计书的２３页和画面设计书的８５页就知道了”（其实是由于设计书写的十分暧昧，造成误解了也不能怪罪中方）。只有做这种事的人，才会对中国企业的的某些错误口出秽言。
“强迫我们实现不可能的性能指标”
中国外包开发中，在计划初期就应该对相关的数据指标作明确的定义，但有些人虽然考虑到这个问题，但最后往往制定出一些缺乏充足的根据的不现实的指标。
比如：
由于没有总结式样书的时间，所以在缺乏充分验证的情况下便草率得出“所有功能的响应时间为２秒”的指标。但在进行设计的过程中，逐渐意识到了这是“不可能完成的任务”。
于是就出现了之前描述过的场景，这就是考验日方负责人真实的技术能力的时刻了。重复一下，在日方技术者的工作积极性高昂的情况下，外包项目中发生的大部分问题时能被解决的。外包开发时，只有委任那些不“高高挂起”的人作为负责人，才能获得相应的回报。如果不能理解外包的意义和目标的话，请做好心理准备，恐怕连这个人平时一般的能力也不能发挥出来。
n 不讲理的条件压制 – 不想吃亏
最后介绍一下关于“不讲理的条件压制”这一话题。
“明明是式样变更，却强调说是式样的‘详细化’”
这样的意见在*内开发中也常常听说。在中国外包开发预算极为吃紧的情况下，日本方面“明知不可为，而偏偏为之”。
“营业与设计者说的话相差千里”
有些时候，负责“品质”与“开发期限”的设计者与负责“金额”的营业负责人之间，由于各自的立场的差异，会导致双方“说话全然不同”的情况。
过去也有过这样的例子，日方的设计着不经意间说了“了解”或“对不起”之类的话后，通过中方项目负责人转达给中方企业的营业负责人（通常是总经理、主管等）那里时，马上就会发展成“金钱问题”。
“在计划或目标中没有的内容，在那个场合下想到了便脱口而出”
越是经验丰富的人，越有在某些场合下“想说便说”的倾向。或许对于他本人来说是经过“切实”的判断的，但很遗憾，这样的内容外国人SE未必能理解。在项目开始后希望调整计划或目标的时候，最好还是直接对中方企业的主管或总经理认真地说明情况，或许这样做有点费时费力，但相比之下会更安全。
类似以上这些的“言行不一致”“不讲理的条件压制”等情况，在那些刚接触外包开发的企业中常常会出现。由于这是日本企业“暧昧”的企业结构造成的，作为发包方如果不改变自己的意识，作为外包开发承接商的中国企业的不满就不会消失。在外包项目中，一丁点的“不满”就可能直接关系到项目的品质恶化或交付期延迟。要脱离这样的恶性循环，日本企业中的每一个成员都必须看到“日本式开发手法”的“暧昧之处”，只有从本质上改变“交流方法”上开始。
外包开发中获得利益的关键无非就是“追求规模指标”（Scale merit）与“远瞻性的投资”。让我们重新审视一下目前为止的“对症下药”式的种种外包开发对策，通过发散思考，尝试将“不吃亏的外包开发”转化成“Win-Win的外包开发”吧。
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/kanji/archive/2006/03/14/623984.aspx