GDC项目管理分享：如何驯服开发中的“混乱”

【GameLook专稿，未经授权不得转载！】

GameLook报道/随着游戏制作规格的上升，游戏制作团队也越来越大。现代3A游戏有动辄数百人的规模。随着人员的增加，团队之间沟通成本呈指数型增长，项目管理的难度也越来越高。在游戏开发中，如果团队无法进行有效的项目管理，那么必然会陷入整体的混乱之中，进而让游戏质量大打折扣。

在GDC大会上，曾有多年3A游戏项目经理任职经验，后专职进行敏捷项目管理培训的咨询师Clinton Keith分享了项目管理的宝贵经验，对项目中可能出现的混乱状况和应对措施进行了详细的讲解。

以下为GameLook听译的内容：

混乱，他们让项目陷入无序，但他们总与游戏开发项目相伴相生。正因如此，我们必须要学会如何通过控制混乱来避免随之而来的负面因素，包括项目死线临近的疯狂加班，项目废弃带来的额外开支，因工期不足而放弃关键功能的上线，或是让项目没做完就匆匆发售等等。尽管做游戏本身只是一门生意，但我们要让项目的运作更有持续性。

我认为是倦怠（burn-out）是我观察到的一个很大的问题。作为一名项目经理，原本的我对待项目极有热情，在连续加班加点三个月以后，我开始变得逃避风险，满脑子只想着赶快完成项目的目标。在倦怠之下，我脑子里想要的只有完全的控制，任何的流程都要越简单越好。我的关注点完全停留在项目上，而不在游戏本身。我变成了一个“海鸥经理”，闯进项目大闹一通，然后立刻逃走。我要对开发者提出的每一个不在计划内的好点子说：“也许听起来挺有意思的，但做这个赚不了钱，你给我专心完成项目计划。”

我今天演讲的一部分内容就是希望避免上面这种情况发生。尽管我所说的内容并不可能适用于任何一种工作室文化，但我希望能把一部分有益的原则介绍给你们。

首先，我想谈谈项目开发中的“压力”。我认为压力就和在健身房举铁有些类似，贸然上高重量很容易让你受伤，但用太低的重量练习反而会让你的肌肉变弱，只有在合适的重量区间中进行锻炼才能获得增肌的效果。项目中的压力也一样：太低的压力会让项目缺少动力，导致游戏的质量不及预期，但太高的压力会让所有人陷入压抑。我们要为游戏开发找到一个合适的压力区间。

我讲我的重点分为四个大类：注重结果而非产出、拥抱风险、管理“负债”、建立工作室文化。

注重结果而非产出

这部分经验来自于我在任天堂日本总部工作的所见所闻，当时我直接和宫本茂打过交道。宫本茂会走进一个开发现场，和我们共同探讨游戏的设计点子，然后给我们三个月的开发经费，让我们没有后顾之忧地地去寻找一个游戏的乐趣何在，三个月后他会再回来。

当我们回头审视之前的开发流程，我们问自己：“我们找到的游戏乐趣到底有多少？”我把他们用这张图的Y轴来表达出来。

我们的第一任务就是去寻找游戏的乐趣，如果三个月内没有找到一个游戏的乐趣何在，项目就取消掉。因此，我们项目的混乱主要出现在项目的早期，我们需要不断实验各种点子，把各种物品排列组合来找到游戏的乐趣基础。此外，宫本茂还会要求我们把摄影机控制等基础的东西先做好，再在其基础上推进项目。

这样的好处在于项目的整体变得可控。在探索阶段，我们专心寻找乐趣，随后游戏的形态开始“涌现”，我们开始在制作摄影机和关卡设计的过程中建构起属于这款游戏的乐趣“公式”和“词汇”，随后我们只需反复利用这些公式就可以创造游戏的乐趣。

而与之相对应的是另一款游戏《Smuggler’s Run》的开发历程，这是一款PS2平台首发护航的开放世界赛车游戏。在项目最开始我们说：“嘿，让我们把环境做得生动一点吧，在里面加上几只鹿怎么样？”后来我们发现人们很喜欢鹿，他们喜欢追着鹿跑或者开车撞上去，甚至比开车还要痴迷。他们甚至自己设置了挑战，比拼规定时间内撞鹿的数量，然后传到网上给别人看。这是一个热门的功能，但我们没花多少精力做这个。

在传统的瀑布开发流程里，我们要经历立项，前期准备，游戏制作，一测二测三测等等各种流程，一切都按部就班地推进，最后把乐趣拼凑成一个完整的游戏。但项目的压力全部来到了最后阶段：我们需要同时优化性能，排除bug，为了工期砍掉关键功能；有人想出了很好的游戏点子，能让游戏变得更有趣，但我们忙成一锅粥，根本没空管这些。

一个极端的例子是开发《Midtown Madness》的过程，当时整个营销部门都对我们不理不睬，但在游戏A测结束以后的一瞬间，他们就突然开始紧紧盯着我们的各种动向，给我们提各种各样的要求。我还听说有临近游戏发售以前，上层看到了游戏的CG动画，然后他们说不喜欢这种风格，要求我们把十几个小时的动画全部重做一次这种事。你们想想这多让人崩溃。如果他们在早期就看到了试制的动画并提出了修改意见，以后的流程就可以顺畅许多。

因此我推荐你们推行以下这些原则。

1. 和关联部门建立起透明的关系，鼓励他们在早期参与游戏的开发，协定合作尺度，和各部门建立起信任；
2. 每三个月输出一个可玩的版本，这样能够帮助校正开发计划，并及时知会上级最新的开发境况，获得许可；
3. 最后关头做出的改变并不都是坏的，要能够利用机会。

当然，这些原则的推行往往会遇到困难。比如现行的合同体系并不允许在项目早期就冒风险。此外，中间管理层有时候会过度要求你交代项目细节，或者提交各式各样的文件等等，这些都可能发生。因此，要尽可能和上层建立信任，向他们展示你的进度，厘清他们的顾虑。

拥抱风险

我们将风险分为两个维度：是否能被预知、以及是否能被解决。

首先是我们能预知到且能解决的风险。这些风险可以提前预测到，并做好相应的准备。即便是采用敏捷开发流程，我们也需要做一定程度的应对来避免混乱的发生。

其次是我们能预知到，但尚没有解决方案的风险。例如，新的Xbox将要发售了，我们想要在新平台发售我们的游戏，但我们还尚不了解如何在新的Xbox平台进行开发。尽管微软告诉你开发会很容易啦，机器的性能也很强大啦，但机器没拿到手一切都是未知数。针对这种状况，我们需要提前考虑如何应对并减少风险的存在。

第三种是我们没法预知，但我们能解决的风险。这种情况我们只能硬着头皮去学习如何对应。

第四种是我想讲述的重点：我们预知不到，而且我们极难解决的问题。正好有这么一个例子：我们之前在开发一个《谍影重重》IP的游戏，但我们谁也不知道的是，主演马特·达蒙的妈妈是一个反电子游戏斗士。因此，马特·达蒙在项目的后期退出了，连带着其他演员也跟着他一起退出了，我们不得不找其他演员。最终我们没能赶上电影上映，游戏的质量也受到了影响。

这种事情无论如何都没法提前备案。因此我想讲的是“拥抱风险”，并非避免风险或排除风险，去积极主动地应对这些风险的存在。

我们当时学到的一套流程是：首先，我们要分辨风险。我们会在项目开始之前进行一套“预复盘”，去梳理项目可能遇到的问题，例如错过关键死线。我们再继续回推，什么因素会导致这种情况发生？例如，我们当时使用的一款中间件还没有移植到这个平台上来。针对这个中间件会带来的潜在风险，我们设置了一个特定的KPI来评估风险的存在性，假如十月一日这个中间件无法使用，我们就认为这个风险存在。然后我们提前思考应对措施，譬如通过购买中间件的源代码，自己来做移植的方式让中间件尽快投入生产。每隔一到三月，我们就会重新评估这些KPI，并反复推敲是否有新的风险出现，或者修改此前定下的应对预案。如果KPI未达预期，我们就当机立断，开始执行此前的备案。

有些工作室文化中会认为这种提前预知风险的行为是在挫败士气，他们只想做到“避免”风险的发生。但事实是风险很难避免，尤其是你对风险本身都不知情的时候。最重要的是在面对风险时能够主动出击，以避免项目遭遇泰坦尼克。

管理“负债”

这里的“负债”是虚指，我们指的是在项目中出现的一些潜在包袱。但和银行贷款一样，债务还清的时间越长，你需要付出的利息就越多。一个bug拖的时间越久，日后想要在代码山中找到这个bug的难度就越高，类似这种事情。设计和内容开发方面也是一回事。在敏捷开发的过程中，我们时常会专注于尽快输出一个可玩版本，把各种问题拖到A测以后再去解决。但这些问题可能随着时间积累，越来越难以被解决。

如下图可见，随着项目推进得越来越深入，躺在bug数据库里的内容越来越多，我们要处理的内容也越来越多。等到项目收尾阶段，“砰”，混乱又出现了。

在开发《Midnight Club》这款开放世界赛车游戏的时候，我们在项目的最后阶段才意识到我们要把所有的纹理都塞进机器的内存里去，于是我们紧急要求美术绘制新的纹理，但依然赶不上工期。我们的技术负责人实在没办法了，下令把所有的纹理质量全部降低75%。我们的美术同事直到游戏上市才发现纹理变得极其粗糙，可以想象他们当时有多沮丧。游戏的质量就是这么被影响的。

我们后来是这样进行改进的。每隔三个月，我们就抽上一周对游戏进行整修，处理一部分之前的问题。如此反复。最终在发售前，我们的工期还留有余量，也不会面临地狱式的赶工的情况，游戏的质量也不会打折扣。这是多赢的局面。

经验总结：

1. 不要害怕“负债”，他们是游戏开发的一部分。不要依赖bug数据库，及时进行处理能够避免项目在某一个时间点陷入密集的混乱；
2. 有意识地进行“还债”，逐渐改进内容整修流程；
3. 改进开发工具：加入自动化测试，缩短反馈周期等等；
4. 对“完工”给出清晰的定义。

建立健康的工作室文化：让开发者如鱼得水

这个部分是能够最有效提升生产力的。创造出一个以工作质量为最高衡量标准的工作室文化将会让项目如虎添翼。

这个世界上有很多低劣的衡量标准。我之前任职的一家工作室的母公司是一家日本企业，他们认为员工呆在办公室的时间越多，就意味着员工越勤奋，哪怕员工在摸鱼。这和加州的办公室文化格格不入。后来我们得知，他们在离我们一百英里外的洛杉矶有一个工作室，母公司的人有时会派洛杉矶的员工在凌晨两点开车路过我们工作室的停车场，看看里面停了多少车。开始他们很光火，因为他们发现根本没有多少车半夜停在那。上有政策下有对策，我们和旁边一家半夜上班的报社达成了一个协定，让他们的员工把车停在我们的停车场。也算是解决了问题。

我曾经也是一个在项目临近死线时会要求全体工作室一起加班的项目经理，我当时还沾沾自喜，因为我会和整个团队一起每周工作七十个小时。但后来在我们的检测中发现，尽管加班的第一周产出量确实有所提升，但到了第四第五周，我们的产出量反而是在下降的。我意识到，人们会感到疲倦，他们会犯更多的错误，进而拖慢整体的办公效率。在了解到这一点后，我就再没有要求团队全体加班过了。

因此，我们需要建立合理的衡量标准。并非是把员工按在办公室从早到晚不动的标准，哪怕这样能让上层更安心。僵化的安排会让员工感到公司缺乏信任，进而影响员工和团队整体的工作效率。同理，要求员工事无巨细地提交报告也是表达不信任的一种方式。对应地，在这种严苛的规则之下，人们会根据规则来调整自己的工作标准——假如你要求我每日代码的行数需要达到一定量，那我就写大量注水的行数来应付。最终受害的是整体的项目质量。

此外，我还想提及一个“心流”的概念。作为游戏开发者，有时候我们会迷恋我们的工作，早上从床上爬起来，快速地洗漱后，立刻就冲到办公室开始创作游戏，效率自然也大大提高。我们将这种特殊状态称为“心流”期。而作为项目管理，我们需要知道如何让开发者进入“心流期”来扩大开发效率。

我们认为，决定心流的两大因素是技术水平和工作难度：如果工作难度显著低于技术水平，那么开发者会感到无聊；如果工作难度显著高于能力水平，那么开发者就会感到高压和不适从。作为领导层，我们在保证员工尽可能呆在舒适区的同时，也可以不断带领着员工挑战更复杂的工作，因为员工的能力也会随着时间提升。