篇目1，分享工作室协调团队分工需知的6个要点

作者：Samuel Rantaeskola

随着团队规模增大，协调各成员的工作也会变得困难。作为游戏从业者，我们非常擅长将小项目从概念做成成品。但是，当团队规模大到一定程度，许多看得见看不见的障碍和麻烦就露出苗头了。大规模团队如果没有运作项目的经验，就会非常阻碍行业的发展。

1、达成一致

在小团队里，各成员之间的持续交流是激发灵感、提高积极性和达成共识的有效方法。然而，在团队成员上百，再加上设计文件并非人人都看过的情况下，单纯依靠成员之间的交流就必然导致项目失败。游戏设计和制作计划之间的紧密联系是保证将高级概念转换成实际产品的关键。

当然，保持“是什么”和“怎么做”之间的联系只能达到一半的目标。达成最终目标的首要方法应该非常清楚，让整个团队都明确。这样，团队才能够既保持工作进度，又不断萌生创意。

2、决定组织

在制作早期阶段，你应该考虑如何组织整个项目。当游戏还在制作时，你如何对它进行排错？记住，当你允许项目组的成员时，应该适当地扩充排错人员。另外，最好能尽制定工作流程，而不是等到有需要时才确定。工作流程可以帮助你计划进度。

3、细分问题

对于大多数团队，这是必须考虑的，但有不少团队仍然把项目当作一个大型拼图游戏。他们费了大量精力，试图最大程度上优化资源配置和管理，但在这样一个信息丛林里，这各方式是不可能产生好决策的。因为他们面临的困境在于，如何从一个大问题中细分出保持尽可能互相独立的小问题。

4、根据问题分配职能

理论上，似乎所有人都很熟悉交叉职能团队，但实际上，混合团队职能是极其危险的。这种形式其实是游戏行业中的落后习惯。如果能控制好交叉职能部门的规模，添加一两个成员产生的麻烦也不会超过在细分职能部门的组织结构中添加成员。并且，如果团队之间的依赖性较小，管理上的开支也会相对少。

5、下放决策权

你应该接受现实：你会失去控制权。自上而下的管理层级结构可能“适用”于小团队，但在大型开发环境下，极其容易出错和导致效率低下。你很快会意识到，这种形式很有风险，即使不能完全淘汰，也必须改革。大型开发团队从休闲游戏工作室的“鸟枪法”中吸取了经验， 也就是独立团队在自己的职权范围内行使决策权。在这种环境下，就不存在拖延团队工作进度的外部干扰了。自然而然地，休闲游戏开发团队非常适合这种管理方式。当然，如果能尽早把问题细化，以及下放权力，大游戏开发团队也能采用这种模式。

6、一个团队就是一个小单位

不要在管理个人上浪费时间了。信任你的团队会做好自己的份内事。在执行项目的某个任务时，个把人可能并没有参与，因为他等着团队中的其他人完成这个阶段的任务。相信我，他可能想到成千上万他可以为项目做的事。毕竟你的团队成员基本上是人才。

篇目2，游戏公司CEO应该避开的11个陷阱

作者：Nick Hatter

在我创建giftgaming之前，我只是喜欢游戏。因为非常喜欢游戏我才开始开发游戏。13岁的时候我便开始使用DarkBASIC。18岁我开始基于Java创造《俄罗斯方块》。21岁的时候我使用了Unity。23岁开始使用Marmalade。我的生活重心似乎始终围绕着游戏开发。

在过去10年间我开发了许多游戏，不管是休闲游戏还是第一人称射击游戏。在完成计算机科学的BSC后，我开始进行一个名为“Pilgrim”的大型JRPG项目，其灵感是来自《最终幻想VIII》。这是一个伴随着全景摄像机，战斗，库存和保存系统的项目。

但是我遇到了一个大问题：我没有资金去支持自己全职完成这个项目或支付美术师的薪资。

于是我天真地参加了Cambridge Startup Weekend希望能够接触到一些投资者。结果我遇到比我想象中更多的投资者。于是我便创建了一家初创公司giftgaming。

TechCrunch Startup BattlefieldAfter的Nick Hatter参与了剑桥贾吉商学院的Accelerate Cambridge课程，在这里我学到了如何筹集资金，如何宣传，如何提防法律问题，如何聘请员工（与解雇员工），所有的这些都是开始一项新业务所必要的元素。

我知道接下来我将获得像TechCrunch和Management等媒体的报道。然后我出现在了《WIRED Magazine》上。所有的一切都快速发展着。这真的很夸张。就在上周我的初创公司被称为2015年最值得期待的10大来自剑桥的公司之一。我也在2周内便获得了30万英镑的资金。我甚至差点忘记自己开始做这件事才1年左右的时间。

就像我的一个导师所说的那样，这是一次“严峻的考验”。但在这一年时间里，我真的学到了许多。不管是关于业务，人，我自己还是生活。从一名独立开发者变成一名首席执行官需要一次“巨大的突破”。

应该避免的11大陷阱：

1.想要达到完美

我已经创造了7款完整的游戏。而我真正发行了多少游戏呢？只有1款（《Thundrclap》）。因为我很害怕创造一些并不完美的内容。其实你应该发行任何内容。然后问自己某一功能是否真的必要。用户是否真的会注意到它？你将会惊讶于所得到的答案。

2.在团队中平等划分股权

我们并非完全平等。基于经验，时间，技能等等元素，人们带给团队的价值也会不同。做到公平的一种有效的方法便是使用“分配公正”原理，如基于上述所有参数让团队基于每个领域以10分为点数进行划分。然后通过整个团体的点数去划分其中每个成员的点数。这将帮助你确保每个团队成员享有相应的分配。

3.让创始者轻易拿走股权

你应该让每个创始者签订一份带有“行权计划”的股东协议书。行权计划是关于“如果你在X年之前离开，你便只能获得Y%的股份”。最理想的情况是，每完成一年的工作，创始人只能拿走其股份的25%。所以如果创始人在1年以前便离开公司，那么他们将不能分配到任何利益。这听起来是否太过苛刻了？并没有。这是很公平的做法。我便见过一些初创公司因为联合创始人带着大量股权离开而被迫关闭的情况。你可以基于Lawbite（游戏邦注：为中小型公司提供在线法律服务）以一个合理的价格定制专属的股权协议书。

4.没有正式的知识产权所有权

如果任何人为你的游戏创造部分内容，你就需要确保到底是谁拥有这些内容的所有权。即使你向对方付钱，他们可能仍拥有内容所有权。而IP转让协议能够帮助你正式拥有内容的所有权。不过你还是需要寻求适当的法律咨询。

5.花费太多时间于竞争中

竞争可以是一种有效的PR方式。但这同时也需要花费大量时间，并可能分散你的注意力。每当看到那些已经拥有自己初创企业的创业家参加startup weekends去思考其它创业理念时我都很困惑。我认为这一点意义都没有。这就像是已经结婚的人还去参加速配活动一样。是的，这么做是有趣的。但是你将会因此分散注意力。如果你正致力于一款游戏，特别是身处一个团队中，你就应该全身心投入于游戏中。这才是你的主要工作。如果你不能保持注意力，你可能最终便难以完成并发行游戏。

6.不睡觉或不运动

“具有创造性的人总是最严重的”这是我的一位导师在在谈到睡眠不足时所说过的一句话。你必须拥有足够的睡眠与运动。只有这样你才能拥有健康的身体与思维。当你拥有健康的心理状态（如足够放松）时，你便能够有效地发挥创造性。而如果你始终睡眠不足，你便很难发挥创造性。

7.失去激情

就像有些人只关心最底层的财政面，而不再享受自己的工作。这在游戏开发中也是如此。创造你想要创造的游戏，这便是你真正的激情所在，即使你创造的并不是一款赚钱的复制游戏。从统计来看，你的游戏获得成功的几率很低（就像任何初创企业所面对的那样），所以你至少还能够享受创造游戏的乐趣。。而如果这正是你的激情所在的话，你便更有可能继续下去，直至情况变得更加艰难，并且你有可能比以前更加努力地执行工作。成功不一定是基于金钱—-这取决于你自己的定义，有可能是来自用户的好评，拥有一个立基用户基础或者拥有自己的游戏品牌等等。

8.认为自己可以做任何事

作为一名CEO，我在这点上就表现得很糟糕。不幸的是，不管你拥有多少才能，总是存在一些你并不擅长的事。你不可能成为任何事物的专家。对于你来说更好的方法是去寻找真正的专家并告诉对方你需要他们做什么事，退后一步让他们能够执行工作。说真的我们一天所拥有的时间并不多，特别当你还是一名兼职独立开发者时。你应该组建一个团队。是的，很少出现真正成功的独行者，拥有一支团队而获得成功的几率更高。并且团队工作总是会更有趣。想想如果你是一个人工作的话每天晚上都要独自面对屏幕做事该多难受啊。或者你也可以选择与好友一起致力于游戏创造中。

除此之外，团队还是筹集资金的重要元素。大多数投资者都不愿意投资于独立个体（但也存在例外）。

9.认为演示版本总是有效的

我还记得之前向导师呈现giftgaming早期原型的情形。在30分钟的会议中，我将所有时间都用于运行游戏原型。我本来应该呈现游戏玩法的相关视频和截图。“啊，它昨天还好好的”这是我经常听到的一句话。你应该在演示的时候使用截图或视频。如果你必须展示一个演示版本的话，也请先准备好截图备份。因为很多时候当你迫切需要使用技术或多媒体时，它们总是会突然坏掉。

10.相信否定者的意见

当我刚开始创建giftgaming时，便有人跟我说我是不会成功的。他们认为：“当一个品牌或游戏发行商能够进行直接交易的时候他们怎么可能还会与你合作呢？”时间能告诉我们答案。我们往往需要花费许多时间去结束与一个品牌的直接交易。品牌和游戏发行商（当然是较为小型的发行商）通常都没有足够的时间去管理这些关系，更别提为自己的游戏寻找适当的品牌。这便是giftgaming能够做到的。千万不要低估创造一个强大的广告平台所需要投入的时间。

现在我们已经拥有超过15个主要品牌，并且我们也开始收到来自世界各地游戏工作室的自助注册。如果我相信那些否定者的意见的话会怎样？如果我未进行研究的话会怎样？我的生活可能会一成不变。否定者是危险的存在，是创新的大敌。如果你拥有一个新的游戏理念，请谨慎对待他们的看法。全新理念总是能够改变一切。

11.未采取建设性的反馈

又名“我的孩子并不丑！”这与上一点有点矛盾，但是如果有人能够提供给你有帮助的反馈，这将非常重要。认真聆听游戏早前反馈。也许你需要重新思考机制的设定。也许游戏玩法或控制不如你想象中的那样具有直觉性。不管好坏，你都需要接受所有具有建设性的反馈。并从中获得学习。有时候听到批评总是会难受，但这总比你因为不想听到批评而导致游戏变得更糟糕好受多了。

这便是游戏开发者应该避开是11个陷阱。事实上并不只有这些陷阱。但如果你能够避开这些，你便能够在任何企业中（不只是独立游戏）获得成功。

篇目3，Wooga成员揭秘公司自主化的团队工作方式

作者：Jesper Richter-Reichhelm（社交游戏公司Wooga工程主管）

去年底有篇描述Spotify如何使用分散处理方法管理部落和小组的文章深深吸引了我。它让我认识到我们并非使用这种方法的唯一团队，我希望在此讨论这篇文章所说的一些理论。

我还想借此说明，我们完全有可能在小型自治团队中采用真正的敏捷工作环境。这并非小事一桩，它需要我们每天都付出精力来保证这种结构顺利运行。以下就是我以自己在Wooga的工作经历为例，对保持团队独立性为何有助于衡量一家公司优劣的总结。

Wooga现状及愿景

Wooga成立于2009年，其愿景是到2020年，所有人都将成为游戏玩家。我们四年前大约20名成员，现在员工（来自40多个国家）已经超过250人，大家都在柏林工作室办公。
员工规模壮大是公司经济成功的一个副产品，在这个成长过程中，我们面临的最大挑战却是不要丧失我们所建立的企业文化。在早期阶段，公司中每个人都紧密合作，也不需要因为等待审批结果而拖延进度。通常来说，随着公司发展壮大，管理层的增加，这种工作方式就会发生变化，并且趋于低效率。

我们该如何守住这种文化？答案就是：一切以独立游戏团队为中心。我们曾对这种方法产生怀疑，但我们相似这至少值得一试。

Wooga是一个由许多小型独立团队组成的集合体，每个团队都要负责制作和运行一款游戏，并在跨职能和自治环境下自主制定决策。他们可以自由分享心得，无需相互较劲，这意味着他们能够在一个大型框架中像小型独立创业团队一样高效执行工作。

他们可以自己决定听从还是忽略外部建议——即使这些建议来自公司创始人。这种方法只适用于杰出的人才。所以雇佣正确的人就是我们在Wooga最重要的事情。我们相信“用人不疑，疑人不用”这个道理。事实证明这个原则非常管用。

团队

团队是Wooga组织的核心。70%员工是游戏团队成员。公司还有部门主管，例如两名负责不同领域的工程主管，以及其他监管各自部门工作的主管。

其余员工则负责提供营销、客服支持和本土化（20%）或者HR、PR、金融、商业分析等中心服务，以及维护游戏的简单服务。“服务”是这里的关键词——这些团队要支持游戏团队，而不是后者服务前者。例如，公司没有专人预算处理流程，游戏团队可以自主决定相关发布日期。

每个游戏团队都有一名产品主管负责为团队制定最终决策。这可以确保团队总能快速制定决策，公司高管也不会成为干预其决策的瓶颈。这实际上是核心管理层对团队的授权。从团队希望制作哪种游戏，到团队打算如何自我管理，都由游戏产品主管来决定。

公司中的团队小至1-3人，首先入伙的人通常会成为未来的项目领导，并提供游戏的最初理念。他们会开发一个可评估并且可试玩的原型。如果原型不够好，团队就会重新开始。如果它看起来极富潜力，团队就会逐步扩大规模，但会尽量将其控制在10人以内。

在游戏上线之后，团队规模会保持稳定或有所增长。更多游戏功能的开发不会拖延开发过程，但会从在线数据分析、A/B测试中提取额外信息，并且需要管理整款游戏。

共享知识

重点在于，即使这些团队是独立动作，并且会相互比较KPI，他们之间却并不会相互竞争。他们之间会经常交换知识和经验。这也正是我们影响独立团队创新（以及弥补独立团队所带来的风险）的方式。

每个团队每周都要开展一个5-10分钟的会议，向公司其他成员报告自己的进度，说明自己的收获（例如之前的A/B测试结果，或者宣布游戏新功能）。这种会议并不限制团队成员所分享的信息类型，只要其分享的是对他人有益的结果即可。

此外，任何人都可以参与这些会议。我们可以在游戏中尝试新事物，如果它们具有可行性，其他团队也可以效仿。

另一种层面的知识交流发生于同个学科的成员之间。我们每月会织织一次内部快闪演讲（5分钟），公司任何人都可以上台说说自己想分享的内容，任何人都可以参与这种演讲。这是一种传播信息，在公司中展开讨论和增强联系的好方法。我们还有针对后端开发、前端开发、游戏设计、商业分析和美术的专门会议。

如果一个话题太复杂，无法在快闪演讲中解决时，就可以在“便当演讲”中提出，此时的参与者在发表25分钟的演讲之后可以得到一次免费的午餐。公司中有半数人参与这种演讲，我们每个月会举办一次这种演讲。

我们会在大礼堂举办这种“便当演讲”，而公司每周例会则在周一早上展开。在这种15分钟会议里，大家会给予新人温馨的问候，或者公布公司战略，宣布游戏发布等消息。这是每周重要的开端，有助于公司中的每个人都获得相应的知情权。

协作

由于团队具有跨职能特点，大家就有了广泛可用的一系列技能，紧密合作的成员也由此组建了优秀的团队。但我们的理念并非让一人独自了解和决定一切，而是让每个团队成员都负起推动游戏前进的责任。

团队本身就有自治权，无需根据其他团队的情况来创造和运行自己的游戏。因此，开发团队在使用由商业分析服务团队提供的共享服务，以及一些标准KPI时要自己进行分析。与之相似，公司中也不会有运行/管理团队帮助他们运行服务器或其他基础设施，而是由编写软件的人自己来运行。公司也不会迫使工程师共享或重用代码，不存在人人必须使用的中心框架。

如果工程师想重用代码，可以访问github中的私人和公共套件库，但他们也可以选择自己重新做起。这是一个折衷方法：我们有时候会白费力气重复工作，但整个公司仍然更为灵活而创新。新团队开工时，原来的团队进度并不会被拖延，整个通信开销也仍然保持在较低水平。

凡是听说过Dunbar相关理论的人都应该知道，当一个群体成员超过150人时，其团队凝聚力就会开始下降。Wooga要求团队成员积极与其他游戏团队互动，相互学习经验，了解其他团队之前掌握的教训。为促进团队沟通，我们将团队一起整合到工作室中。这是我们正在执行的一个战略，目前来看效果理想。

敏捷方法

我们认为敏捷开发并不是指运用特定方法，而是遵从正确的原则，并持续反思自己是否执行了正确的方式。

所以，这里并不存在团队开发软件的统一流程。团队可自主决定如何行事，不过他们通常会结合Scrum和Kanban元素来开发内容。

但这也存在一定约束性：

*团队需要在每周例向公司其他人汇报进度和收获。

*较小的原型团队需要通过批准之后才能开发完整的游戏。大量原型都没有通过这个阶段，这让我们能够在较短时间内测试大量新游戏理念。“失败”正是这个阶段的一部分。公司会分享从被取消游戏项目所得到的经验和教训。

*公司所有人都可以共享所有源代码。

*公司任何人都可以了解所有KPI和参数。

*我们希望大家根据常识来思考和决策。我们试图避免形式化的流程，因为规章制度并不灵活。我们也有一些引导个人决策的普遍原则，有时候也会给予必要的提供，但总体来看这些方法还是很管用。

总结

我是在2009年Wooga还只有10个人时就加入了公司。随着时间发展，创始人希望让Wooga成为一个人人为自己的工作、团队和公司负责的集体。保持独立性和自治性就是我们在Wooga的普遍工作方式。

所以我们的企业文化很强调自主权，公司信任大家能够制定正确的决策，并且多数时候，他们也确实做出了正确决策。当然，人也难免偶尔犯错，但因为大家并不会避讳这一点，所以他们可以很快纠正问题。

篇目4，Valadares谈团队理念、社交游戏发展及企业文化

作者：Vlad Micu

Playfish伦敦工作室总监Jeferson Valadares及其团队肩负沉重使命。他们的任务是：理清社交游戏的未来发展方向。在Valadares看来，这意味着他们需在游戏中融入更多社交情 感和故事元素。Valadares表示，“第一代游戏主要关乎竞争和排行榜元素，我们正在观察这类游戏的未来发展态势及要如何充分利用Facebook有 所变化的用户体验。”Valadares在某次采访中谈及如何将团队视作企业单位进行管理，分析社交游戏领域的下步发展，及要如何在全球范围内经营公司文化。

团队管理

Valadares表示，“我们投入众多时间试验自己的上线游戏。每周游戏都会呈现新元素。发行过众多作品及拥有庞大用户基础的优点是你可以在不同游戏中试验这些内容，查看其运作情况。”各Playfish团队都将项目视作小型企业进行管理，此过程让他们得以轻松获悉什么新功能能够顺利运作。各团队会将运作顺利的功能植入自己的作品中。

Valadares表示，“现在公司已有团队开始着手新项目，这些团队正在试验不同类型的游戏构思。”Valadares工作室的一个新团队尝试通过更具合性质的方式体验社交游戏。据Valadares表示，这旨在弄清此模式如何在减少玩家参与游戏所需好友数量的同时提高他们之间的社交关系。Valadares表示，“玩家无需和10位同事共同操作内容，只需和3位好友合作。”

质量>数量

随着越来越多公司开始涉足社交游戏，社交游戏领域在过去几年获得显著发展（游戏邦注：Valadares从此发展趋势中看到积极的一面，他不仅鼓励同事进行更多尝试，同时希望看到更多业内人士这么做）。

他表示，“当行业日益扩大，业内人士就能够制作出并非瞄准大众用户的独特内容。很多走此路线的人士最终都获得成功。”

除更多尝试外，Valadares还发现，行业涌现更多融入合作模式的作品。这是否能够转化成社交游戏还有待分晓。Valadares表示，“这可能实现，但我不确定这能否在短期内达成，因为我们所处的位置越尖端，所要进行的运算就越多。除非我们转而运用OnLive之类的服务，这样你就不需要借助强大计算机呈现内容，行业就会涌现富有社交性的尖端内容。”

新鲜的灵感

Valadares表示，“有时我们会参考棋盘游戏。这类游戏的优点在于其包含优质故事内容。这通常颇吸引眼球。”Valadares希望社交领域未来能够包含若干元素。“能够出现杰出的故事游戏，因为用户非常一直都非常看重故事元素，我觉得这种情况会一直持续下去。所以我们要如何在社交体验中更凸显此元素？行业已进行若干粗略尝试。”

Playfish文化

获得显著发展后，Valadares的伦敦工作室努力维持自己的公司文化。Valadares表示，“我们获得显著发展，2009年只有3位员工离开公司。我觉得这非常好。我们持续广泛招募人员。公司和我刚加入时相比扩大了4倍（游戏邦注：1年多前公司规模还很小）。”

由于获得显著发展，Valadares不断问自己：“我们要如何庆祝此成绩，同时牢记工作室的最初目标。”随着公司新工作室在全球各地纷纷成立，Playfish人员正努力维持着相同的公司文化。Valadares表示，“在伦敦，各成员都很清楚公司的发展变化，但要将其他工作室联系起来则就困难许多。我们既积极寻求发展，同时又努力维持我们最初的创新精神。”

但就Playfish各地区工作室的特殊文化来说，有些文化差异性应受到推崇。Valadares解释称，“在中国，工作室成员偏好某些游戏。过去，我们试着让他们制作西方国家的游戏，但最后发现他们更擅长制作自己理解的内容。这也是我们分别在美国、欧洲和亚洲设立工作室的原因所在。”

篇目5，影响团队发挥生产力的2大问题

作者：Marcelo Spiezzi Raimbault

游戏开发中最大的挑战并不是学习新技术，创造最佳工具或寻找乐趣。对于许多开发者来说真正的挑战和噩梦应该是如何创建并维护一支多产的团队。从逻辑角度来看，创造游戏只是正确遵循一系列步骤而已。然而游戏却是由人类所创造的而不是机器，所以情况也开始变得严重起来。

很多情况都有可能导致团队的失败。可能是个人的原因也有可能是组织的原因。理解为什么一支团队会遭遇失败比了解如何促成团队的成功更加重要。交流不顺可能会破坏团队工作：《Dark Side of Teams》便是一篇总结了可能导致团队失败的不同问题的优秀论文。而在本文中我将讨论这一论文中所提到的2大问题，即发生于学生所开发的项目《Cult》的开发过程中，并且这些问题也很有可能出现在任何游戏开发团队里。

模棱两可的目标

对于任何项目来说，模棱两可的目标可能是最大的问题。在开发阶段，我们很容易迷失在理念，过程，细节间并忘记真正需要做的一些事。我们必须确保所有团队成员都清楚并理解特定阶段的目标。当目标并不明确时，人们很容易将时间花费在一些不必要的任务中或浪费时间做一些不正确的事。

不幸的是我们经常会忽视这一问题。首先，领导者通常更熟悉项目理念并且总是会认为其余团队成员也有相同的理解。其次，团队领导者只会专注于自己的任务而未关注其它任务也未为它们其设定明确的目标。

对于团队领导者来说，如果他们未能提供给所有团队成员明确的目标便有可能影响他们对于信任的感知。团队成员可能会认为领导者在特定任务上不够信任自己所以才未明确任务。而缺少信任的团队便等于低产能的团队。

如果没有明确定义目标，团队便不可能具有自主性，而缺少自主性的团队将很难开发自己的路线并达到较高的生产力。

缺少紧迫感

截止日期！尽管这是一个会让任何开发者大叫的词，但这却是能够推动团队生产力的必要元素。我们都知道一款游戏是永远都不可能被完成。游戏将经过不断的完善，这也是为何需要截止日期的原因。

我们很容易发现一个成功的Kickstarter项目或一款独立游戏因为缺少足够的钱而未能完成项目。通常情况下，未明确开发时间是导致这些项目失败的主要原因。人们总是会基于紧迫感而行动。如果不存在足够理由为明天做某事的话，人们便可能不会在今天做这件事。我们总是认为自己跟别人不一样，即我们会尽快完成自己的所有任务。然而在团队项目中却不是如此，特别是在游戏开发的创造性环境中。如果不存在紧迫感，项目便不可能按照我们所期待的那样快速发展并在时间到达时具有预期的表现。

创造短时间的交付成果是在团队中保持高度紧迫感的一种有效方式（游戏邦注：就像敏捷开发和scrum开发过程便非常有帮助）。我们必须牢记基本功能还未完成，这是之后需要继续完成的功能。

而截止日期问题通常也是基于模棱两可的目标之上。也就是只有拥有了明确的目标，一个项目才有可能准时完成。即使你拥有许多短期的交付成果，但是它们却不具有明确的目标，团队也不清楚它们该何时完成这项任务，那么这一切也就失去了意义。

首先你需要明确问题

我们总是能够找到全新的“关于成功团队的10大诀窍”，但是关于团队遭遇失败的原因却永远都是一样的。提高团队生产力的最佳方式便是努力处理并消除阻碍它的问题。

篇目6，分享开发团队创造迭代文化的3个要点

作者：Seth Sivak

迭代才能产生最棒的游戏，但我们该如何将其融入工作流程和文化中？这正是我们Proletariat工作室努力的方向，我们每天都在培养这种文化。以下是在你自己的团队中创造迭代文化的三个重要步骤：

1.不断评审

目标：团队中的每个人都能够以一种建设性的方式相互帮助，创造出最好的作品。

创造迭代文化的第一步是让团队成员不断评审他人的作品。虽然一开始大家会有所不适，尤其是被评审的作品尚未完工之时，但这却是在团队中建立一种反馈循环的关键。在Proletariat，我们通常是在周五进行每周评审会议，更小的团队则进行非正式的评审会议。

任务项：在开发过程中创造评审环节，让来自各个学科、领域的成员给予反馈想法。一开始可以是非正式的评审，之后可以逐步发展成自然行为。

2.不存在所谓的“完成”

目标：保持功能的弹性，以便团队成员可以在返工的时候，随着游戏发展对其润色。

持续的评审过程可以让团队自然地展示未完成的作品。下一步就是让大家清楚不存在所谓的“完成”。无论是美术、设计或代码，一切都存在改进或润色的空间。这里的尚未“完成”是指团队会在前进过程中知道自己还有机会重返原来的功能对其进行迭代。但这只适用于团队信任制作人以及进程安排的情况。

在Proletariat，我们会在备忘录中创建列表指出团队需要重新解决的问题。在每个阶段结束时，我们都会尽量留出一周时间来解决备忘录的问题，在此我们将其称为“债务周”。此时团队成员可以做自主行事，优先执行自己认为最重要的事情。

任务项：在备忘录中创建列表指出需要优化的事项。在开发过程中提供一些间歇期，以便大家有余力处理备忘录的事情。

3.放手

目标：允许开放式和诚恳的反馈，以便团队不要执拗于个人想法。

开发者难以割舍自己的某个想法，从而导致项目进程受阻的这种现象很常见。与其执拗于某个理念，还不如放手让团队其余人围绕它展开工作。

应该鼓励团队中每个人都抛出自己的想法，看看最终会产生什么结果。团队每个成员都必须清楚，当某个理念被公之于众时，它就不再属于个人想法。无论是美术、音乐、音效还是编程，各项工作均是如此。我认为最好是让大家把自己的想法传达给团队。让团队成员贡献自己的创作才华，才能更好地创造最终产品。

任务项：认真对待理念本身而非其来源。开发一种能够客观分析游戏情境中的选项的过程。

总结

创造一种迭代文化需要整个团队投入大量时间和精力。优先事项的变化当然会对开发过程带来影响，但是这种文化形成气候时，就能够推动团队每个人在积极、合作的环境中创造最好的作品。

篇目7，分享游戏制作人的7条团队管理建议

作者：Samuel Rantaeskola

我曾在一篇文章中介绍制作人常犯的错误。与教育孩子一样，父母总是会告诉孩子不能做什么，然后再说应该做什么。所以如果我只介绍常见错误而不告诉大家应该做什么，意义不大。于是我又写了本文。

我们都听说过某些个人英雄主义的制作人把整个开发过程扛在自己肩上。这些故事往往是浸润了制作人的个人牺牲的血泪史。然而读者们往往看不到该制作人后来怎么样了：这位英雄不得不花一年的时间让自己从压力综合症中恢复过来，而他的团队因为群龙无首，这一整年都处于混乱状态。这个人可能为产品的诞生做出极大的贡献，但我很怀疑他能否维持团队的长期稳定。

制作是一个领导性工作，不是项目管理；不同的制作人有不同的领导风格。有些制作人喜欢在团队面是施展作为领导的权威，而有些人偏好更平等友善的合作方式。领导风格很大程度上取决于人员构成。但考虑到大部分工作室的员工都是年轻人，制作人确实应该学习一下年轻人喜欢的领导方式。

不幸的是，本文不是一份成功的领导人的工作手册，我在此分享的建议更多地是告诉你怎么想，而不是具体怎么做。制作人必须找到最适合自己的团队和处境的方案。

1、随机应变

不存在以不变应万变的方法。这意味着制作人必须非常灵活，随机应变。他们必须知识丰富，多才多艺，这样遇到问题时才不致于不知所措。我知道这是一条很难让人接受的建议，但要成功，这个心态是必须的。

2、成为合格的倾听者

制作人的职责是让团队中的不同人才各司其职。制作人不能只顾发号施令而不听取其他人的声音。因此，我坚信优秀的领导者也必须是一名合格的倾听者。除了错过有价值的信息，光说不听的制作人还会遇到这个问题：如果下面的人觉得自己不被倾听，就不太可能服从领导。

对于性格外向的人，比如我，这一条很难做到，因为滔滔不绝也是我们的思考过程。

3、信任他人

不被信任感会导致团队成员志气低下，工作力不从心。制作人必须尽自己最大的努力让团队成员相信，他相信团队中每一个人的判断。即使他内心还是有所怀疑。这也意味着制作人必须宽容错误，因为犯错是成长的一部分。制作人应该努力帮助团队成员从错误中学习，而不是一味的批评责骂。

4、成为好老师

制作人的最终目标是建立一个没有他本人存在也能正常运作的系统，甚至是一个让他本人变得多余的系统。当团队遇到他们觉得棘手的问题时，他们通常会首先找制作人去解决。优秀的制作人会帮助团队从问题中学习解决方案，从而让团队得到成长。这样，当下次遇到类似的问题时，团队就不需要过问制作人，自己就能解决了。

5、寻找长期解决方案

有些方法只能让团队暂时摆脱困境。制作人必须不断地评估处境，并寻找问题的长期解决方案。当制作人太专注于解决具体的问题时，他就会忘记修复长期问题。制作人必须依靠团队去解决短期的问题，而把自己的精力放在与团队一起制定防止“旧病复发”的计划上。对我本人而言，这是一个大问题，因为我总是忍不住去碰那些短期问题。

6、目标驱动型

制作人做什么事都应该是目标驱动的，而不是任务驱动的。当他们把时间花在详述达到目标的路径和分配任务时，他们往往忽略了团队更擅长做这些事。描述目标和帮助团队理解为什么要完成这些目标才是难点。这让我想到最重要的一点：制作人必须记住向团队解释为什么。例如，如果要在团队中普及新的工作方式，那么就必须向团队解释这种工作方式的目标是什么。如果没有解释，团队执行效率可能会很低，因为他们看不到那么做的价值。这样，制作人推广新工作方式就得不到应有的改进效果。

7、遵守规定

这几乎不需要说；制作人是团队的一员，应该与其他人遵守一样的规定。如果规定上班时间是早上10点开始，那么那个时间一到，制作人就必须出现在办公室里。如果团队为了赶截止日期而加班，那么制作人最好也一起。领导者不能指望团队比自己付出更多心血。

我在本文中提出的建议大多专注于制作人应该如何与团队打交道。我认为为了打造一支长胜不衰的团队，制作人应该做到以上几点。然而，具体情况不同，我不认为以上建议是时时管用的。为了处理某些情况，制作人有时候会背离这些建议。但他们应该努力使所谓的“某些情况”成为例外，而不是常规。

篇目1，篇目2，篇目3，篇目4，篇目5，篇目6，篇目7（本文由游戏邦编译，转载请注明来源，或咨询微信zhengjintiao）

篇目1，How to not fail in scale

by Samuel Rantaeskola

As game teams are growing in scale there are some severe pains in coordinating these efforts. As an industry, we are quite capable and efficient at moving small scale projects from concept to a finished product. When the team sizes eclipse the century mark, many more obstacles and hindrances both seen and unseen begin to rear their ugly head. The general lack of production experience of running projects at this larger scale is handicapping us as an industry at large.

I am not claiming that the solution I’m proposing here is rocket science in anyway, but rather these are the common pain points I see and hear continuously within the games industry.

1. Unify what to do and how to do it

In a small team, continually communicating the vision of the project with each member is a battletested way to keep everyone inspired, motivated and on the same page. However, solely relying on that method when working in the hundreds and adding to that having a game design document that nobody reads, is a sure path to failure. A tight connection between the game design and production plan is one way on how you can approach breaking down the game from a high level vision into actual work. In this video, I talk about a method for achieving that: http://vimeo.com/51747636

Connecting what and how will only take you half way there. The overarching method of getting to the end goal should be basic enough to be easily explained and understood by the entire team. Within that method, the teams should be able to select the best working formula for them moving forward whilst still feeding in to the whole project.

2. Decide on a structure

In the early phases of production, you should think of how to structure your entire project. How are you going to troubleshoot it when it’s being built? Bear in mind that it needs to scale appropriately as you will add teams to it. It is also a good idea to iron out workflows early on, instead of defining them on-demand. This process will help you plan how to track progress as you are getting into production mode.

3. Subdivide the problem

For most in our industry this is given, but there are a lot of teams out there that are looking at the project as one gargantuan jig-saw puzzle. They spend a lot of effort trying to optimize resources and dependencies to the smallest detail and in that jungle of information it is impossible to make good decisions. The challenge is to create sub problems that are as independent as possible from each other.

4. Build teams around the problems

Everyone seems familiar with the concept of cross functional teams in theory, but in practice evolving to a cross functional organization is extremely arduous. Historically, it has much to do with the outdated culture in the games industry, where the tradition has been to sit with peers in silence. A cross-functional organization scales nicely, and adding a team does not increase the complexity as much as in a departmentalized organization. Resolving dependencies is within the teams and the management overhead can remain fairly sparse.

5. Decentralize decision making

Accept that you will lose control. A top down driven management style and structure “works” in small environments, but is extremely slow and error prone in large scale development ecosystems. You will quickly realize that this strategy is fraught with hazards and will need to be corrected, if not eliminated outright. Large scale development teams have a lot to learn from the casual game studios’ “shotgun approach”, in so far as, the concept of having independent teams which are the decision makers within their domain. In this kind of environment, there are no external bottlenecks which slow down the teams’ progress. Naturally, casual games lend themselves well to this style. However, with an early sub division of the problem and delegation of ownership, it can work in more complex games as well.

6. A team is the smallest unit

Don’t go on a duck hunt to optimize the hours. Trust your teams to make good calls within their area. Every now and then one of the guys in a team will be short on project specific tasks, because he’s waiting for the other guys in the team to finalize the level. Trust me; he can probably think of a million things that he could do that will add value to the game. After all you’re probably hiring talent.

篇目2，From Indie Dev to CEO: 10 Indie Pitfalls

by Nick Hatter

Before I founded giftgaming, I was just like you; I loved games. I loved them so much I started developing them. First in DarkBASIC, at the age of 13 years old. By 18, I was building Tetris in Java. By 21, I was using Unity. And by 23, Marmalade. Somehow, my life kept going back to game development.

In the last 10 years I’ve developed a number of games, everything from Casual to FPS. After finishing my BSc in Computer Science, I started a big J-RPG project codenamed “Pilgrim”, which took a lot of inspiration from Final Fantasy VIII (cliche inspiration; superb game). It was coming on great, with a fully fledged camera, battle, inventory and saving system.

There was just one big problem: I didn’t have the funds to pay myself to do it full-time or to pay artists.

So I naively went to Cambridge Startup Weekend to “make investor contacts”. But instead, I got much, much more than I bargained for. I gave birth to a startup: giftgaming. I became The Pilgrim.

Nick Hatter on TechCrunch Startup BattlefieldAfter being accepted on to the Accelerate Cambridge programme at Cambridge Judge Business School, I was taught everything from how to raise funds, how to pitch, legal issues to watch out for, how to hire (and fire) — all the staples needed for a new business.

The next thing I know, I’m getting press coverage from publications like TechCrunch and Management Today. Then I appear in WIRED Magazine. Everything moves so fast. It’s crazy. Only last week my startup was named as one of 10 Companies From Cambridge To Watch In 2015. I’m also pitching for ￡300,000 in 2 weeks time. I forget I’ve only been doing this for just over a year…

(Image above of me from TechCrunch’s Startup Battlefield)

It has been a “baptism of fire” as one of my mentors says. But in this one year, I have learnt a lot. About business. People. Myself. Life. Going from an indie developer to a CEO requires a “quantum leap”.

Before embarking on the journey to becoming an indie game studio/company, take heed of the following…

Top 10 Pitfalls to Avoid (IMHO):

0. Thinking it has to be perfect
I’ve made over 7 complete games. How many did I actually publish though? Just one (Thundrclap). Because I was too afraid of making the others imperfect. Ship something. Anything. And ask yourself, is that feature really necessary? Will users actually notice? You’d be very surprised.

1. Evenly splitting equity in the founding team
No no no! We are not all equal. Unfortunately. What tends to happen is that people bring different value to team in experience, time commitment, skill and so forth. One good way to assign equity is to use “Distributive Justice”, ie. to slice the pie is to take into account all of the aforementioned metrics, weight them, then have the team grade each other on points out of 10 on each area. Then divide each members points by the points of the entire group. This gives you the equity split for each team member.

2. Letting founders walk off with equity
It’s a very good idea to have each founder sign a Shareholder Agreement with a “Vesting Schedule”. The vesting schedule basically says “if you leave before x years, you only get to keep y% of your shares”. Ideally, you would let founders “vest” (keep) around 25% of their shares for each complete year of service. So if a founder leaves before a year, then potentially they leave with nothing. Sound harsh? It’s not. It’s fair. I have seen other startups been screwed over by cofounders leaving with huge chunks of equity, forcing them to close down. Investors will not like founders leaving with big chunks either. You can get a tailored Shareholder Agreement for a very reasonable price from Lawbite who provide an online legal service for small to medium enterprises.

3. No formal Intellectual Property (IP) ownership
If anyone does any work for your game, you must make sure it’s clear who actually owns what. Even if you pay them, they still own it. An IP Transfer Agreement allows you to formally assign “moral” (ownership) rights over. As always though, seek legal advice.

4. Too much time on competitions
Competitions can be great PR. But they can also take a lot of time, and also cause you to lose focus. I get confused whenever I see entrepreneurs who already have startups going to startup weekends to come up with another startup idea. Makes no sense to me. That’s almost like being married and going to a speed dating event. The same can go for gamejams. Yes, they’re fun. But you will get distracted. So, if you’re working on a game, especially in a team, stick to that game. It’s your significant other and you wouldn’t want to cheat on it. If you don’t keep focus, you may end up with a lot of unplayed and unpublished games like me.

5. Not sleeping or exercising enough
“Creative people suffer the worst” as one of my mentors tells me on the subject of sleep deprivation. You must get enough sleep and exercise. Both have been proven to improve well-being and thinking. When you’re in the right psychological state of mind ie. relaxed, that’s the prime time for creativity. It is very hard to be creative when you’re a sleep-deprived zombie. Trust me. I have been there.

6. Not pursuing your passion
Sounds obvious, doesn’t it? But I see it happen. Some people only care about the bottom financial line, rather than enjoying their job. Again, the same goes for your game development. Build games that you want to build, that are your true passion, even if they’re not a money-making clone game. Statistically, the chance of your game being successful is low (as is any startup), so you might as well enjoy it at least. And if it is your passion, you’re more likely to keep going even when times get tough, and you’re more likely to work harder than ever before to make it succeed. Success doesn’t have to be financial by the way — it is how you define it, whether that is critical acclaim, having a niche fanbase, your own game brand and so forth.

7. Thinking you can do everything
As a CEO, I’m guilty of this one. But unfortunately, no matter how multi-talented you are, there will always be things that you’re simply not an expert at. And you can’t be an expert at everything. It actually makes more sense to find people who are experts, tell them what you need them to do, then step back so they can do their job. There are simply do not have enough hours in the day, especially if you’re a part-time indie developer. Get a team. You need one. Yes, there are a few successful solos, but your odds of being successful as a team and not burning out is much higher. Plus a team is more fun. Do you want to be all alone every night behind a screen? Or would you rather be working on your awesome game with your friends and having a good time?

In addition, a team is absolutely essential for raising funds. Hardly any investors will invest in individuals (there are exceptions to every rule though…)

8. Thinking the live demo will work
I remember going to show my mentor an early prototype of giftgaming. In the 30 minute meeting I had with her, I spent all of the time trying to get it to work. What I should have done is recorded a video of gameplay, and taken some screenshots. “Huh, it was working last night” — A phrase I’ve heard many times. Use screenshots or video in presentations. If you absoultely have to do a live demo, have screenshot backups ready. Technology and multimedia will usually fail you when you most need it.

9. Listening to naysayers
Someone said to me when I first started giftgaming that it would never work. In their words, “why the hell would a brand and a game publisher ever come to you when they can do a direct deal?” The answer is time. It takes a lot of time to close a big deal with a brand direct. Brands and game publishers (certainly smaller ones) do not have the time to manage all these relationships, not to mention finding the appropriate brands to put in their game. That’s something giftgaming does. And don’t underestimate how long it takes to build a robust ad platform.

We now have over 15 major brands onboard and we have started receiving self-service signups from game studios worldwide. What if I had listened to that guy? What if I hadn’t done my research? My life may have stayed the same. Naysayers are dangerous, and are an enemy to innovation. Be careful listening to them if you have a new concept for your game. That one new concept could change everything.

10. Not taking constructive feedback onboard
Also known as “My baby is not ugly!” Contradicting my last point, it is also important to spot when someone is giving you helpful feedback. Listen to early feedback for your game. Perhaps the mechanic needs a bit of rethinking. Maybe the controls or gameplay aren’t as intuitive as you thought. Good or bad, take all constructive feedback onboard. Learn from it. It is painful to have to listen to criticism sometimes, but it’s more painful when your game or product is shunned because you didn’t listen.

So, that’s actually 11 pitfalls. And unfortunately, there are more. Many more. But if you can dodge these ones, I think you can be successful in any venture, not just indie games.

And maybe, just maybe, my baby might enable you to make enough money so you don’t have to look for early-stage funding (without dirtying your game up with more intrusive ad solutions). It’s best to get a team and prototype well-developed with some customers before you try to raise funds, or you end up giving too much of the business away.

篇目3，Using independent teams to scale a small company: A look at how games company Wooga works

By Jesper Richter-Reichhelm

Jesper Richter-Reichhelm is Head of Engineering at social games company Wooga. Here he gives an insight into the firm’s internal organization.

At the end of last year, a document was published that described how Spotify works using a decentralized approach of tribes and squads. Since then, the article stuck with me. It made me realize we were not alone in this approach of fostering independent teams and with this article I want to contribute to the discussion and challenge a few conceptions.

I also want to explain that it is possible to have a truly agile work environment based on small, autonomous teams. It’s no small feat though, it takes effort everyday to keep this structure working smoothly. The following is a work in progress summary of how keeping teams independent can help scale a company, using my experience at Wooga as an example.

Wooga – now and then

Wooga was founded 2009 with a vision that by 2020, everyone will be playing games. Four years ago we had around 20 employees and now there are more than 250 employees from 40 nations all working in our Berlin office.

While that employee growth is a byproduct of economic success, in the process of growing it was a big challenge to not lose the company culture we had built. In the early days everyone in the company worked closely together and were not slowed down having to wait for approvals. Normally as a company grows this changes as management layers are added, and work simply becomes less efficient.

How did we hold onto that culture? The answer: centering everything around independent game teams. We had doubts about this approach, but we believed it would be worth the effort to at least try.

Wooga is a collection of many small, independent teams. Each team is responsible for making and running a single game and is expected to make their own decisions while being cross-functional and autonomous. They should freely share learnings and don’t compete with each other, meaning they effectively act like small, independent start-ups within a larger framework.

It’s completely up to them if they want to listen or ignore outside advice – even if it’s from one of the founders. This is only possible by having great people. So hiring the right people is the single most important thing we do at Wooga. We believe in the mantra, “If in doubt, don’t hire.” That works very well.

Teams

Teams are at the heart of how Wooga is organized. 70% of employees are working in a game team. There are departmental heads, such as the Head of Engineering of which we have two who take care of different parts of that field, and others that look after their respective departments.

The rest are providing central services like marketing, customer care and localization (20%) or others like HR, PR, Finance, Business Analytics and teams that maintain simple services for persistence of games. “Service” is the key word here – those teams serve the game teams and not the other way around. For example there are no artificial budget processes and game teams can decide release dates themselves.

Each game team is led by a product lead that has the final decision for the team. This ensures a fast decision is always possible and the company can scale without top management becoming a bottleneck. In essence this is a delegation of power from central management to the teams. This starts with the type of game a product lead wants to make and ends with the way the teams organize themselves internally.

Teams start small with 1-3 people, with the first always being the future lead and providing the initial concept of the game. They develop a prototype that can be reviewed and most importantly, play tested. If it’s not good enough, the team starts afresh. If it looks promising, the team is ramped up slowly, keeping it below 10 people for as long as possible.

After going live the team size can remain stable or be increased. Further feature development does not slow down the development process but as extra information is derived from live metrics, a/b testing becomes possible and the whole game needs to be operated.

Knowledge sharing

An important point is that even though teams are independent and compare KPIs, they do not compete with each other. There is a constant exchange of knowledge and lessons learned between them. This is how we leverage the innovations made by individual teams (and compensate risks individual teams take).

On one level this is done by each team being asked to provide a 5-10 minute weekly meeting where they report their progress to the rest of the company and explain their learnings, which could be from something like previous a/b tests or new feature announcements. There are no limits or off areas regarding which information can be shared as long as others can benefit from the information.

Also, these meeting are open for every employee to attend. This way we can try out new things in one game, and when they work, that knowledge is spread to other teams. This works quite organically.

Another level of knowledge exchange is between members of the same discipline. We organize monthly internal lightning talk rounds called “5 minutes of fame” where anyone in the company can give a short talk regarding something they want to share and everyone can attend these talks. It’s a good way to spread knowledge and start discussion throughout the company and increase networking. We have specialized meetups for backend development, frontend development, game design, business analytics and art.

Whenever a topic is too complex to handle it in a lightning talk we do brown bag talks. This is a lunchtime talk where participants get a free lunch after the 25-minute talk. Half of the company usually attends these talks of which we have about one per month.

The brown bags are held in our auditorium area where our weekly company meeting takes place every Monday morning. It’s a 15-minute meeting where new hires get a warm welcome, company strategy is presented and announcements like game releases are made. It’s an important start to the week, and helps to keep everyone in the company connected and informed.
Cooperation

Since teams are cross-functional there is a wide range of skills to utilize and good teams organize themselves with members working closely together. Again the idea is not to have a single person knowing and deciding everything, but making it the responsibility of every team member to push the game forward.

Teams themselves are autonomous and do not depend on other teams to create and run their game. As a result teams do their own analytics while using a shared service provided by the Business Analytics service team and a few standardized KPIs. Similarly there is no operation/admin team to operate the servers or other parts of infrastructure. Those who write the software operate it themselves. Engineers are not forced to share or reuse code, so there is no central framework that everyone must use.

Instead, private and public repositories emerge on github when engineers want to reuse code, but they also have the option to start from scratch. This is a conscious trade-off: we sometimes reinvent the wheel and repeat mistakes, but the company as a whole is much more flexible and innovative. Existing teams are not slowed down when new teams start and the overall communication overhead remains small.

Those who have heard the theory behind Dunbar’s number will know that group coherence will start to dissolve when it grows beyond 150 members. At Wooga we rely heavily on team members proactively reaching out to other game teams to learn from their experiences and be aware of what those other teams have learned in the past. To assist communication we grouped together teams into studios. This is a work in progress strategy but so far it looks good.

Being agile

We think agile development is not about applying a specific methodology, it is about following the correct principles and to constantly reflect on whether you are aligned correctly and to correct things when necessary.

As a result there is no unified process on how teams should develop their software. Teams decide on their own how to do things, although they usually blend in elements of Scrum and/or Kanban. That means stand-ups in the morning are the standard, although variations do exist.

There are some constraints though:

Teams work in weekly iterations and present progress and learnings in weekly meetings to the rest of the company.

Small prototyping teams need to get a green light to develop a full game. A lot of prototypes do not pass this stage which allows us to play test many new game ideas in a short time. “Failure” at this stage is part of the process. Lessons learned from cancelled games are shared within the company.

All source code is available to everyone in the company.

All KPIs and metrics are available to everyone in the company.

We expect people to think and decide on their own using common sense. We try to avoid formalizing processes as the resulting rule book wouldn’t be flexible enough. There are some common principles to guide individual decisions and sometimes reminders are necessary but overall it works well.

Conclusion

I joined Wooga when we were just 10 employees in 2009. Over time the founders attitude to work lead to an organic evolution of the company based on everyone being responsible for their own work, their own team and ultimately their own company. Being independent and working autonomously are the common threads in every approach we take at Wooga.

This had lead to a culture where taking ownership is emphasized and expected. People are trusted to make the right decisions and they do make the right decisions most of the time. Of course sometimes people do make mistakes but since they don’t try to hide them it’s actually quite easy to fix things.

篇目4，Playfish’s Jeferson Valadares on teams as business units, social game evolution and managing the company’s culture

by Vlad Micu

Playfish London’s studio director Jeferson Valadares and his team have a big task ahead of them. Their mission: figure out what’s next for social games. For Valadares, that means bringing out more social emotions and narrative in games. “The first generation was about competition and leaderboards, but the second generation is more about self-expression,” says Valadares. “We’re still waiting to see what is going to be next and how to make use of the changing user experience on Facebook.” We sat down with him to talk about teams as business units, the next step in social game evolution and managing a company’s culture worldwide.

Little big teams

“We spend a lot of time experimenting on our live games,” says Valadares. “Every week, there’s always something new in a game. The benefit of having a lot of games and big audience is that you can try these things out in different games and see what works.” With each team at Playfish managing their game as a small business unit, this process allows them to easily find out which new features work well. The individual teams then take the successful features and appropriate them into their own game.

“There are teams that are starting new games now, and these are the teams that are trying different types of game concepts,” says Valadares. One of those new teams at Valadares’ studio has started to take a more collaborative approach to playing social games. According to Valadares, the goal was to figure out how this could minimize the amount of friends playing a social game, but increase the social relationship between them. “Instead of doing something with ten people you are just colleagues with, why don’t you do something with three people you’re friends with,” explains Valadares.

Quality > quantity

With an increasing amount of game companies focusing on social games, the social game space has experienced exponential growth in the past couple of years.
Valadares sees the positive side of this growth, not only encouraging his own colleagues to experiment more, but also hoping to see more of that around him.

“When the space gets this big, there is space for people to do some unique things which might not be for everyone,” he argues. “But there are enough people who are interested in that to be successful.”

Aside from experimentation, Valadares is also noticing a rise in projects that involve cooperative game modes. Whether or not that could translate into social games is still not clear. “It could be,” says Valadares. “I’m not sure whether that’s going to happen in the short-term though, just because the more high-end you get, the more computing you need. Unless we move to things like OnLive, where you don’t need a strong computer when those things take off, then we’ll see social high-end as well.”

Fresh inspiration

“Sometimes we look at board games,” admits Valadares. “The value of having good writing, a good story. It’s something that is really compelling to people in general.” There are lots of things Valadares would like to see in the social space. “A really great story-based game, because a story is something that is very strong for humans, always has been, and I suspect always will be. So how can we weave that in with the social experience more strongly? There have been a few shallow attempts.”

Playfish culture

Undergoing substantial growth, Valadares’ studio in London is very much struggling to keep their corporate culture in place. “We’ve been growing a lot, there are maybe three people who have left in the last year or so,” says Valadares. “I think that’s pretty good. We’re still hiring a lot. I think the company is four times bigger then when I joined, which was a little over a year ago.”

Because of that growth, Valadares has been constantly asking himself “how we can celebrate success and not forget the reason we do things.” With new offices starting in different areas of the world, a lot of Playfish people are moving around trying to maintain that same culture everywhere. “In London, everybody kind of sees what’s happening, but it’s harder to keep the other studios connected,” admits Valadares. “We’re still trying to grow while maintaining the creative spirit that we had in the beginning.”

But baring in mind the particular cultures of the regions each Playfish office is located in, some of those cultural variations should also be encouraged. “In China, the guys in the office like their particular games,” explains Valadares. “In the past, we tried to make them do Western games, but what we actually realized is that they’re better doing what they understand. That’s exactly why we have an office in the US, Europe and Asia.”

篇目5，Two simple factors that can compromise team productivity

by Marcelo Spiezzi Raimbault

The greatest challenge in game development is not learning new technologies, building the best tool or even finding the fun. The true challenge and nightmare of many developers is how to build and maintain a productive team. By a simple logical perspective, creating games is nothing more than following a series of steps in a correct order. However, games are made by people and not by machines (luckily!), and that’s when things can start to go really bad.

Many situations can lead to a team failing. It can go from the individual level to the organization he belongs. Understanding why a team fails can be much more important than knowing what makes a team succeeds. Communication that Damages Teamwork: Dark Side of Teams is a good paper that summarizes different problems that may lead a team to fail. In this blog post, I’ll talk about two big problems mentioned on the paper that happened during the development of Cult, a student project developed at The Guildhall at SMU, and that are likely to happen in any game development team.

Ambiguous Goals

I thought that was right… Ambiguous goals are probably the most critical problem for any project. During development, it is easy to get lost in ideas, processes, details, and forget about what really needs to be done. It is important that all team members clearly see and fully understand the goals for that particular sprint/milestone. When goals are unclear, people are likely to spend their time in unnecessary tasks or even waste time doing the tasks incorrectly.

Unfortunately, this problem may goes unnoticed. First, leads usually have a clearer idea of the project and may assume that the rest of the team also has this same comprehension. Second, team leads can focus only on their tasks and forget to give the proper attention and set clear goals for other tasks.

One important insight for team leaders is that not providing clear goals to all team members can even affect their perception of trust. Team members may think that tasks are not clear/available because the lead does not trust them enough for specific tasks. And a team without trust is a low productivity team.

Without clearly defined goals, there is no way for a team to be autonomous, and only a team with enough autonomy can develop its own path and achieve high levels of productivity.

The feeling of urgency

Deadlines! Although a word that can make any developer cry, deadlines are essential for a team tobe productive. We know that a game is never finished. Games can always be improved and that is exactly why deadlines need to exist.

It is easy to find a successfully backed Kickstarter project or an independent game that failed for not having enough money to finish the project. Usually, undefined development time is the main reason behind these failures. People mainly act based on a feeling of urgency. If there is not enough reason to do something for tomorrow, people probably won’t do it today. We may believe that we are not like everyone else, and that we do all our tasks as soon as possible. However, that is not how things happen in a team project, even more in a creative environment as game development. If there is no feeling of urgency, the project won’t move as fast as it could and may not reach the functionalities needed when the time comes.

Creating short time deliverables is a good way to keep the feeling of urgency always high in the team (Agile development and Scrum really comes in handy here!). Always keep in mind that an essential feature not finished now, is a feature that needs to be finished later.

Deadlines problems also build on top of ambiguous goals. Clear and precise goals are essential for a project to be timed right. It is pointless to have many short time deliverables if their goals are not clear and the team cannot tell when they were achieved or not.

First, understand your problems!

As a last word, there will always be a new “top 10 tips for a successful team”, but the reasons of why a team may fail will never change. The best way to increase a team productivity is to address and remove the issues decreasing it.

篇目6，Creating an Iterative Culture

by Seth Sivak

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.

The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

This is cross-posted from the Proletariat Blog

The best games come from iteration, but how can we build that into our process and culture? This is something we have worked hard to create at Proletariat and we push every day to foster this culture. Here are three important steps to creating a culture of iteration within your own team:

1. Constantly review

Goal: Everyone on the team helps each other create the best work possible in a constructive manner.

The first step in creating an iterative culture is for team members to constantly review their work with the rest of the team. While uncomfortable at first, especially when work is in-progress, it’s critical to establishing feedback loops within the team. At Proletariat, we formally do this on Fridays in our weekly review meetings (which we stream live on Twitch) and informally with smaller groups.

Action Item: Create review steps in the process where people from all different disciplines can give feedback on ideas. Start these formally and then allow them to develop organically.

2. Nothing is ever “done”

Goal: Stay flexible with features so that team members can return to past work and polish it while the game evolves.

The constant review process will get the team comfortable showing work that isn’t complete. The next step is to make it clear that nothing is ever “done”. There’s always room for improvement or polish, whether it is art, design, or code. As the game continues to evolve and features are completed, multiple passes may be required. The idea that it’s not done means that the team can move on knowing they’ll have a chance to return to features later and iterate on them. This only works if the team trusts the producers and the schedule.

At Proletariat, we build lists into our backlog that contain issues the team wants to re-address. At the end of every milestone, we try to leave a week to work on the backlog, which we call a “debt” week. Team members can work on their own, prioritizing the parts of their work they feel need the most attention.

Action Item: Build lists in the backlog with pieces that require polish. Provide frequent breaks during the development process to let the team dig into the backlog.

3. Give it away

Goal: Allow for open and honest feedback and ideas to encourage the team to not hold on to a single personal idea.

It is common to see developers struggle to let go of “their” idea, hurting the process. Instead of focusing on letting an idea go, put the focus on giving the idea away so the rest of the team can build from it.

Everyone on the team is expected to throw ideas into the pile and what comes out is the result of the process. Each member of the team must understand that the moment an idea is spoken aloud to the group it is no longer their idea. This is the same for any art, music, sound, or code. I like to think about this as not letting go of your ideas but instead giving them away to the team. Members are expected to contribute their creative talents and that is a great gift to the final product.

Action Item: Be critical of ideas but not their sources. Develop a process that can objectively analyze options in game context.

Conclusion

Creating a culture of iteration takes time and focus from the entire team. Priorities need to be shifted and changes to the process can certainly take a toll on development. However, once this culture is established, it can enable the team to push each other to create their best work in a positive, collaborative environment.

篇目7，7 Production Guidelines

by Samuel Rantaeskola

Previously I wrote a post about the common mistakes of a producer, which you can find here: Top 6 production mistakes. As with raising children, it is easier to say what not to do than to describe the opposite. Nevertheless, just writing about the mistakes is not helpful unless you take a stab at describing the proper thing to do. So here we go.

We have all heard stories about the hero producers that carried whole productions on their shoulders. The stories include components of great personal sacrifice and extreme commitment. What is often left out is what happened afterwards, a hero that had to recover a year from the stress syndromes and a team in chaos because the engine was not available anymore. This person might be the best solution to get something out the door immediately, but I doubt he is the best to build teams that function in the long run.

Producing is mainly leadership, not project management, and how to lead people differs from person to person. Leaders that are comfortable on stage might execute a lot of their leadership in front of the team, while the ones that prefer intimate environments might want to work more with one-on-ones. The type of leadership required is also highly dependent of the situation. But given that most game studios consists of quite a lot of young people, this article in Forbes about how young people want to be led is a good read if you are an aspiring producer.

Unfortunately there is not a single recipe for successful producing, any advice I can share on this topic has to be focused on how to think rather than exact advice on what to do. Anyone taking on that role of producer will have to find the best solutions for the people and situation they are in. That brings me to the first point of the list.

1. Adapt to the situation

As mentioned earlier there is no generic advice that works in every situation. This means that producers need to be very flexible and good readers of situations. They need to have a wide range of tools that they can adapt to the problem at hand. I know that this is a very hard advice to take in, but this mindset is required to be successful.

2. Be a great listener

A producer’s job is to find the wisdom in the team and make sure that is used. They cannot do that by constantly broadcasting their own message and ignoring the voice of the others. Therefore I am a firm believer that being a great listener is one of the most important traits of a leader. Apart from missing the opportunity to gaining valuable information, the talkative producer ignores the fact that people need to feel listened to in order to accept leadership. The following article explains this in more detail: Leadership & The Power of Listening.

For extroverts, like me, this is a tough advice to apply as speaking is part of our thinking process.

3. Trust people

The feeling of not being trusted will bring down the morale of any person and will also make them less likely to take responsibility for their work. Producer must do their best to show that they trust the judgment of each and every one on the team. Even in instances where they have their internal doubts. This also means that there needs to be tolerance for mistakes as they are part of the growing process. The producer should strive towards helping team members to learn from their mistakes over throwing rants.

4. Be a great teacher

The producer’s ultimate goal is to build a system that works without him, essentially making him redundant. When the team encounters problems that they are struggling with it is often tempting for the producer to take them on personally and ensure they are solved quickly. The great producer will focus his effort on aiding the team on learning from the problem so that they grow. Next time a similar situation comes up the team will be able to get through it without the assistance of the producer.

5. Seek long term solutions

Short term thinking will never get anyone out of a hole for more than a short period. The producer must continuously assess situations and look for long term solutions when problems occur. If he is too engaged in solving the problem it is easy to forget to fix the problem long term. The producer must rely on the team to solve it and spend his energy on devising a plan in collaboration with the team on how to prevent it from reoccurring. This was a big problem for me personally when I was acting as producer, as my itchy fingers really wanted to be in on the fixing.

6. Be goal driven

Everything producers do should be goal driven, as opposed to task driven. When they spend their time detailing the path to the goals and breaking that down to tasks they are usually overlooking the fact that the team is way more capable of this. The challenge lies in describing the goals and helping the team understand why it needs to be done. This brings me to the most important point of this. Producer must remember to explain why to the team. For example, if a new way of working is rolled out in the team it is as important to explain the goals of it as how it works. Without that explanation the buy in for the process will probably be low, as the team members might not see the value. On top of that the producer is missing out on the possible improvements that can come from the team if they are bought into the goal.

7. Obey the rules

This almost goes without saying; producers are part of the team, which means that they should play by the same rules as the rest. If the agreed start time is 10 AM, then the producer better be there. If the team works late for a deadline, the producer better be there. Leaders cannot expect more of the team than from themselves.

Most of the advice I have given in this post is focused on how a producer should interact with the team. These are my views on how they should think in order to build a long term successful team. However, situations differ and I do not think you can follow these guidelines all the time. Producers will often have to diverge from them and get their hands dirty in pressing situations. But they should strive towards making these situations the exception rather than the rule.