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

如何让出色团队在享受中创造更棒的游戏

发布时间:2014-05-20 11:52:13 Tags:,,,,

作者:Clinton Keith

你是否曾经是一个很棒的团队中的成员:这种团队的工作流和时间飞速前进,你每天都是恋恋不舍地下班,并在第二天带着许多想法迫不及待地重返办公室?如果你制作游戏的时间够长,你可能就会经历这种团队体验(这就是所谓的“出色团队”),并且知道这种体验不但可以满足我们的需求,而且能够创造出更好的游戏。

出色的团队:

*通常处于一个创意流。

*会抓住机会而不惧失败。

*成员对自己的工作负责,确保有始有终地完成工作。

不要误解我,出色的团队也可能很混乱,嘈杂,并且不时把大家逼疯。他们关注于游戏,彼此间坦诚交流,即便是传达困难的事情之时。出色团队通常是偶然诞生的,它需要天时地利人和等因素,但如果没有团队成员的经验、技能的支持,它通常不会凭空出现。

在过去十年的培训和辅导过程中,我发现了一些“颇得要领”的工作室培养出色团队的方法。本文主要探讨在此方面获得成功的工作室与无法成就出色团队的工作室之间的差别。

如何优化创意和支持出色团队

我们其实还有比运气更好的培养出色团队的方法。例如情境式领导、Tuckman以及那些有利于培养领导能力的模式,但任何模式都是不完美的。人们并非可以简单预测和操纵的系统,但我们还是有一些让领导和教练用于培养出色团队的基本工具:

*保持团队小型化。大量调查结果表明,过于庞大的团队很容易产生交流问题。这样的团队就不再是团队,而是更缺乏凝聚力的团体。

*根据团队成熟水平来培养互动。有些团队需要大量的辅导,而有些团队却只需要一点接触即可。

*必要时进行一些调整。有时候,尽管团队得到了辅导,但还是不管用。所以要在其不可逆转地损害团队之前,尽量融合团队成员关系。有时候你会发现所谓的“糟糕团队成员”也有可能变成另一个团队中极有价值的成员。

*给予团队更多自主权。随着团队的成熟发展,他们也会开始自我辅导,甚至影响他们的领导。让就顺其自然吧。

这些内容并不局限于任何一种方法论或框架,但框架却有助于建立一个通用词汇表以及一系列接口,作为了解何时及何地发生指导行为的起始脚本。

game development team(from hothardware.com)

game development team(from hothardware.com)

敏捷,尤其是Scrum,就是支持这种团队的框架

可能有些人并不认同这一点。你所知道的就是Scrum是一个必须严格遵循的一系列规则。但这种观念很糟糕。它来自糟糕的执行方式,并且会损害支持出色团队的这一目标。

若要令Scrum方法生效,团队必须深入而发自内心地理解集体投入和自我管理的概念。Scrum理念、实践、规则很容易掌握上。但只有在团队中每个成员都共同投入时,才能在特定的时间内产生实际的成果,而这些成员可能并不了解Scrum。当团队成员开始结束人多手杂的无序状态,并接纳和投入共同的目标时,团队才能够进行自我管理,并快速克服困难以及制定可执行的方案。—— Ken Schwaber,《以Scrum进行敏捷项目管理》

Scrum如何评估沟通方法和出色团队

“没有执行力的出色理论不过是浮云。而没有指导理论的特定实践却常常被滥用。”——Jim Highsmith,《敏捷项目管理:创造富有创新性的产品》

*在一个圈子中消磨时间,一天只回答三个问题的行为怎么可能提高效率?

*要制作出色的游戏该遵从什么做法?

*我们使用什么标准或工具来确保自己能够制作出一款热作?

*优秀的流程如何避免犯错?

这些都是无意义的问题。它们并非什么妙招,当团队没有用心遵循优秀方法时,他们也得不少多少价值。出我团队会根据是否能够让自己更好做事来判断每个做法。也就是说,执行每种做法的决策之后都要有一些潜在价值的驱动。

价值对于人们来说是一个很重要的基础。例如,尊重的价值对我们所有人来说都很重要。我希望其他人尊重我的劳动成果,我也假设其他人想得到相应的对待。这种价值如何引导我们的日常行为?其中之一就是我们如何对应某人犯错的时候。如果某人犯错了,我们可能有两种反应。第一个是犯错之人很懒,很笨或者无能。第二个就是此人可能并不了解正确做事的必要信息。而基于尊重的考虑,我们当然会选择第二种反应。这种对犯错时的尊重,可以避免大家害怕犯错,要知道害怕犯错正是扼杀工作室试验与学习机会的天敌。以下信号是不会有错的:

*创造高度细化的Gantt表格和文件不是为了预测未来,而是在现实发生时保护中层管理不受责备。

*膨胀过程的发生,起源于为了应对过去所犯的每一项错误而创造的规则和做法(寄希望于未来不重犯这些错误)。

Scrum的价值

Scrum拥有5项价值,它解释了所有做法的原因并引导团队的指导方法:

尊重:团队分享成功和失败,并携手增加尊重性,而不是创造一个责备和害怕的氛围。尊重可以创造信任。

勇气:团队自我挑战,工作室要找到更好的工作方法,并创造更佳的工作环境。

专注:团队一次专注于完成一些事情。

投入:团队投身于开发高质量的游戏,并对彼此的工作及其结果负责。

开放:团队运作透明,分享好消息和坏消息,以便更快制定更好的决策。

这些价值解释了日常Scrum方法为何可以经受考验,以及它是定制做法的每个变化基础的原因。例如,有些团队一开始可能会为游戏做一个快速攻略,因为它可以提升团队专注、开放性和投入性。其他团队则会使用电子工具来更新日常进程,并可能忽略这些价值。教练(或Scrum大师)有助于引导团队通过保证这些价值第一位来制定决策。

这种做法为何难以执行?

当我还是三岁小孩的时候,我爸曾试着用爷爷教他的同套方法来教我游泳:他把我抛到当地的一个水池里,指望我学会游泳。不幸的是,那天我差点淹死了,根本没法学游泳,还得他来救我。后来几年他就一直不再让我碰水了。

我并没有将这套方法传授给自己的儿子。我和妻子是将他们带到游泳教练那里,他先让孩子们在浅水中开始,教他们把脸浸到水里学习憋气。之后的课程再教游泳技能,以及管理害怕情绪的方法。我希望儿子们正确看待人们对水的恐惧感,但我并不希望他们因噎废食,从此与水绝缘,以致无法享受夏天戏水的乐趣。

不幸的是,我并没有对自己的首个Scrum团队运用这个方法。我还是用了老爸那种方法。这包括给他们一些手册,告诉他们“遵从里面的规则”。但幸运的是,团队并没有因此而“淹死”,但他们很害怕这些“敏捷事物”。他们严格遵守规则,唯恐我下次又会让他们看什么书。他们只学习了相当于“踩水”的方法,其他就没有了。

我是一个慢热的学习者,但我最终纠正了自己更大的错误。对于下个团队我采用了Scrum方法,我并不再奉行原来那套方法,而是更像一名游泳教练。我让他们参加一些培训经历更大场面,学习词汇表,并掌握我们使用Scrum所希望达到的愿景。我们(管理层)会做好基础,“安全”的做法,例如担任初级开发者的领导,帮助他们评估项目进程。团队刚开始并不会投身于特定数量的功能,而是完成自己力所能及的事情。我们评估了那些达到完成标准的功能,并用它作为下一个项目进程的评价基础。我们仔细聆听他们关于可行与不可行做法的反馈,并在一些容易达成的做法上形成了共识。后来我们会逐渐从中脱身,让他们自己承担更多责任。

这个团队最后所取得的成果与前者截然不同。第二个团队获得了一种主人翁的使命感,并且比较不害怕变化。这个团队迅速改变了他们的环境和做法。他们甚至会向管理层提出需求,例如让QA成员加入团队。我们发现唯一有必要干预的时候就是,在决定是否需要拆除格子间的时候,它们会暴露出电线,需要直接解决问题。

有太多领导不知道如何正视这种根本变化。这需要安全和尊重感的落实。我并不指责深陷命令-控制模式的人,就像我爸和我一样,他们只是来自“按一定规矩做事”背景的人。要打破这个循环很困难,但却值得一试。

你可能会认为这只是一种自我感觉良好的论调,我们只是专注于制作游戏而不去担心执行过程,但要考虑到这一点:在你职业生涯将结束时,当你回忆起自己这一生的游戏开发历程,你认为哪种体验更令人印象深刻:你所制作的游戏,还是你所共事的成员?

“尽管我们可能希望事实并非如此,但我们的确深知:变化时有发生,不以我们的意志为转移。有些人看到随机性,令人害怕的不可预测之事。但我却不是这样的人。在我看来,随机性不但不可避免,它还是生命之美。承认和接纳随机性,可以让我们更有建设性地回应它。害怕会让人们走向确定性与稳定性,但这两者都无法保证安全感。我采用了不同的方法,我不害怕随机性,我相信我们可以选择去发现它的本质,并令其为我们所用。不可预测性正是孕育创意的沃土。”——Ed Catmull,《Creativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True Inspiration

游戏有赖于团队成员,领导及其创造的文化。游戏开发总是具有不确定性,缺乏我们所渴望的预测性,但当我们所追求的可预测性已经超越了自己的知识所支持的范围时,这就会对我们本身、文化和团队造成伤害。不要试图用随机团队创造确定性,我们应该不确定性中给出色的团队松绑。

这是一个双赢的结局:让出色的团队在享受中创造更棒的游戏!(本文为游戏邦/gamerboom.com编译,拒绝任何不保留版权的转载,如需转载请联系:游戏邦

Win-win: Great teams make better games and enjoy making them!

by Clinton Keith

Have you ever been a part of an amazing team: a team where work flows and time flies; you have to drag yourself away at the end of the day and come rushing back the next morning  filled with ideas?  If you’ve worked long enough making games, you may have experienced being on such a team (called a “great team”) and know that such experiences are not only the ones we want, but lead to better games.

Great teams:

Are usually in a creative flow.

Take chances and aren’t afraid to fail.

Hold themselves accountable to their work, making sure features work from end-to-end.

Don’t get me wrong.  We’re not talking about singing Kumbaya in a circle.  Great teams can be messy, chaotic, noisy and drive each other crazy from time-to-time.  They focus on the game and communicate candidly with one another, even when hard things need to be said.  Great teams often happen by chance, when the right mix chemistry, experience, and skills come together, but when left to chance, it doesn’t happen very often.

During the past ten years of training and coaching, I’ve observed how some studios “get it” and foster great teams, while others haven’t learned to.  This article is about the differences between the two.

How to Improve the Creation and Support of Great Teams

There are better ways to foster great teams than chance.  Models such as Situational Leadership, Tuckman as well as others are useful for leadership, but like any model, they are imperfect.  People are not systems that can be so easily predicted and manipulated, but there are basic tools leaders and coaches can use to foster great teams:

Keep teams small.  Plenty of research has shown that teams that are too large simply don’t communicate well.  They stop being teams and become groups, which have less cohesion.
Coach interactions based on the maturity level of the team.  Some teams need a good deal of coaching, while others need a light touch.

Make changes where necessary.  Sometimes, despite coaching, the chemistry isn’t working for a team.  Before it irrevocably damages the team, mix the membership up a little.  It’s amazing how much a so-called “bad team member” can become someone valuable for another team.
Give the team more autonomy.  As a team grows in maturity, they’ll begin to coach themselves and even influence their membership.  Let it happen.

None of this is tied to any methodology or framework, but a framework can help by establishing a common vocabulary and set of interfaces as a starting script to know when and where coaching occurs.

Agile, and Scrum specifically, are frameworks for supporting such teams.

Some of you might not agree with this.  What you’ve seen or were told was that Scrum is a hard-core set of rules to follow.  It’s too bad this view exists.  It follows from bad implementations and it’s doing real damage to the aim of supporting great teams.

For Scrum to work, the team has to deeply and viscerally understand collective commitment and self-organization. Scrum’s theory, practices, and rules are easy to grasp intellectually. But until a group of individuals has made a collective commitment to deliver something tangible in a fixed amount of time, those individuals probably don’t get Scrum. When the team members stop acting as many and adopt and commit to a common purpose, the team becomes capable of self-organization and can quickly cut through complexity and produce actionable plans.
- Ken Schwaber, Agile Project Management with Scrum

How Scrum Values Bridge Methodology and Great Teams

“Grand principles that generate no action are mere vapor. Conversely, specific practices in the absence of guiding principles are often inappropriately used.”
- Jim Highsmith, Agile Project Management: Creating Innovative Products (2nd ed.)

How does standing around in a circle answering three questions a day increase productivity?

What practices do we need to follow to make great games?

What metrics or tools do we use to ensure we’re making a hit game?

How does a good process avoid making mistakes?

These are nonsensical questions.  There are no silver bullet practices and when teams follow good practices without heart they gain little value.  Great teams examine each practice in light of how it allows them to work better.  That said, there needs to be some underlying set of values that drive decisions about practices.

Values are a foundation that are important to people.  For example, the value of respect is important to us all.  I want others to respect my work and I can assume that others want the same for theirs.  How does that value guide our day-to-day behavior?  One way is in how we respond when someone makes a mistake.   When someone makes a mistake, we might have one of two reactions.  The first is that the person who made the mistake was lazy, dumb or incompetent.  The second is that the person who made the mistake didn’t have all the information necessary to do the right thing.  By valuing respect, we’ll intrinsically choose the second reaction.  Valuing respect when mistakes are made avoids the fear of making mistakes that can kill experimentation and learning in studios.  The signs are unmistakable:

Highly detailed Gantt charts and documents are created, not to predict the future, but to protect middle management from blame as reality emerges.

Bloated processes emerge, built from practices and rules created in response to every past mistake, in hopes that those mistakes will be avoided in the future.

Scrum’s Values

Scrum has five values, which underly the reasons for all the practices and direct how teams are coached:

Respect – Teams share successes and failures and work together to increase respectability, rather than creating an atmosphere of blame and fear.  Respect builds trust.

Courage – Teams challenge themselves and their studios to find ways to work better and to create a better working environment.

Focus – Teams focus on building a few things at a time .

Commitment – Teams commit to building games with quality and become accountable to one another and their results.

Openness – Teams operate with transparency, sharing good news as well as bad to make better decisions faster.

These values not only explain the reasons while a daily scrum is standing-only and time-boxed, but are a foundation for every change made to customize the practices.  For example, some teams will do a quick play-though of the game at the start of a daily scrum because it improves focus, openness and commitment.  Other teams move to an electronic tool to update daily progress and might diminish those values.  A coach (or ScrumMaster) helps guide the team through these decisions by keeping these values in the forefront.

Why is it so Hard to Do This?

When I was three years old, my father tried to teach me how to swim using the same method his father had used: He threw me into a local lake off the end of a long pier and expected me to learn.  Sadly, that day I wasn’t going to learn to swim before drowning and he had to rescue me.  I’m told that I avoided the water for the next few years.

I didn’t use this approach with my own sons.  Instead my wife and I brought them to a swimming instructor, who started them off in shallow water, learning to put their face in and blow out bubbles.  Later lessons grew skills, while managing fear.  I wanted my sons to have a healthy respect for the dangers of water, but I didn’t want them paralyzed with fear and not experience the joys of surfing, diving or just cooling off on a hot summer’s day.

Unfortunately, I didn’t apply this approach with my first Scrum team.  I applied dad’s approach of tossing them off the pier.  This involved handing them copies of a book and telling them to “follow the rules”.  Fortunately, the team didn’t “drown”, but they were terrified of all this “agile stuff”.  They clung to the rules, deathly afraid of what book I might read next.  They learned the equivalent of  “treading water” and that was all.

I’m a slow learner, but I eventually correct my bigger mistakes.  For the next team adopting Scrum, I behaved less like my father and more like the swimming instructor.  I had them attend some training to get the big picture, learn the vocabulary and to acquire a vision of what we hoped to achieve using Scrum.   We (management) worked on basic, “safe” practices, such as having leads sit with junior developers to help them estimate a sprint.  The team didn’t commit to a certain number of features for their first sprint, but accomplished what they could.  We measured those features that met a reasonable definition of done and used that metric as a basis for planning future sprints.  In carefully facilitated retrospectives, we listened to their feedback about what worked and what didn’t and agreed on some easy-to-achieve actions.  Slowly, we backed off our involvement and let them assume more responsibilities.

The results for this team were far different than those of the first.  The second team felt empowered with a sense of ownership and were less fearful of change.  This team frequently changed their environment and practices.  They even made demands on management, such as having someone from QA join their team.  The only intervention we found necessary was when, in deciding to tear down cubicles, they exposed live electrical wires and were about to fix the problem directly!

There are too many leaders that don’t understand how to approach this fundamental change.  It has to be done with safety and respect.  I count myself as one of these who has hopefully mended his ways.  I don’t blame others who are stuck in a command-and-control mode because, like my father and myself, they come from a long line of “doing things the way they learned how to do them”.  Breaking this cycle is hard, but rewarding.

You may think this is a bunch of feel-good hand-waving and we should just focus on making games without worrying how, but consider this:   At the end of your career, when you recall your life in game development.  Which do you think will weigh more in your thoughts:  The games you made or the people you made them with?

“Here’s what we all know, deep down, even though we might wish it weren’t true: Change is going to happen, whether we like it or not. Some people see random, unforeseen events as something to fear. I am not one of those people. To my mind, randomness is not just inevitable; it is part of the beauty of life. Acknowledging it and appreciating it helps us respond constructively when we are surprised. Fear makes people reach for certainty and stability, neither of which guarantee the safety they imply. I take a different approach. Rather than fear randomness, I believe we can make choices to see it for what it is and to let it work for us. The unpredictable is the ground on which creativity occurs.”
Ed Catmull  Creativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True

Inspiration

Games are dependent on the individuals, leaders, teams and cultures that create them.  Game development will always be uncertain and lack the level of predictability we might crave, but when we push for more predictability than our existing knowledge allows we start to do harmful things to our culture, ourselves and the teams we lead.  Rather than trying to create certainty with random teams, we need to be setting great teams loose on uncertainty.

It’s a win-win: Great teams make better games and enjoy making them!(source:gamasutra


上一篇:

下一篇: