欢迎来到网易游戏学院藏书馆
手游海外版本项目有着团队规模小、开发周期短、对外沟通成本高等特点，其工作内容也与国内版本有着较大差异。本文从干系人、工作内容、质量控制、沟通、风险管理五个方面阐述手游海外市场本地化的开发流程和注意事项，并配以较多实例进行说明。文中所述方法在手游海外市场本地化工作中具有通用性。
提到手游海外市场本地化，很多人的第一反应是“不就是文字翻译吗？”。实际上，文字翻译仅仅是本地化工作中的一部分。相比于手游的国内版本，海外版本项目有着团队规模小、开发周期短、对外沟通成本高等特点，其工作内容也与国内版本有着较大差异。本文将从干系人、工作内容、质量控制、沟通、风险管理五个方面阐述手游海外市场本地化的开发流程和注意事项。
1.干系人的识别
在手游海外项目中，开发组成员、合作方、商务、SA、运营、UniSDK、计费等都是容易被识别的干系人。但是，海外版本的开发人员通常是从国内版本抽调出来的，这必然会影响到国内版本的开发、营销、运营等工作，即海外版本的干系人并不单纯是与海外版本工作直接相关的人群。举例而言，海外版本会接入登录SDK、广告SDK及其他类型的SDK，这些工作会占用程序员较多的时间，而该程序员此前通常是负责国内渠道SDK接入及更新的程序员，这也就意味着在接入海外版SDK的这段时间，国内渠道的SDK相关工作可能无法及时得到响应，渠道人员以及与渠道对接的营销人员可能会有不满情绪，进而影响后续的合作。尽早地识别出这些容易被忽略的干系人，通过合理安排工作顺序，及时同步信息，可以减少遗漏干系人造成的影响。
2.合作方期望的管理
一个理想的海外版本项目开发团队应该是人员充足、经验丰富且专职开发一个项目，合作方对项目开发团队往往也有这种期望。因此，有些合作方会认为所有需求都能及时得到响应，所有技术难题都能顺利解决，所有新增需求都应该被满足，落后的进度可通过加人或加班来解决。但是，通常情况下，海外版本的开发团队是从国内版本抽调出来的少部分人，部分成员是工作不久的新人，且部分成员要同时兼顾国内版本或其他海外版本的工作。在这样的情况下，开发团队在合作初期就应管理合作方的期望，根据工作总量及实际人力给出合理的排期而不是一味迎合对方的上线计划；对于需求变更、需求增加以及合作方工作的延误，要向合作方说明其对进度的影响；对于技术难点，要让合作方了解开发时间的不确定性；对于跨部门工作所固有的工期较长的问题，要让合作方了解本公司内部跨部门工作的流程。
3.工作分配
本地化过程中，有大量的简单重复性工作，部分团队成员对这部分工作的热情不高甚至有抵触情绪。在有备选人力的情况下，策划人员应考虑团队成员的特点，尊重其意愿。举例而言，本地化包含大量的图片文字资源的制作工作，这类工作安排给实习生比安排给正式员工更为合适。
1.策划人员与合作方一起设计本地化需求
海外版本项目的本地化需求绝大多数是由合作方提出，但这并不意味着开发团队的需求设计工作因此而轻松，更不意味着开发团队可以把需求设计工作完全交给合作方，主要原因有以下两点：
（1）合作方对游戏的理解并不深入，部分本地化需求可能对游戏有破坏性影响。这就要求开发团队的策划人员要用全局思维考虑需求的合理性，对不合理的需求进行调整或拒绝。这方面最典型的例子就是合作方要调整游戏中的投放与回收数值。
（2）需求范围由合作方决定，经常出现范围蔓延。范围蔓延的根本原因在于合作方在设计本地化需求初期考虑不周。为解决该问题，开发团队的策划人员要站在合作方的角度来考虑其需求是否有遗漏，尽早确认潜在需求的有无。
常见的本地化需求可分为以下三类：
（1）资源本地化。包括翻译游戏内文字、视频字幕、图片文字，录制外文语音，制作本地化题库、音乐、美术资源、logo及logo动画。
（2）功能开发。包括SDK或平台（登录、支付、广告、社交、数据统计及分析、消息推送、成就系统、录屏）接入、玩法调整、界面调整、礼包发送功能、多语言切换功能、多货币支付功能。
（3）数值调整。包括充值额度、商品价格、玩法开放等级、养成系统深度的调整。
2.按计划开展非本地化工作
伴随本地化工作会产生很多非本地化工作。本地化工作的成果可以体现在游戏中，非本地化工作的成果不易在游戏中体现。这类工作有些会被合作方忽视，有些会被开发团队轻视。前者会导致合作方低估开发团队的工作总量，进而乐观估计游戏上线时间；后者会导致团队成员拖延这部分工作，在项目后期工作强度过大。开发团队首先要对非本地化工作考虑全面，其次要让合作方了解这部分工作占用的时间，最后要按时完成这部分工作。
非本地化工作可分为以下四类：
（1）资源整理。包括整理游戏介绍资料、游戏数据表、测试用例、运营工具使用指南、美术资源、音频资源、宣传视频素材。
（2）代码管理。包括SVN上海外分支的搭建、SVN上多个海外版本协同管理、patch系统的开发、国内版本向海外版本的代码合并、代码加密、功能开关。
（3）工具制作。包括数据中心搭建、后台工具制作、文本抽取和导入工具制作、文本翻译列表制作、图片文字翻译列表制作。
（4）其他。包括服务器搭建、打包机配置、性能QA、打包及patch发布、创建高级测试账号，等等。
1.本地化资源的制作流程
本地化资源的质量会直接影响游戏品质，而文字翻译、图片文字制作以及语音录制等工作的周期较长，返工成本较高。规范的资源制作流程可减少返工的可能。
（1）文字翻译。不同游戏的文字总量差异较大，其文本量可从几百字至几十万字不等。对于大文本量的翻译工作，通常是由合作方选择外包公司进行翻译，国内开发团队很难干涉这些国外的外包公司的工作流程。但是，开发团队却可以通过事先的细致说明以及翻译期间的质量检查来提升翻译的质量。具体地讲，交互界面上的文字通常都有长度限制，开发团队提供的文字翻译列表上，应将交互界面上的文字单独标注，要求外包公司参照原始长度来翻译；在翻译期间，开发团队应要求合作方及时检查翻译质量，若质量较差，可要求合作方采取对应措施，如更换翻译人员。
（2）图片文字制作。相比于纯文本文字的翻译，图片文字的制作，除了要求翻译准确、长度合适以外，还必须考虑排版（换行、对齐、间距、变形），且字体的选择也会对图片文字的视觉效果产生影响。在流程上，首先，开发团队与合作方要共同确定图片文字所采用的字体，综合考虑字体的美观性以及字体与游戏风格的契合度，并确保合作方对该字体具有合法使用权；其次，开发团队应制作图片文字翻译列表，其内容是原始的图片文字而不是纯文本，以便于翻译工作者在确保准确性的同时兼顾排版；最后，图片文字的制作者应严格参照原始图片文字的尺寸输出翻译后的图片文字。
（3）语音录制。语音是彰显角色特质的重要途径，游戏设计者因了解角色特质，容易挑选出合适的配音员，并使其按照特定的要求来配音。但是，不同语言在发音方式上存在差异，合作方对游戏角色的了解也不一定足够深入。因此，合作方难以仅仅通过听原始的语音就找到合适的配音员，并要求其按照符合角色特质的方式来配音。鉴于此，开发团队应提供详细的配音说明，其内容应包括角色的种族、性别、年龄、背景故事、声音特征、表演要求、台词及其应用场景等。
2.双方在测试期间的合作
在游戏测试方面，开发团队与合作方各有优势。开发团队熟悉游戏内容，知道各类bug产生的原理，能熟练使用后台工具来配合测试；合作方拥有当地的主流机型，了解当地玩家的操作习惯，知道当地常见的作弊方法，并且其测试环境是产品上线后的真实环境。因此，双方在测试期间应充分合作，避免其中一方过度依赖另一方。合作可体现在以下几个方面：
（1）开发团队提供详细的测试用例，便于合作方全面测试游戏；
（2）开发团队提供后台工具并指导合作方使用，加快合作方对特定功能的测试速度；
（3）开发团队尽早向合作方索要当地主流机型的清单，安排采购，以便复现在特定机型上出现的bug；
（4）向合作方提交游戏包之前，开发团队应对该游戏包测试通过，减少合作方不必要的测试工作；
（5）开发团队应了解合作方公司有关测试工作的规定，避免因己方工作的疏忽延误了合作方测试工作的进度；
（6）对于合作方反馈的bug，开发团队应及时响应。
1.顺畅沟通的前提条件
不同国家存在文化差异，不同公司也有独特的企业文化，海外版本项目顺畅沟通的前提条件是彼此相互了解，这一过程会贯穿项目始终。合作期间需要重点了解合作方的方面包括：对方重视效果还是重视效率，信守承诺还是出尔反尔，严格遵照流程还是乐于接受变通，尊重员工个人利益还是奉行集体利益高于一切。
2.需求设计流程
合作方的接口人在设计和描述需求方面未必是专业人士，加上异地办公、语言差异和翻译失真的因素，常出现开发团队的工作成果跟合作方的预期结果存在较大出入情况。规范的需求设计流程可以减少这类情况。两类比较有效的流程如下：
（1）针对国内版本已有功能的本地化，开发团队提供国内版本的相关需求设计文档，合作方参照此文档给出本地化需求设计文档，开发团队再针对其中不明确的地方与合作方进行确认。应用该流程的例子包括登录过程的交互方案、新角色需求。
（2）针对合作方提出的定制化功能，合作方先提供需求方案，开发团队基于游戏特征和方案可行性对方案进行修正，输出需求设计文档，合作方再对需求设计文档进行确认。应用这类流程的例子包括SDK或平台接入、新功能需求。
在上述两类流程中，需求的讨论是基于模式化的需求设计文档，而不是基于口头的交流，这也就减少了双方对同一问题理解存在差异的可能。
3.信息传递机制
在海外版本项目中，开发团队的对外沟通成本较高。信息传递不畅容易产生误会，信息传递混乱会使信息失效，信息过多又会干扰开发团队的工作。这一切的后果都是耽误项目进度。因此，开发团队有必要规范信息传递机制，具体地讲：
（1）定期召开电话会议。会前准备议题并发送对方，议题可包括开发团队的近期任务完成情况、工作中的阻碍及潜在的风险、合作方近期需要完成的工作、需求的确认、项目排期的修订，等等；会中控制讨论范围，控制开会时间，对于口头无法描述清楚的事项可会后通过书面材料描述；会后发会议记录给相关人并督促落实。这类会议的核心目的在于使双方及时同步信息，减少误会。
（2）针对每种沟通渠道指定接口人。该接口人应及时响应对方发送的信息，熟悉产品，能回答合作方的大部分问题，对于不熟悉的问题可调动其他人回答。指定接口人的目的在于明确责任，提升响应速度，减少非接口人受到的干扰。
（3）针对合作方的自有平台指定专人负责。开发团队与合作方都有自己惯用的工具，如功能开发看板、Bug反馈平台。双方都会试图让对方使用己方工具，这样既可达到信息对称的目的，又可减少己方的学习成本和工具使用成本。但是，使用对方工具的一方却会负担学习成本和工具使用成本。若开发团队同时负责多个海外版本项目，并且针对每个项目都全员使用合作方的工具，开发团队的工具使用成本会极高。为减少开发团队的工具使用成本，同时又顺利推进双方的合作，开发团队可针对每个海外版本项目指定专人查看并更新合作方工具的信息，将其信息整理后发布在开发团队的惯用工具上，开发团队的其他成员仅使用己方的惯用工作。
1.竞品风险
海外版本项目周期较短，项目启动直至产品上线的周期通常在3至4个月。但是，在该周期内，目标市场依然有可能出现品质更高的竞品，极大影响产品上线后的市场效果。这类风险的预防措施是尽快使产品上线。控制需求范围，梳理各项任务间的依赖关系并安排好优先顺序，了解己方和对方公司的产品上线流程，持续跟进各项任务的进展状况可确保产品上线的日程不被延误。
2.技术风险
海外版本项目的技术风险常存在于非游戏内容需求，如SDK接入、多语言切换功能、礼包发送功能、包体受限的游戏首包及其patch系统、SVN上多个海外版本协同管理的环境搭建。这类需求的共性是团队成员在开发国内版本时未曾对其考虑，其可行性、开发时间及最终效果都存在较大不确定性。这类风险的预防措施是提高相关工作的优先级，尽早开展相关工作。
3.人员风险
海外版本项目的人员风险与国内版本的人员风险类似，比较独特的风险存在于同时开展多个海外版本项目的团队中。为减少国内版本向多个海外版本合并代码的工作量，有时会由一个程序员来协同管理SVN上多个海外版本的代码。在这样的情况下，若该程序员休假，离职或出现意外，所有海外版本项目都要停滞。这类风险的预防措施是安排至少一个额外的程序员掌握SVN上多个海外版本的代码管理方法。
本文从干系人、工作内容、质量控制、沟通、风险管理五个方面阐述了手游海外市场本地化的开发流程和注意事项。其中提到的方法，可适用于多数海外版本项目，但针对具体的某个项目却并不一定是最佳方案。开发团队可根据每个项目的独特性，适度参考上述方法。