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

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

发布时间:2015-09-25 09:17:38 Tags:,,

篇目1,阐述King公司“快乐工作”的运营理念

作者:Jim Squires

与其他知名媒体的同行一起,我有幸参观了位于斯德哥尔摩的King工作室。这家休闲游戏巨头的代表作是《Candy Crush Saga》和《Farm Heroes Saga》。

此行我们详细地了解了他们如何成为领先的跨平台开发者,尽管这些事迹和数字令人震撼,给我们留下最深刻印象的却是:King的员工很快乐。不是“因为有媒体在这里,所以大家要摆出笑脸”的那种快乐,而是发自内心的那种快乐。目睹了他们的日常运作情况后,不难看出为什么。

下午5点下班。与游戏行业的许多公司一样,组成King团队的成员具有各种各样的背景。成员名单有很多是做过某AAA游戏的人的名字。比如,《Pet Rescue Saga》的首席制作人Henrik Sebring在进入King的Malmo工作室以前是在育碧参与制作即将推出的游戏《The Division》。如果你曾经做过AAA游戏,你一定经历过那种令人崩溃的时期——每一款游戏在发布前都要经历的“关键时刻”。

当你从事AAA/零售游戏,你必须时时追赶可怕的截止日期。为此,你可能要每周在办公室工作120个小时,直到力竭不支。这就是糟糕的现实,也是King不得不担忧的问题。因为从事社交/手机游戏开发,King可以设置自己的截止日期。产品不到发布就不算完工,如果润饰还不够就把发布期延后。因此,King的员工总是能按时下班陪家人。

collaborate(from gamezebo)

collaborate(from gamezebo)

团队合作不竞争。当一家公司内有好几支团队在做多个项目时,往往形成竞争性环境。团队A希望自己的游戏卖得比团队B的好,团队B也不甘心输比团队A。这并不是适合好好做游戏的环境。虽然King的团队承认希望看到自己的产品成为公司的“《Candy Crush》第二”,但King的整个结构是围绕“合作和分享”建立起来的。

怎么做?虽然King旗下有多个工作室且每个工作室都有自己的项目,但King努力把所有工作室都聚集在欧洲。这么做有两非常明智的理由:一是工作室都处于相同的时区,二是工作室之间可以通过快速航班往返。假设你在伦敦的工作室做《Farm Heroes Saga》,你可能有一个创意想添加到游戏中,但你不知道如何执行。因为这是一款三连消游戏,你打电话给身在斯德哥尔摩的首席制作人,看看他们有没有试过。接着你接到通知这款游戏的几位开发者来伦敦跟你一起工作几天,和你的团队一起完善想法,看看是否可行。

King的合作文化不是把你自己的游戏做好——而是把King的游戏做好。那意味着所有人其实都在一个大团队中,无论你属于哪一个工作室,在做哪一款游戏。

team(from gamezebo)

team(from gamezebo)

宽容失败。做游戏是一个要么成功要么失败的命题。有些游戏会成功,有些游戏会失败。King接受这个事实。他们在斯德哥尔摩有一个团队就是专门负责为新游戏构思创意的。或者准确地说,King有一支专业的空想家团队。

当他们想到一个想尝试的点子时,他们就会做成网页游戏放在King.com上。网站是他们的“竞技场”,也是新想法的测试基地。

如果游戏在King.com上表现良好,他们就知道这款游戏的成功只是时间问题,多亏了神奇的分析学。我不想废话太多细节,但King有一个公式可以推导某款游戏是否能够成为下一个“Saga”,是否值得重制为Facebook游戏和手机游戏。极少游戏能达到这个程度——没关系。尝试和失败是我们的学习途径;对于像King这样的游戏公司也不例外,因为这就是生活。

每个工作室不超过80人。还记得上中学时你怎么知道你的年级的所有学生的名字吧吗?虽然King正在以过快的速度成长着,但他们保证把每个工作室的人数控制在人人都能记住其他人的名字的范围内。我们都听说工作室人数不应该超过70或80。为什么?我想答案还是得回到之前提到的合作文化。如果你知道所有人的名字和他们分别干什么,你就不会老是说“喂,那谁,过来看看我设计的新关卡。”

玛芬蛋糕。我没有问过他们每天的“福利”是什么,但根据上图,应该可以猜到是美味的玛芬蛋糕。蛋糕的白色部分是白巧克力/奶酪蛋糕,馅料是巧克力酱。这种蛋糕太粘了,我只好用纸把它包成像墨西哥煎玉米卷的样子。

早上9点来工作室,我看到有几个人聚在一起,一边吃美味的早餐,一边开小会。确实,正是这样的氛围使King成为King。King不是那种让你急匆匆地闯进来扑到办公桌上的公司。在King,你与周围的人建立良好的关系。你合作,你倾听,你享受美味的早餐。也许,只是也许,你还会在这个过程中想出个把令人惊艳的休闲游戏。

篇目2,Harald Riegler谈塑造公司文化的若干原则

作者:Christian Nutt

在欧洲GDC的深入谈话中,Sproing联合创始人Harald Riegler坦白谈及塑造能够赢得尊重及带来成功的企业文化的挑战性及优点。

Riegler(游戏邦注:他管理一家65人的奥地利公司,公司主要制作免费游戏和主机游戏)表示,“正确的企业文化能够激发员工出乎意料的优点。”

他表示,遗憾的是,塑造正确的企业文化是项艰巨挑战——但塑造这一文化非常重要,每位团队成员都要清楚这点。

Riegler表示,“这一文化将决定工作室或团队的成败。糟糕的企业文化甚至会摧毁整个团队。”

虽然“近来的销量上百万管理方式”书籍给出许多建议,但Riegler对于趋势和技巧不屑一顾。他表示,“真正重要的是,着眼于人际互动、人类特性及其行为。”

“良好的企业文化是建立在若干持久原则基础上——原则对我来说不只是系列规则,它是你生活及行动方式的基础。”

但他表示,“完善企业文化需要经久不息的投入,”所以请做好进行改变的准备。

如下是他总结的原则:

尊重

Riegler表示,“要领导团队,你必须对他们怀有内在的尊重之情。”若你不尊重和你共事的人士,“那你从一开始就注定要失败。”

他表示,“若你觉得自己高人一等,”对方会感觉得到。“肢体语言是我们的主要沟通方式。”

Riegler表示,“尊重会带来相互信任的环境,信任非常重要,因为只有在相互信任的环境中,你才能够应对复杂问题。你可以公开谈论大家不想谈论的话题。”

以身作则

Riegler表示,“各种书籍都纷纷表示,如果你希望自己的孩子动手,那就自己亲自示范。”这也适用于公司环境中。

Riegler表示,反过来亦成立:“若你不希望大家这么做,那你也不要这么做。己所不欲,勿施于人。”

责任感

Riegler表示,“这点着实有些棘手。”

他表示,“要让下属变得富有责任感有些伤脑筋。”但作为经理,“我觉得唯一的方式就是,将自己变得富有责任感,进而将此引入企业文化中。”

你要怎么做?他表示,“你得告诉大家,你要着手做什么。你要愿意评估自己。”最后,“你要公开描述自己取得多少成就,这并不简单,因为你很少能够做到事事顺利。”

成熟

“成熟并不意味着你非常有经验,你是个行业元老。在我看来,成熟是指能够自我反思,清楚自己的优缺点,知道自己该做什么,该朝何处前进。”

他表示,遗憾的是,“鲜少有人能够做到这点,因为这需要诚实思考自己的性格,这会让人觉得不舒服。”

但他表示,记住,“优秀参与者通常非常清楚团队所面临的挑战”,自我诚实和自我反思在此是关键——这不仅只是完善自我以及更有眼界;它给团队及公司业务带来深远影响。

他还表示,总是会掺杂爱出风头的人士、阴险小人及强势角色。Riegler表示,“注意所有这些角色,他们非常危险。”

乐趣

他表示,“我觉得乐趣非常重要。”大家可以转投其他不那么有趣的行业,赚取更多收益,因此在游戏行业,趣味是关键。

但他表示,这并不是个不专业或松懈的行业。Riegler表示,“有时这被看作是松懈的行业——年轻人通常将乐趣和缺乏严肃性及雄心壮志混淆。”所以不妨进行你的桌上足球比赛,但要确保公司的目标保持清晰。

另一方面,“成熟和疯狂并不矛盾”(游戏邦注:怪异在游戏行业的文化中不可避免,所以不妨保持开放态度)。

自由

Riegler表示,“自由决定如何解决某任务”非常关键——“而不是采用事无巨细的微观管理方式。”

Rigeler 表示,“享有弹性上班时间,能抽出时间处理家庭问题等”非常重要。“自由给予所有成员较多自主性,互相信任的环境能够有效创造自主性,而自主性能够促使成员倍受鼓舞。”

诚实

这是最重要的元素之一,同时也是最具挑战性的一点原则。“若是犯了错误,不妨大胆承认。不要害怕。在你所处的文化中,承认失败是能够被接受的。”

他表示,缺乏可行性的环境是“怪罪文化”。“在此文化中,很多重要元素就不会公开呈现出来。”

成员们为什么不想保持诚实?他表示,“这都是因为他们害怕应对失败。”但你必须承认,“我们偶尔总是会出错。”

若所处的是倡导公开及诚实沟通的文化,“聪明的团队成员就会发现你出错了,他们会向你指出,防止你铸成大错。”

但他有个提醒:若成员总是诚实指出出错地方,“你可能会陷入吹毛求疵的误区中,”这会带来悲观主义。“但你不能丧失信心。”

认知

Riegler表示,“大家的普遍认知是,文化非常重要,我们的互动方式能够塑造带来成功的文化,这非常重要。”换而言之,“所有人都要清楚这些原则,严格遵循它们。”

你需要承认的是,“大家都能够有所改善。”但“你不能直接告诉他人要进行改善。这不是实际运作模式。这是个缓慢过程。”

后果

Riegler表示,“这些原则若没有得到执行,它们就没有什么意义。”这是自下而上的过程。

他表示,“若你容忍成员忽视公司原则,那你脱离这些原则意味着什么?大家会觉得这些不是真正的原则,这将带来严重危害。”

最后思考

他表示,在没有开放文化的公司中,“很多时候大家会对在会议上指出‘这出错了’的成员印象深刻,你很好奇他们如何做到这点,因为企业文化让我们很难直接指出这些地方。”但若你塑造的是基于相互信任、责任感和互相沟通的文化,“更多成员就可以这么做,公司将得到显著改善。”

他表示,“你能够反思你的优缺点,这会让你变得非常有价值。你需要找到志同道合的伙伴,你可以创建能够顺利存活下来的团队。”

篇目3,开发者需适应并谨慎管理游戏制作风险

作者:Florian Schwarzer

恶梦是什么?恶梦就是,你组建了一支优秀的团队,辛苦地工作了两年,发布了一款精良的游戏——最后眼睁睁地看着它失败了。

更可怕的是:我们这个行业每天都在上演这种悲剧。

令人惊讶的是,我们并不太经常讨论这种风险。甚至我们当中那些肩负着“企业责任”的人似乎也在逃避这个话题。我们经常讨论开发过程或领导策略,却极少花时间探讨如何应对开发风险。这通常会让你产生一种错觉:我们在发布游戏方面一直在进步——但事实上,我们在保证产品成功方面却没有什么长进。

是不是因为居于成功游戏的核心的东西与导致其他软件成功或失败的东西完全是不同的?

长久以来,我们的项目管理一直向软件开发行业看齐,我们从中学到的经验已经帮助我们改进制作游戏的方法。但我仍然认为,局限性是存在的;我们所面临的挑战是其他软件开发管理者永远不会遇到的。游戏开发者遇到的第一个挑战是:游戏设计。

小区别

游戏是用来娱乐的。这就把游戏与传统的软件区别开来了,游戏相当于软件的子类别。这也意味着我们承担的风险与电影或小说一样:我们的受众可能根本看不到我们的游戏好在哪里。研究人员称之为“制作风险”。

Illustration(from-develop-online)

Illustration(from-develop-online)

作为管理者,我们通常认为风险就是应该最小化的威胁,或者在更糟的情况下,至少应该缓解。然而,我们也能这样对待这样的风险:玩家感觉不到我们认为有趣的东西到底有趣在哪里吗?

基本上,让某种东西变得有趣的很大一部分在于让受众产生好奇心。众所周知,我们喜欢新事物——几乎所有游戏都努力地为它的玩家提供一定程度的新意。我们研究,我们制作,我们宣传崭新的东西,无论它是实验作品还是老游戏的续作。

豪赌

当然有一个问题:对我来说是原创的东西,可能对你来说是老套的。要在做出来以前预测一款游戏是否达到我们的期望是非常困难的。特别是还要考虑到这么多受众,预测基本上是一件不可能的事。想一想为什么好莱坞电影会走进模式化的怪圈。

显然,这意味着冒太多创作风险是不明智的。毕竟,如果我们发布的产品与以前的产品都大不相同,那么它很可能就迎合不了大多数人的品味,是吧?

确实,但我们的玩家仍然喜欢新玩意。像《传送门》或者《Wii Sports》这类游戏表明,如果你冒险了,并且找到受众,反响是会非常热烈的。创作风险就像搞投机——结果可能好也可能坏。

当然,围绕一个比较保守的概念做出一款好玩的游戏也是有可能的。比如《星际争霸2》,就是一个成功的案例。再以吉他游戏为例,它们的主题太保守了,虽然执行得不错——所以它们的玩家都玩不久。所以,保险也是一种冒险。

说到底,无论你做的游戏是哪种类型、你做得有多好,你仍然是在投骰子。游戏的卖点正是让游戏成功又冒着最大风险的东西。所以,我们在计划时必须认真考虑。

管用吗?

显然,如果我们想帮助游戏设计师处理有风险的设计,我们首先应该评估它们。同样显然的是,最好能尽快把这些设计做出可测试版。

这里有一个好消息,所有与游戏设计有关的部门都有自己的一套快速制作原型和测试想法的办法。因此,制定测试计划似乎是相当容易的事。比如,你可以先测试新设计的纸上草图,再模拟UI,逻辑原型,最后在测试服务器上发布完全版。这种计划很吸引人,因为让团队和投资商都感到稳妥。当然,它是不管用的。

部分原因在于时间。团队总是太专注于详尽的测试,结果却发现没有时间修复错误的地方。

更糟的情况是,玩家测试产生混乱的数据。玩家会提出各种改进建议,不同看法很容易产生分歧,所以解决方案当然也是五花八门。这时,只要主要投资人或主管认可这种不同的意见,那么游戏设计师马上就失去他们自己的概念的控制权。

敏捷开发的局限性

为了解决时间不足的问题,似乎只能把大规模的原型制作活动严密地整合到开发过程中。让我惊讶的是,当我开始做敏捷开发方面的顾问时,有人告诉我,这是一个糟糕的主意。

我们都知道Scrum和极限编程。把待做事项列成一个目录,把最重要的东西放在最上面。这就好像为自己设定了一系列冲刺目标,每到达一个目标,就应该做完一定量的工作。因为追求每一个目标的过程都是一场冲刺赛跑,所以挤出来的时间就会越来越多。

但我们当中许多人都忽略了“传统的”敏捷开发是什么。没有标志性事件,没有审查。做完前面几周后,最重要的东西做出来了。然后,随着冲刺目标,团队会做出更好的东西。

顺着这个逻辑,把冲刺时间用于制作最终可能要丢掉的原型或要重制的东西,简直就是浪费。制定全面计划?那就是我们出错的地方。

对于B2B应用开发,敏捷开发适用于开发确定的东西。然而,确定排在目录最前面的东西对用户来说就是重要的,这是不可能确定的事。这也是游戏开发中不能确定的。

Illustration(from develop-online)

Illustration(from develop-online)

根源

这意味着,我们应该适应游戏设计的创作风险,我们必须根据我们的领域特性安排开发流程。我们不知道我们最中心的特征对玩家来说是否有价值。我们只能希望是。

对我而言,那些特征和它们被实证的程度,应该作为项目的驱动力。从根本上说,这意味着接受它们每一个都可能被多次重制的事实。以我的经验,不要对实现可能性少于60%的特征做计划。

更大的挑战:我们必须接受争论的存在。它有助于迫使游戏设计师在一开始就确定特征。这样当被告之某个特征不可行时,他们就能很快提供提供实现方法。这使设计师具有一定程度的测试自主权,并且为任何讨论设置可行性标准。

最后,我们必须让投资方发挥一定的影响力。为此,在大测试完后制定一个里程碑式的阶段性目标是明智的。这样你就更加了解你的项目进展到什么程度。因此,如果有必要,这时候也是最适合讨论变化的时候——比如增加预算、调整规模或者取消特征等。

变化也是我们不太讨论的另一个话题。但如果我们能严肃地对待制作风险,我们就总会考虑到那一步。在纸上看起来各种牛逼的东西,可能根本实现不了。尽管如此,太过冒险仍然是不可原谅的错误。

篇目4,分享改进团队信息交流和沟通状况的6种方法

作者:Lee Winder

对于一支优秀的运作和生产团队来说,成功的交流和沟通是最重要的因素之一。如果员工,管理者,发行商以及其他参与游戏开发的人员之间缺少了足够的交流,这个团队的表现就会很成问题了。

如果开发者对自己的工作缺乏自信,不理解自己的工作对于游戏的整体开发有何意义,甚至不知道自己的存在价值在哪,那么这个开发团队只能生产出一些劣质产品,并且团队氛围也将始终笼罩在相互猜疑和摩擦之中。如果沟通不畅,我们很可能要为因此而犯下的错误付出惨痛代价。

以下是我过去几年在团队中试过的改善交流方法:

团队百科

team wiki(from gamasutra)

team wiki(from gamasutra)

建立一个团队百科文库去收集信息和内容,这是一种长久存放文件和信息的好办法,但并不适合保存那些短期内容易失效的信息。

如此,团队成员便能很容易地在百科文库中找到开发过程中的各种相关文件,并且如此也不会影响团队的日常工作。虽然成员们仍必须持续去寻找一些长期有效的信息,但并不需要定期搜索新信息。

不过这种方法虽然很有用,但却不能有效地改善团队成员的日常交流。

博客

我们有一个团队博客,每周更新两三次,更新内容是关于日常工作的讨论,游戏截图以及游戏开发现状等。这种方法让我们能够更简单地向团队成员传达信息,但是前提是,所有成员都必须进入博客中才能进行团队交流。

讨论可以呈现每个员工的工作生活,并以此衡量他们的工作,不过这么做并不能用于评估项目成果。

微博

利用内部微博工具如Yammer(商务社交网络和交流平台)或Status.net(开源微博服务)能够快速公开关于自己的工作,遇到的问题或者其它关于团队信息。微博最厉害之处便在于这是一种很好的交流工具,人们可以频繁地更新内容,并接受关注者的反馈评价。

但是直到今天,利用微博去调动团队氛围仍然是我的一大薄弱点。

并不是因为这个方法不好,而是我很难找到一个平台去迎合绝大多数用户,并且我也很难判断哪些信息是用户所不愿意看到的。但如果你找不到更好地筛选有益信息的方法,那么你所公开的内容可能只会被当成没有帮助的垃圾信息,根本不可能帮助改善团队沟通氛围。

展示墙

展示墙真的是一个很有帮助的工具,特别是在统间式办公室里,但人们往往容易忽视这面墙的作用。在工作室里设置一堵显眼的展示墙能够更好地在团队中传递一些重要信息。

例如,我现在所参与的游戏开发团队有一个很明确的时间安排计划,包括发行时间,开发进度,功能特点描述以及目标要求等。除此之外我们还设有一扇“冲刺墙”,这是最能够展示我们工作状况的地方。而这扇墙的位置更是非常重要,但我们却将其设置在巨大的电视,转动电扇以及众多服务器之间,这削弱了它的影响力。尽管如此,我还是认为展示墙的重要性不容忽视,因为我们确实很难找到一个比它更折衷,更容易让人亲近的方法了。

晨会

晨会能够帮助我们更好地在团队中传递信息,但是为了体现出这种会议的真正价值,你必须遵循一些规则。

尽可能地缩小开会人数。我曾经参加过多次有20多人参与的“站立会议”,但是我却发现大多数参会者都面露疲倦或者只是无聊地等着自己的发言。如果开会人数太多,你便很难准确地将所有重要信息传达给全部参会者。

让参会者集中注意力。如果你的会议是让少数人分别阐述15分钟的执行细节,那么其他参加者肯定会迫切希望早点结束会议回到自己的工作中。

不要把会议变成一种汇报过程。如果每个人在会上都是面向着一个人(特别是经理级任务)作汇报,那么请暂时把那位经理请出会议室,而让汇报者面向所有人说话,这样参会者才能更容易地理解他的内容。

重要事记评论

与玩游戏一样,我们总是喜欢讨论哪里做得好,哪里做得不好,或者怎么做才能变得更好。但这种方法若使用不当,很容易变成无足轻重的讨论。

而如果这些讨论缺乏焦点,或者就像是一个普通的时间表,人们也许就不知道如何发表评论,甚至不知道自己到底在做些什么了。你必须确保人们能够轻松地做出评论并应对任何糟糕情况。

但是如果使用得当的话,我们便能够从这些评论中看到需要改进的内容以及一些有价值的信息。除此之外这还能够让评论者看到自己对于开发团队的帮助和贡献,让他们知道自己的想法的重要性。

结语

由管理者制定时间表并交给开发者执行的日子已经一去不复返了。

提前让几个开发人员聚在一起讨论并规划工作能够让团队成员更加清楚自己的工作职责。

并且,如果成员们在如何执行工作,如何分配任务以及安排时间方面拥有发言权,这会对团队内部的信息传播以及开发工作更加有利。

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

作者: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也是一个日语单词,即关于持续完善内容。制作人,产品管理者,利益相关者和内容创造者都必须不断寻找完善他们工作工程的各种方法。这必须实践于所有项目中,如此结果才会在不断的迭代中得到完善。

结论

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

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

篇目1,5 reasons you want to work at King

By Jim Squires

Along with a handful of other notable press outlets, Gamezebo was recently given the opportunity to tour the Stockholm studios of King, the casual games giant behind titles like Candy Crush Saga and Farm Heroes Saga.

We learned a lot about the business of being a leading cross-platform developer, yet despite all of the facts and figures thrown our way, one learning stood out above everything else: King’s employees are happy. Not just “there’s press here, plaster on a fake smile” happy, but really, genuinely happy. After seeing how the day-to-day operates, it’s not hard to see why.

You’ll be home by 5pm. Like many employees in the games industry, the teams that make up King have a diverse background. It’s not uncommon to come across names and faces that had previously worked on AAA games production. Henrik Sebring, the lead producer on Pet Rescue Saga, was working on Ubisoft’s upcoming The Division before heading up King’s Malmo studio. And if you’ve ever worked in AAA games, there’s a dreaded period that every title seems to go through right before release – “crunch time.”

When you work in the AAA/retail space, there are hard deadlines that need to be met. This can result in 120-hour weeks with people living at the office, only stopping to collapse from exhaustion.

It’s a terrible reality, and it’s one that King doesn’t have to worry about. By working in the social/mobile space, King can set their own deadlines. Products are never final at launch, and if something isn’t quite polished enough, they can always move dates around. Because of this, you’ll always be home in time to enjoy quality time with your family.

Teams don’t compete, they collaborate. When a company has multiple teams working on multiple projects, all too often they see it as a competitive environment. Team A wants their game to sell better than Team B, and vice versa. It’s not an environment that’s conducive to making your game the best it can be. And while the different teams at King admittedly want to see their product become the next Candy Crush for the company, King’s entire structure is designed around collaboration and sharing.

How so? While King operates a number of studios, each focused on their own games, they’ve made an effort to keep all of those studios in Europe. There are two very smart reasons for this: everyone will be working in the same time zone, and no studio is more than a quick flight away. Let’s say you’re working on Farm Heroes Saga in King’s London office. You might have an idea that you’d like to add into the game, but you’re not sure how it will perform. Since it’s a match-3 game, you pick up the phone and call the lead producer on Candy Crush Saga in Stockholm to see if they’ve ever tried it. The next thing you know some Candy Crush folks have just landed at Heathrow to spend a few days with you, fine-tuning the idea with your team to see if it can work.

The corporate culture isn’t about your game doing well – it’s about King doing well. That means everyone is on the same team, regardless of the studio and game you’re tied to.

Failure is totally an option. Making games is a hit or miss proposition in the most literal sense possible. Some games will be hits, more games will be misses. King both gets and embraces this fact. They have a team in Stockholm whose entire job is to dream up ideas for new games. Let that sink in for a minute – King has professional daydreamers. When they hit on a formula that they want to try, they make a web-based game for King.com – their “tournament” site that doubles as a testing ground for new ideas.

If a game performs well on King.com, they’ll know its future in a matter of days thanks to the magic of analytics. I won’t bore you with the details, but there’s a formula that will tell King whether or not a game should graduate to “Saga” status and get a deep-and-detailed remake for Facebook and mobile. Very few games get to this point – and that’s ok. Trying and failing is how we learn; this is a fact that’s as applicable to a games company like King as it is in our own lives.

Studios don’t have more than 80 people. Remember being in elementary school, how you knew all of the names of the kids in your grade, and the grades above and below you? Welcome to King. While the company is growing at a breakneck pace, they’re committed to keeping individual studios small enough that everybody knows everybody else. We were told that no studio should have more than 70 or 80 people. Why? I suppose this loops right back to the earlier mentioned positive: the culture of collaboration. If you know who everyone is and what everyone does, there are fewer roadblocks to saying “hey Lars, come take a look at this new level I’m designing.”

This muffin. I didn’t ask them about what their day-to-day catering is like, but if this muffin is any indication, it’s insanely good. The white part was kind of a white chocolate/cheesecake thing, and the inside was like a chocolate soup. It was so gooey that I eventually had to use the paper sleeve to squish it into a taco.

Walking through the studio at 9am, I saw more than a few folks gathered around a pretty great breakfast spread, taking a quick meeting as they enjoyed some communal food time together. And really, it’s this vibe that sums up what King is all about. This doesn’t seem to be the sort of studio where you rush in and tie yourself to your desk. It’s about good working relationships with the people around you. You collaborate; you listen. You enjoy a good breakfast. And maybe, just maybe, you make some amazing casual games in the process.

篇目2,The keys to a company culture that works

by Christian Nutt

In a heartfelt talk at GDC Europe, Harald Riegler, co-founder of Sproing, frankly discussed the challenges and advantages of shaping a company culture that leads to respect and success.

“The right company culture will bring really good things out of people where you didn’t expect they existed,” says Riegler, who manages a company of 65 that works on free-to-play and console games in Austria.

Unfortunately, he says, forging the right company culture is a challenge — but it’s crucial to shape it, and that every team member understand it.

“That culture will largely decide the success of the studio or team,” says Riegler. “A bad company culture can even destroy teams completely.”

While “the latest million-selling management style” books offer advice, Riegler was dismissive of trends and tricks. “The really important thing is… that it’s entirely about human interaction, the characters of the humans, and their behavior,” he says.

“A good company culture is built on some lasting principles — principles, to me, means more than a set of rules, it’s a foundation on how you live and how you act,” he says.

“Working at it day by day, week by week, year by year is required to improve your company culture,” he says, however, so be prepared to commit fully to change.

Here are his principles:

Respect

“To lead any group of people, you need an innate respect for people,” says Riegler. If you don’t respect everyone you work with, he says, “I feel you’re doomed to fail from the outset.”

“If you feel superior to people,” he says, that comes across. “Body language is most of our communication.”

“Such respect leads to an environment of trust, and trust is really important because only in an environment of trust can you address tricky things. You can bring stuff out into the open that nobody wants to talk about,” says Riegler.

Lead by Example

“Every [parenting] book says that if you want your children to do something, you do it yourself,” says Riegler. This applies to companies, too, he says.

And the reverse is true, too: “If you don’t want somebody to do something, don’t do it yourself,” Riegler says. “Never ask anybody to do something you’re not prepared to do yourself.”

Accountability

“This is where it gets really tricky,” says Riegler.

“It’s often confused for just holding your subordinates accountable,” he says. But as a manger, Riegler says, “the only way, in my opinion — and that’s something I absolutely believe in — you an introduce accountability into organizations by making yourself accountable first.”

How do you do it? “You have to tell people what you’re setting out to do,” he says. “You have to be willing to benchmark yourself.” And then finally, “you have to be prepared to stand there and say just how successful you have been, which isn’t easy, because rarely do you achieve everything you set out to do.”

Maturity

“Maturity does not mean that you’re super-experienced, that you’re an elder statesman,” Riegler says. “Maturity to me is the ability to self-reflect and have a clear understanding of what your strengths and weaknesses are, and what you should be working on, and where you should grow.”

Unfortunately, he says, “a lot of people don’t really do well here, because it requires an honest reflection on your personality, and that can be uncomfortable.”

However, he says, bear in mind that “the best contributors can understand the challenges your team is up against,” and having that self-honesty and self-reflection is key for that — it’s not just about improving oneself and having a better outlook; it has a meaningful effect on the team and the business.

Then again, he says, there are divas, backstabbers, and power players. “Beware of all these kinds of characters; they’re very damaging,” Riegler says.

Fun

“I think fun is really important,” he says. People could probably work in other, less interesting industries for more money, he says, so in the game industry, fun is key.

It isn’t, however, an environment that isn’t professional, or one that’s lax, he maintains. “Sometimes it’s perceived as laxness — young people confuse fun with a lack of seriousness or ambition,” Riegler says. So have your foosball tournament, but make sure the goals of the company are clear, too.

On the other hand, “maturity does not contradict with being crazy” — being weird is part and parcel with the culture of the game industry, he argues, so be open to it.

Freedom

“Freedom to decide how to solve a task,” Riegler says, is key — “not being micromanaged.”

“To come and go at flexible hours, to take some time off to deal with family issues and what have you,” is very important. “Freedom leads to a lot of autonomy of every person, and an environment of trust supports such an autonomy, and autonomy leads to motivated people,” Rigeler points out.

Honesty

This is one of the most important elements, but also one of the most challenging. “If something went wrong, admit it. Don’t be afraid,” Riegler says. “You have to a culture where admitting failure is accepted.”

What won’t work, he says, is “a blame culture.” When you have one of those, “a lot of stuff that is important will not come out in the open,” Riegler says.

Why don’t people want to be honest? “It’s all because people are so afraid to deal with failure,” he says. But you have to recognize that “we all screw up every once in a while.”

If there’s a culture of open and honest communication, “people on the team who are smart will spot you are screwing up, and they will point it out and they will stop you from costly mistakes.”

But he did have one warning: if people are always brutally honest about what’s not working, “you may fall into the trap of becoming hypercritical,” which leads to pessimism. “But you can’t lose faith.”

Awareness

“The common awareness in every person that the culture is important and the way we interact sets the culture for success is really important,” says Riegler. In other words, “Everybody has to understand these principles and live by them.”

What you have to recognize is that “everybody has the ability to improve.” However, he says, “You can’t just go out there and tell people to improve… that’s not how it works. It’s a really slow process.”

Consequence

“These principles are not worth much if they are not enforced by everyone,” says Riegler. This is from the bottom to the top of the organization.

“If you tolerate someone ignoring the principles in the organization, what does that mean, that you can get away with that? Then people will understand they are not really principles, and that will be very harmful,” he says.

Final Thoughts

At companies without an open culture, he says, “a lot of times people are impressed by people who speak out in a meeting and say ‘This is going wrong,’ and you wonder how they do it, and that’s because the culture makes this stuff hard to bring out into the open,” he says. But if you shape a culture built on mutual respect, accountability, and communication, “more people can do that, and everything improves.”

“Your ability to self-reflect on what your strengths and weaknesses are will make you really valuable,” he says. “You need to find like-minded people and you can build teams that can survive in our day and age.”

篇目3,Managing risk: The creative gamble

by Florian Schwarzer

Here’s a nightmare: Build the best team you can, work hard for two straight years, release a well-crafted game – and watch it fail in the market.

Here’s the crazy thing: We work in an industry where that nightmare comes true somewhere every day.

Surprisingly, we don’t talk about this very often. Even those of us who carry ‘business responsibility’ over our games seem to avoid the topic. There’s valuable discussion of development processes or leadership strategies, but little time is spent on how to deal with the great volatility of our products. Often, you’ll get the impression that we’re improving at releasing games on time – but not at ensuring their success.

Can it be that this is because what is at the heart of a successful game is radically different from what makes or breaks other software?

For a long time, our project management has looked to IT for its cues, and what we learned from there has enhanced our way of making games. Still, I would argue that there are limits; challenges we have to face that other software managers will never see. Most of them start with two words: game design.

THE SMALL DIFFERENCE

Games try to entertain. This sets us apart from traditional software, like eshops. It also means that we run the same risk as any movie or novel: Our audience might just not find the game appealing. Researchers call this ‘creative risk’.

As managers, we usually think of risks as threats to be minimised, or, in the worst case, mitigated. One has to wonder: Is the same possible for the risk of people not having fun?

Fundamentally, a big part of what makes something entertaining is down to curiosity. We like new things. This will be news to nobody – pretty much every game tries to offer some degree of novelty to its players. We search, we build, we advertise fresh new features, whether in an experimental title, or a sequel.

ON GREAT GAMBLES

There’s a problem, of course: What may seem original to me, can feel trite to you. Even individually, it can be very difficult to predict whether a game will meet our tastes before we try it. For a whole audience, it becomes effectively incalculable. Just consider how often century-old Hollywood gets it wrong.

Intuitively, this means that it’s a bad idea to take a lot of creative risks. After all, if we release a product that’s different from anything that’s come before, there’s a good chance it’ll miss everyone’s tastes, right?

True, but our players still really like new stuff. Games like Portal or Wii Sports show that if you take the risk, and manage to connect to your audience, the reaction can be tremendous. Creative risk is speculative – its outcomes can be negative or positive.

Of course, it is possible to build an entertaining game around a relatively conservative concept. Take StarCraft II, a careful extension of a well proven game. Then again, take the guitar game genre. There, we have a group of very well executed titles that got too conservative – and saw their audience move on. Taking no creative risks is a risk, too.

In the end, no matter what kind of game you build and how well you build it, all you get is a roll of the dice. The game’s USPs, the very things that can make it succeed, will carry the greatest, most central risks. Accordingly, there’s nothing we should take more seriously in our plans.

DOES IT WORK?

Obviously, if we want to help our game designers deal with risky features, we should help evaluate them. Just as obviously, it’s a good idea to make these features testable as quickly as possible.

The good news here is that every discipline involved in the creation of games has found its own ways of quickly prototyping and testing ideas. Based on those, it seems pretty easy to set up whole test plans. Say, you start out by testing a paper draft of a new feature, graduate to UI mock-ups, logic prototypes, and eventually release a fleshed-out version on a beta server. Such plans are hugely attractive. They reassure the team and stakeholders. Also, they don’t work.

Partially, it’s down to time. Way too often does a team invest into elaborate tests, only to discover that there’s no room to fix what is broken.

Things can get even worse, though: User tests, by their very nature, produce messy data. It’s easy to come to rivaling interpretations, and thus solutions. If a major stakeholder subscribes to such a differing view, the game designers may quickly lose control over their own concept.

THE LIMITS OF AGILE

To avoid all this, it seems sensible to integrate large-scale prototyping more tightly into the development process. To my surprise, when I began consulting Agile experts on this, they told me it was a bad idea.

We all know the basic artifacts of Scrum and XP. You’ve got a backlog, with the most important stuff up top. You’ve got a sprint, during which a certain amount of stuff is supposed to get done. You’ve got a working increment, which grows sprint by sprint.

What a lot of us miss is that, as far as ‘traditional’ Agile is concerned, that’s it. No milestones, no gates. After the first few weeks, the most important stuff is in. Then, with every sprint, the team will be able to release something better.

Following that logic, it’s a waste to spend a sprint building a prototype that may get discarded or even lead to a rework of stuff that’s already done. Setting up whole plans full of that? That’s missing the point.

For B2B application development, the environment Agile was built for, that’s true. There, it is possible to ensure that what is at the top of the backlog is also the most valuable for the user. In games dev, that’s the very thing we often can’t be sure about.

THE ROOT CAUSE

What this means is that to accommodate the creative risks of our games, we must tailor our processes in ways unique to our field. We don’t know whether our most central features are valuable to the player. We only hope so.

To me, those features – and the degree to which they are proven – should drive a project. At the root, this means accepting that each of them will be reworked many times. In my experience, one shouldn’t plan with less than 60 per cent of feature-specific contingency here.

More challenging: We have to acknowledge that there will be controversy. Here, it can help to have the game designers prepare while they are defining the features in the first place. Ask them to name ways by which to tell that the feature doesn’t work. It provides the designers with a degree of ownership over the tests, and sets a reliable yardstick for any discussion.

Finally, we have to give our stakeholders a fair chance to take influence. For this, it’s sensible to set milestones after major tests. There, you will have learned something important about your project. Thus, if necessary, it’s the ideal time to discuss changes – whether that means budget extensions, scope adjustments, or the dreaded cancellation.

That’s another thing we don’t talk about. But if we take creative risk seriously, it’s a step we should always consider. It’s always possible that what sounded fun on paper doesn’t really work out. Pressing on nonetheless – now that’s inexcusable.

篇目4,Opinion: Communication Is Key

by Lee Winder

Successful communication is one of the most important aspects of a well functioning and productive team. Without good communication between peers, managers, publishers, and anyone else involved in the game development process, a team will not perform at it’s best.

If developers do not feel confident in the reasons behind their work, if they don’t fully understand how their work will fit into the project as a whole or indeed when it will be required, the team will produce lower quality work with last minute changes and requirements fostering an atmosphere of distrust and crunch.

But communication is one of the most difficult things to get right but so costly when it’s done wrong.

The following are methods I’ve used over the years to try and improve communication within the team. I’d be very interested to hear other ways people have tried too!

Team Wiki

Having an open Wiki that people can contribute information and notes is a good idea for documentation and persistent information. It is not a good tool for perishable short term information.

Documentation on team processes (getting the latest build, creating submissions, setting up PC’s etc.) is usually the kind of information that finds a home on a wiki, and while it’s useful, it’s not something that affects the team on a daily basis. And as it requires people to physically search for the information in the long term people don’t bother looking for new information on a regular basis.

As a result, the Wiki is useful but doesn’t actually improve the day to day communication on a team.

Blogs

We have a team blog that people update about 2 or 3 times a week, usually discussing their recent work, posting up screenshots or letting people know the state of the project. It’s a nice simple way to push information to the team, though it does require everyone to contribute to the blog to get good cross team communication going.

Discussions can take on a life of their own, which is actually a good way to gauge buy in into a project but can’t be used to judge the success of the process.

But you’d be amazed how many people don’t have any kind of RSS feed reader set up…

Micro-blogging

Internal mico-blogging tools like Yammer or Status.net allow people to quickly thrown up what they’re working on, problems encountered or general team information. The best thing about micro-blogging is it’s push communication style with people’s updates being automatically feed to clients, which people can update as much as they want (I usually recommended at least twice a day).

But so far I’ve had very little success with micro-blogging tools in a team environment.

Not because the idea was bad (when it worked it worked well), but I’ve yet to find a service where the official client is anywhere near usable and able to filter out the information people don’t want to read. Without a good way to filter and push information where you want it (like all the best third party Twitter tools do), it either becomes an information overload or a sea of noise, neither of which improves communication.

Wall Displays

Walls are valuable real estate, especially in an Open Plan office, and I’ve rarely seen them used to their full potential. But highly visible walls in the middle of a team area are one of the best ways to communicate information across a team.

As an example, on my current project we have the entire timeline of the project (it’s only a short one) with dates/deliverables clearly indicated, a ‘where we are right now’ marker and a description – feature by feature – of what is required for a given milestone.

Next to that, we have our sprint wall, which is our most ‘live’ wall display. But position is key, and in our case, the sprint wall’s impact on the team is reduced due to it’s rather awkward position between a big TV, a constantly spinning fan, and quite a lot of server machines. But I did say wall space is valuable real estate, and it’s always hard to find a compromise between distance from team and accessibility.

Morning Meetings

Morning meetings are one of the best ways to push information across a team, but I’ve found that you need to follow a few rules to make them really valuable.

Keep the groups small. I’ve lost count of the number of 20+ people stand-up meetings I’ve seen where the majority of the ‘participants’ are looking bored or simply waiting for their turn. If your groups are not small, the information is less targeted and much less relevant, meaning more information is lost than actually passed around the team.

Keep them focused. There is nothing worse than 1 out of the 6 people speaking for 15 minutes about the most intimate implementation details, leaving everyone else itching to get back to their seats to carry on working.

Don’t make them reporting sessions. If everyone is talking at a single person (usually their manager), take the manager out for a while and get people used to talking to each other as it makes it much more likely for people to take in what is being said.

Milestone Reviews

I love the concept of a milestone review. Everyone playing the game, lively discussions about what went right, what went wrong, and what we can do better next time. But it’s easy for these to be less than stellar if not approached in the right way.

If these reviews are not focused, maybe even as structured as a schedule or points to cover, people may start to feel unsure as to what they can comment on or what exactly they should be doing. You’ve also got to make sure that people feel comfortable both giving and taking criticism and manage the situations when that goes pear shape (and sometimes it will).

I’ve found that when done right, when people contribute to discussions and when people can (importantly) see change as a result of these reviews, the quality of information coming out of them is invaluable. It also has the added bonus of making people feel like they are making a difference to the team and allowing their thoughts to be heard.

Sprint Planning

The days of managers sitting in a room building up a schedule and dishing it out to the developers is (almost) long gone. And there’s good reason for it.

Getting a group of developers (again with the morning meetings it needs to be small and focused) to discuss, schedule and plan the work ahead significantly improves the knowledge people have of what is happening across the team.

Again, if people feel that have a say in how work will be implemented, how it will be assigned and when it’ll be done by is vital to spreading information about the project and the work being done.

So those are a couple of methods I’ve used to try and improve communication and information across the team. I’m sure there are plenty more (and I’ve tried a few which have been colossal failures) so what methods have you used and how well did they work out?

篇目5,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.


上一篇:

下一篇: