作者：Ernst ten Bosch

作者声明：

虽然我在暴雪娱乐工作，但本文只代表我本人的观点，不代表暴雪的任何形式的政策、行为等。

引言

我经常被问到的一个问题是：成为一名游戏制作人需要什么？答案很简单：什么也不需要。要成为制作人，你真的什么也不需要。任何人都可以成为游戏制作人。任何会看人或正 好在某个职位上的人都可以成为游戏制作人。要成为游戏制作人，你不必经过任何正规的培训或获得任何相关的学位。申请游戏制作人的职位，你基本上不会被要求展示有助于游 戏制作工作的才能或知识。当然，如果你熟悉那些既定的方法论如敏捷开发或你是计算机科学出身的工程师，那当然是可以加分的；但这些绝对不是必要的。类似地，如果你是一 个做事有条理、擅长学习的人，那么也是有帮助的。但是，这些是大多数成年人都已经一定程度上掌握的能力，更别说任何人都可以声称自己具备这两种特质中的一种或两种都有 了；毕竟“声称”是没有办法查证的。

但并不是说成为游戏制作人就是一件轻而易举的事，或者游戏制作人的工作没有挑战和困难。真相是，就像人的性格一样，制作人也是有很多类型的，每一类都有各自的优点和缺 点、长项和弱项。比如，不同程度的灵活性对于游戏制作人的工作执行，既可能是幸事也可能是灾难。取决于具体的情况，制作人在任何时候都可以选择承担责任或推卸责任。如 果某个项目大获成功，制作人可能是被捧得最高的，也可能默默无闻；如果项目失败，制作人可能是被骂得最惨的，也可能责任撇得最干净的。关键是要记住，游戏制作人的工作 其实与游戏制作本身没有直接关系。所以如果他都没做游戏，他怎么可能搞砸游戏？

不同游戏制作人的能力和工作方式有很大的不同。有些制作人为人圆滑、像个汽车推销员；有些制作人性格内向、像个学者；有些制作人一张嘴巴闲不住，总是说个不停；有些制 作人交代任何工作都只通过邮件。本文的目的不是解答成为游戏制作人需要什么，而是什么才是优秀的游戏制作人。

本文所说的内容其实是根据我自己应该做得更好的东西和我在同行中看到的、我希望自己有一天能做到的东西，整理而成的。所以大部分是我个人的经验，有些是非制作人的人告 诉我他们希望或不希望自己的制作人做的事。

出于本文的目的，我设想的是一个一般的、中等资历的游戏制作人（如果存在这种标准型的话），而不是非常资深的、能拍板决定百万美元预算的制作人，也不是工作包括倒咖啡 和送甜甜圈的菜鸟制作人应该怎么做。

我也不希望这文变成关于如何做游戏制作工作的指南手册。不同的公司有不同的游戏制作流程中，有些公司甚至根本没有游戏制作人。所以，本文内容不适用于所有人。

当我说我的“羊群”，我指的是那些认为我是他们的最主要制作人的开发者团队。当我说“团队”时，我指的是整个开发团队，包括其他制作人带领的羊群。当我说产品，我指的 是这个团队正在集中注意力制作的一款电子游戏。

为了方便，我把游戏制作人称作“他”；游戏制作人当中也有很多女性制作人，在这个领域，大部分女制作人的表现与男制作人相当或甚至更强。

什么是“优秀”的制作人

我们从最基本的概念说起。为了知道什么才是“优秀”的制作人，显然必须了解制作人要做什么。

我认识的许多游戏制作人都解释不清楚自己到底做什么工作或对游戏开发本身有什么贡献。美术制作人画画吗？不画。程序制作人管理程序员小组吗？不管。制作人能决定什么东 西能放进或不能放进游戏吗？一般来说不能。制作人制定和控制开发预算吗？还是那句话，一般来说不能。那么，制作人到底做什么？

当我对朋友和家人解释制作人的工作时，我通常会作个比喻；我觉得这个比喻准确地形容了制作人的作用，虽然不是详细的工作描述。

一方面，制作人就相当于牧羊人（shepherd）。我指的不是拿圣经布道、作为道德楷模的牧师（游戏邦注：“shepherd”有牧羊人和牧师两个意思）。我指的就是字面意思上的牧 羊人，和赶鸡放牛的那种人一样。这就是为什么我有时候会把我的团队称作我的“羊群”（尽管我仍然不知道我的小伙伴们能不能体会到我称他们为“羊群”时满怀的深情。）

对于牧羊人和羊，真正的价值不在于牧羊人自己，而在于他的羊。羊群才是提供最终产品的家伙，所以应该被精心照顾和养育、有舒适的居所和充足的食物。牧羊人可以吃发霉的 老面包皮，而羊群却必须吃新鲜的优质牧草。

此外，羊群不是归牧羊人所有，所以牧羊人也不是最终对羊群负责的人。他不能决定羊群的命运，要不要剃毛，要不要挤奶做奶酪，能不能杀了做羊肉串。

最后，任何人都可以成为牧羊人；只要他会拿着大棒走上一整天。如果牧羊人不干了或死了，很容易就能找到其他人顶上空缺。

我要用的第二个比喻是，制作人相当于父母。还是跟牧羊人一样，我指的父母没有什么浪漫色彩；跟美丽的母亲或伟大的父亲无关。我指的父母是比较“含辛茹苦”的那一种。我 来解释一下。作为父母，无论发生什么事，无论你有多累多忙多生气，你都要养育、关照和保护你的孩子。你必须做出艰难、无耐的决定，你想好你自己要什么……呃，好吧，在 这出希腊悲剧里是没有“你自己”这个词的。你别无选择，只能无条件地对你的孩子播洒爱和为他们奉献。

对于制作人和他的小伙伴们，这种感情也许不是真实的，也不可能是相互的，但为了共同的目标，执行起来当然要以假乱真。还是以你的开发团队就是你的孩子为例，有时候你撞 见他们，他们也假装没看到你。有时候他们会在你背后笑话你。有时候他们会当面说你无聊或不开窍。而你可以做什么？你必须做什么？你可以并且只能低声下气，继续对他们表 示关爱，无论这种感情会不会得到他们的回报。这就是制作人/父母的悲哀。

游戏制作人的原则

既然我们已经了解制作人在游戏开发这个微观世界中的地，我们就可以看看游戏制作人的目标了。正如我前面提到的，游戏制作人有各种各样的类型。有一类制作人就是电子表 格狂人；这种人喜欢作报告、图表和总结，通常极力避免不必要的人际交往。对他而言，他的羊群是一帮他不得不时时打交道、不幸但必需的人组成的。另一类制作人像个高中生 ；这种人追求人气，渴望别人的认可和重视。他的羊群是一帮可以一起玩的朋友。还有一类制作人是任务机器人；他的世界就是任务管理、资源分配和工作日程表。他的羊群就是 工厂的流水线上的工人，以或多或少固定的速度大量生产产品。

我们来看看一般的游戏制作人是怎么样的。我不打算从既定的项目管理系统如敏捷开发，而是从游戏制作人的一般原则入手，看看他的羊群对他的期待。

灵活性和适应性

我前面提到“流水线”，但如果说有一个属性绝对不能用来形容游戏开发，那么它就是流水线。游戏行业仍然处于它的幼年期，事态几乎不会按照你的希望发生，每前进两步就要 后退一步。这对某些学科的影响更大，而这些学科又有各自的应对方式。对于游戏制作人，应对开发中的变幻莫测，你的应对办法只有：预料到会发生变化；知道某事一定会发生 所以你要尽可能做好准备。正如有这么一句话：“居安思危，未雨绸缪。”制作人必须有这样的素质。

状态意识和报告

我认为，游戏制作人起码应该能意识到团队和产品发生了什么事，确保他的羊群或至少领头羊知道这个信息。他应该不仅应该知道目前的耽误之急是什么，还要知道下一个耽误之 急是什么。任何程序员、设计师或美工都应该能够从制作人口中得知团队的大方向、当天的重要事宜和团队的首要目标。当然，有些事制作人可能不知道，通常是因为那些事与其 他部门有关。然而，制作人不知道应该是那些事的细节，整体情况仍然应该说得出一二。制作人的沟通交流能力是关键。

交工代表

游戏制作人的很大一部分工作是赶截止日期。这是与日期、日程表、计划、起始点、重大变化之类有关的工作。首先，制作人必须知道什么是重要的时间点、还有多少剩余时间、 截止日以前必须做什么、什么最可能赶不上截止日，等等。制作人还要大致了解他的羊群要达到目标面临着什么主要困难，了解至少要达到能描述给第三方、回答基本问题的程度 。他可能不必亲自做开发工作，但他正是他的羊群的代表。

润滑剂

游戏制作人也是搭桥工人、调解人和引导者。制作人经常会遇到他自己解决不了的问题，这时他的工作就是找到能解决问题的人。这也许要求他开会、发邮件，或甚至亲自出门找 人，直到找到答案。

这种事经历多了，他就会发现自己已经积累了大量人脉资源。进一步拓展，这些资源就会成为整个羊群的人际网络。对于团队，制作人是沟通外界的桥梁；对于外界，制作人是通 向团队的窗口。

不应该要求程序员认识IT部门或QA部门的所有成员，但是制作人应该做到。反之也一样，QA部门的成员不必认识团队中的所有设计师、程序员或美工，他们只需要知道一个人就行 了—-那就是团队的制作人。

多面手

在本文开头，我说成为制作人不必精通任何事。那是因为他要负担的事太多了。制作人是个多面手，什么事都逃不出他的法眼和职责范围，只要这件事对他的羊群、团队或最终产 品有好处，他就要承担起来。正如我之前说的，虽然其他人可以专注于自己学科范围内的任务，但制作人应该应付所有他能力范围之内的事，无论是做电子表格、订会议室、写会 议提要、打任务报告或保证会议室的视频会议系统修好了。

外交大使

制作人是个外交大使，无论是对于他的羊群而言，还是对于团队和产品而言。真正的外交大使要了解自己国家的历史、现状、骄傲、耻辱、斗争等等，制作人也是如此。精通这些 事务会使他更容易做出正确的判断、在协商时占据有利位置。与外交大使一样，制作人要走到外面的世界，收集信息，反馈给内部的团队。这样，他的羊群才能与时俱进，走在前 沿。

但最重要的是，与外交大使一样，他必须坚定不移地为他的羊群谋福祉。对外，制作人必须成为团队的拥护者；对内，制作人必须成为他的专业的拥护者。虽然做实际工作的人必 须担忧能否完成任务，如写代码、补漏洞、录声音、译文本、做关卡、画图像，制作人是稳定性和一致性的警示灯，把个人的兴趣丢到一边，把团队的最大利益放在前面。

避雷针

制作人的另一个重要而偶尔被忽略的角色是绝缘体。与高楼大厦上面的避雷针一样，制作人要为他的羊群挡掉外部力量的不良干扰和影响。第三方会不断地来挖你的羊群中有才华 的游戏开发者，无论这个第三方是外部的团队还是内部的其他团队。美工可能会被叫去做特别营销广告的海报，而不是设计新资料片的装备；程序员可能被叫去帮忙修复网站支付 系统的漏洞而不是编写新特征的代码。当然还有永远存在的威胁，如羊群因为懒惰而把漏洞丢给其他人解决，而不是自己动手。如果制作人能有效地发挥自己的职能，那么他的羊 群就能更加专注于他们的核心工作，也就是他们最擅长的、最喜欢的工作。

特定的情境和优秀的游戏制作人应该做什么

既然我们已经知道游戏制作人在游戏开发中的一般工作和作用，我们就可以更加深入地了解优秀的游戏制作人如何处理以下特殊的和常见的情境。

任务分配

所谓的“项目管理”其实说白了就是任务分配，我认识的所有游戏制作人都经常做的事。任务分配是什么？就是这个工作名称所显示的：分配任务。无论是通过电子邮件、便签或 其他什么工具，本质上都一样：技术上是非常简单和平凡的。但即使是这么简单、千篇一律、想搞砸都很难的工作，也只有一种做好它的办法。

制作人可以轻易地把所有相关人员召集到办公室或会议室，命令他们去做什么任务以及花多少时间完成等等。然后，如果任务有什么不清楚的地方，他可以找到原来的命令者；所 有游戏制作人都必须经常审查任务的状态和任务执行者的更新情况。

但这种方式是有缺陷的。在游戏开发的情境下，任务分配不只是指派工作给程序员、美工或设计师的方法，更是制作人和所有项目相关人员的一种发现疑问的方法。任务整合应该 是一个工作记录：包含已经完成的工作和尚待完成的工作、遇到的问题和解决的问题、或导致新任务的事件。及时记录任务分配情况可以使大家对工作更加清楚、为以后的工作积 累经验。所以，任务分配也要包含记录，这是非常重要的。不负责执行这项工作的人是否也理解它？起始日期和截止日期是否符合日程表？任务是否标明“完成”或者错过截止日 期都没有更新？未来的我们是否能够读懂任务分配和执行情况？

当然，把这种程度的详尽和勤勉运用到任何项目的成千上万的任务分配中，工作量一定会滚雪球般地增大，以至于游戏制作人几乎没有时间做其他事，但我认为这么做还是有实在 意义的。制作人应该问自己：我是否理解了这项任务？是否可以期待理想的结果？如果有人问我，我是否能用非技术术语来描述它？如果制作人对这些问题能诚实地说是，那就说 明他在任务分配方面做得不错。

制定日程表

制定日程表的方法肯定有成千上万种，取决于它的目标。制定日程表是为了让程序员、美工和设计师知道他们还有多少时间可以完成任务吗？是为了让营销人员、PR和社区经理知 道任务什么时候可以完成吗？或者是为了显示赶圣诞购物季我们所有人必须完工的日期吗？这些目的可能都有。但无论是哪一个，在过去数年制定日程表的日子里，我学习到两条 简单的、基本的原则：1、不要让工具决定日程表的格式。我只使用Excel。2、你制定的日程表不是只给你自己看，你的客户才是接收者。如果我想做一份私人用的日程表，我会在 表格中加入大量细节、缩略词、笔记和个人评论语，可能会混乱得让其他人都看不懂。

但这些只是基本的建议，我会向需要制定任何一种日程表的人推荐这两点。对于游戏制作人，这么做太简单了：记下他从部门主管处听到的交付日期，填到整齐的表格或图解中， 然后发送给相关人员，不管他们如可抱怨这份日程表的含糊。

然而，优秀的游戏制作人是理解日程表的。他知道重要事件意味着什么、为什么要在某个日期以及如果错过日期会有什么后果。他还知道什么因素能影响重要事件的日期是否可以 达到；谁负责什么，谁在休假，谁生病请假以及哪些团队人手不足、步入正轨或被延误了。

知道了这些东西后，他可以预料问题和障碍，然后解决问题和克服障碍。如果游戏制作被问及为什么截止日期不能更早一些，他必须有现成的可靠的回答，或至少找得出一个。如 果制作人不理解像他的日程表这样基础的东西，他还能理解什？

开会

我认为可以说，并没有太多人真正喜欢开会，所以极少负责主持或准备会议的人会带着满满的活力和热情开会。

游戏制作人，与任何会议组织者一样，应该确保达到基本的组织和会议标准，比如说有议程、有人做笔记、按时结束不拖延、相关人员到位以及会后任务跟进等。听起来很简单， 但实际上不可能始终达到这些要求。至少对我而言。

除了任何行业的会议中的最佳实践，有一件事，如果不是独一无二的，对游戏制作人来说是非常普遍的。与我成为游戏制作人以前参加的大部分会议不同的是，我现在很经常参加 一些讨论我个人不太期待的工作的会议。这意味着我不一定会理解所有东西，我只是必须知道会上说了什么。可能是因为技术性太强或与管理的问题有关，但二者都不在游戏制作 人的责任范围内。或者更经常的是，因为会议是关于完全不同的团队或部门的工作，所以我根本不知道发言人在讲什么！

在那些情况下，游戏制作人除了参加会议，还应该付出其他努力。如果他想有所贡献，他必须不仅知道别人在说什么，还要理解别人所说的。记笔记、分配任务然后敲定日期，这 些事太容易了，一般的制作人都做得到。但真正优秀的制作人会保证他理解材料、某个结论是如何得出的以及为什么要做某个决定。因此，他给他的工作增加了新维度，不只是成 为执行者，分配任务、发送邮件、组织会议，他还成为建设者—-一个有权威的项目所有者和真正的开发者。

沟通交流

在游戏制作人的工作描述中，你必然会看到“优秀的沟通交流者”这一项。我发现它经常被滥用。任何人都可以声称自己具有出色的沟通交流能力，毕竟没有什么标准方法可以判 定一个人到底擅不擅长沟通交流。

这并不是说沟通交流能力不重要，而是说，如果你想成为游戏制作人，你在陌生人面前一定不能怕生。类似地，如果你不敢在众人面前或在会议上发言，那么你可能得换一份工作 了。至少，你不会觉得与人交流是你的限制因素或必须克服的障碍。如果是，那么沟通交流不是你的强项。

所以当制作人在执行“沟通交流”时，他必须记住什么关键元素？

1、每一个人都是独一无二的。优秀的制作人了解自己的团队，知道如何与团队成员打交道。有些人喜欢开会，有些人不喜欢。有些人习惯于一整天埋头工作，通过邮件和聊天应用 交流以。有些人喜欢你路过时跟他说上几句话，有些人则厌恶你那么做。如果制作人知道如何与成员们打交道，他就能更有效地传达信息、咨询问题或当有必要时表示拒绝。意识 到不存在以不变应万变的沟通方式，是学会沟通的第一步。

2、让别人随时找得到你。最重要的事就是让人随时找得到你。当有人要找制作人时，他就必须找得到，让人找得到自己也是制作人的职责。在现在这个时代，找人应该不难，通过 邮件、电话或甚至FaceBook、FaceTime、WhatsApp和Skype等。保证别人找得到自己并不是件容易的事。制作人必须保证别人能从公司的通讯录、内部网站等地方找到他的联系方式 。除了极小数时候，优秀的制作人必须保证只要他在办公桌边，他的MSN就在线；如果他不在办公室，那么他的手机就开机；无论是在家还是在路上，经常查看邮件。这些应该占据 他90%的工作时间，而把联系方式放在邮件的签名处和/或办公白板上应该占据剩下的10%。当别人不在办公桌边或电脑前，这些信息就很有用了。

3、让别人知道你的工作。正如我在本文开头提到的，许多人，包括开发团队的其他成员，往往不知道制作人做什么。结果是，他们不知道制作人是否以及如何为游戏开发做出贡献 。因此，游戏制作人让别人清楚他在做什么是非常重要的。为此，他要同时表现自己可以帮上什么忙和可以做什么。这样虽然会导致更大的工作量，但贡献也更大。帮不上团队或 他的羊群的游戏制作人就是没有用的制作人。任何制作人都可以坐在办公桌前，发送邮件和分配任务，知道他在老板希望他做的事；但优秀的制作人知道如何让外界意识到他的有 用。在会议上，他准备好、注意到且说得出自己的观点。他能提出别人可能羞于提出的问题。他做报告、写日程表，表现他知道开发进程。他回答复杂的问题和根据需要调整日程 表，表明他清楚他的羊群的工作情况。

这些行为看起来可能有些做作或虚伪，但如果制作人希望自己有决策发言权、被平等对待且让人觉得他平易近人，那么就必须让所有人看到他工作得有多么努力，他受的苦与其他 人一样多，即使他并不知道如何动画3D模型、录音或翻译任务文本。

4、效率。最终，良好的沟通交流是为了高效地执行工作。制作人在此扮演重要角色。如果制作人能把任务分配得好，那么程序员、美工或设计师更容易展开工作，不需要解释或修 改。进一步说，如果任务分配得好，就更容易估计执行情况、所需时间、可能遇到的问题以及如何解决那些问题。这样，经理或其他制作人就可以立即了解开发进度。与此同时， 设计师、美工、程序员和测试员可能会从执行中学到一些东西，当他们遇到类似的情况时就不必浪费时间做重复的工作。通过合理分配任务和跟进任务，优秀的制作人不只是与指 派到任务的人沟通，而且是与所有可能得知任务的人交流。

这也适用于制定日程表。有了良好的日程表，开发人员可以立即知道目标的进程和重大事件。如果开发人员必须反复查看才能知道数字的意思，那就太浪费时间了，结果是他可能 会觉得麻烦而不愿意再看日程表，进而忘记截止日期。

与任务分配或制定日程表相比，会议上的沟通交流更是一门微妙的艺术。有些团队可能希望制作人这样开会：进场、保证录像机工作正常、发放议程、保证有人进行会议记录和发 放笔记。但有些时候，团队会希望制作人更加尽职一些：保证发言不脱节，会议不超时等。我们普遍认为，开会不宜太久，不能局限于行话或沦为闲聊，制作人应该充当调解人。 无论团队喜欢哪一种会议形式，制作人都应该知道什么方式对与会者最合适，并且确保与会者落实行动。优秀的制作人是很灵活的，能够在不同的会议形式之间切换，但如果有必 要，还能强制会议按最高效的形式进行。

制作人不应该做什么

我们已经探讨了游戏制作人在游戏开发团队中的角色和优秀的制作人应该如何达到他的目标。现在，我想从相反的角度谈谈，制作人应该避免落入什么陷阱。优秀的制作人不应该 做什么？

不要害怕提问题

大家都默认游戏制作人具有深厚的技术背景或能抓住所有任务细节和漏洞。事实上，如果他花太多时间在这些事情上，他很可能是浪费时间，因为无论何时，总会有人比他更熟悉 那些事情、比他有更好的位置去做那些事情。从更远一点的距离看工作量，会给制作人更全面的视角、更宽广的视野看待事情，这才是制作人的职责所在。另外，如果制作人能够 理解一个问题并且能够用不带技术术语的话把它概述出来，他就能更容易把信息传达给其他人，如其他制作人或相关团队。为此，最关键的一步是提问题。如果制作人发现自己对 什么事情不理解，他必须让人解释给他听，即使这样会使他自己显得愚蠢或无能，或觉得给别人添了麻烦。与其等到任务分配了、开会了才会发现完全不清楚挑战是什么，不如花 时间提问题和要解释。浪费一个人的时间和冒着被人当成傻瓜的风险，总是比浪费所有人的时间来得好。游戏制作人应该学会放低姿态，在必要的时间不耻下问。

不要制造不必要的工作

合理排序工作的第一步就是，决定某工作是否是必须做的。任何人在任何时间都可能产生若干“如果我们做了应该不错”的想法。虽然对于大部分没有执行权的人来说，抱有这种 想法是安全的，但对于具有实权且有办法让想法实现的人来说，特别是那些可能在会议上把想法大声说出来、分配到实际工作中的人来说，是非常危险的。这正是制作人应该保持 谨慎的地方。只因为有人认为做某事不错，并不意味着应该做某事，特别是当这个人本身并不是做事的人。制作人必须意识到决策转化为工作，太多工作会导致延迟，延迟是制作 人的灾星。程序员、美工、翻译或设计师，即使是资深的或主管，对项目的整体看法可能不会与制作人相同，因此可能不会意识到整体影响。所以，制作人必须非常擅长顾全大局 。制作人必须非常清楚，会议能否取消、漏洞能否悬空、任务能否延期或甚至不执行、一项必须完成的工作能否增加工作时间和精力。

不要让人讨厌与你合作

严格地说来，无论是什么专业，对于游戏开发者而言，与游戏制作人保持密切合作并不是关键的。角色美工或服务器程序员可以任务列表就开始一天的工作，无论他的任务是由制 作人还是主管分配的，并不重要。如果他必须加班或通宵，他的直接上司会告诉他。如果他对薪水、升职或休假有意见，他可以找他的经理谈。他并不需要与游戏制作人打交道。

这就是为什么，游戏制作人必须体现自己的有用和平易近人。如果他可以保证别人不忽略他，他在“有用”的道路上就迈开第一步了。我坚信，优秀的制作人可以显著地提高开发 团队的生产效率，但只有人们理解游戏制作人的价值并积极地希望获得那些价值，才能达到那个效果。

不要拖延

延误截止日期可能出于各种原因，比如额外的变数太多或相关性太强。这是应该预料到和准备好的。除了断电、病假、宠物死了和地震，即使是最资深的游戏开发者也可能误判某 个任务需要花多少时间和人力。这是可以接受的。不能接受的是，制作人自己的耽误拖延。如果计划不能制定因为还没开会，这就是制作人的失职了。如果程序员等着网页设计师 的回复，制作人必须保证了解这个情况。如果玩家遇到严重的漏洞，制作人必须找到负责修复漏洞的人。事实上，制作人很容易回避这些问题，因为他要做的通常是发送邮件或打 电话。但正是因为听起来简单，在这些事情上的失败才显得更加令人不能容忍。

不要忘记跟进

发送邮件然后假设对方已经收到了、读了、思考了，这对有人来说都是很容易做的事（游戏邦注：尤其是在这样一个即时通讯、Facebook和随时发表“评论”的时代）。在这种 “过后就忘”的文化里，问责和跟进基本上被忽略了。但在游戏制作人的日常工作里，那样可不好。很大程度上，发邮件、打电话和开会都是有原因，那些原因是需要解决方案的 。在程序员必须回去写代码，美工必须回去做模型，设计师必须回去设计关卡的时候，制作人也没有喘息的机会，不能分心太久。用邮件跟进、在会上总结或询问开发者，是制作 人存在的部分原因。在这些事情上失败了就是放弃了制作工作的核心责任。

结论

很难判定一位游戏制作人是否把自己的工作做好了。正如我在开头所说的，如果产品成功了，制作人可能获得好名声，他可以说：“是啊，我是制作人，成功归功于我。”类似地 ，如果产品失败了，制作人也很容易摆脱所有责备，他可以说：“我不是设计师、不是程序员、不是美工，我怎么可能搞砸游戏？”如果他的团队不错，游戏制作人是可以摆脱被 看低的命运的。

但事实是，憋脚的手艺人才责备自己的工具，对于游戏开发者，他的羊群就是他的工具箱。制作人应该总是拥有他的羊群的产出。他可能不是失败的原因，但那并不意味着他不必 对失败负任何责任。

在本文开头，我提到美术制作人不画画，那是真的。然而，优秀的美术制作人知道画画需要什么。他知道他的团队赶截止日期需要多少时间、有什么困难、什么工作有什么用。他 理解产品的生命周期。类似地，我也提到程序制作人不管理程序员团队。但优秀的制作人知道如何与他的程序员沟通。他知道程序员喜欢怎么工作；谁喜欢呆在阴暗的角落里默默 地写代码，给谁分配任务时要格外谨慎，每一次开会要邀请谁。另外，制作人通常不决定什么东西能加入到游戏中，但他们知道什么建议有用，什么变通合适，什么特征荒唐。制 作人通常比单个开发者有更广阔的视野，更能从大局出发。最后，也许是最重要的，尽管大多数制作人对整个团队的预算几乎没有影响力，但他们必须总是把预算记在心上。这个 世界上没有公司会愿意随便砸钱，但另一方面也是真的：没有公司会因为潜在成本而压抑员工的效率，特别是在创造力主导的行业。这就是为什么优秀的游戏制作人要始终把高效 、截止日期和保证尽快解决问题放在心上。

总之，优秀的游戏制作人要根据与他合作的人、正在开发的产品和截止日期的紧迫性来展开工作。为此，他必须灵活知变通；总是能够适应新环境且有预见能力；当预料中的事发 生时，当所有人都慌作一团时，制作人必须保持冷静和理性。

同时，他必须精力充沛，有强烈的责任感。他必须做到他所承诺的事，必须跟进他分配出去的任务，必须催促拖拉的人、提醒所有人。他可能并不喜欢某些工作，可能不会受到太 多认可，但这也是工作的一部分，优秀的游戏制作人必须在最大利益面前把自我放到一边。在游戏开发人才云集的圣殿里，这是制作人宣称自己的价值的唯一方法。

相关拓展阅读：篇目1，篇目2（本文由游戏邦编译，转载请注明来源，或咨询微信zhengjintiao）

What Makes a Good Game Producer?

by Ernst ten Bosch

Note from the author

Although I work for Blizzard Entertainment, the opinions expressed here are my own and not representative of Blizzard’s policy or conduct in any way, shape or form.

PART 1

Intro

A question I often get asked is: what does it take to become a Game Producer? The answer is simple: Nothing. You don’t really need anything to become a Producer. Anyone can become a producer on a video game. Anybody who knows the right people or happens to be in the right place at the right time can become a game producer. There is no formal training you need to have undergone or diploma you need to have in your possession. In applying for a position as a game producer, you will rarely be asked to demonstrate a specific skill or any knowledge solely attributable to game production work. Sure, in some cases it helps to be familiar with established methodologies like SCRUM or for an engineering producer to have studied computer science, but it’s rarely an absolute must. Similarly it helps to be organized and a ‘fast leaner’, but these are qualities most adults already possess in some measure, not to mention the fact that anyone can claim to possess either or both; there is no way to verify such claims.

But all of this is not to say it’s easy to become a game producer, or that the work of a game producer is free from difficulties and challenges. The truth is, there are as many kinds of producers as there are human personalities, each with pros and cons, strengths and weaknesses. The flexibility, for which this broad spectrum of variety allows in executing the job of a game producer, is both a blessing and a curse. In any given situation, a producer can either claim responsibility or distance himself, depending on the circumstances. If a project reaches a successful conclusion, the producer might receive all the credit, or none at all, while the opposite is also true; if a project fails miserably, the producer is either to blame, or completely blameless. The key thing to keep in mind is that a game producer doesn’t actually create anything that goes into the game. So if he didn’t make it, how could he break it?

And yet, there are large differences in the quality of producers and in the ways different producers execute their jobs. Some are the flashy, car-salesmen type, while others are more of the introvert, academic sort. Some like to walk and talk all day, while others do all of their work solely through email. The purpose of this article is not to find out what it takes to become a game producer, but rather, what it means to be a good game producer.

Most of what I am about to write is based off of what I think I ought to do better and what I see in fellow game producers that I hope to one day emulate. So the majority is from my own experience, and some is from talks I’ve had with non-producers about what they like or dislike most about the producer they work most closely with.

For the purpose of this article, I am envisioning a more or less generic game producer (if such a thing exists), neither very senior nor very junior, just mid-level and therefore neither in charge of getting coffee and donuts, nor of deciding what to do with a multi-million dollar budget.

I also don’t want this article to be an instruction manual on how to do game production. Game production is done differently from company to company, several of which don’t even have producers. This is just to say that what I state here my not apply to everyone.

When I talk about my ‘flock’, I mean the specific team of developers that consider me their primary producer. When I talk about the ‘team’, I mean the entire development team, including perhaps severalproducers. When I talk about the product, I mean the single videogame the team is collectively focused on.

I will refer to producers as ‘he’ solely for convenience purposes; there are plenty of female producers, most of which are equally if not more capable than us men in this field.

Generally Speaking

But let’s start at the beginning. To know what makes a ‘good’ producer, one obviously need to know a little bit about what a producer is supposed to do. Many game producers I know have trouble explaining what they do or how they ontribute to the greater scheme of developing video games. Does an Art producer make art? No. Does an Engineering producer manage a team of programmers? No. Do producers decide what goes in the game and what doesn’t? Generally no. Do
producers set and control the development budget. Again, generally no. So what then?

The way I’ve learned to explain it, both to friends and family, is by using one of two metaphors that I feel paint a reasonably accurate picture of a producer’s role, if not a detailed job description.

On one hand, a producer is a shepherd. I don’t mean shepherd i the biblical sense, as some kind of role model or moral guide. No I mean literally a shepherd, like a goat herder; like someone who herds a flock of goats, which is why I sometimes refer to the team I produce for as my “flock”, and shall henceforth do so in this article (although it is still unclear to me if this term of endearment is appreciated or not by said herd).

As with a goat herder and his goats, the true value lies not with the herder himself, but rather with the goats. They are the ones that provide the final product, so they are the ones that, above all, need the proper care and nurturing, shelter and adequate food. The goat herder can eat old, moldy bread crusts for all anyone cares; the goats on the other hand, need fine, green pastures.

Furthermore, the goat herder doesn’t own the goats, and therefore is not the one ultimately responsible for them. He has no final say in what is supposed to happen to the goats, whether they will be skinned for their hide, milked to make cheese or slaughtered for the meat.

Lastly, anyone can become a goat herder; one merely require the constitution to walk around all day and the ownership of a large stick. And if a goat herder quits or dies, it won’t be too difficult to find a new guy to take his place.

The second metaphor I use is that a producer is like a parent. And again, like with the goat herder, I don’t mean in the romantic sense; the “beauty” of motherhood or being a “proud father”. I mean in the “cursed” sense. Let me explain. As a parent, no matter what happens, no matter how tired you are, agitated or outright angry, you always have to be there for your children, care for them and protect them. You have to make the tough, unpopular decisions, and what you want for yourself….well, there is no “yourself” in this Greek tragedy. You have no other option but to unconditionally express love and devotion to your kids.

Now, for a producer and his flock, the feeling may not be genuine and is unlikely to be mutual, but for all intents and purposes, the implementation should certainly feel like it is. Just as with kids, there will be times when you walk in on them and they’ll barely acknowledge your presence. There will be moments when they’re laughing at you behind your back, or when they opely proclaim how uncool or boring you are, how you don’t “get it”. But all you can do, all you must do, is swallow your pride and keep caring for them, whether the feeling is reciprocated or not. That is the roducer/parent curse.

Game Production Tenets

So now that we understand the place a producer occupies in the social microcosm of game development, let us take a look at the goals of a game producer. As I mentioned before, game producers come in all shapes and sizes. On one end of the spectrum you have your Excel junky; the kind of person who loves making reports, graphs and summaries, and who generally prefers to avoid unnecessary interpersonal contact. To him, his flock represents an unfortunate but necessary group of people he knows he has to deal with regularly. On the other end of the spectrum you have your high-school cool kid; the kind of person who strives for popularity and thrives on public acknowledgement and recognition. His flock is a group of friends who have fun and hang out together. And then there’s your tasking robot, whose entire world is in task management, resource allocation and milestones. His flock is just an assembly line that churns out produce at a more or less fixed rate, like a factory.

Armed with this insight, let’s look a little closer at the role a generic game producer is expected to fill. Instead of looking through the lens of established systems of project management, like SCRUM, I’m instead going to talk about the general tenets of a game producer, regardless of the specific methodology his organization expects him to adopt.

Flexibilty and Adaptability

I mentioned the term ‘assembly line’ earlier, but if there’s one thing that game development certainly is not, it’s an assembly line. With so many moving pieces in an industry that is still in its infancy, things rarely happen as you’d hope and every two steps forward are followed by one step back. This impacts some disciplines more than others, each dealing with it in their own way. For game producers, the way to deal with it is to expect it to happen; know that things are going to change along the way and be prepared for them as best you can. Consider Vegetius: “Igitur qui desiderat pacem, praeparet bellum” (He who desires peace, should prepare for war). A producer needs to adapt so others don’t.

Status awareness and reporting

I feel that at the very least, a game producer should be aware of what’s going on with the team and the product, and make sure that his flock, or at least the Leads, have this information to the degree that it is beneficial. He should not only know what the priorities for the immediate future are, but also what is supposed to happen after that. Any engineer, designer or artist ought to be able to ask any producer about the general direction the team is taking, the important issues of the day and the team’s primary goals. Of course there are going to be things that a producer may not know, usually because it concerns someone else’s discipline. However, those things should generally be limited to the details, not the big picture. Good communication from the producers to the team and from one producer to the next, is key.

Reaching deadlines

A large chunk of the work of any game producer anywhere, deals with reaching deadlines. This is the realm of dates and milestones; moments of time in the future, at which point something starts, finishes or undergoes an impactful change of some sort. First and foremost, a producer needs to be aware of what these moments are; how much time is left, what needs to be done by that time and what is at stake if the deadline is not reached. The producer also needs to have a rudimentary idea of the main challenges his flock faces in achieving the goals, at least enough that he can describe it to third parties and answer basic questions. He may not need to do the work, but he is nonetheless a representative of his flock.

Greasing the wheels

Game producer is also a bridge builder, accommodator and facilitator. A common thing that happens is that a producer is confronted with a problem that he himself cannot fix. It then becomes his job to find the person who can fix the problem. This may require him to attend meetings, email his contacts or literally get out of his chair and walk around in person until he finds his answer.

By doing this over and over again, in time, he will realize he has accumulated a sizeable network of key contacts that he can call upon to help him out. And by extension, this network becomes the network of contacts for his entire flock. And it works both ways; for his team, a producer is the connection to the outside world and for the outside world, the producer is the connection to the team.

An engineer shouldn’t have to worry about getting to know everyone in IT or in the QA department; that’s what he has his producer for. And vice versa, not every member of a QA department needs to know every single designer, engineer or artist on a development team; the only thing that person needs to know is who the producers are.

Jack-of-all-trades

I started this article by saying that there is not just one single thing that a producer needs to be able to do. That is because he should be able to be burdened with a myriad of things. A producer is a jack-of-all-trades and no task should be outside his scope or potential responsibility, as long as it benefits either his flock, the greater team at large or the final product. As I said before, while others are expected to focus solely on their tasks within their discipline, the producer should manage all else in so far as he is able to, whether it’s working on scheduling spreadsheets, booking meeting rooms,
writing meeting notes, entering tasks or makings sure the videoconferencing system gets fixed in the conference room.

Ambassador

Which brings me to the next tenet; a producer is an ambassador, both for his flock, the team and the product as a whole. Just like an actual ambassador, who knows the history of his country, the current state of affairs, the things to be proud of, the things to be ashamed of, the things to fight hard for and the things to back down from, so too does a game producer need to be aware of these things with regards to his team. Knowing these things will help him make good
judgment calls and establish good position of negotiation when the time comes for calls to be made, pros and cons to be weighed and plans to be lade. And it works both ways. Like an ambassador, he is expected to go out into the world, gather what information and insight he can, and report back to the home front. That way his flock can be kept up to date on the goings-on outside of their own comfort zone.

But above all, like an ambassador, he needs to display an unflinching devotion to the general wellbeing of his flock. A producer needs to be a champion for his team, and within it, he needs to be a champion for his discipline. While the people doing the actual work need to worry about completing the tasks; write code, fix bugs, record sound, translate text, design levels and create art, the producer is the beacon of stability and consistency, ever keeping the greater
good at the forefront of his thoughts while putting his own, personal interests aside.

Lightning Rod

Another important and sometimes overlooked role of the producer is to be the insulator. Like a lightning rod on top of a tall building, a producer is there to run interference and, in doing so, shield his flock from undesirable outside forces. A team of talented game developers is constantly besieged by third parties that require its services, both within and outside of the development team. An artist might be called upon to work on a one-off item for a special marketing promo rather than design more armor sets for the next patch; an engineer may be asked to help fix a bug on the website payment system rather than work on the next big in-game feature. And of course there is the ever-present threat, born of laziness, of teams passing their bugs off to someone else rather than deal with it themselves. If the producer effectively executes his role as conduit, his flock will in turn be better able to focus on their core job, which is generally what they are best at and in which they find most enjoyment.

In Part 1 of this article, I talked about the role of a game producer within game development, and the main principals by which he should allow himself to be guided. In this second and final part of my article, I will focus more on what a good game producer should do in certain situations, and what he ought not to do.

Specific Situations and What a Good Producer Would Do

So now that we’ve established what a game producer generally does and what his role is within the development team, let us delve a little deeper into a few specific and common situations in which a producer will find himself, and subsequently determine how a *good* producer would deal with those situations.

Tasking

Nothing says ‘Project Management’ like tasking, and every game producer I know does a lot of it. The job of tasking is really nothing more than what the name would have you believe; assigning tasks. Whether it’s through email, a board with Post It notes or some fancy, customized tool, it’s all essentially the same; technically simple and generally quite mundane. But even with this simple, monotonous work that’s hard to screw up, there is one way to do it, and then there’s the good way to do it.

A producer can easily just get all the relevant parties together in a room, or in individual meetings, and have them dictate to him what the tasks ought to be, how long they’ll take etc. Then if something is unclear about the task, he can simply refer to the original dictator; all the game producer needs to do is to regularly check on the status of the tasks and jab the taskee in the ribs for an update.

But there are weaknesses with this approach. A task, in the context of game development, is not just a method of assigning a job to an engineer, artist or designer. It is also a way to see all the pieces of the puzzle, not just for the producers, but for everyone involved in the project. The combination of all the tasks should ideally function as a record of the work that has been done, has yet to be done and the problems that were encountered and fixed along the way or that have resulted in further tasks. Proper bookkeeping through tasking will result in clarity and lessons learned for the future; a playbook of sorts. So it’s important that the tasks contain the information that will yield this result. Is the task understandable to someone not working on it? Do the start and due dates align and make sense in the general schedule? Are finished tasks marked ‘Complete’, or are we passed the due date without a comment or update? Will future-us be able to read through the task and the comments and know what happened?

Of course, applying this level of detail and diligence to the thousands of tasks a random producer might enter for any given project, will balloon the workload to such a level, that he would have little time for anything else, but I think the point is still valid. A producer should ask himself: Do I understand this task? Is it reasonable to expect the desired outcome? Could I describe it in non-technical terms if someone asked about it? If he can honestly answer yes to those questions, he’s doing a great job.

Scheduling

There must be hundreds of ways of making a schedule, depending on its purpose. Is it to show the engineers, artists and designers how much time they have left to complete their work? Is it for marketing, PR, Community and the Executive Management to show when the work will be done? Or is it to show which dates all of us absolutely must reach in order to make the Christmas shopping season? It could be any or all of these. But whichever one it is, there are two simple basic rules I’ve learned to adopt over the years in how I make my schedules: 1. Don’t let the tool determine the format of the schedule. I simply use Excel. 2. You are not making the schedule for yourself; your client is the recipient. If I wanted to make a schedule for my own private use, it would be filled to the brim with details, abbreviations, random notes and personal comments. It would be illegible to almost anyone else.

But these are just basic tips that I would recommend anyone adopt for any kind of scheduling in general. For a game producer, it would be all too easy to simply take down the delivery dates handed to him from the department leads, put them in a pretty table or in a nice diagram, and send it to whomever might complain that they don’t know what the schedule is.

A good producer however, understands the schedule. He knows what the milestones mean, why they are on that particular date and what will happen when they aren’t reached. He also knows which forces have played a part in determining that a date for a milestone is reachable; who’s working on what, who’s on vacation, who’s out sick and which teams are understaffed, on track or delayed.

In knowing these things, he will be able to anticipate questions and hurdles and subsequently be able to answer those questions and overcome those hurdles. If a game producer is asked why a date in the schedule can’t be sooner, he needs to have a useful answer ready, or at least commit to procuring one, and not resort to deferring to someone else. If a producer doesn’t understand something as basic as his own schedule, what is he there for?

Meetings

I think it’s safe to say that not many people genuinely enjoy meetings, and as a result, few people in charge of leading or preparing for a meeting will do
so with the vigor and enthusiasm necessary to get the most out of it.

A game producer, like any meeting organizer, ought to make sure the basic criteria are met for organizing and running a meeting well. Things like making sure there is an agenda, that someone is taking notes, that it starts on time and doesn’t last too long, that the right people are present and that any action items are followed-up on. This may sound easy, but it’s practically impossible to do consistently. At least for me.

In addition to these standard best practices for meetings anywhere in any business, there is one thing that is, if not unique, then perhaps more prevalent in the work of a game producer. Unlike most meetings I was in before I became a game producer, it is now common for me to find myself in a meeting where we talk about work that I am not personally expected to do. This means I don’t necessarily need to understand everything, I just need to know that it was said. It
may be because it was too technical or because it concerned managerial matters, both of which are rarely within the realm of a game producer’s responsibility. Or, more often than not, the meeting might be about the job of an entirely different team or department, in which case I might have no idea what anyone is talking about!

In those situations, a game producer is obligated to make additional effort outside of the meeting itself. If he wants to be able to contribute, he needs to not only know what was said, but understand what was said as well. It’s all too easy to simply take notes, enter tasks and call it a day, and an average producer could get away with that ad infinitum. But a really good game producer makes sure he understands the material, how the conclusions were reached and why the decisions were made. In doing so, he adds a new dimension to his work, and instead of merely being an executor; an enterer of tasks, and sender of emails, a setter-upper of meetings; he has become an architect; an authority, a project owner and a real developer.

Communication

In job descriptions for game producers you’ll invariably see mention of the necessity to be a “good communicator”. I’ve always found this to be somewhat obtuse. Anyone can claim to be a good communicator and, as far as I know, there’s no standardized methodology of determining someone’s skill at communicating.

This is not to say that it’s unimportant. Being people-shy won’t do if you want to be a game producer. Similarly, if you’re ill-at-ease in large groups or at running a meeting, you might also want to consider another career. At the very least, the need to talk to people shouldn’t be a limiting factor or a hurdle that needs to be overcome. If it is, then communication is not your strong suit.

So what are the key elements that a producer needs to keep in mind when he’s working on his “communication”?

Everyone is unique. A good producer knows his flock, and he knows how best to talk to its members. Some people like meetings, others don’t. Some people want to sit behind their desk all day and do all their communicating through email and chat. Some like it when you drop by their desk for a chat, and some people detest it when you do that. If a producer knows how best to talk to his colleagues, he will be in a far better position to share information, ask questions or say “no” when it’s needed. Realizing that there is no single, catch-all method for communicating is the first step in achieving the best method for communicating.

Be reachable. The single most important thing is to be reachable. If someone needs a producer, they should be able to find that producer, and it’s the producer’s responsibility to make sure this can happen. In this day-and-age, that shouldn’t be too difficult, what with email, cell phones, texting and chat, or even FaceBook, FaceTime, WhatsApp and Skype. It has never been easier for someone to make sure he is reachable. The producer just needs to make sure his contact information is available on whatever centralized contact list the company uses, normally in Outlook or some internal website or wiki. In additional to that bare minimum, a good producer will make sure that he’s logged in to Messenger whenever he’s at his desk, that his cell phone is switched on when he’s not, and that he checks his emails from time to time at home or on the move. That should give him 90% coverage. Putting that contact information in email signatures and/or on office whiteboards should take care of the remaining 10%, which can be useful when people aren’t at their desk or near a computer.

Be visible. As I mentioned at the beginning of the article, many people, including other members of the development team, have no idea what producers do. As a result, they don’t know if and how producers can contribute to the game development process. For this reason, it is important for a game producer to make it obvious what he is working on. By showing what he is doing, he simultaneously shows what he can help with or be used for. Obliging his colleagues in such
a way, will, in turn, lead to more work and subsequently, a greater contribution. A game producer who can’t be of use to his team or his flock, is a useless producer. Any producer can simply sit at his desk, send emails and enter tasks knowing he is doing what his boss wants him to do. But a good producer knows how to communicate his usefulness outwardly. In meetings he’s prepared, pays attention and voices his opinion. He asks questions that others might be too shy to ask. He shows that he knows what’s going on by sending out reports and schedules. He shows that he knows what his flock is working on by answering detailed questions and making adjustments to the schedule so it matches what is achievable.

These actions may seem artificial or somehow disingenuous, but if a producer wants to be involved in the decision making, treated as an equal and be approachable, it needs to be apparent to all that he is working just as hard and suffering just as much as the next guy, even if he doesn’t know how to animate a 3D model, record sound or translate quest text.

Create efficiency. Ultimately, the goal of good communication is to attain a level of high efficiency in the execution of the work the team does. A producer plays a large part in this. If a producer does a good job in tasking out the work, it’s easier for the engineer, artist or designer to get started on it right away, without needing to ask for clarification or make corrections. Then further down the line, again, if the task was entered properly, it will provide a good record of how it was executed, how much time was and has yet to be spent on it, which problems were encountered along the way and what was done to overcome those problems. This way, managers or other producers can quickly find out how much progress is being made and how it will impact the bottom line. At the same time, designers, artists, engineers and testers might learn something from the execution and need not waste time reinventing the wheel, should they run into a similar situation. By doing a good and thorough job at tasking out the work and doing proper follow-up on that task, a good producer is not merely communicating with the person assigned to fulfilling the task, but also with anyone else who might be reading it, perhaps at another time and place.

This also pertains to scheduling. With a great schedule, and producer can immediately communicate to the reader where we are in the process of reaching our goals and what the important milestones are. If the reader has to spend time understating the graph, repeatedly looking at the legend and not knowing what the numbers mean, he wastes time, gets frustrated and will, overtime, stop looking at the schedule and inevitably stop caring about he deadlines.

Communication in meetings is perhaps a more subtle art than it is with tasking or scheduling. Some teams prefer it if the producer simply does the administration of a meeting: setting it up making sure the video projector is working, sending out an agenda and making sure the notes are written and sent out. In some cases though, the producer is expected to be more involved; reign in the wild cards, make sure the conversation is kept on track and that the time limit isn’t exceeded. It is generally agreed that meetings shouldn’t take forever and devolve into useless shoptalk or chitchat, and generally a
producer is in a good position to be the moderator. Whichever system is preferred by the team, the producer in question ought to know what is best for the participants and make sure those priorities are executed upon. A good producer is flexible to the varying nature of different meetings, but if needed, is also able to steer it in whatever direction is most productive.What NOT to do as a Producer

We’ve talked about the role of the game producer within the development team and how a good producer should go about achieving his goals. Now I’d like to drive it home by looking at it from the opposite angle. Wht are the main pitfalls a producer should avoid. What should a good game producer NOT do?

Don’t be afraid to ask questions

It is not expected of a game producer that he has deep technical insight or is aware of the details of every task and bug. In fact, if he spends too much time on those things, he is likely wasting time, because in any event, there will be people out there more knowledgeable about such things and in a better position to work on them than he. By looking at and understanding the workload from a little bit of a distance will give the producer some perspective and allow him to see everything in the context of the bigger picture, and that is exactly what he is there for. Additionally, if a producer is able to understand an issue and able to describe it in general, non-technical terms, sometimes referred to as “producer speak”, it will be easier for him to pass on that information to other parties, like other producers or support teams. The key to making this work, is to ask questions. If something doesn’t make sense to a producer, he needs to have it explained to him, even if it makes him look stupid or incompetent, or if he feels that he might be burdening someone. It’s better to spend some time asking questions and getting explanations, then to move forward, enter tasks and share information in subsequent meetings when it is not entirely clear what the challenges are. Better to waste one person’s time and suffer the shame of potentially looking silly, than to have the whole team suffer. A game producer should learn to swallow his pride and stick his neck out when needed.

Don’t create unnecessary work.

The first step in properly prioritizing work, is to determine whether the work even needs to be done at all. Any random person on any random day may have several “wouldn’t it be cool if we did this!” ideas. Whereas for most people those thoughts remain safely locked away in the realm of inaction, people in positions of power might have the means of seeing them come to fruition. Especially on occasions where opinions can be voiced with an eager audience, like in a meeting, an idea might sprout into a concrete task. This is where a producer needs to be wary. Just because one person thinks doing something would be cool, doesn’t mean it should be done, particularly when they themselves wouldn’t be the ones doing the ‘doing’. A producer needs to be aware that decisions translate to work, and too much work translates to delays, and delays are kryptonite to a producer (or at least it should be). An engineer, artist, translator or designer, even if senior or lead, may not have the same overview of a project that a producer should have, and therefore might not realize the overall impact. So this is were a producer can be very useful. If a meeting can be cancelled, a bug can be punted or a task can be postponed to a later date or can be refrained from needing to be done at all, more time and effort will be made on the work that does need to be done.

Don’t make people not want to work with you

Strictly speaking, it’s not critical for a game developer, in whatever discipline, to work closely with a game producer. A regular character artist or server engineer can simply come in to work in th morning, look at what’s on his task list and start hammering away at his job. Whether his tasks were entered by a producer or his lead, really doesn’t matter. If he needs to work harder or stay late, his direct manager will tell him. If he has questions about his salary, career path or vacation days, he can talk to his manager. He could easily get by without ever having to deal with a game producer.

This is why, above all else, it is important that the game producer makes himself useful and approachable. If he can make sure people don’t outright ignore him, he has taken the first step in becoming helpful. I firmly believe that a dedicated team of producers will greatly improve the productivity of a development team, but this can only work if people understand the benefit of having a game producer, desire that benefit and actively seek it out.

Don’t be the one who holds things up

Delays in reaching deadlines can originate from almost any place, be compounded by a plethora of additional variables and have a myriad of dire consequences for any number of interdependencies. This is to be expected and prepared for. Power outages, sick leaves, dead pets and earthquakes happen and even the most veteran of game developers will misjudge how long a particular task may take to complete. All of this is acceptable. What is not acceptable is consistent
delay on the part of the producer. If a plan can’t be made because the meeting didn’t take place, it’s the producer who failed. If a server engineer is waiting for a reply from a web designer, the producer needs to make sure he gets it. If players have encountered a critical bug, it’s the producer who should find the guy to fix it. And in truth, it is very easy for a producer to avoid being the bottleneck, because usually all he needs to do is send an email or pick up the phone. But simple as this may sound, it just serves to strengthen the reason why failure on this front cannot be tolerated.

Don’t forget to follow-up

It is all too easy for anyone to send an email and simply assume it was received, read and pondered by the recipient. All the more so in this day and age with instant messaging, Facebook and ‘commenting’, in which it is the common practice to simply post a remark and forget about it. This is a fire-and- forget culture in which there is little accountability or follow-through. But in the day-to-day work of a game producer, that’s not good enough. By and large, emails are sent, phone calls are placed and meetings are held for a reason, and those reasons require resolutions. And while engineers need to go back to writing code, artists need to go back to creating models and designers need to go back to designing levels, producers don’t have that luxury and can’t allow themselves to get deviated or distracted for too long. Following-up on an email, action items from a meeting or questions from a developer, is part of what justifies the producer’s position to begin with. Failing in this is failing in a core responsibility of production work.

Conclusion

It’s very hard to determine whether a game producer is doing a good job or not. As I said at the beginning, if a product is successful, the producer can claim credit. He can say “Yes, I was there, I helped make it happen”. And at the same time, if a product fails, it’s easy for a producer to absolve himself of any blame. He can simply say “Hey, I’m not a designer, or an engineer, or an artist. I didn’t break anything”. A game producer can get away with being crappy if his team is good.

But the fact is, it’s a poor craftsman who blames his tools, and for a game producer, his flock represents his toolkit. A producer should always own the deliverables of his flock. He may not be the cause of a failure, but that doesn’t exempt him of responsibility.

At the beginning of this article I mentioned that an art producer doesn’t make the art, which is true. However, a good art producer knows what it takes to make the art. He knows how much time his team will need to reach the deadlines, what obstructions there are, if any, and what the work will subsequently be used for. He understands the life cycle of the product his flock delivers and its place in the general development of the game. Similarly, I also stated that an engineering producer doesn’t manage a team of engineers. Again, true, but a good engineering producer knows how to deal with his engineers. He knows how the engineers prefer to work; who prefers to be alone in a dark corner writing code all day, who needs extra attention on their task assignments and who wants to be invited to every meeting. Furthermore, it’s true that producers generally don’t decide what goes in the game, but if they’re good, they know the game well enough to be in a position to make useful suggestions, propose alternatives and shoot down outright ridiculous feature proposals. Producers often have a broader view than the individual, core developers, and with this broader view comes a useful perspective. Lastly, and perhaps most importantly, although it’s also true that most producers have little to no influence over the team’s budget, they need to always keep it in the back of their minds. No company in the world can afford to throw away money, whereas the opposite extreme should also be kept in check: no company can afford to have their employees stymie their productivity by fretting incessantly about potential costs, especially in a business driven by creativity. This is why being efficient, trying to hit the deadlines and making sure problems get addressed as soon as possible, are what should be foremost in the mind of a good game producer, if in no one else’s mind.

In short, a good game producer delivers a customized service, tailor-made to the people he is working with, the product he is working on and the urgency of the deadlines. To succeed in this he needs to be flexible; always be able to adapt to new circumstances and know that the unforeseen will happen. And when it does, to stay calm and rational even when others aren’t.

At the same time, he needs to be vigorous and exude strong principals. He needs to do what he said he would do and he needs to follow-up on the work that has been set in motion. He needs to nudge slackers, jab stallers in the ribs and remind the heck out of everyone. He may not be liked for it and he may not get much recognition, but that is part of the job, and a good game producer needs to set his ego aside in favor of the greater good. That is the only way he’ll be able to claim his rightful place in the pantheon of true game developers.