从优秀到卓越：本地化项目经理修炼之路

作者

王华伟文思创新软件技术有限公司

转自

《中国翻译》2012年第一期

对于如何成为一名优秀的PM（项目经理），各人的理解不尽相同，达成的途径亦各相异，这里也没有什么固定的答案。

假定我们不能指望个体在各个方面均臻完美，则我们至少可以在某一特质上精益求精。从寻常的角度来看，作为项目管理团队的一员，与任何其他同事相比，我们可能未必有十二分的勤勉，也未必能够做到十二分的严谨（何况我们未必在这些方面就输于他人了），但是我们首先一定要足够地聪敏。SMART 这个词，蕴含着多重况味，你能理解几分，就先做几分好了。从那些做得很好的人们身上可以发现，成为一名优秀的PM，固然和某些与生俱来的天份与悟性相关，但更多地倚赖于一些特定的做事方法。这两个方面，SMART 都涵盖到了。PM 应该是一个什么样的团队呢？我期望它是足够地SMART。一方面，已经进入或将要进入这个团队的每名成员，聪敏是一个基本的特质，它确保我们在任何事情的反应上都能够表现得足够聪明和敏捷，换言之，予外人以灵气涌动的征象；另一方面，它亦确保我们在任何项目的处理上都能展现得足够科学与职业，换言之，我们能够有完全专业的做事态度和方法可资依循。

SMART (Specific, Measurable, Achievable,Relevant, Timely)，当你走近，请你静听；而当你终于能够走过，另一道风景已然呈现。

一、忙而不乱杂而不烦

大抵一般人谈起项目管理，想到既然和管理沾边，必然少不了恣肆纵横、恢弘捭阖，总归要高屋建瓴，气度非凡。我在未入此门之前，也曾经抱了一些这样的单纯幻想。然而，只要生活还是由柴米油盐组成，我们就免不了陷进繁忙琐碎的细节里面去，在日复一日的堆砌与雕琢中度过韶华岁月，无论你是否认同，它都是既定的实情。

因为所处行业性质的缘故，近几年来，我差不多都做着生产型的项目管理工作，再具体一些讲，就是软件的本地化项目管理。本地化这东西，许多人也许还陌生，在你实际所用到的任何软件里面，是基本上看不到本地化痕迹的。用流行的术语讲，它是非常单纯的“幕后”工作，为他人做嫁衣裳，收取一定的劳务报酬，如是而已。

先前的两年里，这工作给我的总体感觉，就是既忙且乱，既杂且烦。到第三年里，因为机缘巧合，和一位韩裔美籍的同行共起事来，这人就是我要记一记的Y，负责XX 客户所有项目的多语言本地化管理。

因为有着长久以来这一行里女性为王的先天成见，是以在第一次电话会议上听到彼端传来的男声时，我竟有些微微的错乱感，仿佛世界一下子很不真切起来。而此前曾经共事且为我所“钦敬”的两位GPM — Yokohama 的T 以及Bothell 的L，这一刻也渐次模糊开来……

其实在电话会议之前，我已然对Y 有着不凡的敬服：从实际的项目情形来看，其严谨性、条理性、完整性皆属前所未见，这让我不禁对项目管理有了别样的另类感受，也让我意识到，在纷繁杂乱的背后，原本也有着某种别样的方法在起作用。这方法不同于T 和L 等人展示的勤勉和耐心。

和Y 共事两个月之后，我已经习惯了他是一位男性，以及他的做事方法。仿佛他也是不怎么加班的，从他所发出邮件的时间戳上可以很明显地辨识出来，不像T 或L，给人的感觉总像经年累月都不用休息，半夜三更甚至周末里都忙着处理电子邮件。Y 不加班的另一个佐证，就是他召开的电话会议，大抵总在他的下午四点半左右，这样就可以不必耽误他在六点钟的准时下班（这当然是我的无端猜忌），但因为时区的差异，为了能够参加他的电话会议，我常常就不得不很早地起床，往往电话会议开完之后都还不到上班时间。然而，我好像也还能接受。从其它项目的纷繁复杂中跳出来，完全进入Y 的结构化世界里，某种程度上不啻一种特别的享受……

在Y 的项目中，所有信息都按照一种高度结构化的方式组织得井井有条，因此在其它项目中那种电子邮件满天飞的情形，这里基本上是见不到的。我记得自己在参与CoDo Service 项目时，一晚上就能被塞进来上百封邮件，看起来自然是费时又费脑的。但看完之后，仿佛也并没有讲什么实质性的东西，而且你还要辛辛苦苦地去汇总相关信息，种种的疑问、困惑、不解，往往就会演变成相互的指责。亚洲的LPM 往往多半还含蓄，但欧洲的LPM 们常常就开始抱怨乃至尖刻地批评，整个项目也笼罩在一片阴郁的气氛中。即或最后磕磕绊绊地完成了，各个语言的质量也往往参差不齐，由于信息的遗漏、误解而导致的错误屡见不鲜，这样的项目，交给客户的时候心里也难免惴惴。

但是如果你在Y 的项目中不幸冒失地发出一封询问邮件，你多半会非常后悔。因为实际讨论后的最终结果往往证明，原因多半是你自己没有认真读完所有要求与说明所致。尤其是这些要求对所有LPM 都是一样的，别人都遵循相应指令在进行生产，独有你自己还冒失地纠缠一些已知的问题，除了显示出自己的驽钝，还能证明什么特别的东西呢？

因为信息组织的高度结构化，所有的发包和提交都得以遵循一种有条不紊的方式进行，我很少在他的项目上遭遇返工的情形，而这在其它项目上是屡见不鲜的。（不管是由于客户的原因，还是GPM乃至LPM 自己的原因。）

Y 给人的感觉，是他在发包之前一定已经将所有生产过程都演练过一遍，我相信如果碰到来自客户的信息缺失，他一定已经先行解决过了；而包含在本地化指令中的详细的注意事项，就是第一线的生产人员都未必能全部碰到。然而，如果你不幸碰到，你也知道该如何去解决。

我常常开玩笑说，做Y 的项目，真的是不大需要用脑子，你就照着做好了。说这话的同时，我心里又开始有隐约的不安，因为我自己距离Y 也还很遥远，要让别人不动脑子就做好我的项目，我还有很长的路要走。

坐在办公室里，看着周遭的同事们忙忙碌碌，有时候也约略觉得困惑，并非所有的忙碌都是有价值的。因为PM 对于信息理解的差异，往往造成信息传递过程的种种偏差，到达一线人员那里时，要么为信息不全而频繁地与PM 商榷，要么为信息泛滥而苦恼不已。而PM 自己也还在抱怨整天为具体的生产事务所困扰，无暇处理项目跟踪，只好采用加班来解决。世界在不停地转，大家也在不停地忙碌，人人都活得似乎不轻松，也因为这个原因，仿佛每个人都没有错。然而，你们都明白，这里面是有问题的。

透过落地玻璃窗看外面长安街上的车流，我常常禁不住会想：Y 在办公室里会是一副什么样子呢？不消说，他多半时间是要埋首在电脑面前的，否则那些信息不会自己就变得结构化起来。然而我能遥想到他的那一份平静，大略是不会有很多电话来烦扰他的（当然客户的电话例外）。到下班的时间，他能很坦然地回家，也不用担心他发出的文件在大洋彼岸会有任何困扰——自然，他也更不必为这种担心而半夜爬起来查电子邮件。

要达到这种境界，除了丰富的经验外，更为难得的是那一种特别的做事方法，这种方法不独和能力相关，也涉及到各人的眼光，以及另外一些学不到的东西，我不知道自己何时可以攀上这级阶梯。虽然和Y 共事只有三个多月，但半年多过去了，他的言行举止，依然清晰如昨，让我时时地看出差距来，而我屡屡试图整理感受时，也往往陷入“此中有真义，欲辩已忘言”的窘境。然而，姑且试试吧，看看Y 的做事方法，到底已为我掌握几成。

二、项目计划：最显功力的是全局视野

大多数人之不能变得优秀的主要障碍之一，就是陷在细节里面走不出来。通常来说，人的理性是有限度的，你可能在一些细微的琐事上考虑得详虑周全，但未必能就更为广泛抽象的东西应用相同的思考方法。所以决定选用哪一样品牌，虽然在日益多元化的市面上来说也有困难，但多数人最终的选择都不会太失理性。不过要说到选择哪一条生活道路，就未必有多少人去仔细想过。而在那些想过的少数人中，也未必有多少人能应用选择品牌时的理性和智慧。我们总是这样地生活着，淹没在绝大多数的细节之中，来不及哪怕是停下来甚至后退几步看一看：我真的了解整体事情的全貌吗？我真的知道我正在着手的事情在全局中的关系和比重吗？也因为缺少全局视野的原因，当我们着手一件

件孤立的事情时，往往做出的判断就未必准确，或者多数时候就未必能做出判断。只有拥有足够信息的人才能责无旁贷的承担责任。当我们指责同事未能按照自己的预期有效完成任务时，我们可能最先需要反思的是：我真的提供了所有必需的信息吗？做Y 的项目，第一课上的就是有关全局视野的训练，教材是一份长达二十页的文档。这文档是Y 亲自撰写，旨在就与该客户相关的所有项目的共性问题作详细的说明，有点法律体系中宪法的意味。按照Y 的设想，这份文档读下来，任何人当能按图索骥的进入备战状态，再结合实际发包中所包含的有关特定组件的Lockit，应该就可以准确无误地进行生产了。

为了让你确切了解我在讲什么，我们不妨看看这份文档的目录结构：

看完这目录，你可有任何感触。不消说，你至少明白了这客户的项目主要包括软件和文档部分。而就软件部分来说，你也知道了主要工具会是Catalyst，同时也当明白了将会如何使用、设置乃至检查Catalyst 相关的工作；而文档部分牵涉到的则会有Trados，以及与Trados 结合使用的MS Word 和Framemaker，你也应当明了将如何使用这些工具、有何具体的设置要求、如何进行文档转换、如何对工作结果进行检查、如何组织最终提交等等。有关实际生产过程中需要注意的共性问题，你应该已经了然于胸。

更重要的是，作为“宪法”，这份文档规定了之后每次发包将会遵循怎样的规则和体系。换言之，它规定了一种统一的“项目语言”，确保所有相关人员都能基于同一层面进行沟通，从而避免了沟通过程中可能出现的任何困扰。

从事实际工作的人们或多或少都会有类似的感触：我们工作中经常面临的各种情绪，比如恐惧、担心、焦虑等等，往往都与不确定相关。我们不知道可能会面临什么，也不知道事情来了之后会发生何种意想不到的局面。即使有时候明知这种担忧毫无助益，但就是无法说服自己去超脱。其实，解决问题的根本办法并不在于如何去超脱。当你感觉到自己能够掌控一切的时候，所有的负面情绪自然会烟消云散；或者，即或有些东西你自己无法控制，但如果你了解一切都在控制之中时，你也会从容许多。

Y 给人的感觉，应该就是那种“一切皆在掌控之中”的气定神闲吧；不惟如此，他还在努力将这份掌控的感觉传达给你，让你也能够完全掌控自己的那一部分。体现在项目设置方面的，除了上面提及的那一份Readme 入门文档以外，任何LPM 在项目开始之初还会收到另外两份文档，一份是关于整个项目的范围与进度的描述；一份是关于整个项目的财务状况的汇总。

我不知道Y 是否特别接受过有关项目管理的训练。我在三年前拿到PMP 证书的时候，所收获的完全是一些概念而已。今天结合Y 的实际演练，才发现两者之间有着惊人的契合。在项目计划之初，Y 用完全鲜活的内容，诠释了项目综合管理、项目范围管理、项目时间管理以及项目成本管理等几个方面。而我枉自空谈项目管理这么多年，竟从未曾做出过一份真正实际的东西出来。

Seven Habits 中的第二条：Begin with the end in Mind，大略也不过就是想表述这些内容吧！

三、项目发包：多走一英里

Walking Extra Miles，翻译成中文之后，其实已经很难传神出那一份意境。但是中心的意思，也还多少保留了下来。

有关它的最好的注解，莫过于我曾经收到的一份由S 所准备的lockit。那份文档的目的，是在于协助LPM 将一份Indesign CS 制作的文档予以本地化。在多数浸淫此行的人们来看，这是一项无须太多解释的任务，哪怕是没有lockit，也未必有什么人抱怨。

有时候我的确不得不对这些严格依循方法论做事的人们抱有十二分的敬意。多数的人们往往都会从自己的立场出发，以为某些事情是不言自明的，但是我们无法预知受众的实际经验与学识。许许多多先前的侥幸心理，往往会为发包后无休止的询问与质疑所取代，而工作中的不谐也多由此而致。S 也许为准备这一份lockit 花费了一些时间，但是我相信，任何人在阅读完这份lockit 之后都不可能再有不解。

在S 的lockit 中，除了惯常的Step by step 乃至图解之外，她对“Walking Extra Miles”的精神的体现，令我尤为叹惋。从常规的思路出发，她告诉你应该考虑用Story Collector 将文本抽离出来，并给予了详细的说明与指导。通常这也就够了，因为这是绝大多数人都会采取的方法。

但是S 并不限于此，她自己又将相应的文本抽离了一份出来，然后特别提醒你，在生产之前，请务必测试是否可以导回去。这一点，大概多数缺乏全局视野的人们，都会很自然而然地忽略掉吧！

进一步，如果能够成功导回去，S 又告诉你，应该如何用TagEditor 对文档进行预处理，她并且提供了相应预处理后的文档供你直接使用；这个还不够，她丰富的经验意识到某些办公室可能并不习惯用TagEditor，又进一步讲述如果有这种情形，则可以如何利用BxFormer 将TTX 转换成RTF 之后再进行实际生产，而且，她也提供了转换后的RTF 文档备你直接使用。

对于那些因种种原因可能无法成功导回去的情形，S 提供了另一种备选方案，即将所有需要翻译的文字手工拷贝出来，制作了一份对照表作为实际的生产之用。而连这份RTF 文档，她都给你预处理好了。

说得远了，我只是想表明一点，训练有素的人们往往深谙“Walking Extra Miles”之道。在这么一件小小的任务上，他们尚且能如此有条不紊；应用到大型项目上，你就能更为深切地感受到其便利之处了，这在Y 的项目中体现得尤为明显。Y 的每一份Handoff，无一例外地遵循如下的标准结构：

标准结构

我常常想：为什么有些人天生就擅长将一切事情组织得井井有条呢？这一份能力难道有什么特殊之处吗？然而另一面你又不得不承认，抽离出一份标准的结构，确乎不是一件容易的事情。而我们绝大多数人常常都会自觉地放弃这份艰苦的努力，放任事情的自然状态，最终则流于无序。而无序的信息所导致的就是沟通的混乱。

在 Y 所准备的发包文档中，除却其标准结构而外，尚有几处亮点是不能遗漏的：

（一）Filelist：将需要实际生产的文档罗列出来，看起来似乎并不是一件什么困难的工作。然而你仔细想一想，就会明白这其中的良苦用心。自然这是“Walking Extra Miles”的又一佐证。尤其当发包涉及到数个文档，而且需要分批提交时，Filelist 的功用就变得尤为明显。而Y 的功力，在处理大批量文档时的优势就愈发明显起来，我曾经见过他用数据透视表所准备的一份Filelist，八种语言，每种语言各包括约四千个文件；且均包含三到四个分批提交日期，竟让他用一张透视表诠释得直观易懂。这种超常的可伸缩性，正是方法论的功效所在。

（二）Instructions：这个所包含的，就是通常我们所讲的Lockit。从我上面所举的Shirley 的例子，人们应该可以约略了解到其中所包含的内容。Bothell 的工程师在准备这类内容时，往往都是基于实际的生产过程而定制，抑且考虑到了生产中可能面临及需要注意的诸多问题。这也是为什么做Y 的项目不用太动脑子的真正原因。既然所有的生产问题都已经在Lockit 中有所表述，一线的生产人员往往很少会有具体的问题去与LPM 求证，LPM 因此往往相当从容。

（三）Templates：对于任何不确定的方面，Y 都预先提供了用于查询的模板。与一般的项目不同，Y 对于查询管理有着明确的规范，模板中各个栏目的填写，也有相应的文档加以详细说明，甚或细化到查询的提交时间、提交对象、提交方式等，无不有明确的要求。你会发现，对于项目中最易引发不确定的因素，经由如此明确的定义，反而人人都释然了。因为你几乎已经可以肯定，假定你有任何可能无法了解或衡量的东西，你将确定无疑地能够从另外某个地方获得答案或帮助。这样看来，还有什么可值得焦虑的呢？

（四）Checklist：照例你在完成工作之后，是需要按照这份检查清单进行核实的，在多数情形下，这种核实具有某种象征性的意味；然而你会发现，即或偶然性极其之小，但忽略这一环节，有时候确然会导致意想不到的尴尬。

（五）Work：在Y 提供给你的发包文档中，你一定能找到一份可以直接用于生产的副本，是他甚至都已经用Trados 和你最新的TM 预处理好了的。然而，他也并不反对你自己重新处理，考虑到各语言可能会有自己的特殊性，他也总是一体提供所有相关的过程文档。

安享这些便利的同时，我常常想，为什么那一英里，我总是走不过去呢？

四、项目沟通：简明、扼要、规范

三年前我刚入此门中时，有位“前辈”曾“意味深长”地告诉我：“项目管理60%以上的时间基本上都用到沟通上了。”此后的实践亦陆续证明：项目经理的时间，有相当一部分都花在了阅读

及处理电子邮件上。其间仿佛还听到一些项目经理抱怨内部沟通占去太多时间乃至不得不加班完成提交。可以很清楚地看出，沟通确乎在项目管理工作中占着相当的比重。

然而，似乎也未见得一位好的项目经理就非要把自己弄得电子邮件满天飞不可。曾经有一段时间，我还深为自己每天收到的电子邮件数量不够充足而略有不安，看着其他同仁埋首在成堆的邮件里忙得不亦乐乎，我很觉得那是一种别样的幸福——不是每个人都可以每天收到数百的电子邮件的，它既是一种辛劳，但另一面也仿佛成了重要性的另一种标志，表明你是处于某个枢纽之中，而在外围，有很多资源在围绕着你游走。

但是，也有过了的时候。印象较深的是上T的电子邮件沟通课程，她现场询问与会诸位每天需要处理的电子邮件数量，听了几位，仿佛都不是她特别中意的答案，她便以身作则地讲述自己每小时处理六十封电子邮件的情景，一时间，众皆默然。也许各人默然的缘由不尽相同吧，而我是有些不以为然的。同样的情形，在我看来就未见得是一件值得讲述的事情，因为它至少在两个方面引发出另外一些问题：其一，如果所有的沟通都是在不足一分钟的时间内完成的，那么这种沟通就未必有足够的商业价值；其二，在如此短暂的时间内，有几个人在点击“发送”按钮时是确曾仔细看过“收件人”和“抄送”框里的那些名字呢？我自己很多时候就深受“全部回复”之苦，明明毫不相干的事情，因为久远而古老的缘由，而不得不被持续地抄送着，不胜其烦。

Y 的项目沟通，相较起来就要简单的多，然而，却也明了得多。

先说电子邮件吧，如我前面所言，因为前期工作准备得规范而有条理，所以几乎没有因为存疑而导致的相互查询和探究的情形，这自然在相当程度上使得项目相关的电子邮件数量锐减下来。另一个方面，鲜明的主题行则几乎是 Y 的独特标志。

99518 / CB1 / Doc / Drop8 / CN / Query 2005-01-07

乍一眼看到时，我很不习惯这串长长的用斜杠分开的主题行，斜杠也是我所合作过的所有项目经理中唯一只有Y 才采用的标志。然而，你不得不承认，无论你喜欢与否，看看电子邮件主题行，你就已经完全明白了邮件将要传递给你的信息。所有相关的关键词，主题行都无一例外地囊括了。大略也是从这个时候开始，我写邮件开始分外地小心起来，最起码，给Y 回信时我都会认真检查主题，唯恐有什么重要的关键词给遗漏了；引申到其它项目上，因为不好意思侵犯Y 的“专利性”斜杠标志，我也就因地制宜，根据不同的对象，或者用半角冒号分隔关键信息，或者改用短横线分隔关键信息，这么实践下来，感觉居然很是不错。电子邮件之外，Y 对项目沟通的另一个卓有成效的管理，在于严格定义了可资依循的Query 规范，与其它项目相比，Y 的努力体现在如下方面：

（一） Query 模板的定义与提供：

Y 不单为项目提供了所需的模板，抑且精确定义了模板中的各个要素。细化到每个条目的日期格式应该如何，精确到每个query 的类型定义应该如何……林林总总，不一而足。如果你有耐心把随附的Query 模板说明文档读完，你当会佩服他的思虑深祥。

（二）伴随每一批Handoff 的发包：

Y 无一例外会在Lockit 中指定各语言可以提交Query 的日期，这样语言协调员就可以集中安排与客户之间的互动与沟通，各个LPM 也可以很明了将在何时收到来自客户的反馈。而这种集中式的努力使得各语言可以共享Query 成果的同时，亦确保了所有 Query 均能在Delivery 之前获得答复，从而保证了各语言整体的提交质量。

（三）项目相关Query 的累积性

每一个 Query 在获得了客户答复并改到文档中之后，LPM 需要将该Query 的状态予以更新，而非自模板中删除。后续的新的Query，则以Open的状态继续添加到模板中。愈到后来，项目相关的所有Query 愈渐累积，从而使得历史追踪成为可能。

在Y 的项目沟通管理中，有必要一提的还有他的电话会议。其实坦率地说，像他这样波澜不惊的项目管理，委实不太需要进一步的电话沟通。我姑且把这单纯当作一种拉近感情的方式吧。毕竟，在冷冰冰的电脑语言背后，我们每两周还能听到彼此的声音，照例电话会议是例行公事般地过一下现行项目的相关状态，而且多半二十分钟到半个小时就会结束，然而，参加这样的电话会议，我的总体感觉还是相当愉悦的。

说到底，我已经习惯了这样简明扼要的沟通方式，并理所当然地把它当成好的项目管理的标志之一。

五、项目跟踪：变是唯一的不变

诚然，计划总归是赶不上变化的，Y 也不是万能的神，他计划得再缜密翔实，也免不了推倒重来的命运，好在客户仿佛也还十分成熟，在我所共事的三个月期间，变化自然还是不少的，不过都还没有脱却可控的范畴。

我们前面提到过，Y 在项目起始之初就会提供一份有关项目范围与进度的描述文档，这一份文档更新的频率，取决于Y 从客户处获知的有关项目范围及进度变更的频率。有一点是确凿无疑的，即一旦Y 了解到项目范围或进度会有变更，他会在第一时间内把更新之后的文档发送给LPM，他相当明了类似的前瞻性信息对于LPM 工作安排的重要性。

在处理项目范围与进度变更方面，我遇到的好几位GPM 都具备较高的应变与处理能力，但是，与某些GPM 只有精力直接把客户的变更文档转发过来不同，Y 往往会用颜色着意标出改动的相关条目，使得接收者可以一目了然地清楚变更所在。无论怎样，也都还好吧，毕竟这些尚不构成太大的影响。

影响较大的是由之引发的其它方面的跟踪能力上。Y 有一份依据项目范围而建构好的成本跟踪表。而他的良好口碑也在于，每个月的月底，他准定会按时更新的所有PO，并将更新后的PO 明细表发送给各个LPM 作为参考。而无一例外的，当月更新过的PO，也一定是依据已有的范围变更进行过相应调整的。

与其它项目中LPM 追着GPM 更新PO 不同的是，Y 很明确他在任何阶段所要做的事情，并且绝少发生拖延的情形。因此，在他的项目中，绝大多数行为都是可预期的、确定的，你大可不必为未来过于惊慌。

在牵涉管理的事情上，被管理者永远都在寻求某种确定感，而管理者则要始终以变化的心态面对一切。而将变化转化为确定并传递给受众，端赖管理者自身的意识与能力。我常常见到一些GPM 自己都在写给LPM 的信中抱怨客户总是变来变去，而LPM 自然也往往照单全收地传达给一线的生产人员，其结果就是“营造”出一份整体的不确定感，人皆惶惶不可终日，项目何以能平顺地进行？变是唯一的不变，另一方面，也须明白以不变应万变。

六、项目提交：巨细皆无遗

对于像Y 这样同时管理七八种语言的项目经理来说，有什么方法能够保证最终的提交质量呢？

我相信大多数的GPM 在面对这个问题时都会主动望而却步，而把最终的决定权下放给各个LPM，这样一来，项目质量就完全取决于各个LPM 的主观能动性。而任何事情一旦牵涉了过多的主观因素，就会变得不可掌控。套用一句俗话：

你所不能衡量的，你就不能控制。

而Y 在努力寻求一些可资衡量的因素。第一个因素，就是相关的日志文件。按照Y的要求，最终更新后的TM，需要同时予以提交；一同提交的，还要有使用该TM 重新分析翻译好的文档所得出的日志文件。这个日志文件，按要求是必须达到100%的阈值的。这一个指标盘下来，就可以滤出文档中可能存在的诸多问题。

第二个因素，就是所有的过程文档。通常其他的GPM 为着怕麻烦的缘故，往往只要求提供最终的文档格式。Y 不一样，Y 要求所有的过程文档都予以提供，遇有文档格式转换的，还需同时提供转换成功的日志文件。

这样操作下来，固然略显麻烦，但好处也是显而易见的。由于美洲和亚洲时区的缘故，相互之间的沟通往往需要24 小时。遇到不幸有的PM 提交了问题文件的情形，优势就出来了。往往工程师会在检查完之后就直接Fix 掉，因为所有的过程文档都在，就不会出现“无米之炊”的情形。而我在三个月的时间里，确曾有一次出现漏交一支文件的情形，然而幸好TM 是最新的，工程师直接跑了TM补交了该文件，省却了诸多的交流与等待；当然，留给我的思考空间也是巨大的。

还有一个因素，就是Y 总是要求LPM 同时提交相关的Checklist 并签名，这多少有些形式的因素在其中，但是多少也成其为一种约束力量。借助于种种可资衡量的因素以及巨细无遗的要求，Y确保了整体提交质量的一致性，从而使得该客户给予的生意额度亦逐年递升。

结语

任何领域的极致，都不啻一幅赏心悦目的山水画。画匠Y 像一只辛勤的蜜蜂，盘绕周旋在他的领地里，舞着一道特殊的风景线。这风景蔓延过来，蔓延到东方广场的办公室里，延伸成PM 的四种特质：

Team Leader
Detail Oriented
Organized
Quality Assurance

仔细想一想，讲了Y 那么多，无非就是在强调他多么有条理，而每一项特质，都有一层境界，在外面徘徊的人们，永远难窥堂奥；步入其中之后，才体会其精深与博大。这种感觉，非独与天生的悟性相关，也倚赖于一种特别的做事方法。你说它是科学，它却同时又是艺术。其间微妙的差异与平衡，你不用心去谛听，是怎么也体会不来的。

Tags: 本地化翻译翻译公司