团队文化建设如何影响和改变企业的最终战斗力

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

作者：Lee Winder

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

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

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

这是为什么？

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

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

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

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

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

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

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

团队开发

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

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

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

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

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

以下是另一种情景：

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

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

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

积极开发者

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

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

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

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

解决问题

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

即辞退这些开发者。

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

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

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

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

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

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

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

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

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

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

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

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

作者：Cliff Bleszinski

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

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

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

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

“样式对比”

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

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

“边界阻塞”

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

边界阻塞有变体：

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

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

“从来没见过做得好的”

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

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

“故意唱反调的人”

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

“不过是X+Y罢了”

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

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

“以后再说”

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

“通天塔”

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

“雪崩效应”

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

“过度分析”

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

“试什么试？”

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

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

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

“保守主义者”

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

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

“但我们是XXX（“XXX”指工作室名称）

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

“我们以前就试过了”

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

“太先进了”

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

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

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

“部落首领”

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

“不在范围之内”

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

“测试把戏”

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

“学舌”

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

“长篇大论”

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

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

“邮件盲”

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

“哥拉斯”

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

“怀疑论者”

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

“先知”

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

“亚哈船长”（游戏邦注：这是小说《白鲸》中的人物，固执地想找白鲸复仇。）

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

“数据控”

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

“精神期望”

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

“无视”

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

“事不关己”

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

“园丁”

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

“漏洞仔”

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

“多个头领”

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

“打包票”

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

“随大流”

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

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

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

作者：Harvard Bonin

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

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

精益六西格玛

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

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

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

换句话说，这两者都是为了消除一些“浪费”。在精益六西格玛中，浪费被定义为“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员式沟通。如果你是一名业余爱好者，学生或独立开发者，你就得自己扮演好这所有的角色。

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

挑战1：羞怯

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

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

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

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

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

挑战2：避免争执

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

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

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

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

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

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

用心聆听

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

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

不要在乎谁赢

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

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

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

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

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

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

可能是你错了

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

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

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

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

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

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

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

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

你的挫折感会形影不离

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

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

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

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

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

将假设性误会为决定性

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

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

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

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

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

软化确定性

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

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

顾问的挫折

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

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

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

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

每个角色的价值不同

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

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

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

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

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

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

过于强调角色作用

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

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

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

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

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

有效地处理批评意见

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

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

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

系统和常规渠道

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

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

实践，从错误中汲取教训

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

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

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

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

篇目1，篇目2，篇目3，篇目4，篇目5（本文由游戏邦编译）