游戏项目范围管理的技巧（二）：聚焦

原作者：Levon Demurchyan 译者：Willow Wu

聚焦……是什么？（上篇请参阅）

关于聚焦这个事，我想解释其精髓的最佳方式是引用Steve Jobs的一句话：

“当你在思考项目焦点时，你以为关键在于说‘是’……其实你错了，关键应该在于说‘不是’……”

从哲学、抽象层面来理解这句话是非常重要的，因为这样你可能会更容易理解聚焦的方式和流程。

专注其实是最具挑战性的事情之一，因为在这个过程中，有很多诱惑会分散你的注意力。未能专注于核心，通过增加新特色来执行计划，这种现象被称为项目范围蔓延（Scope Creep），它是开发周期中最可怕的事情之一。几乎所有的工作室都会出现这样的状况，或者在某一时刻做过这样的事情。项目范围蔓延会产生极大的危害，原因如下：

1.往原先的蓝图中增加新的游戏特色或/和内容会使项目陷入危险。
2.复杂项目的各个部分往往会交织关联，计算难度很大。添加特色可能会产生多米诺骨牌效应，破坏游戏的稳定——基本上每次都会。
3.更多游戏特色意味着更长的开发周期，最终会导致高强度、长时间的加班。
4.预算上涨或者是质量标准下降。
5.团队士气低落
6.团队速度变慢
7.无法实现产品/游戏愿景
8.超过截止日期等于失去项目

这怎么就有危害性了呢？项目范围变化跟这些问题有什么关系？

团队速度是个很微妙、复杂的话题。指的是你/你的团队执行计划或计划任何部分的速度。这是可以帮助你评估你是否遵循计划的最重要指标。在一段时间内，比如一天、一周，你们成功执行了多少任务。所以，它微妙在哪呢？每个人都知道这个指标的存在，但很少有人知道它的重要性，甚至更少知道它其实不是最好的评估指标。因为每个任务都是不一样的。此外，范围的变化是不可见的。当团队遵循计划行事，而不对计划/环境做任何改变或几乎不做任何改变时，团队的速度就是最佳状态。如果团队事先知道下一步要干什么，他们就可以更好地执行任务，如果这是某个重复性流程的一部分，而不是一个独特的任务，那就更好了。在开发过程中，任何一种干扰都是非常具有破坏性的，会对团队利益造成暂时性的伤害。“计划”是愿景的产物。团队知道接下来会发生什么，他们就能够做好准备、承受打击。

高强度加班——噩梦级别的情景，团队成员被任务压到无法平衡工作与生活。项目范围蔓延必然会导致高强度加班。除了我们在这篇文章中提到的这些显而易见的原因外，还因为在战术层面上，作为范围变化的产物，需要做的工作比原先前计划好的又多出了很多。高强度加班是会带来毁灭性影响的，因为每个人都应该休息，而且每个人都需要休息。它最终会磨灭团队的创造潜力，高强度加班是最糟糕的噩梦之一。

团队士气是另一个需要重视因素，而且它非常脆弱。管理不善，即使是世界上最热情、最富有创造力、最有前景、最能干的团队，也会因此被击溃。项目范围蔓延意味着不可预测的变化，而且极有可能危及原计划，直接导致士气下降。这其中有很多心理因素，但最主要的一点是人们不喜欢在被蒙着眼睛的情况下继续艰难前行。另一个原因是人们希望有一个称职的领袖，清楚自己在干什么。这就是为什么透明度和沟通也很重要。任何一种不可预知的变化可能会让团队的大部分心血报废，这也是一种非常消极的体验，虽然这种情况经常发生，但也有其它原因造成的。

未考虑到的关联：每当你在一个半开发的系统中增加或改变一些东西时，你必须非常注意其它部分会不会发生什么改变，因为你可能会为了一个短期的或未充分考虑的更改去调整一个与其它元素/系统有关联的系统，从而导致大混乱的结果。当你改变了复杂系统中的某些东西时，这是不可避免的，但重要的是程度是多少。

预算膨胀是人力管理不善的直接产物。没考虑到系统之间的关联性会影响到产品中某些已经被开发出来的部分，现在必须重新做，有时会花费比当初多得多的时间。因为复杂系统中的导航工作是非常令人头疼的，这一点软件工程师非常清楚。当你扩大项目范围时，如果你还假设可以在最初计算的预算范围内执行，这当然是十分荒谬的。

在我看来，产品/游戏愿景是问题的根源，处理不当会自食其果。如果你有非常清晰的愿景，明确知道自己要做什么样的游戏，那么在大多数情况下你应该也清楚自己该怎么去实现。在愿景不够清晰、确切的情况下开始执行，这就会是你下坡路的起点。你开始添加一些东西试图来弥补，最终只会是更进一步地破坏了游戏愿景，因为你走的还是同一条路。这就引发了连锁反应，这也是我们探讨这个话题的原因。

超过截止日期就等于失去了项目。项目是一种临时性的工作，目的是为了在规定的时间内生产一个产品或达到一个目标。时间结束，项目也应该脱手了。项目范围蔓延会引发连锁反应，大多数情况下你会陷入一个循环，无休止的拖延、重排工作日程、重新规划预算等，一直到资源都被消耗光了，项目终止。

但为什么会这样呢？

如果至少做过一个项目的话，我想大家应该都遇到过这种情况。但是，我们并不清楚是什么促使我们走到这个地步，是什么摧毁了推动项目前进的良性力量，让我们无法按时、无法凭借有限的预算完成项目，是什么引发了项目范围蔓延。在上一篇中，我已经讲解过了如何设置项目范围，提高项目顺利发行的可能性，更好地防止项目范围蔓延。但更重要的是不要在执行过程中偏离，因为你最初设定的范围可能是正确的，但开发起来又完全不是一个方向。所以，是什么导致了项目范围蔓延？

-范围设置含糊（什么要做，什么不能做）
·要做哪些具体游戏特色？
·详细明确的开发计划？
-市场变化等原因影响
-缺乏范围变更管理

我们上一篇就讲过范围设置含糊这个问题，以及应对方法。选择合适的起点，明确范围，这很重要。如果有足够的预算和时间，你可以随时回到这个阶段。重新设定范围是一个非常冒险的举动，你得意识到这么做可能带来的后果。有时候它可以拯救项目，避免陷入某种悲剧结局，但大多数时候，它会导致项目范围蔓延。就如我之前所说的，知道范围里应该有什么是很重要的，但更重要的是知道范围里不该有什么。因为它能给你明确的危险信号，让你知道什么样的发展是绝对不可接受的。如果你已经确定了X游戏特色不在计划范围之内，每当你试图添加一些X或类似X的东西时，你和你的团队成员就有更大的机会识别出雷区。如果你在执行开发之前没有确定好，没有人可以阻止你添加这些东西，因为你们没有确定到底哪些是范围内哪些是范围外。

你要利用自己的能力和知识来确定这些特色。理想情况下，你已经开发了一个具有特定特色的游戏原型，现在你知道下一次迭代会是什么样的。

如果你对特色的想法是抽象模糊的，没有明确设定，你无法确定到什么程度才算做完。此外，你可能也不太清楚第一步应该从哪里入手。这也就意味着你肯定无法安排工作计划、规划预算。但是不设定和设定得不够全面是两回事。后者是你以为你已经对特色做了详细评估、规划了预算，最重要的是，已经交付计划了。这就是为什么预制作非常关键，因为你有更多机会能够精确设定游戏特色，为它做一个明确的开发计划。

所以，开发计划本质上就是你怎么把这个特色变为现实。它是点A到点B之间的路径，开发计划就像是在一个森林里游荡，你需要参考点来三角测量你的位置，以便知道你的方向是否正确。如果你不知道在旅途中要寻找什么，那你成功到达目的地的可能性也就更小了。

开发计划也是很重要的，有个周全的计划能够让你远离争议。每当你感到迷茫的时候，你都可以回到上一个检查点，审视一下哪里出了问题，思考下一步该怎么做。如果你没有这样的计划，或者说计划得不好，就相当于你到处去寻找金羊毛，即使你知道它是什么样的也不一定能找到。在预制作阶段投入足够的时间制定开发计划，这对于最后的冲刺阶段也能产生很大的影响。四处游荡会产生不确定感，即使是面对真实、明确的事物也是如此，所以在没有地图的情况下，到处乱走是非常危险的。在有指导可参考的条件下，团队就能够更容易地识别出不属于计划的行动，避开不必要的偏差。

游戏开发是一项事业，或多或少是会涉及到钱的。而我们必然是在同一个市场，甚至也许是同一个子市场，不管怎样都是交织在一起的。一个行业影响着另一个行业，引发连锁反应，或者说“蝴蝶效应”——如果这个词更易于理解的话。如今的市场发展是非常迅速的，一天之中风云变幻。无数人为了博得用户的喜爱争得头破血流，而我们也在其中。每当大变革降临的时候，环境也会发生变化，市场也会去适应——这就需要流动性，机智和远见。

但并不是所有的人都有机会去适应，因为我们很可能已经耗尽了所有的潜力、精力和专注力。深入的分析和商业敏锐性也许能让你更好地预测市场变化，但这绝不是保证。即使你知道趋势的发展方向，你可能会因为资源、自信心、精力等方面的缺乏而无法迎合改变。这就是我们无法控制的事情之一，就如同大鲨鱼在水族馆里翻大浪。这时我们都开始动摇，心里充满了恐慌，进而影响着我们的决策。唯一补救方法是为你的产品/游戏设立一个明确的目标。这是很重要的，因为这样你就能够清楚自己是朝着什么方向努力，万一靶子移动了，至少你也知道它长什么样。

在我们讲解决办法之前，我想讲一个非常重要的话题——范围变更管理。我并不想传递出“任何改变都是坏事”这样的观点。我们某些最受欢迎、最成功的游戏都是在某个阶段进行了大改。重点不在于做出改变，而是控制改变。就是认真负责任地应对变化，并做出相应的调整——无论是改变范围，推迟截止日期，还是最初计划的任何其它改变。重要的是，你应该对此给予极度重视，还有认真负责的态度。

拒绝任何改变也会带来严重的后果。任何将你和/或你的团队引向目标，或遵循愿景的行动，都是正确的行动。重点不在于方法上的坚持，而是要坚定自己要达成目标的决心。

范围变更管理是一个工具集，你必须要利用它来掌控变化。这就必须制定一个流程，使人们能够根据预先确定或中途确定的衡量指标做出灵活的决策，这些指标有助于评估改变是否是实现最终目标所必需的。这就像是一个漏斗，用来测试提议的改变是否能产生更好的效果，是否值得。这些指标各有不同，要取决于游戏项目本身，跟愿景和业务目标保持一致。目标是固定的，但是达成目标的方法可以是灵活的。做一份指南，说明在各种情况下的应对方法，这就形成了范围变更管理，它能提高实现目标的成功概率。学会对变化提出不同意见，根据不同层面的指标发起辩论，学会从高级管理人员那里争取到变更支持，学会向大家传达这一决策，防止他们措手不及。

好了，我们来讲最后的部分。

反击

状况1：

现在，你已经尽自己所能拟好了最初的范围计划，这就是你所设定的标准。因此，你必须坚持，不能动摇它。一旦你开始了开发工作，地狱之门就打开了。你开始偏离计划路线，往蓝图上添加其它东西、模糊焦点等等。因此，我们必须守住范围。

第一步：不要去做就是了。

你会在开发中途增加游戏特色，主要是因为：

1.你觉得加它们对游戏会有好处，或者很酷。
2.你觉得这不会影响你的计划，可以穿插到日程表中。
3.你觉得游戏挺无聊的，或者缺少某种特色，你需要加以调整。

第一条是最常见的，我们都有这样的经历。我们需要明白的是，即使是一行代码、一个简单的着色器、一小片地图或者是一小个游戏特色，它们都是有代价的。你已经规划好了时间、预算，而现在你试图偷偷塞进一个小特色。你必须得明白，时间和资源对你是有约束作用的。这就是很简单的数学问题。你不能把7升的东西装进4升的容器中。看上去是很容易判断，但实际绝非易事。如果你确实有意识到这一切，那么能让特色溜进你的日程的，只能是在不留神的情况下了。

我们团队的做法是先确定我们的游戏跟哪些东西无关、我们不会去做。写下来，遵循上面的设定。但是从日常工作角度来说，我们要怎么应对项目范围蔓延呢？控制创意风暴对我们来说就是一个可行的解决方案：每当我们有一个新的想法时（我们有很多想法，会不断涌现，就跟你一样），我们就把它写下来，把这个决策推迟到我们对它不那么激动的时候。它非常有效。概括来说就是：我试图为这些决定制造层层关卡，要经历多重审核。这样我就可以从这些令人兴奋的即时想法中过滤出真正绝佳点子。

示例：

-我昨天看了一部电影，我知道我们的游戏需要这个新特色。经过解释、辩论，表示这个点子绝对能让游戏大放异彩，然后问大家是怎么想的。

-好吧，这是个好主意，但是让我们下周在会议上讨论一下，确定一下接下来要怎么做。

这为什么会很重要呢？我们从来不会说不，我们只会说有当初有一份一致同意遵循的计划书，如果这个想法符合设定，我们会去做。

你和你的想法是两回事，如果你把自己和想法捆绑在一块，别人质疑你的想法时，你就会觉得自己受到了冒犯。”——《创新公司》，作者艾德·卡特姆

在这个“范围调整会议”上，我们会准备好一些点子、一些范围调整建议，大家一起讨论，尝试用我们所掌握的各种工具去测试它们。如果这个点子通过测试，得到大家的认可，我们会把它加到游戏中。但是，这种情况真的很少发生，因为大多数想法看起来都很棒，但如果它们真的很棒，它们看起来就应该很合适游戏了，如果它们真的适合，它们看起来就应该是能够在现有的日程规划中实现的。如果这个想法是真的很棒、很适合游戏且具有独创性，我们会为它每天多工作一个小时，但是：

1.我们很少会做这样的事
2.我们会认真负责地做
1）计算所需投入的时间、人力、金钱
2）搞清楚有哪些关联的内容会受影响
3）我们会预估一下万一它是毒药，可能会带来什么样的后果。（如果风险太大了，我们决不会把项目置于危险之中）
4）我们不添加需要4小时以上来规划的特色，也从不添加与预计交付时间段偏差超过5%的特色。
5）我们会问很多设计方面的问题，尽我们所能地寻找漏洞、攻击。
6）没有做过的东西我们不会去做。
3.非常重要：我们把点子展示给股东，努力跟他们解释为什么这是个很棒的点子，告诉他们做了哪些测试。

现在，我希望你能明白这些环节并不是起到占位作用的过滤器，便于你可以随时把有趣的东西塞进去。而是意味着这些过滤器的通道必须是非常狭窄的，或许只有1%的点子能够顺利通过。我们来算算，有很多想法提交上来，但你每2周才审核一次，而且通过率只有1%。而且，现实地讲，这些点子会在会议前直接“熄火”，因为到这时候我们跟它们之间的激烈化学反应已经消失了，不再是“情人眼里出西施”。

创意的关键不是在于有个精彩的点子，而是给复杂的问题提供深层次、有效的解决方案。为了避免踩入那些常见的陷阱，理解这其中的不同之处是非常重要的。

我学到的另一个经验是，如果你觉得自己正在做的游戏是挺无聊的，那么以下其中之一或许是问题的源头所在：

1.你在制作之前没有做原型
2.你做了原型，但没有注意到你的核心特色、游戏循环、机制等核心设计元素不够好，而你试图用次级机制来掩盖这一点。在这之后你依然没有做测试。
3.你测试了手头上的这个有点不堪入目的东西，认为游戏无聊的唯一原因可能在于视觉效果、3D元素、UI、生效等等。
4.实际上，觉得游戏无聊的只有你一个人，目标观众不这么觉得。

第二和第三是非常普遍的。给一个有问题的核心主体增加次级机制和内容是大家都会去尝试做的事。因为你不想放弃一个想法，即使你的执行效果或解释不足以让这个想法变得吸引力十足。或者，在某些情况下，这种想法本身并不吸引人，确实无聊。那你就得跟这个项目告别了，或者一直迭代到核心部分有起色。千万别用华丽的特效和感染力十足的配乐来掩盖。你越是掩盖，越是看不到你需要及时解决的隐患，这是非常糟糕的。

状况2：

市场变化极大地影响了我们的工作。有时候，好几个项目会一起被砍，因为他们已经跟不上市场了。而有时候，我们还会有一点时间去改变项目的命运，及时改变它的方向。这也包括解决预算短缺，比如在预定时间段内无法利用手头的有限资源完成项目。

这时的我们会遇到一种两难境地：删减还是砍掉？所以，在这种情况下我们怎么做才能物尽其用呢？

我认为只要不是核心特色，其实都可以删掉。至于内容，只要有足够的内容来展示功能、创造有意义的体验就可以了——这很大程度上取决于产品本身，就比如冒险游戏和MOBA游戏，它们各自的内容需求一个在天一个在地。就如我在上一篇文章中说的，有的游戏注重机制，有的游戏注重内容，有些游戏比较均衡，所以你们内容的最低需求是多少，这得由你们自己决定。

我们之前在做一款无尽模式的VR动作射击游戏，它的核心内容就是：

1.一个关卡
2.几个核心系统
3.三个英雄角色
4.没有多人模式
5.四类敌人

但我们的最初计划并不是这样的。最初是设定12个英雄角色、3~5种模式、很多系统、跨平台联机、4大类敌人，每大类又分4种，还有5种关卡。我们逐渐缩小范围以便能实现目标，但是我们也没有把它删减到核心部分残缺，无法向目标受众呈现一个有竞争力、有意义的产品，连游戏都算不上。但这还不够，我们必须通过改变部分视觉元素来重新利用一些内容，我们必须更灵活地做事，想办法最大化利用手头的资源。我不能讲太多细节，但是你有很多办法可以减轻工作负担。为此，我建议你去了解这两个东西：WinRAR技术以及帕累托法则。

在下一篇文章里，我们将探讨在项目危急的情况下，你可以使用的急救解决方案有哪些，我将分享我们曾经的一些做法。

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

Fo-what?!

I think the best way to explain the true essence of focus is to quote Steve Jobs:

“When you think about focus, you think it’s about saying YES…. No. It’s about saying NO…”

It’s very important to understand this in abstract terms, philosophically, as it may become easier to understand the pattern and the flow of processes that channel through this issue.

Being able to focus is actually one of the most challenging things to do because there are a lot of temptations along the way to lose focus. Failing to focus and follow the plan by adding new features is called Scope Creep and is one of the most dreaded things that can happen during the development cycle. Nearly every studio in the world does this or has done it at some point one way or another. This process is very destructive for the following reasons:

1.Adding new features and/or content to the same roadmap puts the project in jeopardy.
2.Complex projects have extremely complex dependencies that are even more difficult to calculate. Adding a feature may have a domino effect and destabilize the game, and in pretty much every case it does.
3.More features mean longer hours, eventually leading to crunch.
4.Budget inflation or loss of quality standards.
5.Demoralizes the team.
6.Loss of Team Velocity
7.Product/Game Vision may be lost.
8.Missed Deadlines – Missed Projects

Who cares?

So how exactly is it destructive? How does the scope change contribute to these problems?

Team velocity is a very subtle and tricky subject. This is the speed by which you/your team executes the plan or any part of the plan. This is the first priority metric that helps you assess if you follow the plan. It’s how many tasks do you successfully execute per period of time, for example, a week, or a day. So, what’s so tricky about it? Everybody knows of its existence, few know of its importance, and even fewer know how it’s not the best indicator and advisor. Because no task is like any other. Also, the change of scope is invisible in this sense. Team Velocity is at its best when the team follows a plan without any or next to no changes to the plan/environment. Whenever the team knows what’s next beforehand – they can execute the task better, and if it’s a part of a recurring process, and not a unique task, even better. Any kind of disruption during the development is very destructive and temporarily impairs the team. This “plan” is a product of vision. Whenever the team knows what’s next, they are always able to prepare and take the hit.

Crunch – The dreaded situation, when all team endeavors escalate to a point where it’s impossible to sustain a work/life balance. Scope Creep inevitably generates Crunch. Besides the obvious reasons that we cover in this article, It’s also because on a tactical level there is much more work that has to be done as a product of scope change than is projected on a strategic level, by a mile, to say the least. It involves immense amounts of work that the team blatantly agrees to do. Crunch is devastating, as not only everyone deserves to rest, but everyone needs rest. Ultimately undermining all the creative potential of the team crunch is one of the worst things that can happen.

Team Morale is another important thing and is very fragile. Poor management can devastate even the most enthusiastic, creative, opportunistic, and competent teams in the world. Scope Creep means unpredicted change with a high chance of jeopardizing the plan and directly contributes to morale drops. There are many psychological reasons for that, but the most important is that people don’t like to be on a rocky trip while being blindfolded. Another one is that people want to have a competent leader who knows what he’s doing. This is why transparency and communication is also important. Any kind of unpredicted change most probably involves scrapping major chunks of the team’s work, and that is also a very negative experience, although it happens very often, for other reasons too.

Uncalculated Dependencies: Whenever you add or change something to a semi-developed system, you have to be very careful with what happens to the rest of your work, as you might break all hell loose by changing a system that is interwoven with other elements/systems for a short-term or ill-calculated change. This is something that is inevitable when you set out to change something in a complex system, but the degree of it is what matters.

Budget Inflation is a direct product of labor mismanagement; Uncalculated Dependencies impact some parts of your product that have been already developed, and now they have to be redone, sometimes taking much more time than it took initially, as navigating in a complex system is extremely difficult, something software engineers know extremely well. A more trivial example is when you increase the scope of the product, assuming that it is possible to execute in the same budget as initially calculated, which is, of course, an ill-informed assumption, to say the least.

Product/Game Vision is, in my opinion, the root of the problem which feeds itself when mishandled. If you have a clear vision of what you are going to do, then you also have a clear vision of how you are going to do it, in most cases. Whenever the vision is not firm or clear enough, that’s when everything starts to go downwards. You start to add things to compensate and end up undermining the game vision even more as you continue the same way down the road. This triggers a chain reaction which is the reason we explore this topic.

Missed Deadlines are missed projects. A project is a temporary endeavor, in order to generate a product or meet a goal in a set time period. Whenever this time period starts to slip away, the project slips away too. Scope Creep triggers a chain reaction that leads to this, and in most cases gets you into a loop, a vortex of endless delays, reschedules, re-budgeting, etc., to a point where it consumes all resources and shuts down.

But, why?

So, all of us have encountered this if we’ve made at least one project. But, it’s not obvious what brings us there, what undermines the benevolent force that pushes the projects forward and prevents us from finishing them on time, on budget, what triggers Scope Creep. In the previous episode, I’ve talked about what you can do to set up the project’s scope so that it has better chances of being delivered and is best fortified against Scope Creep. But it’s more important not to drift away from that, as you may set a scope properly, and ruin it during the development. So, what powers Scope Creep?

-Poorly Defined Scope – What to do, and NOT to do
·Poorly Defined Feature Set
·Poorly Defined Development Plan
-Disruption – Market Changes, etc.
-Lack of Scope Change Management

Poorly Defined Scope is what I’ve talked about and shared some insight on how to counter that in the previous episode. It’s important to start from a proper point with a clear scope. You can always come back to this stage if you have the time and the budget to do so. Redefining Scope is an extremely risky and responsible action. Sometimes it’s something that saves the project from certain doom, and most of the time – it’s something that brings it there. As I’ve said, it’s important to understand what is in the scope, but it’s more important to understand what is NOT. This is more important as it gives you explicit red flags for what’s an unacceptable development of events. If you have defined the scope of the game not to have an X feature, whenever you try to add something X or resembling X, you and your team members have better chances to identify a trap. If you don’t have this set up before going into development, nobody can stop you from adding something that doesn’t belong, because you have no agreements on what belongs and what doesn’t.

The features themselves have to be defined to the best of your ability and knowledge. Ideally, you’ve developed a prototype with the given features, and now you know exactly what it is going to be for your next iteration. You need to know what’s the feature you’re working on.

When a feature is abstract and not defined, you can’t tell if you’ve made it or not when you assume you’ve finished the work. Besides, you might not be able to have a clear idea of where to start in the first place. This already means you couldn’t define a schedule and a budget for it, most certainly. But not defining a feature, and not defining it well enough are different situations. The latter is when you’ve most probably been tricked into assuming that you’ve measured, budgeted and estimated a feature, and most importantly, delivered it. That’s why pre-production is very important as you have more chances to precisely define a feature and then make the plan for the development of that feature.

Ok, so the Development Plan is the plan for how you are going to implement a feature. It is the path between point A & point B. A development plan is much like wandering in a forest; you need reference points to triangulate your location to understand if you’re going in the right direction. Whenever you don’t know what you’re going to find during the journey, it’s much more probable you won’t get to your destination.

The Development Plan is also very important because when you have a decent one, you are much more effective in protecting yourself from mediation along the way. Whenever you feel lost you can always go back to the previous checkpoint and debug what went wrong and what to do next. When you don’t have one, or it’s severely weak, you wander around in search of the golden fleece, even though you might know exactly what it looks like. Investing enough time into planning the development in pre-production has a great impact on the final deadline, also. Wandering around generates uncertainty, even towards things that are truthful and well-defined, so it’s very dangerous to walk around without a map. Any action that doesn’t belong to the plan is easier to identify when you have a guide, and it is easier to seize unnecessary deviation.

Professional game development is a business, and involves money, one way or another. And inevitably we are in the same Market, maybe in a sub-market, but it’s all interwoven. One industry impacts the other, and creates a chain reaction, or a “butterfly effect”, if it’s a more convenient term. The modern market is extremely rapid, and changes occur on a daily basis. An immense amount of competition rages for the love of the crowd, and we are in the midst of it all. Whenever a big change occurs, the environment changes, and the market adapts accordingly. Adaptation demands mobility, quick wit and vision.

But not all have the chance to adapt, as we, most probably, already utilize all of our potential, energy, focus, and attention. Deep analysis and a business acumen might provide a better chance of predicting market change, but it’s not a guarantee by any means. Even though you might have an idea where things go, you might not have the confidence, the resources, and energy to outmaneuver the change. This is one of the things that are in some way beyond our control, as big sharks create the biggest waves in the aquarium. This is when we all start to waver, and panic fills our minds and impacts our decision-making process. The only remedy in these kinds of situations is to have a clear vision of your product/game. That’s important because then you understand what’s the target you aim for, and in case the target moves, you know what it looks like.

Before we get to the solutions, I want to talk about a very important topic – Scope Change Management. I don’t want to convey a wrong point of view that any change is bad. Some of the biggest and best hits involved big changes at some point. It’s not about not making a change, it’s about managing change. It’s all about responsibly dealing with change and adapting accordingly, be it changing scope, delaying a deadline, or any other change to the initial plan. What is important is that this is an advanced topic, and you should pay immense amounts of attention and a responsible attitude towards this.

Turning any change down is also destructive: any action that is directed towards you and/or your team reaching the goal, or following the vision, is a correct action. It’s not about being firm with the means to reach a goal, it’s about being firm in adherence to reaching the goal.

Scope Change Management is a toolset that you have to have to handle change. This has to generate a process that enables flexible decision-making on the basis of pre-defined, or continuously defined metrics that serve to assess if the change is necessary to reach the end goal. This is a funnel that tests if the proposed change is worthwhile and optimal. These metrics are different, depending on a game project and are aligned with the vision and the business goals. These goals have to be enforced, but the path to them has to be flexible. Having a protocol on what to do in many different situations is what constitutes Scope Change Management, this is what keeps the creative storm at bay, and provides you with a better chance to reach the set goals. Learn to agree & disagree on change, debate on change with visible and independent metrics, learn to request change approval from a higher manager, learn to propagate that decision so that the team doesn’t feel swamped.

Ok, let’s face the endboss.

Counterpunch

Situation I: You’re not guilty, it just fell.

Now, the initial scope planning was done to the best of your knowledge, it’s a bar you’ve set. Hence, you have to hold it there, and not let it fall. Just the moment you start the development, all hell breaks loose. You start to deviate from the plan, add something to the roadmap, lose focus, etc. Well, we have to defend the scope.

Step I: Just don’t do it.

You add new features along the way mostly, because:

1.You feel this will contribute to the overall game, or is cool.
2.You feel like this will not impact the schedule, you can fit it in.
3.You feel like the game is boring, or misses a feature, and you need to adapt.

The first one is the most common one, and it happens to all of us. What we need to understand is that even a single line of code, or a simple shader, or a little part of the map, or a little feature has cost. And, you’ve already allocated a timeframe, a budget to do all the rest, now you’re trying to smuggle a little feature in. You have to understand that you’re bound by time and by resources. And it’s just math. You can’t fit 7liters into a 4-liter canister. It’s extremely simple, but it is what it is. And, it might be simple, but it’s by far not easy. If you do understand all of this, the only way you can let a small, tiny feature smuggle in, is by being off-guard.

What I did with my team is, obviously, defined what our game is not about, and what we are not going to do. We wrote it down, and we all adhered to it. But, how do we cope with scope creep on a daily basis? Controlling the creative storm is one solution I was able to implement: whenever we had a new idea (and we had a lot, constantly, just like you do) we wrote it down and delayed the decision to a moment where we weren’t so emotional about them. And it worked as a charm. The general abstraction is: I try to create a lot of bureaucracy around these decisions so that I can filter the brilliant ideas from momentary, exciting ones.

Example:

- I saw a movie yesterday and I know our game needs this new feature. <…> explanation… <…>, argumentation… <…>, how it is just THE idea that will make the game exciting…, So, what do you guys think?

- Okay, that’s an awesome idea, but let’s talk about it next week at a meeting and decide what’s gonna happen with that.

So, what’s so important about this? We never say no, we just say, there’s this law, that we all agreed to follow, and if this idea passes the filter, we will do it.

“You are not your idea, and if you identify too closely with your ideas, you will take offense when they are challenged.” – Ed Catmull, Creativity, Inc.

What happens at this meeting, which is called Scope Adjustment Meeting is we have a list of some ideas and changes to the scope, that we have to talk about and try to test them with every tool we have at our disposal. If this idea survives the test and is justified, we do add it. But that happens extremely rarely, as most of the ideas seem awesome, and if they’re actually awesome, they seem fitting, and if they really fit, they seem executable in the timeframe we have. If the idea is actually extremely awesome, fits there and is creative*, we do work an hour a day more, but:

1.We do it extremely rare
2.We do it responsibly
1)We calculate the actual efforts that we have to put in, both time, brain, and cash.
2)We calculate most of the dependencies. (If not, we scrap it)
3)We calculate the risk of what happens if this goes terribly wrong. (If it’s too dangerous we don’t put the project in jeopardy)
4)We don’t add features that need more than 4 hours of planning and never do add features that have more than 5% deviation from the estimated delivery time frame.
5)We ask a lot of design questions, we attack the idea as hard as we can.
6)We do it only when we have already done that before.
3.IMPORTANT: We present the idea to the stakeholders, and try very hard to explain why it’s a good idea and what tests it went through.

Now, I want you to understand that these are not just placeholder filters so that you can smuggle any idea in whenever you see fit. This means these filters have to be so harsh, that only 1% of the ideas you have fit there, maybe. Let’s do the numbers, there’s a lot of ideas coming in, but you only review them once every 2 weeks, and they only have 1% of chance of passing. And, speaking realistically, they (the ideas) actually disappear just before the meeting, because at that point, we have already passed the “creative bliss” state, where we see everything in purple glasses.

*Creativity is not about having exciting ideas, it’s about giving non-obvious, effective solutions to a complex problem. It’s important to understand this difference in order to evade the common pitfalls.

Another lesson I’ve learned is that if the game you’re making is boring, one of these is, probably, true:

1.You didn’t prototype it before production.

2.You prototyped it but didn’t notice that your core features, game loop, game mechanics, and other core design elements aren’t good enough and you tried to cover that up with secondary mechanics. Still didn’t test it after this assumption.

3.Tested the mess you’ve made, and thought that the sole reason for it being boring is VFX, 3D assets, UI, Audio, etc.

4.It’s just you who thinks it’s boring, and not the target audience.

(2) & (3) are very widespread; Adding secondary mechanics and content to a malfunctioning core is something everybody tries to do. That’s because you don’t want to part with an idea, even though your implementation or the interpretation isn’t sufficient enough to make that idea compelling and engaging. Or, in some cases, the idea itself isn’t aligned with engagement and is boring. That’s when you have to say goodbye or reiterate until the core works, but never cover it up with flashy special effects and emotional epic scores. One of the worst parts of this is that the more you cover it up by building on top of a weak foundation the less visible are the ill elements you have to take care of.

Situation II: New Year New me

Market changes affect our work immensely. Sometimes, projects are canceled altogether, because they aren’t relevant anymore. And sometimes, we have a short period of time to change the fate of the project by steering it away from certain doom. This also includes budget shortcomings, such as lack of resources to finish the project in the planned timeframes.

This is when we find ourselves in front of a dilemma: cancel it, or cut it? So, what can we do to get the most out of such situations?

I believe that every single bit of the project that is not one of the core features, can, potentially, be cut. Regarding the content, just enough content to showcase the features and create a meaningful experience is up to you to define, and it heavily depends on the product; If you’re making an adventure, that’s one thing, if you’re making a MOBA, that’s another. As I’ve said in the previous episode, there are mechanics-heavy games, content-heavy games, and a little bit of both, so it’s up to you to define how much content do you need at a minimum.

We’ve been making a VR action shooter game with an endless mode, and our core content was:

1.1x level
2.A couple of core systems
3.3 heroes
4.No multiplayer
5.4 enemy classes

But it wasn’t the initial plan. The initial plan was to have 12 heroes, 3-5 modes, a lot of systems, cross-play between different platforms, 4 sets of 4 enemy classes, 5 levels. We gradually cut our scope to be able to hit the goal, but we didn’t cut it to a degree, where we wouldn’t be able to call it a game, to enjoy the core premise, and to present a competitive, meaningful product to the target audience. But it wasn’t enough, we had to re-use some content by adding some cosmetic differences, we had to be smarter with what we do ourselves, and what needs to be delegated to preserve precious time. I can’t go into details, but there are a lot of things you can do to optimize the workload. 2 things I recommend reading to understand the abstraction: WinRAR technology & Pareto method.

In the next episode, we’ll explore what are the last resort solutions you can apply to a project that is on fire, and I’ll share some of the things we did with our projects.

(source: gamasutra.com )