游戏邦在:
杂志专栏:
gamerboom.com订阅到鲜果订阅到抓虾google reader订阅到有道订阅到QQ邮箱订阅到帮看

万字长文,团队文化建设如何影响和改变企业的最终战斗力,中篇

发布时间:2015-09-18 09:47:27 Tags:,,

篇目1,解析消极开发者对于团队的影响及解决方法

作者:Lee Winder

当我们一开始进入一个团队时并不会产生太多消极情绪,但是当我们努力去发展一个团队并开始鼓舞团队士气和斗志时,这种消极情绪便会一点一点渗透出来。以下内容并非对于世界各地开发团队的深度研究,而是我在过去10几年来通过管理和观察各种团队所获得的经验教训。

当我们着眼于一个团队的构成时,它总是会包含一些能够有效完成游戏创作的人以及某些会糟蹋了整体游戏的人。任何一个项目开发总是会汇聚一些个体,然后询问他们是否愿意为了达到一个共同目标而暂时一起工作。而这些不同个体所具有的不同个性有可能会促就一款成功的游戏,也有可能会彻底毁掉一款游戏。

很明确的一个现实便是,比起使用各种有效的方式去完善团队,任何个体总是能够更加轻松地摧毁一个团队。也就是消极性总是能够以燎原之火般的速度在团队中迅速蔓延,而积极性却如糖浆一般难以扩散。

negative(from robertfagan.com)

negative(from robertfagan.com)

这是为什么?

工作中的个体总是更容易产生消极态度。消极做事,大谈团队的坏话甚至是破坏游戏的行为总比创造更多优秀的内容,对自己的工作负责,走出一个定义清晰的角色或完成任何有意义的工作简单得多。

消极开发者的定义是什么?

开发者将会以多种不同的方式带给一个团队消极影响。最明显的便是他们对于当前项目所持有的态度,如无端的抱怨,莫名地推脱工作要求或在上班时间偷懒等。

他们可能在开发过程中未能呈现出更多技能,或影响了开发产品的质量。

有时候这些开发者的态度并不能体现出团队所追求的精神。也许你要求开发者对自己的工作(游戏邦注:包括设计与执行)承担更大的责任,但是某些开发者却只会执行上头所交付的相关工作。

可能开发者并未参加日常会议,或者只是含糊地陈述了一些观点,并明显透露出对别人工作的毫不关心。

不管怎样,我们能够很容易明确开发者的消极态度对于一个团队的影响。这也是我们在开发过程中最难处理的一块领域。

团队开发

让我们通过一定的情景进行分析,绿色代表“积极”开发者,红色则代表“消极”开发者。

在第一种情景中,两位开发者将并肩工作,一名开发者表现良好,而另外一名则没有多大成效。也许其中一名开发者是抱着消极的态度,也许他只是不想争取更好的结果。不管出于何种原因,他对团队所做出的贡献始终都不如积极开发者。

developers(from gamasutra)

developers(from gamasutra)

大部分情况下,这种情景只会促成一种结果。积极开发者在看到搭档总是逃避工作并且未投入足够的努力后,他便也会慢慢产生怠倦心理,并逐渐变成消极开发者。

通常情况下消极开发者并不会因为看到积极开发者的辛勤工作而转变自己的态度。所以最终你便只会同时拥有两名消极开发者。

developers(from gamasutra)

developers(from gamasutra)

什么情况下态势才会发生改变?什么时候消极开发者才会认清事实并开始努力发展游戏?我想这些答案都不会有多大的激励效果。

以下是另一种情景:

developers(from gamasutra)

developers(from gamasutra)

这是一种较为平衡的情景,但是同时开发者也更容易忽视产品的质量而不是想办法去完善它,即他们很容易走上错误的发展方向。

developers(from gamasutra)

developers(from gamasutra)

基于各种观察,你最终获得好结果的比例为3:1,但是这仍是一种具有风险的方法,因为当积极开发者开始出现态度转变时,这一比例将重新回到之前的1:1。

developers(from gamasutra)

developers(from gamasutra)

如果你所拥有的积极开发者和消极开发者的比例为4+:1,你便需要努力确保其他开发者不会出现态度动摇的情况。在很多情况下,消极开发者并不能凭借自己的力量做出改变,其他开发者也不会因为比自己更优秀的开发者所带来的同侪压力而发生改变。

developers(from gamasutra)

developers(from gamasutra)

积极开发者

但是不管是面对何种情景,我都不敢保证积极开发者始终都能够带给团队积极影响。优秀的开发者并不能轻易放松,他必须更加努力地工作,不断创造出更优秀的内容,并带着更大的雄心而发展。

让我们再看看以下的情景:

developers(from gamasutra)

developers(from gamasutra)

这些开发者之所以优秀都是有原因的,要么具有较高的个人自豪感,要么具有较强的野心,或者是纯粹地享受着工作带给自己的乐趣。而如果优秀的开发者长期待在一个满是消极开发者的空间,那么最终结果也是可想而知了。

developers(from gamasutra)

developers(from gamasutra)

如果积极开发者处在一个充满了消极开发者的工作环境中,或者积极开发者很难在此感受到真正的推动力量,他们的态度便会很容易出现动摇。而一旦你失去了更多的积极开发者,你便会发现有越来越多开发者意识到自己不再有积极工作的必要了。

解决问题

面对团队中的消极开发者主要有两种方法。第一种方法较为强硬,但是如果你身处的区域具有健全的劳动法,你便不适合使用这一方法。

即辞退这些开发者。

developers(from gamasutra)

developers(from gamasutra)

老实说我并不推荐这种方法。因为这么做虽然能够解决问题,但是却会在团队中留下一些漏洞,你之所以会雇佣这些开发者肯定是出于某种原因,那么你何不尝试着去找回他们身上的这些亮点?

而组织内部的执行管理结构(如果使用得当的话)不仅能够解决这一问题,同时还能帮助消极开发者重新正视游戏并努力成为团队中的佼佼者。

明确问题的来源。是因为开发者不喜欢游戏还是他们在工作以外的时间遇到了某些困难,是因为他们不认可上司的工作分配还是他们根本不想待在这一团队中?

基于这些回答,你才能采取更合适的应对方法。。

明确目标。设定那些能够扭转局面的目标,不要只是设定好便不再搭理。每周或每两周去审查目标的的落实情况,设定一些短期目标与长期目标形成互补。

设定一个明确的截止时间。不要因为一些微小改进而不断拖延时间,只有明确的截止期限才能让你更加重视自己的工作。

明确最终结果。不管他们是否有机会去尝试其它工作或者只能终止合约,你都必须让团队成员清楚在完成目标或错失目标时会出现何种结果。

保持稳定的记录。记录下每次会议的内容,并且每天去记录所有目标的发展过程或最终结果。

辞退他们。尽管这么做较为残忍,但是如果你所采取的任何方法都没有成效,你便别无选择了。如果你一直在尝试着解决这一问题但是开发者却对此无动于衷,你便只能采取这一方法了。

在健全的劳动法律条款下,如果你所遵循的是绩效管理策略,你便可以在改造开发者无效的前提下与之解除合约。

消极开发者的消极性是基于他们对于团队目标的影响,以及对于其他开发者所带来负面影响。消极态度的蔓延速度总是会大大超出你的想象,并且将会导致你的团队中的其他人拉低了自己的真实能力标准,或最终选择离开团队。

篇目2,总结开发者在合作过程中的典型交流方式

作者:Cliff Bleszinski

到今年夏天,我从事职业游戏设计就到第20个年头了。我曾领导团队设计平台游戏、FPS、单机游戏、多人游戏等等。我曾和一些最令人叹服的程序师、美术人员、动画师、写手和制作人共事。这20年以来,我注意到创意人员经常使用的交流方法。

我知道虽然开发人都非常高明,但有时候他们并不敢肯定与同行相比自己能有多聪明。我曾看到开发者在留言板上对百万美元的游戏大作、独立游戏宠儿等过度分析、吹毛求疵。我们总想证明自己比其他人有先见之明,或者引用一个例子,说明那个创意已经被尝试了、能成功、会失败或行不通等。

开发者们为了“赢得”得谈话,经常会使用一些讨论、争论和辨论方式。本文要介绍的就是这些常用手段。

以下说法和绰号没有恶意地针对谁;事实上,有几个方法确实是因为有理有据才被使用的。例如,样式对比可以避免制作出派生产品;边界案例有时候可以抹杀可靠的想法。以下就是我所谓的交流“技巧”。

“样式对比”

这是指开发人为了否绝一个创意,立刻在他的头脑中检索他的游戏/流行文化库,然后找出最接近的想法作为比较对象(常常是糟糕的或失败的案例)。

以《阿凡达》为例,“你想制作一部关于蓝皮肤的人在丛林中对抗坏人类的军队和机器?什么,蓝精灵丛林大战外星人?”不恰当地类比,《战争机器》可以看作是80年代的低级恐怖电影《C.H.U.D》(游戏邦注:在电影《C.H.U.D》中有一种生活在城市底下的基因突变人,以食人肉为生,而《战争机器》中也存在类似的怪物)。

“边界阻塞”

这是指用一个边界情况来否绝可能很了不起的想法。例如,举出边界情况的人可以否定在《天际》中创造一个大世界的想法,因为担心玩家要走回原来的地方,且步行太老套。清楚明确的修改方法如“快速旅行”的可以轻易地解决这个大世界问题。

边界阻塞有变体:

“交际人”:这是指因为某个想法在边界情况或特定的合作模式中不成立就否决它——这是边界阻塞的变体。“《英雄本色》的慢动作怎么可能在合作模式中起作用?不可能!”

“完美主义者”:类似于边界阻塞。这是指开发者发现在某种情况下,一个很不错的设定可能看起来并不完美。比如,格斗动作有时候会导致角色发生微小的变化。

“从来没见过做得好的”

这句话的意思也就是“我以前从来没见过这种想法行得通或做得好的。所以,我们不应该这么做。”这是一种相当不言自明的论断,事实上,这也可能是为什么应该执行某个想法的理由。按这种逻辑,所有创意都只能是雷同的。

比如,在《战争机器》中设定了一种生活在地下的Locust人,这个设定行得通的原因有很多,但我们仍然对它持保留意见。毕竟,这个设定使该游戏从其他带有常规外星人的游戏中脱颖而出。

“故意唱反调的人”

为了保全颜面,大多数开发人经常故意唱反调,甚至在他们自己也相信这个想法时候。律师经常使用这一招。

“不过是X+Y罢了”

这是指开发者怀着酸葡萄心理贬低其他成功的作品,因为他可以轻易地看出其中的原理。事实上,正是因为游戏原理非常简单明显,才使游戏如此成功。

例如,《Words with Friends》:“不过是异步拼字游戏罢了。”是的,正是如此,所以它成功了。

“以后再说”

当开发者听到一个想法——无论好坏,就说这个想法很适合之后的版本或续作。这句话的真实含义是,“我认为这个想法不值一试,所以我们放弃吧,我说以后再说是为了让你不难受。”

tower of babe(from gamasutra)

tower of babe(from gamasutra)

“通天塔”

这是当开发者在一个本来很简单的设定上堆砌太多额外的小东西时,但这些小东西最终危及整个设定。这座“通天塔”是被自己的重量压跨的。

“雪崩效应”

之所以用这个方法否绝一个想法,是因为这个想法需要许多其他部门(游戏邦注:如动画、UI或美术)做更多工作。通常,有趣或值得尝试的特点都会牵涉到更多部门,因为涉及多个学科的知识。

“过度分析”

这个常用的词是指过分考虑某个想法,以致于一事无成。

“试什么试?”

换句话说,“我们怎么跟别人比?”因为在某个方面面临激烈的竞争,开发者就这么问,以免尝试。

“他们有N个开发者啊!”

当开发者说到某个竞争团队的规模有多大时就会这么说,说完这句话以后紧接的就是上面那句。为了高效地工作,Epic公司总是让最好的人从事同一个任务,用最好的工具。

“保守主义者”

“但是我们一般都是这么做的啊!”在娱乐行业,特别是与技术有关的行业,为了生存,创意和反思是非常必要的。自满和墨守成规必然导致失败。

在某个常规行业工作20年可能是个优势,但在技术行业,这可能会成为你的绊脚石。作为开发者,越要保持眼界开阔,要活到老学到老。

“但我们是XXX(“XXX”指工作室名称)

当工作室准备将自己的名誉押在某个项目的成功上时,就会发出这样的战斗口号,还自认为很强大。当工作室的人这么说的时候,你就知道这个工作室离内乱的日子不远了,因为更年轻的新员工满怀梦想,总是想取代老员工、创造新的辉煌。

“我们以前就试过了”

为了否定旧想法的替代方案(可能行得通),就提出以前尝试旧想法失败的经历。

“太先进了”

你的想法太棒了!事实上,这个想法太前卫太创新了。所以,我们不应该尝试,因为听起来挺费功夫的。

“按我们这行的话说……”

这是指,为了在争论中占上风,开发人抛出只有他自己专业的人才懂的术语,使不同专业的其他开发人不知所云。例如,程序员用代码的原理跟美术人员讨论,设计师用设计行话向动画师解释。

“部落首领”

当开发人固执地信仰自己的专业(美术、编程、设计等),而排斥工作室里其他专业的人的见解。

“不在范围之内”

“这个想法很好,但不在我们的项目范围之内。”很不幸,有时候,最好的想法不会在原本的计划之内。

“测试把戏”

开发人为了否绝某个新设定、新武器,就强烈建议“和谐”它,他的方法是在测试时变更它,这样游戏就按着他的思路设计了。有时候,人们为自己的想法付出了很多努力,结果却被别人破坏了,遇上这种情况,看开了就好。

“学舌”

这是指一类人,他们听到你的想法,反而像从来没听过似的,用自己的话把你的想法当成自己的说出来,还忘记自己是从哪听到这个想法。这从根本上说没什么大不了的,只要这个创意行得通就行了。

“长篇大论”

这类人用三页长的邮件回应设计建议或讨论。

每次都是这样,最终,你得为这个人设一个专门的文件夹。

e-douche(from gamasutra)

e-douche(from gamasutra)

“邮件盲”

这类人在邮件方面似乎总像个彻头彻尾的傻冒,即使他们并不是故意的。

“哥拉斯”

因为主观地认定一个想法不好,这类人莫名其妙地就叫停所有进程,提出自己全新的想法,最终所有人都不得不重新开始。

“怀疑论者”

这类人没有任何明确的理由就拒绝一个想法,他们的说法是“对此,我不知道……”,却往往很管用。

the prophet(from gamasutra)

the prophet(from gamasutra)

“先知”

这类人对一个想法怀有一时的冲动热情,但从未站在设计或其他学科的角度考虑它。这类人单纯地希望所有人都相信这个想法会成功,而不是根据它做出原型。这往往是年轻的、没经验的设计师的举动。

“亚哈船长”(游戏邦注:这是小说《白鲸》中的人物,固执地想找白鲸复仇。)

这类人拒绝承认某个想法行不通,同时不断地尝试,不惜浪费珍贵的代码和美术资源,妄想有一天,这个想法会成功。

“数据控”

这类人出现的情况是:“这个表格中的数据客观公正地表明,你的想法永远不会成功,你会使很多人不愉快,这个方向我们不能走。”

“精神期望”

这是指一个程序师拒绝理解被提出来的设想,直到这个设想以程序师自己想的方式被要求执行时。

“无视”

这类开发人有意(或无意)地忽略可能会成功的想法。

“事不关己”

这类设计师口口声声说想要创意,听了别人的想法后又默默地忽略任何不是他自己想出来的东西。

the gardener(from gamasutra)

the gardener(from gamasutra)

“园丁”

园丁早早地种下了想法的种子,然后多次在会议上提起,甚至与他人闲聊时也不忘说上一句。最后,这个想法开始在其他人心里生根发芽,直到它成为游戏中的一部分,都没有人记得这个想法最初是从哪冒出来的。这确实是个实用的技巧。

“漏洞仔”

当进程中出现一个设定,设计师不考虑这个设定的目的或作用,只顾着指出明显的错误,而这些错误显然是最终能解决的。

multi boss(from gamaustra)

multi boss(from gamaustra)

“多个头领”

当一个人没有明确的顶头上司,不知道该听谁的发号施令时,他往往会听从多个人的指挥。设计总监、执行制作人和董事可能各有自己的观点,让没有明确上司的员工感到困惑不堪。

“打包票”

这个词是指发言人向媒体承诺某个设定,让团队不得不按他放出的话来做。

“随大流”

创意人员看到最近游戏的游戏中有什么,他就采纳什么,心想这样就可以做出好游戏,也省了想法子创新。

总而言之,以上就是我这些年见识过的开发人的个性的交流“技术”。多谢了在Epic、ChAIR和People Can Fly的同行们为我提供的材料。我希望有远见的开发人可以意识到这些问题,并相应地改正。我也希望此文能让博得创意人员的会心一笑。

篇目3,如何消除游戏开发过程中的浪费

作者:Harvard Bonin

最近我们在网上经常会看到许多在一般软件开发时很受欢迎的项目管理技术,但它们却很少用于游戏创造中。尽管Scrum已经有力地推动了游戏制作,但是还有许多技术仍然被忽视。这是一种不幸的情况,因为来自传统和敏捷方法的其它方法也能够应用于我们的产业中,并帮助我们创造出一些正面的结果。

在本文,我并不会详细解释精益六西格玛。相反地,我将专注于精益六西格玛的核心原则并分析如何将其应用于我们每日的游戏开发中。

精益六西格玛

Lean Six Sigma(from baidu)

Lean Six Sigma(from baidu)

精益六西格玛是名为“精益”和“六西格玛”的两种项目管理技术的结合。

精益:专注于在所有活动中有效地传递消费者的价值。任何不能为消费者添加价值的活动都必须果断删除。

六西格玛:专注于从过程中删除所有瑕疵和变量。

换句话说,这两者都是为了消除一些“浪费”。在精益六西格玛中,浪费被定义为“muda”。这是一个日文单词,意味着“无价值的;无用的;闲置的;多余的;废弃的;消耗的;浪费的。”浪费可以以任何方式出现。停工时间,重做,不匹配的功能需求,过度交流等等。精益六西格玛明确了8种类型的浪费(有时候是7种)。

精益六西格玛中存在许多潜在的理念。完整的开发项目是围绕着这一框架中的技术,等式和工具而尽心,但是因为内容太泛了,我们难以在本文中进行探索。如果你进一步探索的话可能会注意到许多理念直接应用于制造业中。同时其核心原则也对游戏制作带有直接且正面的影响。

为什么会出现浪费问题

根据我的经验,浪费元素是团队最大的焦虑来源。最重要的便是浪费时间。在所有领域中努力清除浪费是制作人和项目管理者必须拥有的一种心态。许多制作人认为他们的主要角色便是领导整个项目。他们认为自己就像骑着马位于军队最前方的将军一般,朝着敌军方向挥舞着剑并高喊“冲啊”!也许他们的角色带有这样的元素,但这却是非常有限的。一支带有经验的团队可能已经知道如何有效工作,而制作人如果想有效利用时间就必须专注于如何避免浪费而不是引导着团队朝目标盲目前进。有时候制作人必须让团队做其最擅长的事并花时间去消除阻碍发展的内容。

两大不可饶恕的罪行

在我的职业生涯中,我曾经遇到许多充斥着问题的项目。实际上,我的所有项目都是困难重重。当完成这些项目时,团队经常会转向事后检查并照亮制作过程中引起的许多问题。最频繁且最具影响的关注点通常是围绕着“交流问题”和“偏差的期望”。

交流问题:团队经常会抱怨他们不知道项目的目标,日期,各部门的任务或管理者的期望。这一问题似乎会出现在每一个项目中。幸运的是我们能够通过纪律,技术和透明度承诺轻松解决它。最重要的是,制作人和项目管理者必须清楚这一问题,因为这是浪费时间的主要根源。

偏差的期望:当创造功能,图像,代码等等内容时,在“完成”的定义方面,管理层和内容创造者总是不能实现同步。这种矛盾将导致更频繁的重复劳作。产品拥有者,利益相关者和所有者(游戏邦注:创造性控制的唯一来源)都必须清楚地与所有内容创造者进行沟通。

这两个问题间的共性就是“浪费”。它们都有可能导致时间的浪费。时间是产品开发中最有价值的资源。因为精益六西马格是关于消除浪费,所以它将能够有效应用于游戏开发中。

TIM WOODS:8种类型的浪费

在精益六西格玛中有8种类型的浪费。

以下是一些学术定义:

T—-转移:移动人们,产品和信息

I—-库存:储存零部件,组块,需求文件

M—-动作:弯曲,转向,触及,提升

W—-等待:为了零部件,信息,只是和设备而等待

O—-生产过剩:创造出超过需求的内容

O—-国度加工:更严格的容差或更高级的材料(超过标准)

D—-瑕疵:重做,废弃,错误的文件

S—-技术:未充分使用的功能,删除未充分训练的功能

来源:http://www.isixsigma.com/dictionary/8-wastes-of-lean/

想想你自己的每日游戏开发体验。这些对于浪费类型的定义是否能够帮助你揭露项目的低效能?以下是一些例子:

转移:资产转移是否花了太长时间?是否存在创造时间太过冗长且带有瑕疵?

库存:是否投入了太多时间于隔天就会改变的冗长的设计文件中?是否存在太多范围外且会导致团队分心的未修剪理念?

动作:环境的设置是否会阻碍交流?致力于高度迭代功能的人们是否坐在一起?工具是否容易使用且有效?他们的工作空间是否有利于高效工作?

等待:团队是否不断地等待着其它部门完成工作?他们是否经常出现空闲?

生产过剩:美术师是否创造出不符合最终要求的资产?这些资产是否有用?在明确要求前某些部门是否早已赶超其他人?

过度加工:是否创造出比要求更加详细的资产?他们是否过度优化那些对消费者没有多少意义的功能?

瑕疵:代码是否伴随着漏洞?是否是可扩展的?最终工作是否与预期相匹配?资产的创造是否匹配引擎功能?他们的工作是否符合预期标准?

技术:任务是否与团队成功的技能组合相违背?PHD是否致力于GED能够完成的任务?或者相反?

TIM WOODS:应用

理论和概念很棒,但是它们没有多少好处,除非能够应用于开发过程中的实际活动中。以下是我的特定游戏列表(未完成的),团队们可以将精益六西格玛整合到其中并尝试着去消除浪费。没有任何方法能够解决所有的项目问题,但是如果将其全部整合在一起便能带给开发团队巨大的帮助。当然了你也可以添加更多内容。

进行每日站立会议:尽可能简短,10至15分钟的站立式会议非常有用。这能够促进成员间频繁的面对面交流,并且不需要耗费太多时间。较少且不准确的交流便是一种浪费。

用风险会议取代每周制作人状态审查会:在每周的状态审查会中,所有人将围绕着一间屋子提供一些更新内容,这是一点帮助都没有的。在定期的交流和报告中,成员们已经了解了相关信息。我们需要的会议是每个制作人能够提出他们的前三个项目风险并向群组请求指导。无用的会议是一种浪费。

在实体项目空间突出张贴目标/日期/价值等内容:渗透式交流能够确保所有团队成员都能够清楚项目的宏观目标。通过贴海报等方式去帮助团队成员牢记目标。面对面的交流是最有效的迭代方式。制作人必须采取任何机会向团队成员和利益相关者传达目标期待。不统一的团队成员会创造浪费。

坐在附近的人能够致力于高度迭代且相互协作的功能:团队成员致力于统一的功能,特别是未知且具有探索性的功能对于他们的成功很重要。避免他们无需走太多路便能够与同事进行沟通。功能越陌生,他们越能近距离共事。较少的交流将会创造浪费。

面对面频繁地交流转折点和项目目标:在墙上张贴目标和价值虽然很有帮助,但面对面的交流更加重要。为了得到一封电子邮件的回复可能需要花费1天以上的时间,但面对面讨论将是实时进行的。制作人和产品拥有者必须把握任何可能的机会向团队成员和利益相关者传达目标期待。通过电子邮件或聊天工具而造成的交流延迟便是一种浪费。

频繁地交流创造性目标:与截止日期一样,我们必须持续地分享创造性目标。通常情况下,“完成标准”是取决于创意总监或产品拥有者。他们必须频繁分享自己的要求。误解创造性目标将会创造浪费。

确保所有内容创造者都清楚完成标准:产品拥有者的一个主要角色便是传达他们对于功能的创造性要求和指令的期待。更快地做出慎重的决策很重要。我始终都坚信着美国海军陆战队的:70%规则。如果你认为你的计划拥有70%的可行性,你就必须尽快地去执行它。如果它是错的,你则可以不断地调整它。我曾与许多不断等待着“完美”计划的创意总监合作过。纸上谈兵只会创造出浪费。

在所有相关项目中推动透明交流的价值非常重要:我曾经待在一些牢牢握着项目核心数据的公司。他们总是认为团队不能处理坏消息或者他们会失去一些人员。但是公开与诚实不仅是一种道德,同时也是一种良好的商业意识。团队必须获得最佳信息才能帮助自己更好地朝着目标前进。在大多数情况下保持秘密是一种错误的做法,将有可能引起团队的反抗。糟糕且极少的交流会创造浪费。

优化价值流:项目管道可能是项目中最大浪费的创造者。内容创造者必须能够尽快地回顾并迭代他们的工作。破损的结构,较长的资产转移都有可能限制团队完成工作的能力。较长且破损的价值流可能创造浪费。

鼓励内容创造者去呈现临时工作:没有人喜欢呈现未完成的工作。他们会认为评论者不会理解它最终会变成怎样活着他们会因为一些不相干的问题受批评。创造者和评论中必须创造这种信任。频繁地评论迭代工作将能够消除重做(浪费)。呈现临时工作也能够避免浪费时间。等到工作完成后在呈现出来将会创造浪费。

尝试着消除创造性评论会议所创造的重做:这一点与前一点相似,然而理想的情况是没有任何来自“官方”创造性评论会议的重做。这些工作应该在评论会议前便接受过评论和修改。评论会议应该是官方的“许可证”,而不是探索创意总监全新理念的会议。在我所致力的每一个项目中,内容创造者都会抱怨工作的评论时间太长了。这不仅会创造时间的浪费和重做,这对于所有参与者来说也是一大挫折。产品拥有者必须删除评论,真正相信团队成员。为了这么做,他们必须能够清楚传达要求和他们的期待。源自少有的创造性评论的重做将会导致浪费。

流线型化或删除会议:如果你的团队觉得会议无用,有可能是你未能有效地组织会议。你可以找到许多关于如何有效运行会议的内容。你必须准备好适当的会议议程,特定问题等等内容。人们都不是很喜欢会议并觉得它们只是在浪费时间。制作人必须学习各种关于组织有效会议的方法。会议应该是关于解决方法的集合,而不是重申所有人都清楚的内容。无效的会议只会创造浪费。

适当的环境下使用反挖掘代码是有帮助的:并不是代码的每一部分都必须带有完美的架构。有时候团队将通过亲身体验一个功能获得更多好处,即使潜在的代码很混乱。玩家经常在敏捷的状态下遭遇失败。这意味着团队必须快速创造原因,如此他们便能够尽快地进行迭代。反挖掘代码将能够帮助你更快地获得一个实例功能。在功能被熟知前进行过度的设计和大量的系统创造可能导致浪费。

追踪并解决开放式问题:团队必须不断追踪围绕着项目的开放式问题。应该优先解决带有最重要引擎和期望值的问题。消费者最期待的功能应该被放置在最前方。开放是问题是项目的风险来源。

专注于消费者的需求:团队必须保证他们是在为消费者创造功能,而不是自己。未能与消费者需求相关联的活动必须被删掉。有时候人们会喜欢致力于自己所喜欢的项目,而不管终端用户的价值。致力于与项目最终目标无关的功能只会创造浪费。

KAIZEN(改善)

最后,制作人的最大责任便是继续探索保证项目顺畅运行的方式。Kaizen也是一个日语单词,即关于持续完善内容。制作人,产品管理者,利益相关者和内容创造者都必须不断寻找完善他们工作工程的各种方法。这必须实践于所有项目中,如此结果才会在不断的迭代中得到完善。

结论

就像之前所提到的,精益六西格玛是包含图表,等式,方法和技术的一个综合型框架。团队只需要理解获得利益的原则便可。这不只是一个框架,还是一种心态。浪费是项目杀手。寻找方法去消除浪费是所有团队都必须具有的一种心态。

篇目4,沟通也是一种重要的游戏开发技能

知道如何开口和有效写作与知道如何编程、使用Photoshop、遵守设计流程、创建关卡、作曲或者准备音频一样重要。这些都是某人在准备好将沟通这种技能呈现给团队之前所需要学习的技术,需要掌握的概念,以及需要完成的练习。

游戏开发者尤其如此

当然,世上人人都需要沟能,并且可以从中获得更多益处。但我们为何专挑游戏开发者来讲?

我并不是说只有游戏开发者才存在沟通问题。但根据过去十年与数百名计算机科学系的学生、独立开发者以及专业软件工程师打交道的经验,我可以说我所遇到的游戏开发者普遍存在一个特定的沟通问题。这也是我们所面临的一个特殊问题,因为这并不单关系到一天的工作是否顺利,我们的沟通能力还会对我们是否能够合作甚至是独立完成工作产生实实在在的影响。游戏开发者通常为自己的工作而兴奋,但无论是因为技术局限性还是因为沟通局限性而导致某些很棒的功能无法实现,那都会让游戏遭殃。

分清工作职责

如果程序员负责编程,设计师做设计,美术人员做美工,音频能力制音频,这里会有相同的沟通角色吗?

当然,甚至还有好几个。

制作人。即使是在小型业余爱好者或学生团队中,这通常也会由其他角色所包揽,制作人专注于团队人员之间,以及团队成员与外界的沟通问题。有时候这项工作会被误解为分配安排,但要制定这种分配计划则需要大量的交流和邮件往来,以及让所有人都处于同一轨道的持续沟通。

设计师。设计师在游戏开发过程中的角色之一就是通过游戏与玩家沟通。指出游戏目标是什么,哪些内容会对玩家受害或者受益,玩家下一步应该去哪里,从而传达游戏的内部状态信息——这对游戏设计的影响远大于编程。根据游戏团队的技能组合情况,某些情况下设计师与游戏的直接工作就是关卡布局或数值调整,如果大家的工作互有交集,设计师与程序员、美术人员及其他人员的沟通交流更为重要了。在一个人担任多个角色的小型团队中,沟通就成了让其他人知道游戏状况的一个必要环节。

主管。在一个拥有主管的大型团队中(常见于专业团队),主程序员,主设计师或主美术师还得具有出类拔萃的沟通才能。这些人并不一定需要是最出色的程序员、设计师或美术师——虽然他们当然需要具有这方面技能,但他们是因为能够有效领导他人而身居高位,而这又涉及所有方向的大量沟通:与上级、下级之间的沟通,甚至协调上下级和他人之间的沟通。

文案:并非所有游戏题材都需要文案,但对于那些需要写作内容的游戏来说,沟通就显得更为重要了。与那些并不身兼程序员一职的设计师相似的是,除了一些实际对话或其他游戏内置和插页文本之外,团队中的文案通常并不直接创造多数内容或功能。会写一些东西并不能算是称职的文案,文案和内容创造者还应该同他人频繁交流,以确保执行效果与自己所想象的世界完美融合。

非开发角色。这一切只考虑到了开发过程中的团队内部交流。学习如何与测试人员、玩家或者项目消费者和潜在新雇员(这里甚至还忽略了投资者和财务专业人员)更好地交流,则是另外一个巨大的挑战,如果团队规模够大的话,你还得同人机互动专家、营销专家、PR人员以及HR员式沟通。如果你是一名业余爱好者,学生或独立开发者,你就得自己扮演好这所有的角色。

我们通常遇到的沟通问题有两种。虽然它们看起来好像是两个极端,但实际上这两者之间并没有看上去那样泾渭分明。在特定情况下,其中一者甚至可能从另一者演变而来。

Interpersonal-Communication(from onetechgeek.com)

Interpersonal-Communication(from onetechgeek.com)

挑战1:羞怯

首个问题就是我们有些人比较害羞。我所遇到的一些极具天份的程序员、设计师、美术人员和作曲家就是害羞的人。这实际上会限制他们的创作——如果他们无法大声说出自己的想法,就可能给游戏、团队或者公司造成损失。

不幸的是,我们很容易为害羞找到借口。毕竟,这些有才华而害羞的人之所以能够发展自己的专长,就是因为他们能够远离喧嚣,独善其身地修炼自身本领。但遗憾的是,这种想法不利于帮助他们和团队从中获益。

团队成员之间的交流在游戏开发过程中的作用不容小觑。有时候你得在3D Studio Max上完成工作,有时候又需要拿出来大家一起讨论才可能完成工作。

我发现害羞的另一个因素在于,人们知道自己所在领域的出色之处,他们总能看到自己的工作要达到自己的预期,还有很大改进空间。

一个人在所在领域的人群中处于什么地位并不重要,重要的是项目中的开发者比其他人更清楚其中的不同之处。由于大家的专长、兴趣和背景各有不同,所以这就难免会成为一个问题。

挑战2:避免争执

有时候害羞看似由于过去不太成功的互动而形成的过度补偿。有人想开口来分享自己的想法,补充他人的观点,但却遇到了伤害,也没有取得什么成果。参与讨论容易让人们激动和生怒,所以有名开发者在一次无谓的挣扎之后终于放弃了。也许他们觉得自己的想法并没有得到合理的接受,甚至它根本就不值得自己卷入这种麻烦中。

我的一名大学导师曾经向我指出:“Chris,有时候人们挑战你的观点时,他们并不是真的在否定你的说法。他们只是不认同你的表达方式!如果你用不同的方法说法同样的观点,可能他们就会支持了。”

他说的完全正确。我听到这种说法后,除了突然让自己住嘴,也开始发现其他人也存在这种情况。会议、合作型课堂项目,甚至是人们的日常交流都会产生冲突,那些心地善良,无意冒犯他人之人,确实总体上会认同双方的目标和观点,而普通人无意识的敌意升级却经常引起事与愿违的反复争执。

造成这种问题的原因和行为模式有不少。在10年的研究之后,我开始更理解这一点,这种情况仍然时有发生,它仍然是我必须积极应对的情况。

这就不难理解人们在感觉自己融入团队就是麻烦的起源之前究竟遭遇过多少次这种情况。这种情况的结果就是回避,降低自己在对话中的个人投入,并服从人们在讨论中所达成的一些行动项目。

如果沟通技巧很糟糕,无论其他技术或美术技能再好,你都很难得到他人的帮助,很难得到玩家和评论人员的关注。另一方面,如果你的沟通技能十分了得——极具说服力、清晰、公正而富有条理,那么你能够处理的项目范围和类型可能就会惊人地扩展,因为作为优秀的沟通者最关键的地方就在于,成为任何各具才能(以及经验、灵感)的开发者所组成团队中极有意义的一部分。

communication(from practicalpmo)

communication(from practicalpmo)

用心聆听

仔细倾听,意味着不但要听到他们在说什么,或者给予他们一个发泄口,还要试着与他们共同理解潜在意思,而据此作出相应的调整则远比听起来更困难,或者至少是比我们所想的更不自然。你可以通过训练自己更好地倾听而受益。我之所以能够这么说,是因为任何人(无论是总统和实习生,家长和孩子,学生和老师)都能够更好地倾听。

但这里有个倾向就是,将自己视为主角,其他人则是NPC,尽管我们理智地知道这种做法是不现实的。倾听的部分要素在于有意识地依此行事。其目标并不是让他人来适应你的想法,而是通过大量背景和视角,以让人们获得参与其中的良好感受而找到前进的出路。

不要在乎谁赢

对话沟通中并不存在谁是赢家的问题。

这个道理听起来显而易见,但有许多人仍然没有充分理解。开发讨论并不一定是场争论。即使是创意冲突也不可避免地会呈现某些不可兼容的想法都在争夺日程表上有限的开发关注点的局面,但争论并非解决问题的良方。

在一个交流对话的模式中,两个持有不同观点的人参与其中,最后其中一者赢了,另一人却输了。我并不认为任何人都会有意识地认同这种对话模式,但从我们在电话上所看到的政治人物谈话的头部特写,电影角色之间的对话,甚至是我们本能的斗争或逃跑意识都会将此视为一种默认的对话模式。

不要去想谁是观众(注:要尽量避开其他观众,因为这通常可能以防御性、自我保护的姿态污染一个文明的对话环境),或者想象公正的裁判会判断谁是赢家,要考虑参与其中的人所处的立场可能会影响到将来的争论。

如果你所有的先决参考材料都在引导你强烈地相信某一特定方向,你可能只是在推波助澜地给这个夸张的方向帮倒忙了。无论何时我们遇到一个不太喜欢,尤其是涉及设计、美术或商务等可能有许多可行方向的领域,只要我们将其与消极、敌意的人联系在一起,那无论是哪种理论依据在支持这项选择都没用了。

要友善地对待此事。首先要担心的是理解他们观点的优势和考虑,然后才是你自己的观点得到理解和考虑。注意这两者都不是要“说服”他们,或者向他们展示“正确的”方法,而是尝试相互理解,因为如果没有这个前提,其他的讨论内容都只会沦为针对不同想法的争吵。

可能是你错了

谈到相互理解:不要害怕在想出发生什么情况后放弃一个观点,并意识到还有另一个更可行的方法。我们总是顾及面子问题而坚持捍卫自己的观点——尤其是在还没有吃透这些想法的情况下。

聪明人在遇到新信息或顾及新的考虑时总是善于变通。你们并不是在玩红队对抗蓝队的游戏。你们是同一个团队中的人,要尽量向同一个方向传球,也许你的队友更清楚哪个方向才是正确的目标。

另一方面就是要给其他人摆脱困境的出路。提供一些新信息或关注点,让他们更容易改变自己的想法,即使这些信息实际上并不足以改变他们的想法(因为这可以让他们用更合适的方式 回应新信息,而不是一开始就表现出不确定性)。承认他人所在立场的优势并不会让你的立场处于弱势,这只不过是让他们觉得自己的想法被倾听和得到了认可,以及你考虑的并不只是自己的初始想法,还包括他们的想法。无论是以哪种方法解决一个问题,都要允许大家存在不同的见解,而不是形成谁站在你一边,谁反对你的印象(实际上,通情达理的人一般是反对特定观点而不是针对某人)。

当某一观点不可避免地被妥协或放弃时,作为富有技巧的沟通者就不要对此太刻薄或者穷追不舍了。不要介入太人私人感觉,这是团队的最高利益,并非每个建议都可能被采纳或者最终被游戏所保留。

假定无过失,就要假设是最好的情况

所谓的稻草人论证就是指我们不赞同或者试图反驳一个简单化的反对立场这种情况。在非正式情况下,针对政治分歧或者宗教/文化信仰的激烈争论,经常可以见到人们反对团体中最为极端、非理性或明显棘手的成员,而不是去对付那些更中肯、理性和富有说服力的信徒。这就会陷入一个僵局,由于双方都觉得自己在推进一个反对对方的观点,所以任何一方都不会觉得自己的问题得到了解决。

如果大家的目标是形成一个更为成功的合作,而不只是让自己暂时感觉良好,那么最正确的做法就是采用与稻草人论证相异的做法。假设他人是出于理性、正式和好意的立场,如果这并非你在沟通中所看到的现象,那就去进一步理解对方。或者甚至可以帮助他们进一步发展他们的想法,寻找对方所没有想到的其他优点——也许从这一点出发可以让那些原本与你无关的立场受益。

如果你所持有的观点与他人的提议并不相同,最好将自己的想法提出来,同时再提出另一个可以作为替代性方案的想法。如果它被另一个你通过真正的讨论和考虑所提出来的更好的建议所取代,或者形成了一个似乎对双方都有好处的想法,那就更好了。

你的挫折感会形影不离

这是我通过自己的摔跤训练生涯而得到的一点生活经验。多数时候当人们不安或受挫或者失望时,他们多半是对自己失意和失望,而通过责备将矛头指向他人却并不能疏散这种情绪。

即使这在任何情况下并非100%正确(当然,有时候人们可能会非常欠考虑,自私或者不负责任,你有理由对他们感到失望)——我发现假想我们自己的情绪状态是一个非常管用的方法,因为它让外界的事物得到了控制和变化,以便我们专注于自己所能做的事情。

对有违我们信任的人感到失望?我们的失望可能是源自我们无法认识到我们不应该信任他们。对做错事的人生气?我们可能是气自己没有把握好方向或者期望太高了。对不理解那些你认为显而易见的事情的人感到抓狂?你可能是因为觉得自己无法向他们清晰而高效地描述事件而受挫。

如果人们没有很好地理解或接受你的观点,但你却相信自己的想法具有价值,只是没有得到充分的考虑,不要将此归咎于他人的理解无能,而要想想这是因为自己没有表达清楚。也许他们不会遵从你的参考意义,或者无法更好地通过简单的图表或流程图而理解你的想法。也许他们理解了你在说什么,但却不知道为何你会认为这值得一提,或者他们知道你的意思但就是不懂你所想的事情与你所认为的改变之间有何联系。

最好是写下概括性的重要内容(游戏邦注:人们通常难以吸收含有大量细节的论据,除非他们已经知道其中的大意),并以其他方法来解释说明。提供一个展示案例。如果你已经有一个自己认为很重要但却没有得到认可的观察,最好是以另一种新方法引出这个观点,而不是令其夹杂在其他混乱无章的字词中,导致其无法合理地呈现或得到支持。

将假设性误会为决定性

结论可能会变。当他们处于初稿阶段时,他们很可能会这样——这正是我们为何要制作初稿的原因!因为它们还只是一个计划、理念或一个原型时更易于修改和调整,它们越是成型其结论就越为牢固。

这种误解会产生两种错误的沟通方式:将你自己的假设性理念误理为决定性的,或者将他人的假设性理念误解为决定性的。在开发阶段,随着更多人的参与,项目就会发生变化从而反映出哪些做法可行或不可行,或者更好地利用团队成员的强项或兴趣。

如果你早期在项目中推进了一个人们看似赞同的想法,但之后则可能因开发过程中发现由于时间和资源有限,而不得不对其改进或删减。它甚至可能被完全删除,甚至在混乱中完全被忽略了。在提到它的案子之前,要先重新考虑一下项目可能会如何变化(因为当时该想法只是刚刚成形),以便决定是否需要更新这一想法,令其符合团队和游戏发展方向。

有时候某些想法在开发过程中的价值就是给予我们专注的方向,而该理念能否保持其原来的形式则要让位于团队和玩家是否会喜欢游戏。它可能需要重新加工,可能需要进行一点调整,也可能在最后的开发阶段却发现它并不像现在这么可行了。也有可能你最终还是得放弃它,尽管它曾经是团队过去所实现理念的垫脚石。

另一个做法就是犯同样的错误,从而了解他人的想法:在它们还是假设性的时候将其想象成决定性的。这种情况的发生也许要归因于该想法距离未来结果还很远,以及初始理念和讨论发生时大家还没发现或解决的问题。如果一个项目需要人们有意支持一打汽车类型,但在开发过程中实际上只用了三种不同的汽车 ,以便将精力运用于其他必须的开发环节,那就会发生这种情况。人们会变得乐观,人们会犯计划性的错误,人们无法预测未来——但重要的是不要将这些人类瑕疵与有意的谎言或不守信混为一谈。如果有人在开发早期说出了一个项目之后可能实现的愿景,不要太当真,也不要将其视为板上钉钉的合约,只要将其视为他们所打算的方向即可。执行的过程中实际上还需要妥协。

软化确定性

团队内斗的一个普遍起源就是对某一个观察或说法的确定性的错位感,它反映了团队其他人并不一定认同的价值优先权,尤其是当有一个人的说法凌驾于团队其他人优先权之上的时候。

最好是谦逊地承认自己只能看到部分情况,你所能做的就是从自己的立场出发澄清事情的发展方向。为大家的争议留有余地,“我最多只能说……”或“在我看来……”或“我当然不可能代表所有人,但至少根据我所玩过的该类游戏题材来讲……”这类开场白看似无甚作用,但实际上却可以避免将团队拴死在一个结点上,从而根据不同角度展开有意义的讨论。

顾问的挫折

校园里充斥着大量想法与行事风格一致的人,他们拥有相似的价值观,通常也是同一代人。在教室之外,无论是合作开发一个游戏项目,加入一家公司,或者做其他事情,似乎都是这种情况。通常情况下,如果你的技能是视觉艺术,寻径你就得同那些不是很懂视觉艺术的人合作。如果你的技能是设计,你就得与许多非设计师共事。如果你具有技术专长,你就得同大量非技术人员打交道。

这也正是你在团队中的原因。因为你知道他们所不懂的内容。你可以看到他们所无法看到的问题。你知道他们不知如何应对的方法。如果团队或公司中的其他人能够以相同的方式理解你的想法,寻径他们可能根本就不需要你参与了。你在这个位置的目标就是帮助他们理解问题,而不是因为他们的理解与你不同而看轻他们。要帮助他们看到你所见到的内容。

我将此称为顾问的挫折,因为它特别强调一点:如果有一家并不了解销售(或者设计、IT等领域)的公司给一名销售顾问打电话,就是因为他们不了解这个领域所以才会打电话咨询。此时幼稚、缺乏经验、没有准备的顾问对此情况的一个可怕反映就是——这些人怎么会对如此基础的内容一无所知?顾问的作用是找到这个认知差距,并给他们补上一课,而不是因此而贬低他们。毕竟这家公司还要做大量专家所不能完全理解的事情,因为这些并非他们所熟悉的领域。

如果你发现了一些与自己有关的问题,要与团队分享。因为这正是你存在的部分价值。你也许会看到团队中其他人所不能见到的方面。

每个角色的价值不同

上述要点的另一面就是欣赏其他不如你自身观点更显而易见的因素和问题需要同这一点相平衡,在某些情况下甚至需要颠覆它。

挫折可能起源于顾问挫折的一种夸张形式:程序员可能会本能地将团队中的其他角色视为二级程序员,设计师可能将其他人视为二级设计师等等。这并不是一种有效的思考方式,因为他们不适合你的位置,而且你也不并适合去做他们的事情。位置不局限于某人推动项目进程的技能,它还代表他们在团队中对项目的某一方面所持有的一种责任和身份,一种看待特定问题的专业眼光。程序员可能无需担心色彩方案,美术人员可能不用操心如何编程,而只要玩法可行,设计师也不需要顾虑美术和编码问题。

这正是让人们各司其职的好处之一,即便团队是由身兼数职或者独立开发项目的成员组成。

由于大家的出发点不同,开发过程中就难免出现妥协。美术人员可能会因图像渲染的异常问题而烦恼,但工程师可能会有团队已经使用了他们可用的技术来支持这种美术风格但却仍然无法实现的正当理由。音乐或音频设计师可能会觉得某些增进谱或动态调整方法可能会让游戏的音频增色,但玩法或关卡设计师则可能有一些自己所熟悉的关于用户体验、站程或输入方法等棘手问题。

制作人有时候口碑很差的原因之一就是,作为项目“经理”他们并不理解这些情况,因为他们的职责是确保游戏取得进展,直到按时完成和发布为止。所以他们遇到这些问题的妥协理由通常就是,“……但我们得按计划完成游戏”。如果某人不为此而努力,那么项目就无法完工。

所以当你有幸与一支优秀而平衡的团队共事时,要善待团队中的其他人,因为他们都在找你所看不到的盲点。要让你自己成为一名更出色的沟通者,这样你才能为他们提供同样的帮助。

过于强调角色作用

现在我觉得有必要特别说明一下小型团队开发角色在讨论和考虑过程中不应该卷入成员的能力分类问题。

虽然绘制视觉艺术的成员很可能是美术风格的最终决定者(游戏邦注:这不仅是一个美学偏好问题,还是一个他们在工作中因自身的能力、强项与局限性所带来的副作用),但这并不意味着团队中的其他人就无权提供一些自己对该美术风格的反馈和建议(要知道,美术人员可能只能创造一种特定的视觉风格,但这并不意味着程序员就应该全力以赴实时支持这种风格),应该允许他们提出自己的意见,并以游戏粉丝或媒体的身份来谈谈看法。

一名团队成员真的比项目中的其他人更了解动画吗?果真如此,那么这名成员就应该参与同动画执行或部署相关的讨论。但即便你不是动画人员,如果你能提出大量不同的媒体案例,并且有一个如何令之与技术、设计或其他学科相互作用的执行想法,那么你还是有必要参与讨论(尽管其决定权仍在于最有影响力,以及最有相关经验的那个人)。

躲藏在自己的角色背后,认为“我并不是美术人员,所以这不关我的事”或者“我是设计师,所以这不是你需要担心的问题”并不会给团队带来好处。游戏质量会影响到每个参与其中的人。你可以提出一个与自身有关的看法,并由拥有不同背景和不同观点的人来提出意见。大家一起找到最佳方法。

boss-leader(from hobbygamedev)

boss-leader(from hobbygamedev)

与这些角色说明相关的一个区别理念就是仆人型领导。它提倡的是团队领导不应该像制作人、总监或主设计师一样将自己视为其他人的上司,他人只能服从自己的命令,而要像团队中的另一名合作者一样与大家共处,所不同的只是自己还负有监管项目方向以及抽取不同经验类型的责任。他们必须平衡自己与他人的想法,从而让大家形成一个共识,要尽量让团队保持快乐心态,这就是他们手中的技能和工具。

有效地处理批评意见

在批评发生的时候——无论是你的游戏完成之后的批评,还是遭遇了反对的声音,要先让自己同被讨论的要点相隔离。当你们对你的工作给予反馈时,无论是针对你的编程、美术、音频还是其他的,这些都是针对你所创造作品的反馈,而不是针对你本人的批评。

反馈的出发点几乎都是为了让游戏更好更棒,在问题暴露并影响到他人之前,或者在游戏会遭遇重大返工之前指出并修复问题。有时候反馈来得太迟了,延误了项目修复,与其否定反馈倒不如将其铭记在心并在之后多加用心(毕竟这不是你开发的最后一款游戏或理念,不是吗?)。

防御性姿态通常只会产生事与愿违的结果,至少是浪费有限的时间和精力。

系统和常规渠道

形式和一对一的日常签到会令人感觉官僚作风,但合理的更稳和调节却可以令其发挥重要功能。应该为人们提供一个发表自己看法的渠道,要让大家与项目相关的人进行半常规的接触,这样才能建立一种信任感,而不至于在发现问题时感觉是在彼此针锋相对,而非提出一些小意见而已。

在我曾参与的一个游戏开发团队中,我们曾试图在还没有开始执行的早期阶段就缩小可能的前进方向。在一次公开的讨论中,大家提出了一些看似可行的想法。当我们让大家举手表决,看看这些想法的支持率时,我们发现有一个想法仅有廖廖数名支持者——这些支持者是其中最有发言权的参与者。即便只是引进一点形式,也可能给予那些项目中更寡言少语,但却拥有同样出色想法和考虑之人更多发言渠道,这样团队才好权衡不同的考虑和优先权。

实践,从错误中汲取教训

抓住更多锻炼沟通能力的机会。在所有角色中,在人群中,在正式与非正式场合,在与数人外出途中,与多人外出过程中均是可以利用的机会。

现在,我并不喝酒,也不去酒吧或俱乐部。我几乎从不参加派对。这周末我也没有去看超级杯的打算。我并不是说你应该强迫自己去做那些本不愿意做的事情。我只是想说你应该去找那些能够让自己放松自如地练习沟通能力的场合。

无论你是单兵作战还是与团队共事,都要好好利用与团队打交道的挑战。去参加会议,参与一些俱乐部活动。如果你所在的团队需要一些消息或花边新闻,要自愿提供这些信息。

沟通是一种游戏开发技能。与任何其他游戏开发技能一样,你通过持之以恒的练习终会获得巨大收获。

篇目1篇目2篇目3篇目4篇目5(本文由游戏邦编译,转载请注明来源,或咨询微信zhengjintiao)

篇目1,Opinion: Negative developers and team stability

By Lee Winder

It doesn’t take much for negative feelings to start to seep into a team but it takes a lot more to turn a team around and start to raise morale and motivation. The following isn’t based on an in-depth study of development teams across the world but on my own personal experience of managing and observing a number of teams over the last 10 years.

Take of that what you will…

When you look at the make-up of a team, it will always be staffed by people who raise the game and by some who only bring it down. It’s the nature of taking a group of individual people and asking them to work together for a period of time towards a common goal. It’s the individuality of these people who can take a project and make it fly or cause it to crash and burn.

One thing that’s clear is that it’s much easier for a single individual to bring a team down than it is for an individual to improve the team in any significant way. Negativity will spread like wild-fire through a team whilst positivity acts more like treacle and can be much harder to spread around.

But why?

A negative attitude to work is a whole lot easier. Doing less, talking badly about the team, or rubbishing the game is much easier than creating excellent content, taking responsibility for your work or stepping outside your defined role and doing something great.

What defines a negative developer?

There are many ways in which a developer might have a negative effect on a team. The most obvious is through their general attitude to their current project, be that general low-level complaining, pushing back against work requests for no good reason, or general slacking off during the day.

It could be a lack of skill development or even a backsliding in the quality of the work they are producing.

But it could also be an attitude that doesn’t gel with the general ethos the team is aiming for. Maybe you want your developers to take more responsibility for their work and how it’s designed and implemented, and one or two developers will only work when they are told exactly what they need to do.

Maybe it’s a developer who doesn’t get involved with the daily meetings, mumbling through and obviously not interested in what other people are doing.

At the end of the day, identifying a developer generating a negative effect on a team is usually pretty easy. They’re the ones who are difficult to deal with in usually many aspects of the development process…

Team development

Lets have a look at a few situations where a green developer is a ‘positive’ developer, red a ‘negative’ one.

In the first situation, we have two developers working side-by-side, one working well and another not doing so great. Maybe one of them has a bad attitude, maybe they don’t want to really push what they are doing. Either way, their contribution to the team is much less than that of the positive developer.

In most cases, this will go only one way. The good developer, seeing their partner being allowed to get away with not working so hard and not having to put in as much effort, will eventually start to slow down and equalize with the poorer developer.

It’s much less likely that the poorer developer who is getting away with poor work or a bad attitude will see the better developer and decide to put in that extra work. As a result, you now have two bad developers rather than one.

When does it go the other way? When does the poor developer look around and start to raise their game? The answer isn’t very encouraging.

Take the following situation:

Theres a tight balance here, but since it’s much easier for a developer to reduce the quality of their work rather than improve it, it’s easier to slide the wrong way, and at that point it’s very easy to see where this will go.

Based on a number of observations, it seems at though while a 3:1 ratio might get you some good results, it still brings risks because should one developer start to slip, it then becomes 1:1, which puts us right back at the start.

In most cases you can only really guarantee that other people will not slip if you have a 4+:1 ratio between positive and negative developers. In a number of cases, the negative developer didn’t change their attitude without help, but other developers didn’t slip due to the peer pressure of the other better developers.

Positive developers

But in all these situations, I’m not giving these positive developers enough credit. A good developer won’t always slack, they’ll continue working hard, producing great content and generally continue to fly high.

But take the following situation…

These developers are good for a reason, be that personal pride, ambition, or sheer enjoyment of the work they are doing. And if a good developer finds themselves in the minority for a long period of time, the outcome is inevitable.

Great developers won’t stick around if those around them are not working to their potential or failing to create an environment in which the better developers feel themselves being pushed. And once your great developers leave, you have a much higher chance of those left realizing they don’t need to actually work that hard to get through the day.

Solving the problem

There are two ways to deal with poor developers on a team. The first is the most drastic, but initially not an option if you’re working in a region with sane labor laws.

Just drop them.

To be honest, I wouldn’t recommend this anyway. Simply letting someone go generally removes the problem, but it can leave a lot of holes on the team, and you hired this person for a reason, why not try and get that spark back?

Performance Management structures (you do have a Performance Management process don’t you?) within an organization can, if done correctly, not only resolve the problem but allow the poor developer to raise their game and become a star on the team.

Identify the source of the problem. Does the developer just not like the game, are they having a difficult time outside of work, do they disagree with how work is being allocated, or do they just not want to be there?

Depending on what their answers are, you’ll have a good idea of where to go next.

Make sure goals are set. Define goals designed to turn the situation around, but don’t just set and forget about them (which happens far to often). Monitor them on a weekly or bi-weekly basis, setting very short-term goals to complement the longer term ones.

Define a fixed period of time. Don’t just let things drag on with only small improvements here or there, have a deadline at which point things will get more serious.

Make it clear what the end results will be. Whether they are the chance to work on something different or whether it’s a termination of the contract, make it clear so everyone knows what will happen when the goals are reached or missed.

Keep constant records. Make sure every meeting is documented and the progress or results of all the goals are recorded daily.

Let them go. While it is drastic, if improvements are not being made given all the opportunities you’ve given them, then there really is no other option. If you’ve bent over backwards to try and solve the problem and the developer hasn’t taken you up on the offer, then there really is nowhere else to go.

And even with those sane labor laws, the documentation you’ve been keeping over the Performance Management period mean you can release the developer from their contract knowing you tried your best and they didn’t want the help.

So negative developers, whatever is defined as negative based on the goals of your team, are almost guaranteed to have a bad effect on a group developers. Negative attitudes to work and development can spread much faster than you might think and will either cause people on your team to normalize at a level far below where they need to be or will simply leave.

It’s vital that as a group these developers are tackled fast, rather than when their effects start to be felt.

篇目2,Cliff Bleszinski’s Game Developer Flashcards

by Cliff Bleszinski

As of this summer, I’ll have been making games for 20 years professionally. I’ve led the design on character mascot platform games, first-person shooters, single-player campaigns, multiplayer experiences, and much more. I’ve worked with some of the most amazing programmers, artists, animators, writers, and producers around. Throughout this time period, I’ve noticed patterns in how we, as creative professionals, tend to communicate.

I’ve learned that while developers are incredibly intelligent, they can sometimes be a bit insecure about how smart they are compared to their peers. I’ve seen developer message boards tear apart billion-dollar franchises, indie darlings, and everything in between by overanalyzing and nitpicking. We always want to prove that we thought of an idea before anyone else, or we will cite a case in which an idea has been attempted, succeeded, failed, or been played out.

In short, this article identifies communication techniques that are often used in discussions, arguments, and debates among game developers in order to “win” said conversations.

These observations and monikers are not meant to be antagonistic; in fact, several of the approaches mentioned here are employed because of valid reasoning. For example, pattern matching can be a good way of avoiding making derivative products, and sometimes an edge case can, in fact, kill a solid idea. So here are my Game Developer Communication “Flashcards.”

“Pattern Match Dismissal”

This is when a developer immediately runs through his gaming/pop culture library in his head and finds the closest thing to compare it to (often, a bad or failed example) in order to shoot it down.

For example, in regards to Avatar, “You want to make a movie about blue people in a forest with a bad military and mechs? What, Smurf Ferngully Aliens?” The Gears of War franchise, pitched improperly, could be seen as the old ’80s schlock horror movie C.H.U.D.

“Edge Blocking”

This refers to using an edge case to block a potentially awesome idea. i.e., an Edge Blocker would shoot down the idea of having giant worlds in Skyrim because of a concern that you’d have to trek back to where you came from and that all that walking would get old. Obvious and clear fixes such as the gameism of “fast travel” can easily solve this issue, allowing for huge worlds.

Edge Blocking has variants:

“The Networker.” This is a way of shooting down an idea because it won’t work in an edge case or unique co-op situation — this is a variant of Edge Blocking. “How would Max Payne slo-mo work in co-op? Impossible!”

“Perfectionist.” Similar to Edge Blocking, this is when a developer finds one instance whereas a cool feature might not look absolutely perfect, e.g., an amazing melee move that occasionally will result in some minor clipping of characters into one another.

“Ne’er Do Well”

Or “I’ve never seen that feature done before, or done well. Therefore, we shouldn’t do it.” This one is pretty self-explanatory, and, in fact, can be the reason why an idea should be done. Following this logic only leads to “me-too” creation.

As a reference, a Locust population from the underground in Gears of War worked for many reasons, but we still had reservations about it. In the end, it helped differentiate the franchise from others that featured the usual aliens-from-above/space.

“Devil’s Advocate”

Most developers tend to use this technique, even when they believe in an idea, as a form of covering their ass. Often used by lawyers.

“It’s just X+Y”

This is when a developer dismisses another successful product, sour grapes style, because he can easily see the formula. The fact that the formula is so simple and obvious is often why said product is so successful.

For example, Words with Friends: “It’s just asynchronous Scrabble.” Yes, it is, and it’s brilliant.

“Future Release”

This occurs when a developer hears an idea — good or bad — and says that it will fit nicely into a later version or sequel. This is code-speak for “I don’t think that idea is worth doing, so we’re going to shoot it down by saying we’ll do it later in order to make you feel better.”

“Toppling,” a.k.a. “Tower of Babel”

This technique is when a developer adds too many bells and whistles to a feature that was pitched as simple, but ultimately jeopardizes the feature altogether due to these additions. The feature “topples” under its own weight.

“Think of the Children!”

This is otherwise known as “Cascading Dependencies.” The tendency is to shoot down an idea because it will cause more work for other departments, such as animation, UI, or art. Often, features that are interesting and/or worth doing have these sorts of ramifications as they combine all disciplines.

“Analysis Paralysis”

This is a commonly-used term for the technique of over-thinking things to the point where nothing is actually done.

“Why Even Try?”

In other words, “How do we even compete?” Intimidated by the immense competition in any given space, a developer asks this as a way of giving up before even giving it the “old college try.”

“They Have N Developers!”

This is a phrase that is often used by a developer to cite a competitive team and how large their staff is on their game, and is used as a way of leading to “why even try?” The Epic Way has always been to put the best people on a task, with the best tools in the business, in order to work smarter.

“Traditionalist”

“But this is how we’ve always done it!” In entertainment, and particularly in technology, innovation and re-thinking things is often quite necessary in order to stay alive. Becoming complacent and doing things the same way over and over again is a surefire way to induce failure.

Being a 20-year veteran of any regular business may be an advantage, but in technology, it can sometimes limit you. As a developer gets older, it’s crucial to keep an open mind and to always be learning.

“But We’re (Insert Studio Name)”

This is the battle cry of a studio that is ready to rest on its laurels due to a certain level of success and thinking they’re badasses. The moment folks at a studio start saying this, one can count the days until the studio implodes, because a younger, hungrier crew out there wants what you have and is willing to dream and make it happen.

“We Tried That Before”

Citing a previous failed attempt at an idea in order to kill a new (and potentially workable) permutation of said idea.

“Too Cool”

Your idea is great! In fact, it’s too cool and innovative. Therefore, we shouldn’t do it, because it sounds like a lot of work.

“Jargonating”

This is when a developer uses forms of jargon only native to his discipline in order to win an argument with a developer of a different discipline, e.g., a coder using code-speak to an artist, or a designer using designer lingo to an animator.

“The Tribal Leader”

This happens when developer believes in his discipline (art, code, design, etc.) over any other in the studio, so fuck those other guys.

“Noscope”

“That idea is great but isn’t within the scope of the project.” Sometimes, the best features are the fringe ones that sneak in under the radar and not on the original schedule, unfortunately.

“Playtest Grandstanding”

This is when a developer fails with a new feature or weapon and loudly suggests “balancing” it by changing it during a playtest, therefore often getting his way. Sometimes, people just suck with a sniper rifle and get destroyed by others, and that’s okay.

“The Repitcher”

This is the person who hears your idea, seems like they didn’t initially hear it, then re-pitches the same exact idea in their own words as their own, forgetting where they originally heard it. This ultimately doesn’t really matter, as long as the cool idea comes from somewhere and is implemented well!

“Filibuster,” or “TL;DR Guy”

This is the person who responds to a design suggestion or discussion with three-page emails.

Every time.

Without fail.

Eventually, you make a custom filter for this person.

“The E-Douche”

This is the person who almost always seems to come across as a total asshole in email, even when they don’t really mean to because, frankly, email sucks.

“Godzilla”

This is a person who somehow manages to shut down all progress on an idea and comes up with his own completely new pitch that is subjectively better or worse, essentially trying to make everyone start over.

“The Doubter”

Someone who rejects an idea without having any sort of clear reason why: “I don’t know about that…” Often useful against the…

“Prophet”

A designer who has a rush of excitement about an idea, but hasn’t thought through it fully in regards to its design and/or ramifications. Said designer simply expects everyone to have faith that the idea will wind up good instead of properly making the case for it. This is often common behavior with a younger, less experienced designer. Similar to…

“Captain Ahab”

This is when a designer refuses to admit that an idea just isn’t panning out, while endlessly iterating on it, using precious code and art resources, assuming someday, one day, it will be fun.

“Data Bombing”

This an argument used that goes as such: “This chart of loosely related and completely unbiased data shows how your idea will never succeed, you’ll offend lots of folks, and it’s a direction we cannot afford to go in.”

“Psychic Expectations”

This is a technique used by a coder in which said coder refuses to understand the pitched/desired feature until it is requested in the exact specific manner the coder wants to hear it.

“Ignorannihilation”

The developer who intentionally (or unintentionally) misses the obvious and starves a potentially good feature until it is cut.

“Not My Idea, Not Going to Do It”

This is when a designer takes input from others and claims to want a call for ideas, yet quietly ignores anything he didn’t come up with himself.

“The Gardener”

The Gardener plants the seed of an idea early and then brings it up again many times in meetings and in casual conversations with individuals around the office. Eventually, the idea starts to take root and grows on people until it becomes an actual feature in the game and no one can remember where the idea came from in the first place. This is actually a very useful technique.

“Obvious Bug Guy”

This is when a developer is being shown a work in progress feature and, instead of thinking about where the feature is headed or what it can do, feels the need to point out obviously broken things that will clearly get fixed eventually, like Z-fighting.

“Multiboss”

This when a person has no clear, obvious boss or chain of command, and is often told by multiple people what he should be working or focusing on. One’s design director, executive producer and president may each have varying opinions about what to do, leaving said staff member confused.

“The Promiser”

This term refers to a spokesperson who pitches or promises a feature to the media, which puts the team on the hook to actually code said feature once they’ve gone public with it.

“The Bandwagoner”

This is the term for the creative who wants to add whatever feature he saw in a recent popular game as a way of making the game better instead of trying other ways to innovate.

So, in conclusion, that’s the list of personalities and techniques that I’ve encountered throughout the years. Thanks to some of my peers at Epic, ChAIR, and People Can Fly for contributing to the list. I hope that aspiring developers can recognize these patterns and adjust accordingly, and I hope that established creatives are able to get a chuckle out of this.

篇目3,The Elimination of Waste: Lean Six Sigma applied toward Game Development

by Harvard Bonin

These days one must only search online to find many project management techniques that are prevalent within general software development but are not utilized often in game creation. While Scrum has made a strong push into game production, many other techniques remain on the sidelines. This is unfortunate since other methods from Traditional and Agile methodologies can be applied to our industry and could help yield positive results.

In this article I will not explain Lean Six Sigma in detail. There are plenty of materials available if you’re interested in pursuing further. Instead, I will focus on the core principles of Lean Six Sigma and show how it can apply to everyday game development.

LEAN SIX SIGMA PRIMER

Lean Six Sigma is a combination of two project management techniques called “Lean” and “Six Sigma”.

Lean: Focuses on delivering customer value efficiently above all other activities. Any activity that does not add value for the customer is removed from the process.

Six Sigma: Focuses on removing all defects and variation from the process.

In other words, both are seeking to eliminate “waste”. In Lean Six Sigma terms this waste is defined as “muda”. This is a Japanese term popularized by Toyota and means specifically “futility; uselessness; idleness; superfluity; waste; wastage; wastefulness”. Waste can appear in many ways. Idle time, rework, mismatched feature requirements, under and over communication, etc. Lean Six Sigma identifies eight (sometimes seven) types of waste.

There are many concepts underlying Lean Six Sigma. Entire development projects have been built around the techniques, equations and tools available within this framework but they are much too involved to explore in this short article. If you explore further you may notice that many of the concepts apply most directly to manufacturing. While this is true the core principles can still have a direct, positive impact on game production.

WHY WASTE MATTERS

In my experience, wasted opportunities are the single largest source of angst on teams. Wasted time, most of all. Continually striving to remove waste in all areas is a mindset that producers and project managers must develop and embrace. Many producers think that their main role is to lead projects through guidance, task-forcing and sheparding. They believe that they are like a general on a horse in front of an army, pointing their sword towards the enemy and yelling “charge!” While the role can have these elements, it’s shortsighted and limited. An experienced team probably already knows how to work well and the producer’s best use of time might be to focus on waste rather than march them toward a goal. Sometimes producers must let the team do what it does best and spend their own time bulldogging the blockers out of the process.

THE TWO DEADLY SINS

Throughout my career I’ve experienced many problem ridden projects. In fact, all my projects have been difficult. When they are completed the team usually turns to the post mortem to help shine a light on the many issues the production experienced. The the most frequent and impactful concerns often revolve around “communication problems” and “misaligned expectations”.

Communication Problems: Teams often complain that they weren’t aware of the project goals, dates, inter-departmental tasks or management expectations. This issue seems to arise on every project. Fortunately, it’s one that is the most easily fixed through discipline, techniques and a commitment to transparency from all involved. Most of all, producers and project managers must be acutely aware of this issue since it’s a main source of wasted time.

Misaligned Expectations: Often management and content creators are not in sync regarding the definition of “done” when creating features, art, code, etc. This misalignment leads to more rework on titles than most any other issue. The product owner, stakeholder, owner, etc. (whoever is the single source of creative control) must be clear in this communication to all content creators.

The commonality between these two issues is “waste.” Both issues are instrumental in creating wasted time. Time is the single most valuable resource available to product development. Since Lean Six Sigma focuses on waste removal (time creation) it’s particularly useful when applied to game development.

TIM WOODS: THE EIGHT KINDS OF WASTE

There are eight kinds of waste defined in Lean Six Sigma. An easy mnemonic to recall these is “TIM WOODS”.

Here is the academic definition.

T Transport: Moving people, products & information

I Inventory: Storing parts, pieces, documentation ahead of requirements

M Motion: Bending, turning, reaching, lifting

W Waiting: For parts, information, instructions, equipment

O Overproduction: Making more than is immediately required

O Over processing: Tighter tolerances or higher grade materials than are necessary

D Defects: Rework, scrap, incorrect documentation

S Skills: Underutilizing capabilities, delegating tasks with inadequate training

source: http://www.isixsigma.com/dictionary/8-wastes-of-lean/

Consider your own daily game development experience. How may these types of waste definitions can be applied to help uncover your project’s inefficiencies? Here are some examples:

Transport: Does the transfer of assets take too long? Are build times lengthy and defect ridden?

Inventory: Is too much time invested on lengthy design documents that change the next day? Are there too many unpruned ideas out of scope that distract the team?

Motion: Is the environment set up to hamper communication? Are people working on highly iterative features physically sitting together? Are the tools accessible and effective? Is their workspace conducive to doing effective work?

Waiting: Is the team continually waiting for other departments to complete their work? Are they often idle?

Overproduction: Are the artists creating assets without confirmation of the end requirements? Will the assets be used? Are departments running ahead of others before requirements are specified?

Over processing: Are people making assets that are too highly detailed than what is required? Are they “gold plating” and polishing features that are the least impactful or important to the customer?

Defects: Is the code ridden with bugs? Is it extendable? Does the resulting work align with the expected work? Do the assets created align with the engine capabilities? Does the work match the expected grade?

Skills: Are tasks mismatched with the skillset of the team member? Are PHDs working on tasks a GED could accomplish? Or vice versa?

TIM WOODS: APPLIED

Theory and concepts are fine but they have little benefit unless they are applied toward tangible activities during development. Below you’ll find my game specific (incomplete) list of actions teams can perform to embrace Lean Six Sigma thinking and try to eliminate waste. None solve all project issues alone but taken collectively they may help teams significantly. No doubt you can add many more.

Conduct daily stand-ups: Short, ten to fifteen minute, well run Scrum stand-ups are useful. They promote face to face communication on a frequent basis and don’t require a large time investment. Infrequent and inaccurate communication is wasteful.

Replace weekly producer status meetings with risk meetings: Conducting a weekly status meeting where everyone goes around the room to provide updates are generally useless. The information should have already been known through regular communication and reports. Focused weekly meetings where each producer brings up their top three project risks and asks for guidance from the group can be very useful. Useless meetings are wasteful.

Prominently post goals/dates/values within the physical project space: Osmotic communication envelopes the team to ensure that no team member is confused about the macro goals. Put up posters, monitors, etc. to help keep the goals on the forefront of the team’s mind. Face to face, personal communication is best and the most iterative. Producers must take all opportunities to communicate the goal expectations to the team and stakeholders. Uniformed team members create waste.

Seat people working on highly iterative and collaborative features near each other: Team members working on the same feature, especially if it’s unknown and exploratory is critical to their success. Eliminate as much walking as possible and ease collaboration. The more unknown the feature, the closer they should be. Infrequent communication toward a focused goal creates waste.

Frequently communicate sprint, milestone and project goals face to face: While posting goals and values on the surrounding team walls is supportive, personal communication is best. It is the most iterative. An email may take a day or more for a response but face to face discussion iterates in real time. Producers and Product Owners must take all opportunities to communicate the goal expectations to the team and stakeholders. Communication delays via email or chat is waste.

Frequently communicate creative goals: As with due dates, the creative expectations must be shared continually. Generally, the “definition of done” lies with the Creative Director or Product Owner. They must be vigilant in sharing their requirements…often. Misunderstood creative goals create waste.

Make sure the definition of “Done” is clear to all content creators: One of the main roles of the Product Owner is to communicate their expectations surrounding a feature’s creative requirement and quality. Fast, measured decision making is vital. My continued belief (which is supported by Lean Six Sigma) is to follow the United States Marine’s “70% Rule”. If you think your plan has a 70% chance of working you must execute as quickly as possible. You can always adjust if it’s wrong. I’ve worked with too many creative directors that wait for the “perfect” plan. Navel-gazing creates waste.

Promote the value of transparent communication on all project related matters: I’ve worked in many companies that held core data about the project closely. They often felt the team couldn’t handle bad news or they might lose people to attrition. Being open and honest is not only ethical, it’s also good business sense. Teams must be fed the best information to help them work toward their goals. Keeping secrets, in most cases, is a mistake and can fester into discontented teams. Poor, infrequent communication creates waste.

Optimize the value stream: The project pipeline can be one of the biggest waste creators on project. Content creators must be able to review and iterate on their work as fast as possible. Broken builds, long asset transfers, etc. can significantly limit the ability of the team to do their best work. Long, broken value streams create waste.

Encourage content creators to show interim work: No one likes to show work that is undone. They may think that the reviewer doesn’t understand what it will evolve into or that they’ll get critiques about irrelevant issues the creator already intends to resolve. The creator and the reviewer must develop this trust. Frequent reviews on iterative work will help eliminate rework (waste) overall. Showing interim work reduces wasted time. Waiting to show work till it’s finished creates rework…and waste.

Attempt to eliminate rework resulting from creative review meetings: This point is similar to the previous one, however the ideal situation is that NO rework comes from “official” creative review meetings. This work should have already been reviewed and altered prior to the review meeting. The review meeting should be a bureaucratic “stamp of approval”, not a meeting to explore the creative director’s lofty new ideas. On nearly every project I’ve worked on content creators have complained that they must wait far too long for their work to be reviewed. Not only does this create waste in the form of idle time and possible rework, it’s a significant frustration for all involved. The Product Owner must delegate reviews to trusted team members. To do so, their requirements must be communicated clearly and their expectations must be established. Rework from infrequent creative reviews creates waste.

Streamline or eliminate meetings: If your team finds meetings useless you are probably not conducting them properly. There are many, many sources that outline the best way to run them. Proper agendas, specific questions to be answered, etc. People generally dislike meetings and find they are a waste of their time. Producers must study the many ways to hold effective meetings. Meetings should be about collaboration on solutions, not reiterating what everyone already knows. Inefficient meetings create waste.

Hack, in the right circumstances: Not every piece of code must be beautifully architected. Sometimes the team gets more benefit from experiencing a feature hands-on, even if the underlying code is messy. An agile adage states that teams should “fail frequently”. This means the team must prototype quickly so that they may iterate toward quality as fast as possible. Hacking code can get to an example feature faster. Over designing and massive system creation before the feature(s) is well known can lead to waste.

Stalk and assassinate open questions: The team must continually stack rank the open questions surrounding the project. The questions with the most impact and expected frequency should take the highest priority. The features with the highest value for the customer (gamer) should be placed at the front of the line. Killing open questions with religious fervor steadily removes uncertainty and risk from projects. Open questions are sources of risk on a project.

Focus work on customer needs: Teams must be vigilante in making sure they are creating features for their customers, not themselves. Activities that don’t directly correlate with customer needs should be removed. Sometimes people like to work on their own pet projects despite the value for the end user. Working on personal features that don’t align with the project end goals creates waste.

KAIZEN

At the end of the day the producer’s foremost responsibility is to continually search for ways to make the project run more smoothly. “Kaizen” is a Japanese term from Toyota that evangelizes continuous improvement. Producers, Product Managers, Stakeholders and Content Creators must always be on the hunt for ways to improve their work process. It’s a mindset that must be practiced on all projects so that results can improve over iterations.

IN CONCLUSION

Lean Six Sigma, as noted earlier, is a very involved framework that includes graphs, equations, methods and techniques that are very involved. Teams may only need to understand the principles to gain benefit. More than a framework, it is a mindset. Waste is a project killer. The practice of finding and eliminating it is a mindset that all teams should embrace.

篇目4,Communication is a Game Development Skill (Part 1 of 2)

Today’s subject is an incredibly important one that gets a lot less attention than it should. Most videogame development guides and tutorials fail to acknowledge that communication is a game development skill.

Knowing how to speak and write effectively is right up there alongside knowing how to program, use Photoshop, follow design process, build levels, compose music, or prepare sounds. As with any of those skills there are techniques to learn, concepts to master, and practice to be done before someone’s prepared to bring communication as a valuable skill to a team.
Game Developers Especially

Surely, everyone in the world needs to communicate, and could benefit from doing it better. Why pick out game developers in particular?

“…sometimes when people are fighting against your point, they’re not really disagreeing with what you said. They’re disagreeing with how you said it!”

I don’t meant to claim that only game developers have communications issues. But after spending much of the past ten years around hundreds of computer science students, indie developers, and professional software engineers, I can say that there are particular patterns to the types of communication issues most common among the game developers that I’ve met. This is also an issue of particular interest to us because it’s not just a matter of making the day go smoother; our ability to communicate well has a real impact on the level of work that we’re able to accomplish, collaboratively and even independently. Game developers often get excited about our work, for good reason, but whether a handful of desirable features don’t make it in because of technical limitations or because of communication limitations, either way the game suffers for it the same.

Whose Job is It?

If programmers program, designers design, artists make art, and audio specialists make audio, is there a communication role in the same way?

There absolutely is. There are several, even.

The Producer. Even though on small hobby or student teams this is often wrapped into one of the other roles, the producer focuses on communication between team members, and between team members and the outside world. Sometimes this work gets misunderstood as just scheduling, but for that schedule to get planned and adjusted sensibly requires a great deal of conversations and e-mails, followed by ongoing communications to keep everyone on the same page and on track.

The Designer(s). One way to think about the designer’s role in game development is to communicate with the player through the game. Indicating what’s the goal, what will cause harm or benefit, where the player should or shouldn’t try to go next, expressing the right amount of internal state information – these are matters of a game’s design more so than its programming. Depending on a game team’s skill makeup, in some cases the designer’s only direct work with the game is in level layouts or value tuning, making it even more critical that within the team a designer can communicate well with programmers, artists, and others on the team when and where the work intersects. On a small team when the person mostly responsible for the design is also filling one or more other roles (often the programming) communication then becomes integral to keeping others involved in how the game takes shape.

The Leads. On a team large enough to have leads, which is common for a professional team, the Lead Programmer, Lead Designer, or Lead Artist also have to bring top notch communication skills to the table. Those people aren’t necessary the lead on account of being the best programmer, designer, or artist – though of course they do need to be skilled – they’re in that position because they can also lead others effectively, which involves a ton of communication in all directions: to the people they lead, from the people they lead, even mediating communications between people they lead or the people they lead and others.

Some of the most talented programmers, designers, artists and composers that I’ve met have been quiet people. This isn’t an arbitrary personality difference though. In practice it limits their work – when they don’t speak up with their input it can cost their game, team, or company.

The Writer. Not every game genre involves a writer, but for those that do, communication becomes even more important. Similar to the designer that isn’t also helping as a programmer, a team’s writer typically isn’t directly creating much of the content or functionality, aside perhaps from actual dialog or other in-game and interstitial text. It’s not enough to write some things down and call it a day, the writer and content creators need to be in frequent communication to ensure that satisfactory compromises can be found between implementation realities and the world as ideally envisioned.

Non-Development Roles. And all that’s only thinking about the internal communications on a team during development. Learning how to communicate better with testers, players, or if you’ve got a commercial project your customers and potential new hires (even ignoring investors and finance professionals), is a whole other world of challenges that at a large enough scale get dealt with by separate HCI (Human-Computer Interaction) specialists, marketing experts, PR (public relations) people and HR (Human Resources) employees. If you’re a hobby, student, solo, or indie developer, you’ve got to wear all of these hats, too!

There are two main varieties of communication issues that we tend to encounter. Although they may seem like polar opposites, in reality they’re a lot closer than they appear. In certain circumstances one can even evolve from the other.

Challenge 1: Shyness

The first of these issues is that some of us can be a little too shy. Some of the most talented programmers, designers, artists and composers that I’ve met have been quiet people. This isn’t an arbitrary personality difference though. In practice it limits their work – when they don’t speak up with their input it can cost their game, team, or company.

It’s unfortunately very easy to rationalize shyness. After all, maybe the reason a talented, quiet person was able to develop their talent is because they’ve made an effort to stay out of what they perceive as bickering. Unfortunately this line of thinking is unproductive in helping them and the team benefit more from what they know. Conversation between team members serves a real function in the game’s development, and if it’s going to affect what gets made and how it can’t be dismissed as just banter. Sometimes work needs to get done in 3D Studio Max, and sometimes it needs to get done around a table.

Another factor I’ve found underlying shyness is that a person’s awareness of what’s great in their field can leave their self-confidence with a ding, since they can always see how much improvement their work still needs just to meet their own high expectations. Ira Glass has a great bit on this:

It doesn’t matter though where an individual stands in the whole world of people within their discipline, all that matters is that developers on the project know different things than one another. That’s inevitably always the case since everyone’s strengths, interests, and backgrounds are different.

Challenge 2: Abrasiveness

Sometimes shyness seems to evolve as an overcompensation for unsuccessful past interactions. Someone tried to speak up, to share their idea or input, just to add to someone else’s point and yet it somehow wound up in hurt feelings and no difference in results. Entering into the discussion got people riled up, one too many times, so after one last time throwing hands into the air out of frustration, a developer decides to just stop trying. Maybe they feel that their input wasn’t properly received, or even if it was it simply wasn’t worth the trouble involved.

As one of my mentors in my undergraduate years pointed out to me: “Chris, sometimes when people are fighting against your point, they’re not really disagreeing with what you said. They’re disagreeing with how you said it! If you made the same point differently they might get behind it.”

He was absolutely right. Once I heard that idea, in addition to catching myself doing it, I began to notice it everywhere from others as well. It causes tension in meetings, collaborative classroom projects, even just everyday conversations between people. Well-meaning folks with no intention of being combative, indeed in total overall agreement about both goals and general means, often wind up in counterproductive, circular scuffles arising from an escalation of unintended hostility.

There are causes and patterns of behavior that lead to this problem. After 10 years of working on it, I’ve gotten better about this, but it still happens on occasion, and it’s still something that I have to actively keep ahead of.

It’s understandable how someone could run through this pattern only so many times before feeling like their engaging with the group is the cause of the trouble. This is in turn followed by backing off, toning down their level of personal investment in the dialog, and (often bitterly) following orders from the action items that remain after others get done with the discussion.

篇目5,Communication is a Game Development Skill (Part 2 of 2)

…if you communicate masterfully enough – persuasively, clearly, fairly and reasonably – then the scale and types of projects that it’s possible for you to work on expands tremendously…

Last month, in part one, I identified a couple of common points of trouble that arise for videogame developers. Communication matters! If communication skills are in bad enough shape, no matter what other technical or artistic skills have developed it’ll be hard to get others to collaborate, and hard to get players and reviewers to hear about the work. On the other end of the spectrum, if you communicate masterfully enough – persuasively, clearly, fairly and reasonably – then the scale and types of projects that it’s possible for you to work on expands tremendously, because being a good communicator is essential to winding up as a meaningful part of (or even starting and leading) any team of other developers who are bringing their own respective skills, experience, and inspiration into the picture.

Listening and Taking to Heart

You’ve heard this all your life. You’ll no doubt hear it again. Hopefully every time communication comes up this gets mentioned too, first or prominently.

Listening well, meaning not just hearing what they have to say or giving them an outlet but trying to work with them to get at underlying meaning or concerns and adapting accordingly, is way harder than it sounds, or at least more unnatural than we’d like to think. You can benefit from practicing better listening. I can say that without knowing anything about you, because everyone – presidents and interns, parents and kids, students and teachers – can always listen better.

There’s a tendency, even though we rationally know it’s out of touch with reality, to think of oneself as the protagonist, and others like NPCs. Part of listening is consciously working to get past that. The goal isn’t to get others to adopt your ideas, but rather it’s to figure out a way forward that gains from the multiple backgrounds and perspectives available, in a positive way that people can feel good about being involved with.

Don’t Care Who Wins, Everyone Wins

There’s no winner in a conversation.

This one also probably sounds obvious, but it’s an important one that enough people run into that it isn’t pointed out nearly enough. Development discussion doesn’t need to be a debate. Even to the extent that creative tension will inevitably present certain situations in which incompatible ideas are vying for limited development attention on a schedule, debate isn’t the right way to approach the matter.

In one model for how a dialog exchange proceeds, two people with different ideas enter, and at the end of the exchange, one person won, one person lost. I don’t think (hope?) that anyone consciously thinks about dialog this way, but rather it may emerge as a default from the kinds of exchanges we hear on television from political talking heads, movie portrayals of exchanges to establish relative status between characters, or even just our instinctive fight or flight sense of turf.

Rather than thinking in terms of who the spectators (note: though avoid spectators when possible, as it can often pollute an otherwise civil exchange with defensive, ego-protecting posturing) or an impartial judge might declare a winner, consider which positions the two people involved would likely take in separate future arguments.

If all of your prior references have led you to believe strongly about a particular direction, you only do that rhetorical position (and the team/project!) a disservice by creating opponents of it.

Whenever we come across as unlikeable, especially in matters like design, art, or business where a number of directions may be equally viable, then it doesn’t matter what theoretical support an option has if people associate it with a negative, hostile feeling or person.

It doesn’t matter what theoretical support an option has if people associate it with a negative, hostile feeling.

Be friendly about it. Worry first about understanding the merits and considerations of their point, then about your own perspective being understood for consideration. Notice that neither of those is about “convincing” them, or showing them the “right” way, it’s about trying to understand one another because without that the rest of discussion just amounts to barking and battling over imagined differences.

You Might Just be Wrong

Speaking of understanding one another: don’t ever be afraid to back down from a point after figuring out what’s going on, and realizing that there’s another approach that’ll work just as well or better. There’s a misplaced macho sense of identity attached to sticking to our guns over standing up for our ideas – especially when the ideas aren’t necessarily thoroughly developed and aren’t exactly noble or golden anyhow.

A smart person is open to changing their mind when new information or considerations come to light. You’re not playing on Red team competing against Blue team. You’re all on the same team, trying to get the ball to go the same direction, and maybe your teammate has a good point about which direction the actual goal is in.

You’re all on the same team…

The other side of this is to give the other person a way out. Presenting new information or concerns may make it easier for them to change their mind, even if that particular information or concern isn’t actually why they change their mind, simply because it can feel more appropriate to respond to new information then to appear to have been uncertain in the first place. Acknowledging the advantages in the position they’re holding doesn’t make your position seem weaker by comparison, it makes them feel listened to, acknowledged, and like there’s a better chance you’re considering not just your own initial thoughts but theirs too. When a point gets settled, whichever way things go, let the difference go instead of forming an impression of who’s with or against you. (Such feelings have a way of being self-fulfilling. In practice, reasonable people are for or against particular points that come up, not for or against people.)

When an idea inevitably gets compromised or thrown out, being a skilled communicator means not getting bitter or caught up in that. Don’t take it personally. It’s in the best interests of the team, and therefore the team’s members (yourself included), that not every idea raised makes it into implementation or remains in the final game.

Benefit of the Doubt, Assume the Best

A straw man argument is when we disagree with or attempt to disprove a simplified opposition position. In informal, heated arguments over differences in politics or religious/cultural beliefs, these are frequently found in the form of disagreeing with the most extreme, irrational, or obviously troubled members of the group, rather than dealing with the more moderate, rational, and competent justifications of their most thoughtful adherents. This leads to deadlock, since both sides feel as though they’re advancing an argument against the other, yet neither side feels as though their own points have been addressed.

Assume that the other person is coming from a rational, informed, well-intentioned place with their position.

When the goal is to make a more successful collaboration, rather than to just make ourselves temporarily feel good, the right thing to do is often the opposite of setting up a straw man argument.

Assume that the other person is coming from a rational, informed, well-intentioned place with their position, and if that’s not what you’re seeing from what has been communicated so far, then seek to further understand. Alternatively, even help them further develop their idea by looking for additional merit to identify in it beyond what they might have originally had in mind – maybe from where you’re coming from it has possible benefits that they didn’t realize mattered to you.

If the idea you may be holding is different than what someone else is proposing, welcome your idea really being put to the test by measuring it against as well put-together an alternative as the two of you can conceive. If it gets replaced by a better proposal that you arrived at through real discussion and consideration, or working together to identify a path that seems more likely to pan out well for both of you, all the better.

Your Frustration is With Yourself

This is one of those little life lessons that I learned from my wrestling coach which has stayed with me well after I finished participating in athletic competitions. Most of the time when people are upset or frustrated or disappointed, they’re upset or frustrated or disappointed mostly with themselves, and directing that at somebody else through blame isn’t ever going to diffuse it.

Even if this isn’t 100% completely and totally true in every situation – sure, sometimes people can be very inconsiderate, selfish, or irresponsible and there may be good reason to be upset with them – I find that it’s an incredibly useful way to frame thinking about our emotional state because it takes it from being something the outside world has control over and changes to focus to what we can do about it.

Disappointed with someone violating our trust? Our disappointment may be with our failing to recognize we should not have trusted them. Upset with someone for doing something wrong? We may be upset with ourselves for not making the directions or expectations more clear. Frustrated with someone that doesn’t understand something that you find obvious? Your frustration well may lie in your feeling of present inability to coherently and productively articulate to that person exactly what it is you think they’re not understanding.

If your point isn’t well understood or received but you believe it has value that isn’t being rightly considered, rather than assuming the other person is incapable of understanding it, put the onus on yourself to make a clearer case for it. Maybe they don’t follow your reference, or could better get what you’re trying to say if you captured it in a simple visual like a diagram or flow chart. Maybe they understand what you’re saying but don’t see why you think it needs to be said, or they get what you mean but don’t see the connection you have in mind for what changes you think it should lead to.

If your point isn’t well understood or received but you believe it has value that isn’t being rightly considered, rather than assuming the other person is incapable of understanding it, put the onus on yourself to make a clearer case for it.

Clarify. Edit it down to summary highlights (people often have trouble absorbing details of an argument until they first already understand the high level). Explain it another way to triangulate.

Provide a demonstration case or example. If there’s a point you already made which you think was important to understanding it but that point didn’t seem to stick, find a way to revisit it in a new way that leads with it instead of burying it among other phrases that were perhaps too disorganized at the time to properly set up or support it.

Mistaking Tentative for Definitive

Decisions can change. When they’re in rough draft or first-pass, they’re likely to – that’s why we do them in rough form first! It’s easier to fix and change things when they’re just a plan, an idea, or a prototype, and the more they get built out into detail or stick around such that later decisions get made based on them, then the more cemented those decisions tend to become.

There are two types of miscommunication that can come from this sort of misunderstanding: mistaking your own tentative ideas for being definitive, or mistaking someone else’s tentative ideas for being definitive. During development, and as more people get involved, projects can change and evolve a bit to reflect what’s working or what isn’t, or to take better advantage of the strengths and interests of team members.

If there was an idea you pushed for earlier in a project and people seemed onboard with it then, it’s possible that discoveries during development or compromises being made for time and resource constraints have caused it to appear in a modified or reduced form. It might even be cut entirely, if not explicitly then maybe just lost in the shuffle. Before raising a case for it, it’s worth rethinking how the project may have changed since the time the idea was initially formed, to determine whether it would need to be updated to still make sense for the direction the team and game has gone in.

Sometimes the value of ideas during development is to give us focus and direction, and whether the idea survives in its originally intended form is secondary to whether the team and players are happy with the software that results. It may turn out to be worth revisiting and bringing back up, possibly in a slightly updated form, as maybe last time was at a phase in development when it wasn’t as applicable as it might be now. Or it may be worth letting go as having been useful at the time, but perhaps not as useful now, a stepping stone to other ideas and realizations the team has made in the time that has passed.

People get optimistic, people make planning mistakes, and people cannot predict the future – but it’s important to not confuse those perfectly human imperfections with knowingly lying or failing to keep a promise.

The other side to this is to make the same mistake in thinking about someone else’s ideas: thinking they are definitive when they are necessarily tentative. This happens perhaps because of how far off the idea relates to the future, and how much will be discovered or answered between now and then that is unknown at the time of the initial conception and discussion. If a project recruits people with the intention of supporting a dozen types of cars, but during development reality sinks in and only three different vehicles make sense in favor of putting that energy into other development necessity, those things happen. People get optimistic, people make planning mistakes, and people cannot predict the future – but it’s important to not confuse those perfectly human imperfections with knowingly lying or failing to keep a promise. If early in a project someone is trying to spell out a vision for what the project may look like later, don’t take that too literally or think of it as a contract, look at it as a direction they see things headed in. Implementation realities have a way of requiring compromise along the way.

Soften That Certainty Away

A common source of fighting on teams is from a misplaced sense of certainty in an observation or statement which reflects value priorities that someone else on the team doesn’t necessarily share, or especially when the confidently made statement steamrolls value priorities of someone else on team.

Acknowledge with some humility that you only have visibility on part of all that’s going on, and that the best you can offer is a clarification of how things look for where you’re coming from or the angle you have on things. Leave wiggle room for disagreement. Little opening phrases like “As best as I can tell…” or “It looks to me like…” or “I of course can’t speak for everyone, but at least based on the games that I’ve played in this genre…” may just seem like filler, but in practice they can be the difference between tying the team in a knot or opening up valuable discussion about different viewpoints.

Consultant’s Frustration

School surrounds people with other people that think and work in similar patterns, with similar values, often of the same generation. Outside the classroom, whether collaborating on a hobby game project, joining a company, or doing basically anything else in the world besides taking Your Field 101, that isn’t typically how things work. Often if your skills are in visual art, you have to work with people that don’t know as much about visual art as you. If your skills are in design, you’ll have to work with a lot of non-designers. If you have technical talents, you will be dealing with a lot of non-technical people.

That is why you are there. Because you know things they don’t know. You can spot concerns that they can’t spot. You understand what’s necessary to do things that they don’t know how to do. If someone else on the team or company completely understood everything that you understand and in the same way, they wouldn’t really need you to be involved. Your objective in this position is to help them understand, not to think poorly of them for knowing different things than you do. Help them see what you see. Teach a little bit.

That is why you are there. Because you know things they don’t know… Your objective in this position is to help them understand, not to think poorly of them for knowing different things than you do. Help them see what you see.

I refer to this as the consultant’s frustration because that’s a case that draws particular emphasis to it: a company with no understanding of sales calls in a sales (or design, or IT, or whatever) consultant, because they have no understanding of that and that’s why they made the call. A naive, inexperienced, unprepared consultant’s reaction to these situations is one of horror and frustration – how on Earth are these people so unaware of the basic things that they need to know? The consultant is there to spot that gap and help them bridge it, not to look down on them for it. Meanwhile they’re doing plenty of things right the specialist likely doesn’t see or fully understand, because that’s not the discipline or problem type that they’re trained and experienced in being able to spot, assess, or repair.

When you see something that concerns you, share that with the team. That is part of how you add value. You may see things that others on the team do not.

Values Are Different Per Role

The other side to the above-mentioned point is appreciating that other factors and issues less visible to your own vantage point may have to be balanced against this point, or in some cases may even override it.

Frustration can arise from an exaggerated form of the consultant’s frustration: a programmer may instinctively think of other roles on the team as second-rate programmers, or the designer may perceive everyone else on the team as second-rate designers, etc. This is not a productive way to think, because it’s not just that they are less-well suited to doing your position, but you’re also less-well suited to doing theirs. A position goes beyond what skills someone brings to move a project forward, it also brings with them an identity and responsibility on the team to uphold certain aspects of the project, a trained eye to keep watch for certain kinds of issues. The programmer may not be worried about the color scheme, the artist may not be worried about how the code is organized, the designer may not care about either as long as the gameplay works.

…a programmer may instinctively think of other roles on the team as second-rate programmers…

That’s one of the benefits of having multiple people filling specialized roles, even if it’s people that are individually capable of wearing multiple hats or doing solo projects if they had to.

In the intersection of these concerns, compromises inevitably have to get made. The artist may be annoyed by a certain anomaly in how the graphics render, but the engineer may have a solid case for why that’s the best the team’s going to get out for the given style of the technology they have available. The musician or sound designer may feel that certain advanced scoring and dynamic adjustment methods could benefit the game’s sounds cape, but the gameplay and/or level designer may have complications they’re close to about user experience, stage length, or input scheme that place some tricky limits on the applicability of those approaches.

One of the reasons why producers (on very small student/hobby/indie teams this is often also either the lead programmer or lead designer) get a bad rap sometimes, as the “manager” that just doesn’t get it, is because their particular accountability is to ensure that the game makes forward progress until it’s done and released in a timely manner. So the compromise justification that they often have to counter with is, “…but we have to keep this game on schedule” which is a short-term version of “…but this game has to get done.” If someone isn’t fighting that fight for the project, it doesn’t get done.

Be glad that other people on a team, when you have the privilege of working with a good and well-balanced team, are looking out for where you have blind spots. Push yourself to be a better communicator so that you can help do the same for them.

Too Much Emphasis on Role

After that whole section on role, I feel the need to clarify that especially for small team development (i.e. I can total understand military-like hierarchy and clarity for 200+ person companies) role shouldn’t pigeonhole someone’s ability to be involved in discussions and considerations.

While it’s true that the person drawing the visual art is likely to have final say on how the art needs to be done (not only as a matter of aesthetic preference, but as a side effect of working within their own capabilities, strengths, and limitations), that does not mean that others from the team shouldn’t be able to offer some feedback or input in terms of what style they feel better about working with, what best plays to their own strengths and limitations (ex. just because an artist can generate a certain visual style doesn’t mean the programmer’s going to be able to support it in real-time), and what they like just as fellow fans of games and media.

Does one team member know more about animation than others on the project? Then for goodness sake, of course that person needs to be involved in discussions affecting the implementation or scheduling of animation. But even if you’re not an animator, that you’ve accumulated a different set of media examples to draw upon, and have an idea for how that work may intersect with technical, design, or other complications, there’s still often value in being a part of that discussion (though of course still leaving much of the decision with whoever it affects most, and whoever has the most related experience).

It’s unhelpful to hide behind your role…

It’s unhelpful to hide behind your role, thinking either “Well, I’m not the artist so that isn’t my problem” or “Well, I’m the designer, so this isn’t your problem to worry about.” The quality of the game affects everyone who got involved with making it. You make a point of surrounding yourself with capable people that are coming from different backgrounds and have different points of view to offer. Find ways to make the most of that.

A related distinction to these notes about role is the concept of servant-leadership. Rather than a producer, director, or lead designer feeling like the boss of other people who are supposed to do what they say, it can be healthy and constructive for them to approach the development as another collaborator on the team, just with particular responsibilities to look out for and different types of experience to draw from. They’re having to balance their own ideas with facilitating those of others to grow a shared vision, they’re trying to keep the team happy and on track, that’s their version of the compiler or Photoshop.

Handling Critique Productively

When critique comes up – whether of your game after it’s done or of a small subpoint in a disagreement – separate yourself personally from the point discussed. When people give feedback on work you’re doing, whether it’s on your programming, art, audio, or otherwise, the feedback is about the work you’re doing, it’s not feedback about you (even if, and let’s be fair here, we could all honestly benefit from a little more feedback about ourselves as a work-in-progress, too!).

Feedback is almost always in the interest of making the work better, to point out perceived issues within a smaller setting before it’s too late to fix the work in time for affecting more people, or before getting too far into the project to easily backtrack on it. Sometimes the feedback comes too late to fix them in this case, in which case rather than disagree with it accept that’s the case and keep it in mind to improve future efforts (this isn’t the last game or idea you’re ever going to work on, right?).

Defensiveness, of the sort mentioned in the recent playtesting entry, is often counterproductive, or at lease a waste of limited time and energy.

Systems and Regular Channels

Forms and routine one-on-one check-in meetings can feel like a bureaucratic chore, but in proper balance and moderation they can serve an important function. People need to have an outlet to have their concerns and thoughts heard. People need to be in semi-regular contact with the people who they might need to raise their concerns with, before there is a concern to be raised, so that there’s some history of trust and prior interaction to build upon in those cases and it doesn’t seem like a weirdly hostile exception just to bring up something small.

In one of the game development groups I’ve been involved with recently we were trying to narrow down possible directions for going forward from an early stage when little had been set into action yet. From just an open discussion, three of the dozen or so ideas on the whiteboard got boxed as seeming to be in the lead. When we paused to get a show of hands to see how many people were interested in each of the ideas on the board, we discovered that one of the boxed items had only a few supporters – those few just happened to be some of the more vocal people in the room. Even introducing just a tiny bit of structure can be important in giving more of an outlet to the less outspoken people involved with a project, who have ideas and considerations that are likely just as good and, as mentioned earlier, probably weighing different sets of concerns and priorities.

Practice, Make Mistakes to Learn From

Seek out opportunities to get more practice communicating. In all roles, and at all scales. As part of a crowd. In front of a crowd. In formal and informal settings. Out with a few people. Out with a lot of people.

Now, for personal context: I don’t drink. I don’t go to bars or clubs. I’ve admittedly never been one for parties. This weekend I have no plans to watch the Super Bowl. I’m not saying you should force yourself to do things that you don’t want to do. What I am saying is to look for (or create) situations where you can comfortably exercise your communication abilities. Whatever form that may take for you.

Seek out opportunities to get more practice communicating.

Given a choice to work alone or work with a group, welcome the opportunity to deal with the challenges of working with a group. Attend a meetup. Find some clubs to participate in. When a team you’re on needs to present an update, volunteer to be the one presenting that update.

Communication is a game development skill. As with any other game development skill, you’ll find the biggest gains in ability through continued and consistent practice.


上一篇:

下一篇: