做了24年3A，我积累了这些团队管理经验
游戏葡萄
编者按：本文来自微信公众号“游戏葡萄”（ID:youxiputao），36氪经授权发布。
腾讯公司高级副总裁马晓轶曾说，3A很大程度上意味着工业化的能力。而在今年7月GameIndustry报道，腾讯游戏在美国洛杉矶开设了Lightspeed工作室，正在为PlayStation 5和Xbox Series X开发3A级别的开放世界游戏。
在由腾讯游戏学院举办的第四届腾讯游戏开发者大会（Tencent Game Developers Conference，简称 TGDC）上，Lightspeed工作室总经理Steve Martin分享了他在团队搭建、架构设计、项目管理等方面的经验。对于正在尝试几百人协作的高成本项目，需要优化组织架构与项目管理方式，搭建工业化开发流程的团队来说，这篇分享能让你少走不少弯路。
以下为主要分享内容，葡萄君对部分内容做了精简和重新翻译：
大家好，我是Steve Martin。今天我想聊聊如何建设3A游戏的开发能力，以及Lightspeed LA是如何搭建的。
为什么我要从零开始搭建一个3A游戏工作室？先来介绍一下我自己。我从1996年开始为索尼PlayStation主机开发游戏，在接下来的24年里，我先后在全球各地的多家工作室任职，曾参与《极品飞车：地下狂飚》《马克思·佩恩》《侠盗猎车手》和《荒野大镖客：救赎》等系列游戏的开发。
2019年，在R星（Rockstar Games）工作了14年之后，我渴望新的挑战和机会。于是我开始和光子接触。我们希望把光子最好的工作方法和对卓越的追求，与西方最好的经验、知识和人才结合起来，切入3A游戏市场。于是就有了我们在加利福尼亚州新开设的，面向全球的3A工作室。
接下来我们讨论一些关键问题，比如团队规模和团队建设。
团队规模：做3A需要一支超大的团队吗？
这是一个超大全球团队（global meta team）的时代。我们可以构建跨越时区、国家甚至大洲的研发体系。而且在新冠疫情期间，大家也都在尝试居家办公、远程办公。
那么我们一定要打造一个多地协作的超大团队吗？我们可以先看看超大团队的利弊。
超大团队有如下几个好处：
1. 拥有大量的开发资源；
2. 能够在全球范围内挑选顶尖人才；
3. 拥有7x24小时工作的潜力——比如研发团队和QA团队可以放在两个时区，形成接力式的开发流程；
4. 可以把一些技术要求不高的岗位放在成本比较低的地方，以此降低支出。
但它也有一些弊端：
1. 容易增加人员数量，而不是缩减规模；
2. 人才资源库虽然庞大，却无法提升流程的效率——如果公司人员充足，何苦花时间优化系统？
3. 人才稀释（Dilution）。找到40个3A标准的美术是一回事，但组建一支400人的团队又是另一回事。除非你用多年来锻炼团队，否则不可能保持相同的人才标准；
4. 更高的管理成本。中层管理人员的数量和团队人数可并不是一个线性的关系。一个40个人的美术团队，可能需要8名资深员工，2个组长（leads）和1名美术总监；但一个400人的团队，可能需要80名资深员工，40名协调员（coordinators），20名组长，8名资深组长，2名总监和1名高级美术总监。前者的比例是4:1，而后者的比例大约是4:1.5。因此，一个40名美术的团队其实需要51个人，而一个400人的美术团队则需要大约550人。
5. 繁多的会议——想象一下协调一个150人的团队要开多少会吧。
6. 个体不再重要。为了维持人情味，团队要耗费巨大的成本。举个例子，如果你是团队的2%（即一个50人的团队），那你一定对项目很有参与感，很有主人翁精神，你和同事也都彼此认识；但如果你只是团队的0.18%（即一个500多人的团队），那你可能最多只认识15%的同事，对项目可能也没什么热情——这是在我身边真实发生的故事。
7. 臃肿的细节。庞大团队的创造力太过剩了，这听起来有点儿凡尔赛……但由于大家都处在不同的地点和时区，管理层不可能检测到员工的所有工作，更何况他们还处在不同的地点和时区。
所以你们经常能看到一些出发点很好的小设计（pet project），它们有不错的深度和细节，但从宏观角度来看它们又不太必要。而每次发现这种设计的时候，团队往往已经浪费了大量的资源和金钱。
8. 高额的成本。多个工作地点的开销，巨额的工资，IT、HR和支持设施……一支1500人的团队，做6-7年的费用非常惊人。
所以我们要不要建设一支超大的团队？我认为答案是否定的。因为建立一支超大的团队并不会增加成功的概率。游戏开发的成功取决于创造力、控制力和执行力。在短期之内建设一个超大的团队，我们很难构建起一套拥有这些特质的系统，这个风险太大了。
那如果没有超大的团队，我们该怎么做事？
在早期阶段，我们只会在确实有需求的岗位增加人员，而不会分配不必要的人力——如果我有100名美术，那我会确保他们人人都有活儿干。
同时，我们还会不断地挑战现有的假设，不断根据KPI和数据重新评估和制定计划：明年我们是需要更多，还是更少的人？
我们也会控制开发内容的规模——别被那些沙盒游戏牵着鼻子走。人们真的想要一款能玩上200个小时，拥有成千上万可收集要素的游戏吗？我猜不是。那就不要为了追求过多的内容而折腾你的团队。
总而言之，不管是什么类型的游戏，只要你事先稍微多做一些分析，你就能更合理地利用资源，这会让你对团队规模有新的理解。
团队架构：如何保证「管理」与「制作」的平衡
那该怎么设计团队架构，才能实现效率和创造力的最大化？关键在于「管理」和「制作」的平衡。
管理人员太少，你就有面临沟通问题的风险，或者只能让创意人才去做琐碎的管理工作，跟进项目进度；而如果管理人员太多，每个部门都会依赖自己人来负责沟通，那不同的部门之间就容易彼此分裂。
举个例子，这是一个最典型的团队组织结构，我给不同的团队加上了颜色，方便辨认。
（可将手机横置浏览）
这种模式在8-10年前非常普遍，而且至今仍然存在于某些工作室当中：总制作人会先和各个制作人沟通，制作人们再与各个分支的总监沟通，让他们把信息带回各自的团队。这是一个标准的瀑布型沟通体系。
但层级结构越深，信息传达的难度就越大。而且当信息需要更正的时候，大家还会沿着错误的方向继续工作一段时间，直到收到新的信息为止。同时，这个信息向上反馈的效率也非常低下。
好，擦掉这个模型，我们重新建立一个更重视制作的管理架构：团队希望通过添加部门人员以增加沟通渠道。
（可将手机横置浏览）
很明显，现在我们制作人的数量增加了2倍，还增加了同等数量的助理制作人，整个团队传递信息的能力大大增强了。棒！
呃，不过现在总制作人要和一个庞大的制作人团队进行沟通，每个制作人还要用助理制作人和分支团队进行沟通，越来越多的人为了同步信息而开各种小型会议，大家的信息反而非常分散。
举一个简化的例子：助理制作人告诉大家，我们要做一个有三条胳膊的反派角色，而角色美术说，我们的骨骼系统无法处理多余的肢体，需要重新设计角色，或者更改骨骼系统的代码。
于是角色美术告诉总监，总监告诉助理制作人，助理制作人告诉制作人，制作人做决定再下达命令……等到信息沿着链条传递给所有相关人员，AI和动画已经在错误的方向上耽误太久了。
让我们再次把屏幕清空，看看我的建议。
（可将手机横置浏览）
在这张图的顶部，总制作人、制作人和总监们组成了一个创意委员会。而在图片底部，我们也有一支助理团队。
在日常工作中，创意委员会先彼此沟通，由总监将信息传递给各个团队。同时他们也会直接和自己的助理沟通，而这些助理们也会直接彼此沟通，并和各个团队沟通。这样我们就有了既能自上而下，又能自下而上，还能同级之间彼此沟通的组织架构。
仍旧举那个三条胳膊反派角色的例子。在总监们一起讨论的时候，程序或者美术总监就能发现骨骼方面的问题；就算他们都没发现，那角色美术发现问题之后，也会直接通知给美术助理。而美术助理既能通知美术总监，也能通知程序和动画的助理。这就可以大量节省消耗在错误方向上的成本。
另外关于团队搭建还有一些小细节。
1. 可以组建一支跨部门的敏捷开发小组，在演示新的玩法特性Demo，或者新内容的第一部分时它特别有用。
2. 除了工作流程，开发环境也是影响开发效率的关键。为了节省一时的成本牺牲开发设备的配置或是降低网速，一定会导致巨大的效率损失；同理，牺牲版本搭建、编译和加载的时间也会导致类似的后果。
3. 我们还应该挑战组织架构。例如在功能测试和版本测试的时候，QA确实很重要；但如果要进行大规模的功能测试或者TRC测试，再等待QA团队的反馈就没那么合适了。那我们是不是还有保留一支庞大的QA团队？搭建一支独立的团队，让QA助理与开发人员一起工作，单独测试会不会更好？
一些项目管理技巧
在游戏开发中，不可能存在完美的计划。执行得最好的项目也会延误。但在拥抱变化的同时，我们也可以采用一些简单的办法来优化项目管理。
如果一件任务需要超过一周才能完成，就把它分解成子任务；我们还可以跟踪任务推进的过程，以后再开发重复的内容，我们就可以给出更准确的估算。以建筑或者建筑内部的结构为例，我们可以估算每平方米的平均工期，建筑做得越多，估算这个指标的方程式也就越完善。
那如果是不相似的任务，比如写一个新功能的代码呢？我们可以先估算技术特性的风险，以及它在无法实现的情况下会对项目造成多大的影响。如果风险和影响都很大，那我们就要避免这类任务，或者严格控制它的数量。如果它对游戏真的特别重要，那我们就要尽早开始这项任务。
还有一点非常重要：收集实时数据。
有的团队想延长后续同类内容的开发时间，结果相关领导说：「这次花的时间是很长，但我们也有很多收获，下次的时间肯定可以更短。」这种错误观念非常常见，因为他们拿到的是错误的数据。这个时候，团队有三种解决问题的思路：
思路一，保留之前的计划排期，但会根据之后三次类似工作内容的数据，重新调整平均值；
思路二，立即调整计划排期，并根据之后新的数据调整平均值；
思路三，在评估任务和实际工作的过程中，根据更多数据调整平均值。
思路二的效果似乎更好，因为如果按照原始计划排期计算平均值，数据的增量肯定有限。但这个思路也并不万能，大家还是要根据数据，和专家进行讨论，再决定最合适的方法。
想让进程安排更加合理，我们还要面对需求漂移（feature creep）的挑战。它会延长工期，增加成本，甚至要削减内容才能赶上Dealine。
很多制作人都说，想在Deadline之前完成项目，避免需求漂移非常关键。A级或者2A项目确实如此，但3A项目并不一定。某些情况下，不断发展的创意确实能够提升游戏体验。
如果想追求真正的3A品质，那很多事情都会挑战我们既定的时间表。因此，我们还有一些方法能降低额外的成本。
1. 让内容计划更具弹性。
假设我们在做一款3A射击游戏，它的一大特色是多层高级协同AI，这个AI伙伴可以跟随玩家战斗，跨越平台，甚至进行紧张的隐身潜行。而我们希望设计几个任务来凸显这项惊人的技术。
但AI团队却很焦虑。他们一直在想办法怎么让AI伙伴拥有靠谱的隐身意识，这让制作时间排期有太多的未知数。
在这种情况下，很多人可能觉得应该为AI团队留出更多的时间。但有些关键内容又非常依赖于AI技术的进展，它们很可能成为游戏的主要卖点。那我们就可以通过弹性的工作内容计划来降低风险。
比如我们必须要做出一个功能齐全的AI伙伴。但设计也可以来实现这个需求；或者是调整任务对AI代码的需求，比如让故事解释一下，为什么做一些潜行任务的时候AI伙伴不在身边。这样我们可以提前准备很多解决方案，而非为了解决问题，一次又一次地延长开发时间。
2. 划分A、B和C内容。
假设我们在做一款开放世界MMORPG，设计师需要让可收集物品、任务和NPC散布在地图的每个角落。在这种情况下，我们可以先划分A、B和C三种量级的内容：A是最小值，C是最大值，B是性价比最高的中间值——它既能保证内容足够丰富，又能兼顾开发成本。
比如设计团队的结论是，对于这款游戏的可收集物品数量来说，最小值是150，最大值是500，而最合适的值是375。所以我们会把150项内容标记为A内容，另外225项标记为B内容，最后125项是C内容。在研发过程中，大家要首先完成A内容，之后再完成B内容，还有余力的话再做C内容。
这种方法可以避免一种尴尬的局面：游戏一个区域的内容过于饱和，但其他区域却比较荒凉，这样玩家就会觉得，开局的体验为什么比结尾丰富了那么多。
关于细节迭代
你可能会发现，以上这些方法的共性在于，我总是先强调内容的质量和多样性，并尽可能地保留之前的逻辑，最后只会在数量上做出牺牲。因为3A游戏的设计和控制必须流畅。玩家必须觉得自己能精确控制屏幕上的一切细节——说实话，这是开发过程中最耗时，成本最高，也最完善的因素。
那怎么处理完善这些细节呢？答案很简单：迭代。我们要一遍又一遍地迭代所有的设计要素组合，直到它们的反馈、精细程度、视觉、听觉和触觉都能完美地结合起来。
玩家和角色的联系来自细节。在角色开始移动之前，玩家需要将摇杆推多远，多长时间，又要多久才能变成慢跑？更改方向需要多长时间才能执行？瞄准和移动之间的界限是什么？释放摇杆多久之后，角色才会减速停下来？仅仅在平坦的地面上行走，就有这么多微妙的细节。你的开发列表很快就会长得令人发指，这个迭代的过程需要无限的耐心，任务非常容易延期。
那么问题来了，如何安排这个过程？这就是敏捷开发的领域了：可以组建一支突击小队，划分项目和计划的结构，了解团队身处何方，要前往何处，何时才能到达那里，谁是关键人员，他们工作的最佳环境是什么，迭代的潜在阻碍和瓶颈又是什么。
举个例子，对于角色控制型的游戏，瓶颈往往会出现在动作捕捉上。我们只能靠推测来制定动作和动画的录制计划，有些计划看起来不错，但到屏幕上就不对了，等到重新完善计划，预约摄录影棚重新拍摄，往往又要花费几周甚至几个月的时间。
所以我们在加利福尼亚的工作室正在安装小型的模拟动捕设备，它不会用来捕捉大型的叙事动作或特技，但可以用于角色动画的迭代。突击小队可以在工作室内用它进行大量的动捕测试，废掉不好用的想法，然后再去录影棚拍摄。这样我们就能向演员精确地列举所需的动作，列出变化可能性的清单，并知道哪些动画适合动捕，哪些动画适合手K。
除了动捕，这种集成迭代的思路可以应用到每一个工种当中，它为团队提供了一个允许失败的安全区域。想让团队做出高质量的产品，你就必须降低他们的试错成本。只有被鼓励突破边界，尝试各种疯狂的想法，创意团队才真正进入了3A游戏的境界。