/【雷火UX带你聚焦GDC2022】告别冲刺期加班:从范式到实践(Pragma Platform:Chris Cobb)

【雷火UX带你聚焦GDC2022】告别冲刺期加班:从范式到实践(Pragma Platform:Chris Cobb)

关于GDC

GDC是全球游戏行业最具规模、最有权威、最有影响力的专业峰会。GDC2022中,雷火UX共获邀17场演讲,分布在9个核心演讲以及8个峰会演讲,再度刷新中国游戏行业纪录,领跑全球。    
   
每年的GDC大会上,全球顶尖的游戏开发者们将齐聚在这里,交流彼此的想法,构想游戏业的未来方向。接下来雷火UX公众号会选择一部分高质量的演讲,陆续为大家进行介绍。本篇为大家介绍的是来自Pragma Platform的首席技术官Chris Cobb的演讲“Production Essentials Summit: Anti-Crunch: Patterns and Practices”。    

Chris Cobb

CTO, Pragma Platform

                             

                             

                             

演讲标题:

Production Essentials Summit: Anti-Crunch: Patterns and Practices                              
告别冲刺期加班:从范式到实践                              
演讲者信息:                              

Chris Cobb,Pragma Platform的首席技术官,拳头游戏前技术主管和程序经理。曾在《英雄联盟》项目组中帮助建立玩家行为检测团队,并负责完善了玩家匹配系统。他于2019年创办了旨在为多人和社交游戏提供技术支持的后端游戏引擎公司Pragma Platform,并担任首席技术官至今。

演讲概述

由于游戏的特殊性和复杂性,加班成了电子游戏行业中极其常见的现象,也导致了员工福祉下降、工作模式不可持续等问题。Chirs Cobb在这场演讲中深入探讨了他在项目管理中的几种范式和心得,同时,也分享了公司是如何在“客户成功”、“高速保质”、"团队解放"的企业价值观中进行实践,构筑健康、可持续的工作氛围的。
                             

                             
01.  这四个问题,项目经理需要经常问自己                              

                             

                             
                     
作为一个游戏团队的项目经理,如何通过更加科学、有效的项目管理使自己的团队减少加班,更有效的工作呢?演讲者提出,作为项目经理首先要问自己4个问题:                      

我们真的在实事求是地估计工作量吗?

事实上,很多人对于工作量的估计是无用的。大多数情况下人们只是随意地填了一个日期上去,然后在Dead Line(交付日期)前焦虑地让时间从指尖流逝。但正确地进行工作量估计非常重要,它不仅与开发时间挂钩,更与工作室的预算挂钩,这极大地影响着现金流的稳定性,而现金流对一家工作室的重要性不言而喻。                      
下图正是我们大部分人在使用,却又很难起到作用的工作表。为一个任务安排固定的若干天时间,然后再紧接着开启下一个任务,将所有任务安排完毕后,头尾日期相减,便得到了项目的估计时间。但它起不到实质性作用,其原因是,如果某个小任务拖延了期限,后续的所有任务期限都会被打乱,你需要极其频繁地更新这个日程表。同时,这样频繁的子任务延期会让项目成员频繁地接收负反馈,损伤团队的士气。                      
                     
作为项目经理,最需要明晰的一件事情是:工作量估计并不是一种“承诺”。为一个还没有实操过的工作安排固定的期限,并要求一定要在此之前完成,本身就是一件很难的事——你永远不能预测未来。因此,给每个小任务规定不切实际的人为期限,并强硬地要求负责人一定要在此之前完成,是催生加班现象,并伤害团队凝聚力的做法。                      
但这也并不意味着就将项目管理放任自流,什么时候能做完就什么时候做完,这只会导致惰性的增长和预算无限制超标。所以Cobb将每一个子任务替换为了重叠的钟形曲线,曲线的纵坐标代表该天所需要完成的工作量,峰值所处的横坐标则对应了完美情况下该任务完成的预计时间。这样的排布允许前期任务在遇到瓶颈或者是连锁式的工作量时,及时转向下一个任务,不会严重地影响整体排期;同时,过几天再回来扫尾原先的任务时,也可能会有新的思路和想法。                      
                     
当你和你的团队完成一个功能时,你也许会顺着该功能的思路,想到很多激动人心的新功能、新特性。而在开发的初期,这些连锁式的工作可能数不胜数。你需要镇静地克制住这些新特性的诱惑,但这不意味着你要将这些想到的新特性全盘排除,而是说需要坚决地评估、遴选、安排这些新特性的优先级,否则开发将永远无法完成,这同时也是一个极佳的考验团队版本控制纪律性的机会。                      
当然,新特性的确是必要且有意义的,因为随着开发的进行,你对于这个产品的理解也越来越深入。但是千万不要忘记在前期估计交付日期时,预留出开发新特性的时间周期,这往往是人们在拟定开发计划时最常犯的错误。                      

是否有防止“信息孤岛”现象?

“信息孤岛”是一种在组织过度分工情况下,各个单位彼此鲜少往来,各自为政,缺乏横向协作的现象。这会导致各单元间的重复工作、需求理解错误、团队稳定性下降等一系列问题,进而降低产品开发效率。其中,代码工程师间的“信息孤岛”是非常常见的场景。Cobb举例道:当团队内代码工程师的工作过于孤立,以至于某段重要代码只有一位工程师有能力维护时,一旦遇到其休假或病假等特殊情况,团队便很难开展工作。这也等于变相地囚禁住了自己的员工,打破了员工工作与生活的平衡。                      
                     
因此,Cobb在公司的实践中采用了“结对编程”(Pair Programming)的模式,通过这样一种敏捷的软件开发模式,使两位代码工程师在同一个工作站上一起工作,由一人担任领航者,负责思考战略层面的方向,提出改进的想法和未来可能要解决的问题,同时观察审查代码;一人担任执行者,负责集中于“战术”层面程序的编写。在这个过程中,二者的角色可以经常交换。                      
虽然结对编程会使代码交付需要耗费更多的工时,但在编写代码的过程中,可以集思广益,使得编写出的代码Bug更少,性能更好;让员工更容易感觉到相互扶持的心理状态,增强凝聚力;也让同一份代码有至少两位工程师有能力维护,降低了团队的不稳定风险因素。                      

是否在开发过程中保持测试?

QA(Quality Assurance,质量保证)团队是游戏行业中不可或缺的一部分,它们负责对游戏进行测试,保证其质量。但演讲者提到,QA团队在行业内常常被视为一个孤立的团队,在项目开发的后期引入,并没有成为游戏开发的一部分,当开发团队进行计划时,他们的视角和思路并没有被纳入考量。于是,团队往往陷入这样的模式:开发团队闷头做事——QA团队发现大量BUG——需要额外的预算和时间来优化——导致加班。因此,Chris采用了TDD(Test-driven development,测试驱动开发)模式,旨在将QA团队嵌入开发团队中,使开发人员在编写代码之前便高度关注功能需求,减少不必要的BUG。同时,这样的方式也使大部分的Bug可以在开发流程中被发现,而不再全部堆积于项目交付前。                      

是否实践了代码的持续集成与交付?

当一个大型工程团队协作进行开发时,各个工程师代码间的互相干扰是一个很大的风险因素。也正因如此,工程师们往往会划分职责,并在自己的功能分支上进行开发。但Cobb认为,作为项目管理者,需要对代码合并的频率有清晰的了解和认识,因为如果合并的频率过低,游离在主干之外的工程师埋头走向错误方向的风险就会大大提高,进而导致产能的浪费。相应的,代码整合的时间也会因此大幅增加。Cobb所见识过的最疯狂案例是整个团队只花了6个月便开发完了全部功能,但却整整花了两年半时间才将所有代码整合完毕,这对于一个小型团队来说是不可接受的,其可能导致的损耗也可见一斑。                      

因此,Cobb引出了“基于主干开发“(Trunk-based development)的概念。在这种模式下, 每位开发者都将自己的工作内容分成小批量,高频多次地将工作内容合并到主干中。它降低了合并的复杂性,并通过减少开发线和进行小而频繁的合并来保持代码最新。


                     
02.   企业文化                               

                             

                             
接下来,Cobb阐述了自己是如何在企业文化的建构中嵌入可持续工作的理念,为公司创造更高效精益、健康的文化环境的。                      
首先,Cobb提出了他对于企业文化,即企业价值观建构的看法:当我们在谈论企业价值观时,它不应该是诸如“卓越”、“诚信”、“尊重”等人人都适用的“概念”,而应该落实到具体的“行为”,这样才能避免落入无法评估的窠臼,从而更好地指引员工在工作中实践这样的价值观。                      
紧接着,Cobb正式引出了自己为Pragma Platform拟定的三条核心价值观。                      

助力客户成功

“助力客户成功”是近年来在高科技行业兴起的新型概念,是一项长期的商业战略,旨在最大限度地提高客户和公司可持续的盈利能力。                      
在演讲中,Cobb将该概念引入了自己所处的场景:自家的后端游戏引擎Pragma Platform与其客户——各大游戏工作室,并进一步对这一概念做出了诠释:优先考虑客户的定制化需求,而非一个理论上完美的系统。由于后端游戏引擎公司内的大部分员工为工程师,他们对于一个自洽而完美的系统有着近乎执着的追求,因此这常常会导致其对优化引擎效率有着极高的热情,而忽视了客户真正在游戏开发过程中的需要。对于各大游戏工作室来说,他们更希望能有自己类型游戏的定制化工具,而非一个理论上完美、在各个领域都泛用、但使用难度曲线极为陡峭的工具。Cobb希望自己的员工可以在工作中时刻牢记这一点,这不仅能为公司带来更多长期收益,也能让员工们更有效率,减少加班——不要浪费时间在无人使用的功能上。                      

高速保质

“开发速度”与“开发质量”是一根轴上不可能同时到达的两极,困扰着游戏行业的从业者们。游戏工程师们往往站在开发速度这一端,一旦接到需求就开始动手快速开发,希望能够尽早交付;而系统架构师和游戏设计师们则往往站在“开发质量”这一端,在前期不断地计划、计划再计划,但有时却忽略了何时开始构建。                      
因此,Cobb希望他的员工们能够在这两端间找到合适的平衡点,即在高速开发新功能的同时,有纪律性的工作:全程QA、减少信息孤岛、持续代码整合等等。表面上完成一个功能很容易,但要确保它没有bug、可以实际交付却很难。Cobb希望所有员工能在工程实践中牢记这一点。                      

解放团队

现代的游戏公司,许多都已经进化成了架构庞大、体系复杂的巨兽,这在带来集聚优势的同时也带来了弊端:各个部门间不可避免的信息沟通障碍、利益冲突,降低了内部运作的效率,花费了额外的制度性成本。在开展工作之前,往往需要和四面八方的部门谈判;同时还要跑各种繁琐的流程,以拿到相应的权限。Cobb举例之前在《英雄联盟》系统中,有四种不同的计时方法,这使得游戏中的各个系统十分复杂、混乱地纠缠在了一起,同时部门间的信息障碍使他们很难找到病因,这直接导致了S2世界赛上的游戏崩溃。                      
                     

因此,Cobb在公司内尽最大程度地减少了人为界限,希望员工们聚集在一起构思并创建共享的解决方案。这样的团队氛围能够让员工们感到更安全,也提升了团队的士气,并培养了员工们的主人翁精神,让员工们认识到他们对自己的工作拥有所有权和控制权。


                     
03.   总  结                               

                             

                             
                     
电子游戏是一个极其复杂且包罗万象的程序,各个系统千丝万缕地纠缠在一起,也就导致在工程实践中,极易出现工期控制不当、员工被迫加班的局面。但这并不是将加班常态化的理由。通过科学的项目管理方式,例如求是的工作量估计、消除信息孤岛、全程保持测试、持续集成代码等,仍然可以为健康、可持续的工作方式保驾护航,既保护了员工工作生活的平衡,也为企业本身提供了生生不息的根源竞争力。                      
  

本文来自微信公众号“网易雷火UX用户体验中心”(ID:LeihuoUX)。大作社经授权转载,该文观点仅代表作者本人,大作社平台仅提供信息存储空间服务。

TAGS: