《PMBOK®指南》第6版重要术语译法探讨

文／汪小金

汪小金，云南大学教授，哲学博士，参加了《PMBOK®指南》第3～6版的中译审校工作，《项目管理评论》首席学术顾问。

项目管理的全球标准《项目管理知识体系指南》（《PMBOK®指南》）第6版英文版已于2017年9月由（美国）项目管理协会（PMI）发布，中文版（ISBN: 978-1-62825-186-9)也已于2017年12月由PMI在美国出版。这本权威项目管理标准，自1996年首版以来，一直在引领全球项目管理的发展。它也对规范项目管理的英文基本术语发挥了重要作用。

我很荣幸地参加了《PMBOK®指南》第3～6版的中译审校工作。翻译这本标准是一件相当困难的工作，包括翻译其中的专业术语。我对《PMBOK®指南》第6版的一些重要术语该如何翻译，做了一些思考。在此，与大家交流一下我的个人看法，希望为规范项目管理的中文基本术语做一点抛砖引玉的工作。

Stakeholder（相关方）

这个词该如何翻译，一直存在巨大争议。如果完全照字面翻译，就应该是“拥有利益者”。在电子工业出版社出版的《PMBOK®指南》第3版中，把它翻译成了“干系人”，后来第4版和第5版也继续沿用“干系人”的译法。“干系人”这个词虽然用了10多年，但是仍然没有被项目管理界普遍接受，主要原因是 “干系”是略带贬义且不常用的词。《PMBOK®指南》第6版中，Stakeholder改译成了“相关方”。我认为这个改译是必要且经得起时间检验的。初看，“相关方”不如“利益相关方”符合英文原意。细想，“相关方”不仅更简洁，而且更符合《PMBOK®指南》第6版强调的“Stakeholder一词的外延正在扩大”，应该“识别所有Stakeholders，而非在限定范围内”。现在的Stakeholder Management，不仅要关注在项目上有直接利害关系的人，而且要关注会受项目各种间接影响的人，以及能够以各种直接或间接方式对项目施加影响的人。那些与项目只有间接关系的人，最易被忽视，却又不应该被忽视。

Stakeholder Community（相关方社区）vs Stakeholder Group（相关方群体）

这两个概念有相当程度的交叉。前者可以翻译成“相关方社区”“相关方群体”“相关方社群”等，后者可以翻译成“相关方小组”“相关方群体”“相关方团体”等。通常，Stakeholder Community的覆盖范围要比Stakeholder Group更广；同属一个Community的人，其关系密切程度则不如同属一个Group的人。为了区别起见，《PMBOK®指南》第6版中把前者翻译成“相关方社区”，后者翻译成“相关方群体”，是比较合适的。当然，Stakeholder Community不一定是像居民社区那样的实体社区，也可以是虚拟的。例如，对一个新产品研发项目，分布在世界各地的该产品的全部潜在用户就构成了一个虚拟的Stakeholder Community。从这一点讲，也可以考虑把Stakeholder Community翻译成“相关方社群”。

Accountability（终责）vs Responsibility（职责）

在日常英语中，这两个词的区分并不明显。但在管理学中，它们的区分比较明显，尽管有时可以用Responsibility代指Accountability。我和易洪芳在合作翻译《项目治理：有效项目决策的实践指南》（罗斯·加兰著，中国电力出版社2014年5月）一书时，曾经认真研讨过Accountability的译法。因为实在找不到一个现成的中文词，我们就新创了“终责”这个词。我们当时还写了如下说明：“职责是来自职位的、对相关工作的执行的责任。可以通过授权把相关职责交由其他人履行，或者由其他人与本人共同履行。终责是基于相应的职权(Authority)和职责，而对工作执行的结果必须承担的最终责任，即如果结果不符合要求，就必须被追责或问责，就必须接受处罚。终责无法以任何方式让别人代为承担或与自己共同承担。终责是绝对不可转移的，且必须由单个个人独自承担。通常，一系列职权和职责会指向一个终责。”例如，即便项目的全部技术工作都不是项目经理亲自做的，项目经理也“与生俱来、顺理成章、毫无争议”地必须为项目的成败承担终责。《PMBOK®指南》第6版中把Authority,Responsibility 和Accountability分别译成“职权”“职责”和“终责”，是比较合适的。

Authority（职权）vs Power（权力）

这两个词有很大交叉。有时，Authority就是 Power，Power就是 Authority。在《PMBOK®指南》的各个版本中，这两个词的区分都比较明显。Authority 是来自特定职位的权力，所以被译成了“职权”；Power的来源虽然包括职位但不局限于职位，所以被译成了“权力”。《PMBOK®指南》第6版第3章提及的14种权力，其中的大多数权力都与职位没有直接关系，如参照权力、关系权力、情景权力、迎合权力。因为项目经理往往需要在职权不足的情况下承担对项目成败的终责，所以，他必须适时地利用各种与职位没有直接关系的权力，去领导项目团队完成任务。《PMBOK®指南》第6版之所以要列出这么多种权力，就是提醒项目经理不要受限于职权。仅靠职权的项目经理，最多是一个好的管理者，而绝不可能是一个好的领导者。

Project Artifacts（项目工件）vs Communication Artifacts（沟通工件）

这是《PMBOK®指南》第6版新出现的两个术语。在日常用语中，一切人工制品都是Artifact，无论规模大小或复杂与否。照此推理，在做项目的过程中由项目团队或其他相关方编制的任何文件，产出的任何成果，都是Artifact。在《PMBOK®指南》第6版中，无论是Project Artifacts 或Communication Artifacts，都主要指在管理项目的过程中所形成的各种文件。这些文件是可以通过沟通活动（Communication Activities）进行传递的。把这两个词分别翻译成“项目工件”和“沟通工件”，是比较合适的。“工件”，既简洁，又隐含“人工制作”的意思。

Individual Project Risk（单个项目风险）vs Overall Project Risk（整体项目风险）

要求同时管理Individual Project Risk 和Overall Project Risk，是《PMBOK®指南》第6版的重大改进之一。前者是指已经识别出来的、一个一个的具体风险，后者是指全部的不确定性来源（包括但不限于已经识别出来的所有单个风险）联合导致的项目目标的可能变动区间，如：项目可能推迟或提前多少天完工。这两个术语的翻译难度不算大。与可选的译文“个体项目风险”“个别项目风险”“全体项目风险”“综合项目风险”相比，《PMBOK®指南》第6版中的译文“单个项目风险”和“整体项目风险”更为合适。

Generalized Specialist (通用的专才）vs Subject Matter Expert（主题专家）

Subject Matter Expert是以往版本的《PMBOK®指南》中早已存在的，一直被翻译成“主题专家”，即精通某一领域的专家，这个译文已经约定俗成。Generalized Specialist则是新出现的词汇，指在多个领域都比较在行的专家（全才）。在敏捷项目上，项目团队必须是小规模且全功能的，这就要求每一位成员都是多面手或一专多能者。在《PMBOK®指南》第6版中把它译为“通用的专才”，意思很到位。这个译文中用“专才”而非“专家”，较好地体现了Specialist与Expert的区别。虽然Expert一定是Specialist，但Specialist不一定是Expert。Specialist的专业精通程度通常会低于Expert。例如，十项全能运动员是Generalized Specialist，对短跑、跳远、跳高等十项运动，都能做得不错；但是在任何一个单项上，他都无法达到专事该单项的、作为Subject Matter Expert的运动员的水平。“通用的专才”这个译文，稍有不足的是，这个“的”字有点多余，简化成“通用专才”会更好。

Benefits Management（效益管理）vs Benefits Realization（效益实现）

这两个术语的意思很清晰，既相互联系又各有侧重。翻译的难点在于Benefits有多种可能的译法，如“利益”“收益”“益处”“好处”“效益”。特别是对“收益”和“效益”这两种译文，许多人各有各的偏好。按百度百科，“效益”是指效果与利益，也指项目对国民经济所做的贡献，它包括项目本身得到的直接效益和由项目引起的间接效益。百度百科也直接指出了“效益”的对应英文是Benefit。百度百科中对“收益”的解释是，就该财产收取天然的或法定的孳息，对应的英文是Receipts或Proceeds。按照一般的理解，“收益”更像是经济方面的有形收入，而“效益”则包括有形和无形的利益。照这样看，把Benefits Management 译成“效益管理”，把Benefits Realization译成“效益实现”，就是很合适的。《PMBOK®指南》第6版中稍显不足的是，对Benefits的译文，有些该统一为“效益”的地方没有统一，却用了“收益”。