译员在项目中途提出的问题是一种信号，不是打扰。处理得好，疑问表是你手上性价比最高的质量机制；处理得差，它就沉默了——而沉默是昂贵的。
- 一位不提问的译员是个警讯
- 它为什么会死掉，代价是什么
- 怎么让它一直活着
一位不提问的译员是个警讯
在任何有真实难度的技术项目上，一位好译员都会有问题。某个源文句子有歧义。某个术语在同一份文档里出现了两种写法。某个缩写没有定义。当这些问题不再出现时，善意的解读是源文完美无缺。现实的解读是译员放弃提问、开始猜测了——而在有歧义的技术内容上猜测，正是最严重错误的来源。
疑问表就是承载这些问题的通道：一份共享清单，译员在上面记下自己无法解决的问题，由你这边的人来回答。它的价值不是行政性的。它是你能拿到的、关于「源文、项目说明或术语中有东西不清楚」的最明确的早期预警信号——而且它浮现的时候，修起来还很便宜。
它为什么会死掉，代价是什么
疑问表沉默只有一个原因：问题回答得慢，或者回答得敷衍，于是译员学会了提问不划算。一旦如此，那些歧义不会消失——它们会被悄悄地、按假设解决掉，而你会在审校时、在交付后、或者从市场上才知道。
这笔账很清楚。一个在翻译途中被回答的问题，成本是两行回复。同一处歧义到审校才被抓到，成本是一次重译加一次重审。等到一份受监管文件已经提交后才被抓到，成本可能是一次重新申报。疑问表是这条曲线上最便宜的那个点，而团队却经常为了省下某个人一天的注意力而把它饿死。
| 同一处歧义在哪里被抓到 | 代价 |
|---|---|
| 翻译途中 （疑问表） | 两行回复 |
| 审校阶段 | 一次重译，加一次重审 |
| 受监管文件已提交之后 | 可能是一次重新申报 |
而团队却经常为了省下某个人一天的注意力，把最便宜的那个点饿死。疑问表沉默只有一个原因：问题回答得慢或者敷衍，译员学会了提问不划算——于是歧义不会消失，它们会被悄悄地按假设解决掉。
怎么让它一直活着
指定一位真的能回答的负责人——一个有领域语境的人，而不是一个只做转发的邮箱。设定一个译员可以依赖的响应时限；哪怕只是「一个工作日内」也会改变行为，因为译员可以绕开一个未决问题继续工作，而不必停下或去猜。
把答案回灌进术语库和项目说明，让问过一次的问题不会在下一份文档上再问一遍。反复出现的疑问是贵司源文材料的缺陷，修复它属于上游——属于撰写环节——而不属于一遍遍地回答。
最后，去读问题的分布，而不只是逐条看答案。疑问集中在某一节，通常意味着贵司源文的那一节确实不清楚，而下游每一个语种都会撞上同一堵墙。把源文修一次，比用十二种语言回答同一个问题便宜。