The Game Producer's Handbook（游戏制作人手册）-第8章 ...

加斐

这一章会讨论一些成功制作人在过去管理项目过程中用到的常见工具和技术。虽然本章是无法包罗万丈的，更多只是一些能让你的日常事务更正式、更专注且更有条理的技术和工具。其窍门在于把这里列出的技术和工具都看一遍，然后挑选出合适你团队和特殊情形的方案。最优秀的制作人会喜于各种正式的规范和流程，确保不会低估任何一个良好的流程。但切记要注意的是也别滥用这些流程。要把创新融合到一个结构化的流程里是很难的。
制作视频游戏用到的流程

这部分会详细列出一些流程中的具体细节，制作人应该用这些流程去跟踪项目过程中发生的各种情况，以此确保在团队、管理层和发行商之间有着合理有效的沟通。
每日增量报告

每日增量报告和报告体系是我在尝试当一名成功制作人的过程中发现的第一个且最有价值的一个流程。接下来这段会让你简单看看它是怎么运作的。在这个系统里，每个团队成员在每一天都要在结束当天时提交一份简短的清单。假如他当天什么事也没有完成，那他得说清楚当天做了些什么，但每个成员每天至少努力完成一项任务是很重要的。
团队成员应该把他们的任务拆分成多个可管理的部分去完成它们。尽管不一定总能这样做到，但这应该作为努力的目标。每日增量流程用于在第二天向团队沟通回反馈。这个流程会以以下的方式运作：

• 提醒发起者的邮件里到了每个工作日的下午5点都会自动发出一封题为“每日增量：[日期]”的提醒邮件。
  
• 每个团队成员只要回复提醒发起者的这封提醒邮件，以列表的格式去列出当天完成的内容，这大概要花费90秒～2分钟。
  
• 第二天，制作人或者助理制作人要做的第一件事就是把回复的所有邮件都读一遍。这大概会花费5～9分钟，主要取决于团队里有多少人。假如团队里有人缺席或者病了，制作人或者助理制作人也能在报告中注意到。
  
• 随后，无论谁来负责发布这份每日增量报告，他都需要把报告划分成三类：策划、美术和程序。接下来他要把每个团队成员的每一条每日增量拷贝到相应的部门分类里。例如美术人员的增量归到美术分类中。
  
• 发出该份每日增量报告。
  
• 整份发布的报告看起来会像图8.1所示的那样。
  

每日增量报告的好处
每日增量流程是跟踪大型团队开发过程的一种准确、简单和有效的方式。尽管在你最初尝试去在开发过程中引入一项新流程会遇到不少团队成员的抵抗，但当整个团队意识并经历到它的好处后，这些抵抗最终都会不击而退。下面列出了每日增量流程具有的一些好处。

• 只需要很低的时间开销。
  
• 对整个项目跨度中发生的事情都提供了一份每日记录。
  
• 各部门能很容易看到。
  
• 能很容易关联回计划里（你可以要求各项任务都遵循一样的命名体系，也就是每个团队成员所报告的完成工作必须和计划上的任务名一致）。
  
• 能确保大型团队彼此之间以有效的方式交流。
  
• 能提供一种有效的方式去回顾各种决策和资源分配，以此来衡量这些决策对目标的有效程度。
  

源码/版本控制报告

你可以考虑很多版本控制工具，但看起来对游戏开发者最有利的工具是Perforce。大部分的版本控制软件都能产生清单，报告出游戏每天编译所需的每个文件的状态。大部分版本控制软件都能提供这类的功能。

备注
当使用版本控制软件时，花时间去学习和理解其功能的作用，看看如何能合理地利用它。这是一个产品的命脉。曾经有一次我在边谈电话边迁出一个文件，突然不小心迁出了整个数据库，结果它不断迁出每一个文件，以至于把别人的文件也迁出了。这最终导致了工作混乱，让我很尴尬的，尤其是当一名程序员走来问我为什么迁出了他的代码时。

利用Wiki

如果你从来没听说过Wiki，那我很庆幸你现在读到此处。我以前也从来没听说过，直到有人向我推荐http://Gamasutra.com上一篇Jamie Fristrom的文章“Manager in a Strange Land: Collaborating with Wiki”为止。（译者注：该文章在译者博客里也翻译过了，名为《Manager in a Strange Land系列：用上你的Wiki》：http://blog.sina.com.cn/s/blog_48fbe4a101007rlr.html）
Wiki是一个协作式的文档和头脑风暴工具。但根据它用法上的不同，它也是管理设计文档的利器。假如你尝试过设立一个内部网站去管理和记录整个设计过程并因为工作量太大而失败了，那wiki就是一种很好的方案。

备注
Wiki可以在网上免费下载到（http://openwiki.com）。当你把它安装到服务器后，你需要对它进行更新（它会自动告诉你需要从微软官网上下载些什么才能运行）。整个过程是像安装QuickTime那么简单的。

Wiki可以像这样用：要增加或修改Wiki上的内容，你只需要点击两下就ok了。文档本身都能不断更新，像创作设计文档和技术设计文档都很适合用Wiki管理。Wiki支持的复杂性高到像文档那种高度，低到像程序任务清单上每项任务一两句描述那么简单。这能让程序员在一个功能实现并测试后对该项任务作出详细注释。
Wiki上还可以放上FAQ部分，这些FAQ可以涵盖版本控制、所有类型美术资源的迁入和测试流程，以及游戏当前版本的测试管线描述和问题解决方法，放入这些内容都是对团队很有用的。
但也有一个小点是需要关注的，那就是团队里的某个人可能会修改里面一些重要的内容。但幸运的是Wiki有着一个版本控制功能，它能对所有之前的修订、编辑和修改都做下记录，所以制作人能看到谁对此改动了，以及该改动是在何时发生的。
使用Wiki的其中一个缺点在于它不能很好地打印。虽然整份文档都是可读的，但在打印机上却无法把原始的格式打印出来。你要花点时间去在Microsoft Word里把它转换和重新编排格式，但最终也不是不可能做到的事，只是麻烦而已。
你还能通过邮件把Wiki上设计文档更新过的部分的链接发过去。尽管很少人会阅读整份文档，但在你需要就某项特定功能开会讨论，且与会的每个人都要对设计文档中最近更新的部分了解时，这是个不错的办法。
最后，Wiki能很容易更新文档，能在团队内部协作，且能跟踪所有的改动和更新，但这并不意味着团队会吃这套。你还是必须去感染他们，此时Wiki就会像病毒那样传播出去了。下图8.2展示了wiki的样例。



图8.2 Wiki工具

团队会议

关于团队会议首先要记住的一点是它的成本很高，因此要确保会议是有价值的。每个团队成员只要闲站15分钟就会耗费将近15美金。因此你让团队里的30号人在团队会议里站上30分钟就会耗掉将近900美金。你不觉得把这些钱投入到别的地方更好吗？所以每当你很想让整个团队参与一次会议时都要切记这点。
虽然团队会议是成本很高的，但假如没有定期展开，其代价也是很高昂的。其效率的关键在于为会议设立一个日程和格式。以我的经验来看，团队至少一个月一次是最好的。在团队会议过程中，你应该把重点放在游戏开发进展中的积极因素，展现出你为各种挑战的达成提前准备好规划，除此之外，还得确保团队从每次团队会议中得到正面的消息。
主管会议

当在开发商中工作时，其中一个最有价值的流程是每周主管会议。在这个会议上，主程、制作人、助理制作人、主美、美术总监和主策划会讨论接下来一周的目标，讨论接下来一个月的里程碑，以及当前面临的各种挑战。虽然没有一个制作人能同时给出所有这些领域的挑战的解决方案，但在每一次的主管会议里，制作人的职责在于促成各种问题是公正讨论的，而且能得到清晰的解决方案。以下清单列出了主管会议的格式：

• 回顾各项完成事项
  
• 列出各种问题
  
• 产生各种选项
  
• 提出解决方案
  
• 建立一致意见
  
• 做出决定
  
• 把结果传达给该项决策会影响到的任何人
  
• 对该项决策以及行动的结果备案留底
  

确保会议上有人在做记录，且在会议结束后尽快地发布出来。
高管/筹划指导委员会议

有一种会议是不那么让人开心但却很重要的，那就是和高管或者是筹划指导委员会的会议了。在这种会议上，制作人通常要主持整场展示。高管会评审和评估团队的进度，其目标是了解他们对项目的投入产生了哪些结果了。

备注
假如你在一个大型机构里，那为产品安排一次筹划指导委员会议是很有价值的。让来自其他项目的主管、市场部门的主管，以及其他的高级人员一起来参与，他们能对产品开发的方向提供一定的价值和客观看法。

对高管会议来说，最好是由制作人来控制整个日程，提早公布这份日程，并提出各种需要高管决定的关键性问题（例如法务问题和战略方向），同时提出各种建议和事实来支撑你的立场。在会议中包含回答问题、展示新特性，以及展示游戏整体进度的时间。你要知道这些关键性的反馈是很有价值的，但也不是所有反馈都能在这次会议上得到的。对一个制作人来说，其才能表现在理解这点，并决定如何从高管会议中得到最有价值的反馈。除此之外，务必为这次会议做好准备。你要展现出你对开发过程的控制，赢得高管团队持续的信心。
风险管理工具

由于制作人的主要职责是管理风险，所以一套综合可靠的风险管理工具对制作人来说是很重要的。接下来这部分会谈谈成功的风险管理中用到的一些工具。
风险管理表
当管理一个项目的风险时，首先第一步是判别出风险所在。最好的开始方法是在一张清单里列出每一个可能的风险，然后与项目的主管一起头脑风暴，判别出所有真正的风险。你需要把项目里的每一块都单独列出来，包括美术、程序、声音、设计、市场和产品。别急着去量化或者细化每一条风险，先侧重于把所有的风险都列出来分好类先。最后看起来像图8.3那样。
而后第二步是细化和量化风险清单中的每一项风险，定出风险的概率和发生后的影响程度。概率也就是该风险发生的几率，而影响程度是指每项风险在发生时对项目带来的潜在影响。你可以用0～100%的刻度范围来标识出这两个估值。
接下来你需要根据它们的相对值来对这个风险矩阵排序。最高的风险排在最上面。然后把风险分派到不同人头上，让不同人负责管理特定的风险。你要确保把其中不少风险指派到自己头上，因为风险管理本身就是你的主要职责，但也有不少风险是更适合放在主管身上的，因为他们都在特定领域上更专业，例如是技术上的风险。



图8.3 风险管理表

在图8.3里，你能看到制作人的职责是让团队里有着各种最合适的才能的人，而这也恰恰是项目里最高的风险。所以当矩阵里的这些风险都指派出去后，下一步是为每个风险负责人建立一套专门的应对方法。当这些应对方法都定下来后，把它写到风险管理计划里。不过切记，把以上内容写下来并定下计划不等于这些风险就去除或者解决了。下面我们会继续看看制作人在一个项目里还能做些什么去管理风险。

备注
这本书的配套网站（http://www.courseptr.com/downloads）上列出了风险管理计划、评估矩阵，以及相关流程的样例。

其他风险管理手段
风险从来都是无声无息地潜入并弥漫到整个开发项目里的，即使是最有经验和最资深的人员也不可避免。但作为制作人，你应该掌握一些手段去防止你的项目遭受到这些幽魂的侵扰，让它们不会对技术、创意，以及一些创作成分很高的未知因素进行威胁和破坏。
其中最弱的抵抗是什么都不做，让团队陷入加班和计划延期的苦难里。另一种方法是做出一份虚假的计划，尽可能在里程碑交付日期前垫入很多的缓冲时间。但由于越来越多的发行商在新项目的预制作阶段就要求严格审查了，所以身为制作人的你应该在那时候就考虑这些风险，通过你的风险评估报告去判别出开发计划中存在的风险。
啊？那你的意思是说制作人应该当着发行商和高管的面展示和指出这些风险吗？！对，答案正是这样！即使你花尽心思去确保项目里有合适的团队，确保所有成员都足以让项目达到预期，但大多数有经验的发行商还是会从他们经历的项目里看出一大堆风险的。虽然这些风险可能都无法在计划里清楚可见，但它们的确影响你完成项目的整个开发过程。你需要列出把这些风险最小化的负责人、解决方式（例如技术授权或者新的工具），以及解决时间（最高的风险总是要最先计划）。这样做还能让你和发行商的制作人之间建立良好的关系。换位思考，假如你是发行商中有经验的第三方制作人，那你可能早已发现这些风险了，因为可能在你开发过的其他游戏里早就碰到过这些问题。通过考虑这些风险，你能让项目多一重保险，让它更有可能如期发布。
评估风险是一个很棘手的过程。正如前面提过的，要做到这点是有方法的。但你还需要考虑很多事情。风险不等同于任务，因此别把制作更多功能强大的工具视作是一项风险。像支持一个新的渲染引擎所需要的工作也不是风险。风险应该是游戏玩法的概念本身是否足够独特，是否能让它在市场上产生差异化。外部依赖也是一种风险，尤其是你不知道该如何才能减少该项风险时。假如你考虑用第三方软件，例如DivX，你可能在测试之前完全不知道它是否能兼容你的渲染引擎。风险还包括一块新内容的创作，例如录制交响乐团来作为游戏音乐，这可能是你的团队之前从没做过的。
你应该考虑的风险是一些很复杂或者实验性的功能，而不是某一天会有陨石突然砸到你工作的办公大楼的风险。考虑那些你认为合情合理的风险。例如团队里可能只有一两个人是之前做过你现在的游戏类型的，那可能风险是团队对这个类型或者平台是没经验的。
设法让风险最小化
你能通过很多方法来把一个视频游戏开发项目中的风险最小化。这是在判别出风险后要采取的下一步。有些风险是无法减轻的，此时计划必须考虑到这些风险的存在。但身为制作人，你可以去把项目里其余的风险减到最小，例如：

• 在你没有一份相对完整的设计前别开始游戏的开发。你需要一份能产生效果的设计，它不需要包括所有的细节，但必须有着开发之始所需的用例情景。
  
• 去除所有的未知因素。花时间去研究和确定你所不清楚的因素。利用预制作阶段去掌控住整个项目，去除所有不可知的因子。
  
• 建立一份糟糕情况发生时的后备计划。一直保持手头上有一份随时可行的B计划草案。
  
• 花时间去建立一个原型来核实项目的概念。你的团队可能会为这个小项目耗费一点时间，但这总比要在团队里加30号人且对游戏绝大部分进行重设计来得成本低廉。
  
• 把最出色的人先放到最高风险的项上。先把这些高风险的项清掉，而后剩下的也会迎刃而解。
  
• 采用第三方工具或者其他需要团队以外的专家的解决方案。
  
• 在计划里加入一定的灵活性，让你能在情况发生改变时重调优先级。你要知道情况是一直在改变的。
  
• 在需要的时候进行重设计。尽早且经常地砍掉部分功能。
  

一种降低风险的开发方法
现在我们来看看一种开发方法，它名字叫前载开发模型（Front Loaded Development Model）。
这套模型的目标和标准模型一样：目标是做出商业上成功的一流游戏。前载开发模型会在完整开发前进行原型开发和不断调整，以此来确保得到一个经过验证的游戏概念。它会让一个小型开发团队去不断回顾开发出来的东西，确定这个原型的乐趣性，然后再进行调整和修改游戏设计，以此减少体验中的不足，同时强化已验证的概念中的强项。不过不是所有的概念都能原型化后再经测试进入到游戏里的。而且最好不要把一些完全没有风险的开发项拿去原型化，例如游戏里的动画播放机制。这对大部分游戏开发者已经是一个标准特性了，完全不会对开发过程带来风险，所以别在早期把时间浪费在一些已证明能实现的内容上。要把你的精力放在那些还没确定和改良的概念上。
标准开发模型是很常用的。当游戏的概念被验证且原型做出来后，游戏就可以进入完整开发了。但随着游戏在开发过程中不断演进，搭在游戏上的成本也随着风险的增加同时增加。当一个项目已经搭了显著的资源投入后，要撤销项目是很难的，这尤其表现在开发后期，因为此时会浪费掉数百万美金和几年的时间了。
然而相比于前载游戏开发模型，你就很清楚为什么一些最成功的游戏开发商都用前载开发模型的方法了，例如顽皮狗、暴雪、任天堂和Insomiac。通过采用这套模型，把多个项目立项并培育在预制作阶段，对各种概念和游戏玩法不断测试和改良，迭代多次直到出现一个大家都认同的原型后才展开开发，如此开发商和发行商能一起携手减少项目风险和游戏开发项目的投资组合。到了真正展开开发时，各种创意和技术上的风险都减少到一定程度了，剩下的不过是真正的制作阶段了。但风险是随着成本的增加而减少的。

备注
Mark Cerny曾经谈到过这种方法，说到为什么它对发行商是很重要的，能确保发行商通过这个手段能随时“如愿地撤销”项目。“假如没有看到明显的进展，或者假如团队做出第一个可玩的版本了，但游戏性上不够吸引，此时就得撤销项目了。不过如果你没打算把预制作的输出结果提到一个很高的要求，那用这个方法也是没意义的。你的团队必须要成为最棒和最能干的团队。团队要有一炮成名的决心，第一个可玩的版本最终要比得上这个类型中主流的已发布产品，因此标准不定最高是没意义的。”

通过在项目早期阶段就撤销项目，游戏开发商和发行商能降低风险，不会对一个未经验证的玩法概念投入数百万美金并再投入一大笔钱去把它放到市场后才发现它是完全不赚钱的。
由于游戏开发是如此一个大笔资金流动的业务，牵涉到成百上千的人力时，所以制作人需要确保他们的产品能有最大的获胜几率。通过在项目早期不断把风险降低，你能把风险限制在一定程度。当风险被限制住后，回报通常也就随之而来了。
使用Project、Excel以及一些很复杂的计划手段

每个制作人都必须预见到的一个噩梦是他不得不同时用多种工具、步骤，或者神秘手段去更新项目状态，而偏偏这些方法又是不互相关联的。由于微软的Project是一个很强大的计划工具，但它也是很复杂的，要有效地运用它是很具挑战的。接下来我们会谈谈如何建立起一种灵活且易于更新维护的计划方法。虽然这种方法并不完美，但它是我至今发现的最棒的组合方式。在游戏行业里，貌似至今还没有一种统一的计划方法。
以Excel的表格开始
计划的真正开始通常是在预制作阶段的尾声的，但必须在开发阶段之前。你还记得我们前面谈到过的程序任务清单和特性清单？让我们回到这些任务清单上，把清单中的任务项拆开。此时你觉得拆开后的每项单独任务都能确切地评估吗？假如不能做到，那看来你还没把它们足够拆分开。这个过程称为工作分解系统（Work Breakdown System），而这张表往往称为WBS表。表里的每项任务都需要分解成有限的小块工作。
例如，有一项任务叫做“让动画管线运作起来”，该项任务的时间是3周，那它看起来是不如彻底拆分成如下几项有效的，包括：确定输出的数据格式、把它与游戏引擎要求的数据比较、修改美术导出工具以匹配引擎数据要求、建立中间数据格式、测试管线。所有这些都是建立动画管线的确切任务。于是，其WBS看起来会像以下这样：

• 让动画管线运作起来
  
  
  • 确定输出的数据格式
    
  • 把它与游戏引擎要求的数据比较
    
  • 修改美术导出工具以匹配引擎数据要求
    
  • 建立中间数据格式
    
  • 测试管线
    
  
  

利用WBS方法，你可以和你的主管一起去对各项任务分配资源。遵循着类似的方法，你可以建立起一份游戏需要的所有艺术类资源的完整清单，包括美术、声音和音乐部分。而后可以根据游戏设计文档来去校验这份清单，把文档里提出的用例情景再回顾一遍。当详细核对过这些后，你就能做出详细的计划了。
你可以建立一份Excel表（随书的网站里有一份模板），把特性清单、程序任务清单，以及资源情况表都放在里面。然后为每项任务都增加三列，标题定为最佳时间、最糟时间和最可能时间，里面填写的值以天数为单位。
接下来让负责这些任务的程序、美术和策划去给出这三种情况的估值。把整个项目分成三张表，一份给程序、一份给策划、一份给美术。
为了让整份庞大的计划可管理，我把任务拆分成单项单个团队成员可消化的资源。通过这种方法来让他们单独考虑每项任务的情况。然后他们会填好这张表格，也会注意到表格里有没有别的任务漏了列出来（尤其是依赖性的任务）。
通过这种数据收集的手段来审查你的工作，确保每一项任务和特性都考虑到。对于那些还没指派的任务和特性，别让它们留空在那里，而是和你的主管一起去给出合理的数据。你可以在你觉得有待讨论的地方放上一个标记，标记它是不确定或者需要更多调查的。一旦碰到你犹豫不决的地方就这么做。最后这张表会像图8.4所示。



图8.4 这里是一个虚构项目的表格，它收集了所有新特性完成所需的时间。

使用公式
有一个小小的公式能用来权衡出一份计划里更准确的时间估值。其公式原理为：最佳情况（B）加上3倍的最糟情况（W），再加上2倍的最可能情况（M），最后除以6。
也就是如下的公式：
（B+3W+2M）/6=时间
这个数字可以用到计划里。它是一种快速简便且保留性的灵活估值，能让你在计划里考虑上冗余部分。它也能提出评估过程中的感情因素，因为这个公式擅长于量化一般难以量化的问题。它还能帮助你正确地评估任务，因为在这个过程中已经剔除了感情因素了。团队成员不会在明明清楚只要花1.5周就能完成时，为了让自己留下点灵活性，还必须宣称这项任务得花2周来完成了。它能让人员客观地给出答案，而不用担忧答案所引起的后果。

备注
确保这份表格在源文件控制下，这样你才能控制各个版本并跟踪版本的修改历史。你还要确保每个团队成员都是在电子版上填充的！

关联到MS Project上
当你完成了各项任务的表格后，把它按照游戏系统、艺术类资源和设计任务分类，把类似和依赖性的任务尽可能靠近地放在一起。然后把最终的“结果”列和MS Project文件关联起来，如下图8.5所示。



图8.5 建立关联

如果你想更高档一点，你可以把表格与MS Project文件关联起来，让它能自动更新时间，但这往往很麻烦，因为常常会要插入新的任务。
当设立好整个基础并评估出程序、策划和资源开发任务的所有数据后，你需要建立一份完整的计划，开始找出计划中的依赖关系。当Project文件建立以后，你需要每日地更新维护。你也可以回到Excel表格里开始——当项目需要大调整或者在方向上改变时，你就需要一份全新的计划了，此时你可以回到Excel表格上。你可以跟踪之前的估值的准确度，注意到这些估值与实际有多大差距，然后相应地调整MS Project里的计划。例如，倘若你发现一整套程序任务都和表格里提供的估值偏差50%了，那可能就得把剩下的程序任务都调整40～50%了。又或者你可以把它视作是一个问题，然后着手去寻找解决方案。
这种表格的做法能为制作人提供一个容错边界，这是一种灵活的、可防御的、相对科学的做法，而不是基于纯粹主观判断的。经过一段时间后，你可能会基于你对团队评估技巧的了解而建立起你自己的公式。
计划风险
另一种计划风险的方法更高级一点。Timothy Ryan在2003年2月3日，在Gamasutra上发表了一篇题为“开发计划的风险管理”的文章（译者注：该篇文章译者也翻译了，题为《通过开发进度表管理风险》：http://blog.sina.com.cn/s/blog_48fbe4a1010091w0.html）。这篇文章提出了不少本文采纳过的观点。现在让我们来回顾一下前面提到的一些风险管理方法。
你可以把所有的风险按它们的影响领域分组，例如程序风险是针对技术/程序计划的。接下来把它们按特性来组织起来，把特定的特性或者游戏系统对应的风险作为该组任务的最后一项。通过这样，制作人能把前置（依赖）任务与该项特性任务组（例如特定里程碑需要的某个特性）关联起来。用这种方法能更容易地把风险和特定的特性及里程碑关联在一起。在使用这种方法时，按以下步骤去完成：

• 对“前置任务（Predecessor）”列点击右键，选择“插入列（Insert Column）”。
  
• 通过“列定义框（Column Definition）”来定义该列，选择标记1（Flag 1），标题命名为“风险（Risk）”。
  
• 点击“确定（OK）”，然后该列会插入到你的甘特图里。这几步如图8.6到8.8所示。
  

图8.6 右键点击并插入新列。然后定义该列。



图8.7 在域名里选标记1，标题中填“风险”。



图8.8 确保把风险项的该列的值设为Yes。

在格式菜单中选择条框风格（Bar Style）。

• 一直往下找到“风险”一项的图示。把“任务显示为”（Show For…Tasks）设成标记1（Flag 1）。
  
• 把风险任务的条框颜色设成实心，颜色选蓝色或者红色（或者其他合适的颜色）。然后按“确定”关闭菜单。这几步如图8.9和8.10所示。
  

图8.9 选择条框风格，让风险任务的外观区别于其他任务。



图8.10 现在各项风险都安插在计划里了，而且很容易识别出来。

现在你的风险任务都很容易辨别出来了。你可以修改风险评估的前置属性，把它写成13FS+1d（13FS表示第13行的任务是前置任务，1d用作风险的缓冲或者未知风险，我通常会根据风险的大小把这个值定在1～7之间）。

• 最后，你还要做一项预防措施来确保风险都管理到位了，你要在计划里有着两个不同的里程碑。第一个里程碑是里程碑完成日期。这个日期是该项特性的所有任务理应完成的时间。而后是风险评估和成果评审。当完成这两步后，该里程碑才提交，如图8.11那样标记为“里程碑提交（Milestone Submitted）”。这能在该里程碑提交给发行商前，让身为制作人的你有时间去和各个主管评审该项特性的成果。
  

图8.11 风险评估在里程碑“完成”后且提交前进行。

备注：
你可以把各个子项目和主文件关联起来，通过这个方法能把游戏的不同领域区分开来。这能让主程有一定的灵活性去回顾和更新计划（例如为任务增加依赖关系），而不必一直等着你更新完资源计划后才能动手。尝试去把游戏开发的不同领域划分成不同的子项目文件，然后把它们关联到一个每周定期回顾的（高层）主计划里。

在计划里加入冗余值

另一种方法是在计划中加入冗余值，只把某些资源计划到80%的功效，甚至是50%的功效，这样能让你在出现问题时有着更高的灵活性。你可以通过对一项任务或者单个资源点击右键，在单位（Units）一栏里填上合适的百分值，如图8.12所示。MS Project的这个特殊的功能尤其适合用在为主管计划任务时（前提是此时他们身上负有游戏开发的任务）。这能让他们空出50%的时间去做别的任务（例如行政、解决问题、管理等等），而无需在计划里到处都加上诸如“行政”或“表现审核”一类的字样。
我的大体法则是任何一个主管在计划上都不应安排超过80%的工作量。你可以把这个冗余系数加入到前面谈过的公式里，但在用这种方法时，你也得确保这个冗余值既不会太多，也不会不够，要让你感觉舒服且自信。



图8.12 在这里调整资源的效率。

更自由的形式
虽然我不建议用这种方法，但这种情况在大多数软件项目里都是不可避免的。通常项目里有一些人（资源）不太适合于正常的规则，无法告诉你接下来将会完成哪些特性或者任务，尤其是在他们同时展开多项特性和任务的开发时。假如你发现在团队里无法解决这个问题，那就要用这里介绍的计划方法了。
首先你可以把他们的任务标记为0时长，只对他们工作完成的时间给一个固定日期，尤其是在任务附有依赖关系时务必如此。又或者你可以用前面提过的“冗余值”的方法，把该资源同时划分到3个任务上。在这种情况下，资源只能同时在三项任务上各自贡献33%的效率，或者是在四项任务上各自贡献25%的效率，以此类推。不过我还是建议尽可能让一项资源同一时间只专注于1～2项专门的任务。当你要同时做其他事时，你是很难把一件事做好的，这也是为什么我反对用这种方法并希望制作人强调WBS方法的原因。

备注
确保用这种方法或者用以上列出的多种方法的组合在每一份计划里加入适度的冗余值，否则在情况发生改变时你会没有余地去操作和响应，这能让制作人留下最后一手，让他能把工作做得更出色。

让人害怕的加班

即使你是世界上最棒的制作人，在项目的某个时期还是需要你的团队加班的。尽量把加班留到真正需要的时候，而且务必节制地使用。确保每个人都觉得“在某些特殊时期，我们会一起加班来达成我们设立的目标”。这能避免出现有的人总是加班而有的人从来不加的情况，又或者压根不知道自己为什么加班。你要让团队提前注意到他们可以安排自己的人生。避免让加班成为一件经常发生的事，你要把重心放在让团队如何在工作时间内更有效且高效地工作上。
加班在利用一个额外的机会或者一项真的很酷的特性时是很适用的。假如你让每个人都对这项刚实现的新特性感觉很棒，那当游戏出色表现时没有人会记得他们多花了一个周末或者几个晚上去加过班的。

备注
即使是在加班阶段，你也要在员工已经持续工作11小时后让他们回家（10小时的工作时间和1小时的午餐时间）。大多数程序员在持续工作10小时后就会开始犯各种错误，此后用来纠正错误所需的时间比他们在第二天再继续做还多得多。的确，我知道程序员往往都喜欢工作到深夜，但我并不鼓励这种做法，假如你看到各种错误开始出现了，那就马上主动停止它。

依赖关系与替代资源

如今已经谈到过风险管理了，接下来让我们看看各种依赖关系，以及这些依赖关系是如何影响到制作人的工作的。依赖关系是指一项工作在另一项工作完成之前是不能展开的。例如角色在没做出来（建模和贴图）之前是不能导入到游戏世界里的。动画在角色放进游戏世界前是无法测试的。音效在美术资源没完成并导入到游戏世界前是无法摆放的。角色在建模、贴图，以及至少部分动画完成之前是不算完成的。过场动画在语音录制完成之前是无法放进游戏里的。语音在剧本完成前是无法录制的，而剧本在你聘用到文案前是无法完成的！
对制作人来说，这意味着除非你确定了项目里所有的依赖关系，否则总会有一些人要等着其他人才能完成他们的任务。而且即使你已经了解所有的依赖关系，并在计划里考虑到了，这种情况还是会发生。但重要的是在它发生时去把它的影响减到最小化，确保有一定的灵活性能让其他工作跑起来，让关键路径继续运作。
让项目继续前进而不用卡在某个依赖关系上的一种方法是为所有的资源建立替代资源。这意味着游戏世界里各种贴图、角色、关卡、音效、语音、音乐、背景和物件都有着替代资源。但采用替代资源也有一个技巧。你必须确保用这些替代资源不会产生更多的依赖关系。
当为游戏制作替代资源时，你需要确保设立了一套文件命名约定。这意味着所有的音效文件都会遵循一套命名指南，并且很容易辨认出来。策划把音效命名为“bigbang01.wav”，脚本函数也调用同样的音效文件夹，播放该个文件。当你实现出最终音效时，用最终数据去替代老数据，把新数据拷到正确的资源目录里。
这个例子表示该种方法可以在游戏开发中任何时候运用到大部分的对象里。你可以建立替代贴图，而后你就能让各种模型很快能在游戏里看到有没有效了。这能让你有更多的时间去迭代和创新。假如每个人都要一直等着别人去把资源做到100%才能在游戏里看到，那整个流程就会变得极慢了。你应该鼓励这种流程和方法，鼓励项目里用替代资源，甚至包括替代的游戏关卡。
例如，用替代资源的方法能让美术人员不必光等地形工具的最终版本去整合地形、世界光照和场景光照。至少他可以用替代地形开始把各种物件放到游戏里，看看整个表现怎么样了。
事后剖析（Postmortems）

事后剖析是很简单的。在每个里程碑结束时，让团队做一份简短的一段式的描述或者总结，列出本里程碑进行的情况，列出本次做得好和做得不够的地方。回顾各种数据，把相关的有意义的建议写到计划里，让余下的里程碑能更轻松有效。到了接近项目尾声的时候，整个流程应该已经打磨得很好了，此时应该更顺畅且高效了。
我把事后剖析的方法用到几乎每件事的结束时，包括一个大型项目、一个小型原型，以及各个里程碑。反馈是很有价值的，而事后剖析报告（以及《游戏开发者》上的文章）是避免将来再发生一些过去已知错误的很好的方法。
事后剖析只需要遵循以下简单的格式就够了：

• 做得对的地方？
  
• 做得错的地方？
  
• 建议的改良方法
  

你可以把事后剖析以邮件或者文本模板的形式存放。无论用哪种方式，在阅读后留下有价值的部分，放弃没那么重要的部分（例如不是基于100%事实的主观意见），然后设立计划展开行动。
里程碑接受测试

至今为止，我建立的一种最简单和最灵活的构建游戏开发项目的方法是利用里程碑接受测试（MATs，milestone acceptance tests）。这个流程和方法如下所列，但我会对它进一步解释，让你了解到为什么即使该流程没有在开发协议中列出还是要实现出来。
MAT的目标是规划和预留游戏开发中的动态因素。这个方法让发行商和开发商都能响应产品焦点、市场，以及玩法方向上的变化，而无需花时间去重新谈判协议细节或者各个里程碑的交付定义。
MAT的流程包括如下：

• 里程碑X（通常是预制作后期的一个早期里程碑）定义了项目的整体目标。此时最终版的创意设计和技术设计都提交并且通过了。
  
• 随后的里程碑交付定义包含了基础的模板和一些通用的标准，例如列出了某个日期前要完成的具体数量的特性。
  
• 下一个里程碑要交付的关于游戏、引擎特性、美术资源和其他交付项的具体细节要在协议的截止日期前提交。这些细节称为里程碑接受测试标准。它清楚描述了在下一个里程碑里会交付什么内容，且这些内容是双方达成一致的。
  
• 当里程碑提交到发行商时，发行商会用里程碑接受测试标准去作为一份校验清单或者测试计划，以此确保各项游戏特性、美术资源和交付的具体细节都如约定那样达成了。
  
• 该流程能让发行商准确地比对描述清单和完整的交付内容，包括资源、游戏特性，以及其他需要交付的交付物。这种清单校验过程在衡量成本带来的成果价值时是极其有效的。
  

假如你把这段话也加入到开发协议里，那就更好了。但如果不是这样，那我强烈建议开发商与发行商之间建立起类似这样的非正式基础。假如双方都对里程碑的接受和完成的具体标准达成一致，那应该基本上没有任何争端或者不一致的情况发生。这能把历时几个月的事情浓缩成一张一页长的清单，确保开发团队的各个主管都有着清晰的目标。作为开发商中的制作人，你永远不应该提交一个你认为会失败的里程碑。而一旦用了这里列出的MAT方法，你应该能在提交前就清楚它会不会失败了。
从外部收集的意见

为了完成这本书的研究，我还和视频游戏行业里不少人聊了一下。自然地，每个人都对什么是一个优秀制作人有着自己的想法。以下列出了一些行业专家在谈到这本书时都提到的话题：

• 成为一个优秀的风险管理者。了解各种风险，并在需要时设法找出其解决方案。
  
• 诚实是关键。团队必须信任你和你所说的话。
  
• 尽早且经常地砍去功能。越多的功能意味着越频繁的加班。
  
• 抵挡团队不受外面的干扰（包括管理层、市场部门、以及与游戏无关的行政问题）。
  
• 永远不要说谎。但如果他们都不问，那也别总急着说出答案。
  
• 别牺牲团队士气去换取成果。
  
• 尽可能让自研工具减到最少。
  
• 尽可能重用工具和技术，但倘若你要做的是一款伟大的游戏，那也别让这点把你限得太死。
  
• 善待人员。一点小错足以铸成大错。
  
• 花时间去记住团队里每个人的名字。了解每个人的一些情况。这是制作人持有的最重要的认识。
  
• 饮料总是由制作人掏钱的。
  

这些都是一些你应该考虑的通用指南，它能造就出成功且压力更少的日常习惯。这里还列出了一个程序员的访谈，借此你能在以后从团队中读出一些迹象，从而不会在将来的项目里重复犯过去犯下的错误。

采访程序员Nick WaandersNick Waanders是有着欧洲和北美多家游戏开发商工作经历的行业专家。他对制作人给出了一些很有价值的建议。 Q：假如要你对行业提建议（尤其是视频游戏中的制作人），你觉得制作人最应该重视的工具或者知识是什么呢？ A：制作人需要去帮助团队，而不是去驱使团队。假如大家都尊重你，而你也尊重你的人员，这对你的产品是很有好处的。没有什么比大家都认为老板是傻子来得抹杀士气了。这再次跟诚信沾上关系了。别满口谎言，和你一起工作的都是一群很聪明的人，不需要多久时间他们就能识破你的谎言了。 Q：在与程序员交流的过程中，一个制作人应该显现出来的最重要的特质是什么呢？ A：证明他有大把的钱！严肃来说是我觉得重要的是把问题暴露给程序员，再让他指出有哪些方法可选。程序员会清楚在现有代码基础上哪些方法是合适的，也能给出这些方法分别要花多长时间。但你要确保对每一次要求都有着足够的风险管理了。例如当我在欧洲工作时，当时的制作人坚持我们要加入迷你游戏。我们告诉他这会耗费很多时间和精力，但他坚持要这么做。结果，这些迷你游戏在最终游戏里只扮演了很小一部分的角色，然而大家为此耗费了总开发时间的40%，且产品最终也没有发布，这让我很纳闷。这就是把团队的时间错误投资的例子。 Q：你曾经和一个优秀的制作人共事，并看到他对产品带来积极影响吗？能谈谈这样的例子不？并且为什么这件事会在你脑海里印象这么深？ A：制作人Jonathan Dowdeswell是让整个团队在《战争黎明》中做得很好的一个主要原因。他总是能第一个抓住最大的问题和风险。当我们越靠近最终的完成日期，我们的风险承受能力也越小。因此当一些新特性提出来时，他会和所有主管一起去评估风险。假如风险太大，那该项特性就很可能会砍去。在砍去特性时是不带任何情感的，情感只依附在整个产品上。我觉得这的确是一个目标驱动的过程，这种思路也真正投射到整个团队上。 Q：基于你的经验，你觉得制作人常常犯下的错误有哪些呢？其他制作人该如何从这里吸取教训呢？ A：我觉得对信任最大的破坏来源于制作人直接为发行商说话，而没有清楚意识到团队是应该更优先的。假如如此重复多次，那团队就会觉得你没有去尽可能避免外部对团队的影响了。 假如就一个主题有着大量不同的观点，那说服主程的最好办法是具备符合逻辑的论据。这可能听起来显而易见，但程序员大多是纯逻辑思考的。这意味着你必须能把所有原因形成有逻辑的言语。 假如该主题是关于如何实现某一部分代码的，那你就应该相信主程。例如，在我之前工作的公司里，制作人会走过来说：“我们希望这个和那个在游戏里有，我觉得这不应该花太多时间的。你觉得要多久能把它做好呢？”往往制作人脑海里最简单的东西都是极难做的。在他所说的例子里，诸如“在这里加入魔法”往往最可能是极难实现的一点。所以我觉得与其问程序员要花多少时间，不如先让他们提出一些可能的解决方案再去评估时间。 Q：你觉得制作人利用得不够或者应该更多研究的工具是什么呢？你觉得哪种工具能让主程工作变得更轻松？ A：你得对团队使用的各种工具都有基础了解。如果你看到团队里有人在用你从来没看到过的工具，那就问问这个工具能用来做什么。当你在跟踪各种已完成的任务时，我个人推荐通过邮件或者每周会议的形式去跟踪。这种方法能让每个人在一周里都至少相互谈过一次话。每个制作人都应该读读微软出版的《开发过程调试技术》（Debugging the Development Process）。这是程序类书籍，但它适用于任何开发过程，且包含了大量有趣的陈述和观点。任何读过这本书的制作人都会赢得程序员的尊重。

总结

本章列出了能让制作人日常生活更轻松和更易管理的各种关键工具。你是不可能把所有可以用上的工具都使用上的，但这些手段里有不少都是行业里一直使用的。你可以从中挑选最合适你和你的项目的方法。在游戏开发中是很少有一种万金油的方案的。