“你明白我的意思……”

　　轻率地下结论、想当然地处理事情——我们都犯过类似的毛病。而本地化项目失败的原因常常就是因为沟通不准确或不清楚，尤其是谈到交付物(你需要把HTML文件编译成一个chm文件吗?)和服务(你希望由谁来开发这个软件?)的时候。

　　在和客户交谈中抽取出真正的项目需求，并在项目过程中管理好客户期望，是所有本地化项目经理的重要任务。下面是一些有关项目需求的例子：

　　1.中期交付物和最终交付物是什么?清晰地描述项目所有的中期交付物和最终交付物至关重要。项目交付物包括所有的产品交付物，外加项目特定的组成项，例如进度报告、缺陷报告、已完成的检查清单、翻译记忆库、术语库等等。

　　2.各交付物的时间表如何?最后期限如何分类：是如你所愿的，还是很紧急的?有时候我们要处理像贸易展会这样“规定得很死的”期限，这无疑会增加项目风险。

　　3.项目的预算是多少?如何处理预算差异?这是一个“依耗时和材料而定价”的项目呢，还是一个“成本固定的”项目?项目预算还应对项目变更单有一个清晰的期望。

　　4.客户对最终交付物的质量期望是怎样的?在项目初始阶段建立质量标准可以极大地帮助客户设定正确的期望。对于本地化工作来说质量标准的制定不是一件容易的事，因为风格和术语的处理都囊括了太多的主观性。

　　5.客户对于他/她在项目中承担的责任有何认识?我们都至少遇到过一次由于客户更新或审查源文件而无法在交付期间内完成任务的情况。客户需要理解这些延误对进度和预算的含义。应该在项目的规划阶段就确定这些期望，而不是等到这些延误成为不可更改的现实后。

　　需要沟通的不止这些。在项目执行过程中还需要沟通清楚每位团队成员需要做什么，这一点很重要。如果事先没有沟通清楚，就会导致重工、未分配的任务以及团队成员间普遍的受挫感。这让我们想到另一个话题。

　　缺少规划时间……

　　你已经把大部分时间用来谈判需求、预算以及交期。现在交易谈妥了。但是供应商和客户都希望继续项目并开始翻译活动。多数情况下，你的交付期限已经很紧了。最不愿意做的事情就是花时间做规划。立即开始投入翻译工作非常具有诱惑力，但是了解下面这点也许能帮助你三思而后行：导致多数项目失败的两大原因是：(一)误解客户需求;(二)缺少规划。

　　现在，是时候完成规划了，它包括项目方法、资源分配、所有中期交付物的交付期限、风险管理等等。最好做一份详细的、可以满足多种用途的项目规划：

　　作为项目相关人员(尤其是利益相关人)的指示图。项目规划将会概述项目的各阶段，并阐明各阶段内的活动和里程碑之间的依赖关系。此外，它会将所有交付物的交付期限记录在案。

　　能够清晰地描述每位利益相关者的责任。我个人喜欢使用线性职责表(LRC)，这个表的左列各栏清楚地列出了所有的项目交付物，其它各列则是相关联的利益相关者。二者的交叉点上详细列出了某个项目交付物的每位利益相关人须履行的一下责任中的一项或多项：创建、审查、批注或不适用。

　　作为项目在进度、开支和质量各方面绩效的测量标准。甘特图样式的基准进度表为比较计划绩效和实际绩效提供了一种简单易行的方法。累计预算和实际成本相比较为财务绩效提供了很好的指示器。

　　我听见你说：“我可没时间写一个50页的项目规划”，你说得对。项目规划的详细程度取决于很多因素：

　　利益相关人的个数，尤其是团队大小;

　　项目和产品的复杂程度;

　　客户方本地化的成熟度;

　　交付物的数量;

　　是否使用新技术;

　　对于多数本地化项目来说，一个考虑周详的MSProject进度表，包括资源分配、交付物描述记录、限制条件、以及所有的预算信息就足够了。

　　此外，在规划阶段，你可以完成一些并行的活动：例如翻译术语、准备翻译套件，为初始的客户审核会作进度规划等。

　　当你理解了需求并完成了规划，你或许以为前面的工作就会一帆风顺了。然而，在接下来的话题中，我们就会谈到其它一些可能让你船沉大海的暗礁。

　　失误偷偷潜入……

　　作为一个本地化供应商的项目经理，你有很多相互矛盾的目标：

　　在交付期限、质量和预算方面达到客户的期望，让客户高兴;

　　在每个项目的毛利和所有项目的产出方面，又要让自己公司的管理层高兴;

　　让客户高兴的最容易办法就是接受任何以及所有的项目变更——面带微笑，摆出一副“我们可以做到”的态度。然而，照这个逻辑推理下去，你很快会受到惩罚：项目范围蔓延。结果是你要面对“错过的交付期限”、“降低的毛利”、“来自你的客户以及你自己公司管理层的不满”。

　　怎样才能在保持一个“我们可以做到”的态度的同时还控制好项目的范围呢?如果你的需求定义得很好，初始项目规划也做得很好，那么你的项目至少在开始的时候是有一个明确的范围的。但是，控制住这个初始范围需要有正式的审批流程——任何对原项目范围的变更都需要审批;不这样做的结果只能是自尝失败苦果。

　　本地化项目的范围控制包括：

　　在立项阶段和规划阶段，详细讨论如何通过项目变更单来管理变更。

　　对于每一次范围变更，应及时地生成一个项目变更单。这里关键是要及时：范围变更的需求一提出，而不是等到项目结束。

　　对每一个项目变更单进行沟通、讨论、和审批，基于它对项目目标的影响(进度、预算、功能和质量)。

　　使用版本控制软件和翻译记忆库来跟踪源文件和本地化后的文件版本。

　　使用工具(例如，MSProjectServer)来管理各个项目的资源分配，帮助你获取项目变更对你自己的项目和其它项目的影响。

　　最常见的范围变更包含更新源文件、增加区域，增加交付物。在有些情况下，最好把变更请求当场一个新的项目，而不是更改项目变更单，特别是这个请求包含新的交付物的时候。

　　有一条很好的规则，值得牢记心中，即：项目范围应该包含达到项目目标必须的每件事，但是不包含不必须的任何事。

　　审校员：伪装的叛徒?

　　我们最后的失败原因是本地化项目所特有的：客户方审校员的角色，以及他们对项目的潜在影响。对于多数本地化项目，最后一个项目里程碑是客户正式接受产品交付物。一般每个产品的本地化版本会有一位或多位的审校员。

　　与软件开发项目不同，由于自然语言的本质，本地化和翻译项目的质量要求比较主观。尤其是术语和风格，大多由客户审校员的偏好来决定。

　　正确地抓住客户方审校员认同的术语和风格需求至关重要。在项目早期的时候就这样做，之后则对客户审校员的期望进行管理。

　　在项目规划阶段，你需要确认客户方审校员是谁。你应该和他们建立互信关系。通常情况下，和你打交道的是一位背上审校责任并以此为主要任务的国内销售人员或营销人员。

　　有些审校员在产品本地化上不接受“公司控制”，这对你的项目是个极大的危险。这类审校员不会喜欢你的本地化产品。他们对英文原版没有发言权，而他们又觉得自己的市场需要超过公司管理层愿意支付的更大程度上的区域适应。这种情况特别容易出现在(线上或线下的)营销和培训资料。作为一位本地化项目经理，你也许发现自己闯进了一个公司雷区，而本地化质量则成为客户公司各部门之间争夺控制权的武器。

　　想要从这种失败情况中恢复过来，非常困难。因此，在规划阶段，应投入足够的时间来定义审校员的角色。避免潜在雷区的最好办法就是：清晰地定义审校过程并保证审校员的尽早参与。如有可能，在决定术语和风格的时候也将他们包含在内。

　　最后……

　　本地化项目管理需要一种非常积极的“我们可以做到”的态度，以及很强的分析能力。本地化项目管理的复杂任务在下面这幅图中得到了很好的阐述。