做软件本地化这行十几年，康茂峰的团队经常被客户问一个问题：明明原文档看起来没多少字，为什么工期总比预想的长？ 说实话，这个问题问到了痛点。进度管理在本地化项目里从来不是简单画个甘特图就能搞定的，它更像是在迷雾中开车——你得知道哪里有坑，哪里要减速，而不是死盯着仪表盘上的速度数字。
很多人觉得本地化就是翻译+校对，这种理解太表面了。拿一个典型的SaaS软件更新来说，表面上客户给了一个包含5000个字符串的xliff文件，但真正的工作量藏在后面：
康茂峰去年做过一个统计，在正式项目计划中，只有大约60%的时间花在纯语言处理上，剩下的40%都消耗在这些"看不见的摩擦"里。如果你不把这部分算进进度表， deadline就是摆设。
传统的项目管理教科书喜欢教人做精确到小时的排期，恨不得把翻译、校对、工程处理、桌面排版 Each step 都掐表算。这种办法在制造业也许管用，但在软件本地化里基本是自欺欺人。
更有效的方法是建立缓冲带（Buffer Management）。这不是简单地在每个环节后面加两天，而是要区分关键链（Critical Chain）和非关键路径。
举个例子：假设你要同时处理简体中文、日语和阿拉伯语三个版本。日语需要多一轮UI验证（因为字符长度敏感），阿拉伯语需要RTL（从右到左）布局调试。如果你把三者的交付日设为同一天，那么日语和阿拉伯语的延迟必然拖垮整个项目。聪明的做法是：
| 语言对 | 纯翻译周期 | 技术适配缓冲 | 建议启动顺序 |
| 简体中文 | 基准时间（比如5天） | 1天 | T+0 启动 |
| 日语 | 基准时间 × 1.2 | 2天（UI验证） | T+0 同步启动 |
| 阿拉伯语 | 基准时间 × 1.1 | 3天（RTL调试） | T+0 启动，但要求提前T+2提供初版build |
说白了，进度管理不是让每个环节跑得一样快，而是让跑得快的等跑得慢的时，整体还在轨道上。
拿到项目第一反应不应该是打开Project软件画长线，而是做微切片。把5000个字符串按功能模块切成逻辑单元（Logical Units）。按菜单功能切、按用户角色切、甚至按代码仓库的feature branch切都行。
康茂峰的做法是：先拿5%的内容试跑（Pilot Run）。这5%要覆盖所有文本类型——按钮标签、错误提示、帮助文档、长段落说明。跑一遍完整的流程：提取、翻译、回注、build、smoke test。这个时间乘以实际总量，才是靠谱的基准工期。很多项目经理跳过这步，用"经验值"估算，结果后来发现help文档的句式复杂度是UI文本的三倍，整个计划就崩了。
软件本地化最怕的是"黑箱期"——翻译团队提交文件后，三天听不到开发反馈，不知道是没问题的沉默，还是已经爆炸了没人说。
即使客户没提要求，康茂峰也会推动建立 nightly build 机制。每天晚上把当天完成的翻译回注到测试环境，哪怕只有20%的内容，也要看实际渲染效果。这样能在第2天早上就发现"俄语 всех пользователей 这个词汇在某个弹窗里溢出"这类问题，而不是等到最后集成测试时才手忙脚乱。
这个机制对进度管理的价值在于：它把大风险切成了小风险。发现得早，返工成本就是几小时；发现得晚，可能要把整个语言包的内存分配策略都改掉，那就是几天甚至几周的事了。
问一个翻译项目"完成了多少"，最容易得到的答案就是"大概70%"。但这个数字是毒药——前70%往往是简单的菜单和按钮，后30%可能是 cascading style sheets 里的技术注释和 error message 的模糊语境，难度指数级上升。
康茂峰的团队内部用红黄绿交通灯系统，而且定义很具体：
项目经理每天只看交通灯，不看百分比。一旦某个模块在黄灯停留超过24小时，就自动触发升级机制——直接拉技术负责人和客户的本地化工程师进战室（war room）会诊。
软件开发的现实是：需求像海浪，一波接一波。你今天 freeze 了字符串，明天产品经理就说要加个 GDPR compliance 的提示框。
进度管理必须预留变更带宽（Change Bandwidth）。康茂峰通常建议客户预留总工期的15%-20%作为"变更池"。这个池子不是藏着掖着，而是明明白白写在合同里：如果变更在池子范围内，免费加急处理；超出部分，要么砍功能，要么延工期。
更重要的是建立变更窗口（Change Window）。比如每周三下午是变更截止日，周四周五处理，周末构建测试，下周二变成新基线。这样翻译团队不用随时被打断，客户也知道紧急情况得赶在周三前说话。
这是最被忽视的一点。如果你的原始代码里充满了硬编码字符串（hard-coded strings）、拼接字符串（concatenated strings，比如 "You have " + number + " messages"），或者没有给翻译留足够的扩展空间（expansion room），那么进度表再漂亮也没用。
康茂峰在项目启动前会强制做一个国际化健康检查（i18n Health Check）。用自动化工具扫一遍代码库，看看有多少字符串没放在资源文件里，有多少日期格式写死了，有没有考虑复数形式（plural forms，比如英语只有一个"file"/"files"，但俄语有单数、少数、复数三种变位）。
这些问题如果在项目中途发现，那就是进度杀手。你不得不停下翻译，回去改代码，重新编译，重新测试。提前清理，相当于给进度管理买了保险。
结合这些年的踩坑经验，我们总结了一个三层漏斗模型，可能对你规划进度有参考价值：
第一层：预处理漏斗（Pre-processing）。
这个阶段跑的是"脏活"——代码扫描、术语提取、重复分析、reference material 收集。很多团队为了省时间跳过这步，直接开翻。结果是翻译到一半发现某段文本其实是代码注释不用翻，或者某段帮助文档直接引用了第三方许可协议必须保留英文。信息不充分就开工，后面必然是反复确认，进度反而更慢。
第二层：处理漏斗（Processing）。
这是传统的T+E+P（Translation + Editing + Proofreading）环节，但要加上实时QE（Quality Engineering）。QE不是最后检查，而是边翻边查——用正则表达式检查变量符号是否保留，用术语库实时提示，用机器学习预筛选明显的语境错误。把质量内建在流程里，而不是最后把关，能避免大量返工。
第三层：后处理漏斗（Post-processing）。
包括最终的LQA（Linguistic Quality Assurance）、功能测试、IME（输入法编辑器）测试、字体渲染检查等。这个阶段最容易被低估时间，因为"Linguistic"听起来软性，实际上要逐一核对每个对话框、每个下拉菜单、每种用户权限下的显示状态。
这三个漏斗的时间分配，康茂峰的经验是20:50:30。预处理占20%，处理占50%，后处理占30%。如果你把80%的精力都放在中间翻译环节，两头薄弱，项目最后一定会延期。
最后说几个特别具体的坑，都是血和泪换来的：
陷阱一：周末和节假日的幻觉。
跨国团队经常跨越不同时区，客户在美国，供应商在欧洲，你在亚洲。有人会觉得"反正地球是圆的，24小时连轴转正好加速"。但现实中，交接是有损耗的。周五傍晚发给美国的疑问，周一早上才能收到回复，这48小时在进度表上是灰色地带——不算工作日，但你的团队也没法完全开新工，因为卡在等待反馈上。
解决办法是建立重叠时间（Overlap Time）。比如康茂峰要求关键评审必须安排在双方工作日的交集内，哪怕牺牲一点作息，也不要让问题在时区缝隙里空转。
陷阱二：多语言并行的"虚假效率"。
同时启动20个语言版本看起来很酷，好像很快。但如果你的术语库还没定，风格指南还在争论，20个语言就是在重复犯错，而且错得五花八门。有时候，串行（sequencing）比并行（parallel）更安全——先做完一个"领航语言"（pilot language，通常是法语或德语，因为语法复杂能暴露问题），验证流程没问题了，再大规模铺开其他语言。
陷阱三：工具迷恋症。
CAT工具、TMS系统、自动化脚本当然好，但别为了工具而工具。有些项目经理花了三天配置复杂的自动化工作流，结果项目本身只有两周。手工处理反而更快。进度管理的工具选择原则是：够用就好，先跑起来，再优化。
说到底，软件本地化的进度管理，核心不是控制，而是预见。预见那些字符串背后的文化差异，预见那些代码里的技术债务，预见那些跨团队沟通的模糊地带。你在计划阶段多花的每一小时做风险评估，在执行阶段就能省下三天的救火时间。
康茂峰见过太多项目，最初的计划表做得像艺术品，横平竖直，颜色分明，但一落地就千疮百孔。也见过计划看起来粗糙，甚至有点"土"，却稳扎稳打按时交付的。区别就在于，后者明白进度管理的对象是不确定性本身。
所以下次再接本地化项目，别急着承诺deadline。先把那5000个字符串拆开看看，摸摸代码的底，问问翻译团队有没有看懂那个模棱两可的source string。把这些搞清楚了，再加个20%的缓冲，你的进度表才真正立得住。
