本文原作者：Johan Hoberg 译者ciel chen

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

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

理解什么是质量

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

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

IndieDevDiary1-GameDevelopment(from gamasutra)

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

理解什么是复杂性

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

信任与授权

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

所有权

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

多功能且真诚的团队

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

Monument Valley（from gamesindustry.biz）

信息多样化

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

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

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

反馈和社会契约

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

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

合理的测试外包

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

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

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

探索性测试

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

风险性测试

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

运行所有可能的测试不仅不可能，因为几乎每个复杂的产品都有无数的测试，而且即使有可能，这也是一个资源浪费的巨坑，这些资源本可以用来更好地生产价值的。
另外，不要认为预定义的程序测试涵盖了所有可能的测试，并不是的。

运营与开发之间的协作

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

服务型的领导力

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

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

本文由游戏邦编译，转载请注明来源，或咨询微信zhengjintiao

In this article I will explore what I believe is a good foundation for building high quality games, and software in general. I will cover a wide array of different topics which have in common that I believe they all contribute to this goal. I will not go into detail on every topic, but will try to provide additional reading material when appropriate. This is not an exhaustive list and there are of course other important factors that I will not cover, but I have added those that are most crucial from my perspective. So to iterate and and be bold and clear:

“I believe that the following components are crucial building blocks which enable the creation of high quality games”

Understanding Quality

To build high quality games we first have to have an idea of what that actually means. I believe that Gerald Weinberg said it best:

“Quality is value to some person.”

If you deliver a game that is of high value to your customers, then that game has high quality. A software that continuously crashes usually does not provide its users with high value, thus we could consider it as a low quality product. Always think in terms of value to people. Number of bugs, or any other metric does not matter if the value is high, and the other way around. You can have zero bugs and still have a low quality product that does not provide value to anyone.

Understanding Complexity

We are building complex products, and complex problems are defined as problems where cause and effect can only be deduced in retrospect. The implications of this are huge. A communist five year plan for governing something as complex as a country is pointless, since you can never know in advance how to solve this complexity. The same goes for detailed project plans for research and development. Research and development is complex, and any attempts to plan these projects in detail up front is a fool’s errand. You have to inspect and adapt. Start working, inspect the outcome of that work, and adapt to the new circumstances. If you create a plan that outlines the scope of a development project, and you set a date for when you want this project to be complete, the only factor you can modify to compensate for changing circumstances is quality.

Trust & Mandate

You can never micromanage your way through complexity. Not only does solving complex problems require a high level of understanding, it also requires the ability to adapt. A manager disconnected from the everyday work does not have the understanding, and cannot make the right decisions for solving these complex problems. Trust needs to be established between management, and the experts solving the problems, and this needs to come with a mandate to adapt to changing circumstances. If you want to build a high quality complex product, you can state what problems you want solved, but not how the experts are going to solve them, because this is not known in advance.

Ownership

But for trust to be established ownership must be taken by the development teams. When you work on a product you own the value of that product. You are responsible for delivering value, and that includes everything. It does not matter what your role is, or what competence you have – if you see something that detracts from value, then it is your responsibility to make sure it gets addressed.

Cross-functional, Genuine Teams

To create this trust-ownership culture you need to build relatively permanent, cross-functional, genuine teams. For a team to be able to own the problem or product they are working on, they need to have the entire skillset required to solve that problem or develop that product. As soon as you begin dividing work between teams and have too many dependencies between teams, you are eroding ownership and creating bottlenecks. It is never your fault something is wrong, it is some other team’s problem. When you see a value detractor you assume another team will pick it up.

You also need to build effective teams that are able to deliver high value and that takes time. If you continuously move people between teams like resources in an excel sheet you will never be able to build a trust-ownership culture, and the teams will never reach their true potential.

Informational Diversity

Informational diversity is important in a team, i.e. you need different background, skillsets, experiences and views of problems. Research has found that informational diversity stirs constructive conflict, or debate, around the task at hand. That is, people deliberate about the best course of action. This is key to solving complex problems and providing high value.

Competence, Not Roles

When you are putting together your cross-functional team you need to think about the competences needed to solve the complex problems, not which roles you are suppose to have. Roles are not important, solving the problem is. Everyone in the team should do whatever it takes to solve the problem. Whomever is capable should do what is necessary to reach the goal, and not be limited by artificial constructs such as role descriptions. Some tasks might require an expert programmer, while some require rudimentary programming skills. The second of these tasks could potentially be picked up by someone who does not normally write code. If you have the skills to solve the problem, then you solve the problem. So everyone in the team is a product developer, and some have high competence in programming, while others have high competence in testing, art, UI, UX, design, etc. But everyone should strive after having some rudimentary competence in all areas.

Feedback & Social Contracts

To be able to have a high functioning team, not only does it require proper product feedback from stakeholders, but also performance feedback within the team. Stakeholders need to be involved in what is being produced, and that it is of high value, and the team needs to continuously revisit how they work and adapt to changing circumstances.

There needs to be a social contract in place. Everyone needs to know that all feedback is giving with the intent of developing the most valuable product in the best possible way. To help people grow and develop, not to evaluate performance, criticize or assert power.

Motivation

We need highly motivated people to solve complex problems. Modern motivational theory promotes intrinsic motivation which can be nurtured in a number of way:

What we do not want is the more traditional extrinsic motivation in the form of carrots and sticks, rewards and threats. To solve complex problems efficiently motivation needs to come from inside. In short, for this to happen, people need to be surrounded by people they can relate to, they need to feel that they are growing, that they are not micro-managed, and that what they are doing makes a difference.

Quality Intelligence, Not Quality Assurance

You can never test quality into a product. Testing will never assure quality. What it will do is give you information about the state of the product. You can then use that information in any number of ways. So get rid of the old QA acronym, and the old way of thinking about QA and testers as gatekeepers of quality, and instead adopt Quality Intelligence:

“Quality Intelligence is a set of techniques and tools for the acquisition and transformation of raw data into meaningful and useful information for quality analysis purposes”

Quality is owned by the development teams, and testers are part of those teams, but everyone in the team should feel equal ownership of the quality of the product.

Design for Testability

Testing is not an activity you tack on at the end of your development process, performed by someone outside of the development team. Testing should be part of the development process from the start. During planning, during design, during development, you should always think about testing and quality. Testing is a continuous activity throughout the development cycle, involving everyone in the development team.

Designing your code for testability will much improve your chances of implementing a successful automated test framework and automated tests, but also help make the manual testing more valuable, with for example opportunities to support this with different tools.

Everyone Tests to their Ability

Testing is not an activity exclusively performed by testers. Complex testing problems are solved by testers. Obvious problems can be solved by anyone, and that goes for all fields of product development. Obvious programming problems can be solved by anyone with rudimentary programming skills, and obvious testing problems can be solved by anyone with rudimentary testing skills. And everyone has rudimentary testing skills.

Developers test their own code to the best of their ability, and if the code is complex, then most likely someone with a higher level of test competence supports the developers with additional testing.

And everyone in the team helps regression test the game before a release. The Product Owner, the Scrum Master, the programmers, the artists, the game designers, the data scientists. Everyone.

Outsource Testing Right

There will always be certain competences or equipment that are not feasible to have within a development team. Localization testing could be one example. Testing which requires cumbersome, expensive equipment could be another. Different sorts of certification testing might require an external party. In general you should always look for ways to keep as much of the testing within the team as possible, and make informed decisions on when to outsource testing to other parts of the company or third parties.

Why not outsource all testing and focus on development within the team? There are many reasons for this, but the absolute most important one is: Ownership. The team owns the problem, and the team should solve the problem. If you outsource testing you are most likely also inadvertently transferring some of that ownership as well.

But then there are tons of other reasons: Feedback loops and communication problems. Producing waste in forms of detailed test cases, unnecessary bug reports and additional requirement specifications. Longer turnaround times. And so on.

Exploratory Testing

In almost every case, producing manual test cases and running them over and over again is a waste. Don’t do it. Always assume you product developers with a high level of test competence will perform exploratory testing (you need to learn and understand this concept), and then in the cases where you see an actual value in creating a test case, do it. But also consider writing automated tests in these cases – if you need to create a manual test case for something, then it is almost always better to create an automated test instead.

This is the only way you will be able to handle all the testing required inside you development team.

Risk-based Testing

You will never have time to run all possible tests. You need to prioritize. What input you choose for this prioritization will differ, but once it is done, you will know what to test to get the most value out of your test activity. At some point you will have enough information to make a product quality risk assessment, and then you provide this information to the team and stakeholders. If someone wants to reduce risk even more, you continue your test activity, and if they do not, then testing stops.

Running all possible tests every test activity is not only impossible, since there is an almost infinite amount of tests for every complex product, but even if it was possible it is a giant waste of resources, that could be better spent producing value.

Also stop thinking that your predefined test cases cover all possible tests. They do not.

Continuous Integration

This is common knowledge by now, but when you work in a team, sitting in isolation working on your own code for a long time, and then trying to integrate it to the master branch is not a good idea. Integrate often, and have an automated test framework that enables fast feedback. Also make sure that you have someone with test competence continuously looking at the master branch, analyzing risk and performing more complex tests when needed. And never merge anything to the master branch without testing to the extent of your abilities first.

Collaboration between Operations and Development

Once a game goes live, unfortunately your ownership of the product does not go away. Make sure to have a close cooperation between the development team and those involved in operations of the live product. Customer Support is one example, IT operations is another. If you have a data science department looking at incoming numbers, then they are also important.

Servant Leadership

Managers should understand that their role as generals on a battlefield is going away. Coaching, enabling and supporting is what a manager should be doing. Highly skilled, driven individuals, grouped together in self-organizing, genuine teams working on complex problems is what is needed today to develop high quality software efficiently. The last thing they need is someone looking over their shoulder, trying to micromanage.

If you have the above listed building blocks covered, you are in a good place to be able to develop high quality games, or any other piece of software. That is not to say that it is impossible to do otherwise, but it is definitely less efficient. Developing high quality games is not the same thing as manufacturing soda cans – what was defined as best practices last century is no longer the best way to run your software development organization. Everyone will need to adapt, or be replaced.（source：gamasutra.com ）