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

你是否曾经是一个很棒的团队中的成员:这种团队的工作流和时间飞速前进,你每天都是恋恋不舍地下班,并在第二天带着许多想法迫不及待地重返办公室?如果你制作游戏的时间够长,你可能就会经历这种团队体验(这就是所谓的“出色团队”),并且知道这种体验不但可以满足我们的需求,而且能够创造出更好的游戏 。
【如何让出色团队在享受中创造更棒的游戏】出色的团队:
*通常处于一个创意流 。
*会抓住机会而不惧失败 。
*成员对自己的工作负责 , 确保有始有终地完成工作 。
不要误解我,出色的团队也可能很混乱,嘈杂 , 并且不时把大家逼疯 。他们关注于游戏,彼此间坦诚交流,即便是传达困难的事情之时 。出色团队通常是偶然诞生的 , 它需要天时地利人和等因素,但如果没有团队成员的经验、技能的支持 , 它通常不会凭空出现 。
在过去十年的培训和辅导过程中,我发现了一些“颇得要领”的工作室培养出色团队的方法 。本文主要探讨在此方面获得成功的工作室与无法成就出色团队的工作室之间的差别 。
如何优化创意和支持出色团队
我们其实还有比运气更好的培养出色团队的方法 。例如情境式领导、以及那些有利于培养领导能力的模式,但任何模式都是不完美的 。人们并非可以简单预测和操纵的系统,但我们还是有一些让领导和教练用于培养出色团队的基本工具:
*保持团队小型化 。大量调查结果表明 , 过于庞大的团队很容易产生交流问题 。这样的团队就不再是团队 , 而是更缺乏凝聚力的团体 。
*根据团队成熟水平来培养互动 。有些团队需要大量的辅导,而有些团队却只需要一点接触即可 。
*必要时进行一些调整 。有时候,尽管团队得到了辅导,但还是不管用 。所以要在其不可逆转地损害团队之前,尽量融合团队成员关系 。有时候你会发现所谓的“糟糕团队成员”也有可能变成另一个团队中极有价值的成员 。
*给予团队更多自主权 。随着团队的成熟发展,他们也会开始自我辅导 , 甚至影响他们的领导 。让就顺其自然吧 。
这些内容并不局限于任何一种方法论或框架,但框架却有助于建立一个通用词汇表以及一系列接口,作为了解何时及何地发生指导行为的起始脚本 。
敏捷,尤其是Scrum,就是支持这种团队的框架
可能有些人并不认同这一点 。你所知道的就是Scrum是一个必须严格遵循的一系列规则 。但这种观念很糟糕 。它来自糟糕的执行方式,并且会损害支持出色团队的这一目标 。
若要令Scrum方法生效,团队必须深入而发自内心地理解集体投入和自我管理的概念 。Scrum理念、实践、规则很容易掌握上 。但只有在团队中每个成员都共同投入时,才能在特定的时间内产生实际的成果,而这些成员可能并不了解Scrum 。当团队成员开始结束人多手杂的无序状态,并接纳和投入共同的目标时,团队才能够进行自我管理,并快速克服困难以及制定可执行的方案 。—— Ken ,《以Scrum进行敏捷项目管理》
Scrum如何评估沟通方法和出色团队
“没有执行力的出色理论不过是浮云 。而没有指导理论的特定实践却常常被滥用 。”——Jim,《敏捷项目管理:创造富有创新性的产品》
*在一个圈子中消磨时间,一天只回答三个问题的行为怎么可能提高效率?
*要制作出色的游戏该遵从什么做法?
*我们使用什么标准或工具来确保自己能够制作出一款热作?
*优秀的流程如何避免犯错?
这些都是无意义的问题 。它们并非什么妙招,当团队没有用心遵循优秀方法时 , 他们也得不少多少价值 。出我团队会根据是否能够让自己更好做事来判断每个做法 。也就是说,执行每种做法的决策之后都要有一些潜在价值的驱动 。
价值对于人们来说是一个很重要的基础 。例如,尊重的价值对我们所有人来说都很重要 。我希望其他人尊重我的劳动成果,我也假设其他人想得到相应的对待 。这种价值如何引导我们的日常行为?其中之一就是我们如何对应某人犯错的时候 。如果某人犯错了,我们可能有两种反应 。第一个是犯错之人很懒,很笨或者无能 。第二个就是此人可能并不了解正确做事的必要信息 。而基于尊重的考虑,我们当然会选择第二种反应 。这种对犯错时的尊重,可以避免大家害怕犯错 , 要知道害怕犯错正是扼杀工作室试验与学习机会的天敌 。以下信号是不会有错的:
*创造高度细化的Gantt表格和文件不是为了预测未来,而是在现实发生时保护中层管理不受责备 。
*膨胀过程的发生,起源于为了应对过去所犯的每一项错误而创造的规则和做法(寄希望于未来不重犯这些错误) 。
Scrum的价值
Scrum拥有5项价值,它解释了所有做法的原因并引导团队的指导方法:
尊重:团队分享成功和失败,并携手增加尊重性,而不是创造一个责备和害怕的氛围 。尊重可以创造信任 。
勇气:团队自我挑战,工作室要找到更好的工作方法,并创造更佳的工作环境 。
专注:团队一次专注于完成一些事情 。
投入:团队投身于开发高质量的游戏,并对彼此的工作及其结果负责 。
开放:团队运作透明,分享好消息和坏消息 , 以便更快制定更好的决策 。
这些价值解释了日常Scrum方法为何可以经受考验 , 以及它是定制做法的每个变化基础的原因 。例如,有些团队一开始可能会为游戏做一个快速攻略,因为它可以提升团队专注、开放性和投入性 。其他团队则会使用电子工具来更新日常进程 , 并可能忽略这些价值 。教练(或Scrum大师)有助于引导团队通过保证这些价值第一位来制定决策 。
这种做法为何难以执行?
当我还是三岁小孩的时候,我爸曾试着用爷爷教他的同套方法来教我游泳:他把我抛到当地的一个水池里,指望我学会游泳 。不幸的是,那天我差点淹死了 , 根本没法学游泳 , 还得他来救我 。后来几年他就一直不再让我碰水了 。
我并没有将这套方法传授给自己的儿子 。我和妻子是将他们带到游泳教练那里 , 他先让孩子们在浅水中开始,教他们把脸浸到水里学习憋气 。之后的课程再教游泳技能,以及管理害怕情绪的方法 。我希望儿子们正确看待人们对水的恐惧感,但我并不希望他们因噎废食,从此与水绝缘,以致无法享受夏天戏水的乐趣 。
不幸的是,我并没有对自己的首个Scrum团队运用这个方法 。我还是用了老爸那种方法 。这包括给他们一些手册,告诉他们“遵从里面的规则” 。但幸运的是,团队并没有因此而“淹死”,但他们很害怕这些“敏捷事物” 。他们严格遵守规则 , 唯恐我下次又会让他们看什么书 。他们只学习了相当于“踩水”的方法,其他就没有了 。
我是一个慢热的学习者,但我最终纠正了自己更大的错误 。对于下个团队我采用了Scrum方法 , 我并不再奉行原来那套方法,而是更像一名游泳教练 。我让他们参加一些培训经历更大场面,学习词汇表,并掌握我们使用Scrum所希望达到的愿景 。我们(管理层)会做好基?。?“安全”的做法,例如担任初级开发者的领导,帮助他们评估项目进程 。团队刚开始并不会投身于特定数量的功能,而是完成自己力所能及的事情 。我们评估了那些达到完成标准的功能 , 并用它作为下一个项目进程的评价基础 。我们仔细聆听他们关于可行与不可行做法的反馈,并在一些容易达成的做法上形成了共识 。后来我们会逐渐从中脱身,让他们自己承担更多责任 。
这个团队最后所取得的成果与前者截然不同 。第二个团队获得了一种主人翁的使命感,并且比较不害怕变化 。这个团队迅速改变了他们的环境和做法 。他们甚至会向管理层提出需求,例如让QA成员加入团队 。我们发现唯一有必要干预的时候就是 , 在决定是否需要拆除格子间的时候,它们会暴露出电线,需要直接解决问题 。
有太多领导不知道如何正视这种根本变化 。这需要安全和尊重感的落实 。我并不指责深陷命令-控制模式的人,就像我爸和我一样,他们只是来自“按一定规矩做事”背景的人 。要打破这个循环很困难,但却值得一试 。
你可能会认为这只是一种自我感觉良好的论调,我们只是专注于制作游戏而不去担心执行过程,但要考虑到这一点:在你职业生涯将结束时,当你回忆起自己这一生的游戏开发历程 , 你认为哪种体验更令人印象深刻:你所制作的游戏,还是你所共事的成员?
“尽管我们可能希望事实并非如此,但我们的确深知:变化时有发生,不以我们的意志为转移 。有些人看到随机性,令人害怕的不可预测之事 。但我却不是这样的人 。在我看来,随机性不但不可避免,它还是生命之美 。承认和接纳随机性,可以让我们更有建设性地回应它 。害怕会让人们走向确定性与稳定性,但这两者都无法保证安全感 。我采用了不同的方法,我不害怕随机性,我相信我们可以选择去发现它的本质,并令其为我们所用 。不可预测性正是孕育创意的沃土 。”——Ed  , 《, Inc.:theThat Stand in the Way of True
游戏有赖于团队成员,领导及其创造的文化 。游戏开发总是具有不确定性,缺乏我们所渴望的预测性,但当我们所追求的可预测性已经超越了自己的知识所支持的范围时,这就会对我们本身、文化和团队造成伤害 。不要试图用随机团队创造确定性,我们应该不确定性中给出色的团队松绑 。
这是一个双赢的结局:让出色的团队在享受中创造更棒的游戏!