开发者谈如何以实际行动构建高质量游戏

本篇文章中我将对我所认为作为构建高质量游戏以及一般软件所应具备的良好基础进行探索。我会讲到很多不同的主题，这些主题的共同点是——我相信它们都为构建高质量游戏的目标做出了贡献。我不会细讲每一个主题，但是适当的时候我会提供补充阅读材料。这不会是一个详尽的清单列表，肯定还有其他一些重要的因素我没有覆盖到，但是从我的角度看来我所提到的那些都是构建高质量游戏最关键的部分，所以为了重申其重要性我要把这些字眼粗体让它们更清晰：

“我相信下面的内容都是构建高质量游戏的关键基石。”

理解什么是质量

为了构建高质量游戏我们首先不得不先要有对“高质量”的一个确切概念。我认为Gerald Weinberg说得最好了：

“质量就是对一些人来说存在的价值。”

IndieDevDiary1-GameDevelopment(from gamasutra)

如果你要向你的顾客推荐一款游戏，那么这款游戏就应该具备高质量。一款没事就崩溃的软件通常对用户是没有什么高质量可言的，所以我们可以认为这种软件是低质量产品。我们要懂得从对人类价值的方面来考虑产品——只要产品价值高，漏洞多、或者任何其他的指标什么的都没多大关系，反之则相反。一款没有任何漏洞的产品，也可能质量低到无法提供人们以任何价值。

理解什么是复杂性

我们在构建的是复杂性产品，而复杂性问题被定义为：需要根据追溯回忆推理而得出因果关系的问题，所以这里的含义是非常广泛的。一项管理国家的五年计划，这种复杂性可以说是没什么意义的，因为这里的复杂程度让你根本不知道怎么解决这个问题，而这对于一份详尽的研究与开发项目计划来说也是如此。研究与开发是复杂的，任何想要对这些项目进行预先规划的努力都是徒劳的——你只有先观察，然后做出调整去适应：工作开始时，先观察工作成果，然后调整适应新形势。如果你所创的规划概述了一个开发项目的范围，然后你设定了项目完成的日期，这时为了弥补形势改变，你唯一可以修改的变量因素就是质量。

信任与授权

永远也别对复杂的事物进行微观化管理。复杂问题的处理不仅要求对问题能深度了解，而且要有应变能力。一名管理者如果跟每天的工作脱节，那他既无法了解工作内容，也无法做出解决复杂问题的正确决策。管理需要建立应有的信任，然后让专家来解决问题，而这就需要授权让他们去做出调整来应对随时变化的情势。如果你想要构建一个高质量复杂性产品，你就要说明你需要解决的问题，而不是告诉专家怎么解决这些问题，因为没有人能提前知道问题是什么样的。

所有权

但是为了建立信任，开发团队要拥有产品的所有权。也就是说你所为之工作的产品，其价值归你所有。因此你也就有责任要交付其价值，你需要担负起产品的所有责任。无论你的角色作用是什么，或者你有什么样的能力——只要你看到什么是有损产品价值的，那你就有责任去处理它。

多功能且真诚的团队

为了创建这种基于信任的所有权文化，你可能需要成立一支相对久远、多功能型、真诚的团队。对于一支有能力拥有问题或产品的团队来说，他们得要有所需的完整技能组来解决这些问题或开发这件产品。一旦你开始在团队之间划分工作，并且在团队之间有太多的依赖关系，你就会破坏产品所有权并造成瓶颈。因为这会让成员有一种事情出错不是自己的问题，是别的团队成员的问题，造成团队成员之间责任的推卸。所以你还要建立一支高效的团队，他们要能够交付高价值产品，当然这需要时间。如果你经常性地在团队之间把人员像资源一样调动，这样很难建设一种基于信任的产品所有权文化，并且团队将很难发挥出他们真正的潜能。

Monument Valley（from gamesindustry.biz）

信息多样化

信息多样性在团队中是很重要的，比如说，你会需要不同的产品背景、整套技能组、丰富经验以及对问题的看法。调查发现，信息多样化可以激发大家对手头上的任务的建设性冲突与辩论。也就是说，人们进行的是对最佳化行动的思考——这就是解决复杂性问题和提高高价值产品的关键。

重视团队能力，忘记自己的角色

当你凑齐了一支多功能型的队伍时，你要思考的是解决复杂问题需要哪些能力，而不是你要扮演什么样的角色。你扮演的角色并不重要，解决问题才是重点。团队的每个人都应该尽自己所能地去解决问题。无论是谁，只要有能力就应该去做为了达到目标必要做的事，而不应该工作角色描述里的人为概念所局限。有一些任务也许需要编程专家来完成，然而有一些则只需要基本的编程技巧就好。第二种任务就可以由那些平常不怎么写代码的人来完成。总之就是说如果你有解决问题的能力，你就应该去解决这些问题。所以说团队的每一个成员都是产品的一个开发者，有些编程很厉害，而有些则在产品测试、美工、UI、UX、设计等方面很厉害——但每个人都应该努力去让自己具备各个领域的基本技能。

反馈和社会契约

为了能有一个功能性较高的团队，那不仅需要股东们适当的产品反馈，还需要在团队内部的反馈演示。股东们应该要参与到生产的过程中来，这是非常有价值的一件事，还有团队需要能持续地重新审视他们的工作原理以及对形势变化的应变方式。

所以需要签订一份社会契约。每个成员都需要知道所有的反馈都是为了以可能性最大的方式去开发出最有价值产品。要去帮助人们成长和发展，而不要去评判表现、批评或袒护权利。

合理的测试外包

总有某些能力或者设备是团队没能具备的。比如本地化测试就是个很好的例子。测试会很繁琐，昂贵的设备也是另一个因素。不同类型的认证测试会需要外部方的加入。总的来说你需要找到方法让测试尽可能地在团队内而完成，并能够对何时应该将测试外包给公司其他部门或者第三方做出明智的决策。

为什么不把所有的测试都外包给别人，让团队专注于开发呢？这里有很多原因，但是最重要的是这个：所有权（归属感）。团队存在问题，就要解决问题，如果你把所有的测试都外包了从某种意义上来说你不经意地把这个产品的所有权也转移了。

但是还有非常多的原因：反馈循环和交流问题；以详尽的程序测试、不必要的漏洞报告以及额外的需求规格说明所这些形式所产生的浪费；更长的周转时间等等。

探索性测试

在大多数情况下，制造手动程序测试并反复地运行它们是一种浪费——所以别做这种测试。你要始终假设你的产品开发人员门是具备高等级测试能力的，他们将进行探索性的测试（你需要学习并理解这种概念），然后当你看到了创建的程序测试存在切实价值时，就做这种测试就好了。不过也要考虑下在这些情况下编写一些自动化测试——如果你要为了什么目的创建一个人工程序测试，那么创建一个自动化测试几乎总是更好的。

风险性测试

你永远不可能有时间把所有的测试都运行一遍。你需要分清轻重缓急。你输入的这个优先顺序选择会有所不同，不过一旦定下来，你会知道要测试什么才能让你的测试活动价值最大化。在某种程度上，你会有足够的信息来进行产品质量风险评估，然后你把这些信息提供给团队成员和股东们。如果有人想要进一步降低风险，你就继续你的测试活动，如果他们不再有这样的需要，你就可以停止测试。

运行所有可能的测试不仅不可能，因为几乎每个复杂的产品都有无数的测试，而且即使有可能，这也是一个资源浪费的巨坑，这些资源本可以用来更好地生产价值的。

另外，不要认为预定义的程序测试涵盖了所有可能的测试，并不是的。

运营与开发之间的协作

一旦说游戏上线，不幸地告诉你，产品仍然归你所有。所以要确保开发团队和运营上线产品的有关人员要保持密切的协作关系——比如说在客户支持工作，再比如说IT运营工作。如果你有数据科学部门来研究传入的数据，那么他们也同样很重要。

服务型的领导力

管理人员应该明白，他们在战场上的将军角色正在消逝。指导、赋能、支持才是一个管理人员现在的工作内容。如今为了高效地开发出高质量软件，我们需要的正是这样一支技艺精湛的、有干劲的、自主性地汇聚在一起的这样一只真诚的团队。他们最不需要的就是有人站在他们的肩膀上试图对他们进行微观管理。

如果你巨额被上述列出的要素，你就可以开发出高质量的游戏或者任何其他高质量软件。这并不是通过其他方面达不到这样的效果，但是肯定没这些来的有效。开发高质量游戏跟生产易拉罐苏打水是不可同日而语的——上个世纪所定义的最佳实践不再是运营软件开发组织的最佳方式。每个人都要去适应——要不就得被替换。