团队论 一位游戏制作人的团队建设感悟

发表于2017-09-01
评论0 797浏览
       这篇文章,只是我带领团队做游戏的一个缩写。里面不乏很多人遇到的问题,也不乏很多问题的解决思路。实战经验,各位在以后的日子里,如果遇到这样的问题,能避免些就避免些。

       人员构成上来说,同制作人的经验是有很大关系的。当我经验尚浅的时候,我也组建过团队,当时记得是招了几个行外的美术,招了一个火石的做了2年的程序员,当时做的游戏也是比较简单,所以在配备上,以能做出东西为主,我觉的,这个思路现在我仍然受用,不见得一定要招各种厉害的人士,厉害人士未必会很好沟通,有时候反而因为他自己的想法阻碍了案子的成型。

        后面有经验了,在招人的过程中,开始考虑的是上线处理的问题了,如果一个团队中没有有能力的核心,那在上线后,问题暴露的会特别的厉害。解决乏力。所以后期的案子中,我起码会在项目中留2个很有能力的技术力量,而且会同外部的技术大牛建立联系,以备后用。因为上线后才是bug大批量爆发的日期,再多的提前测试也不会解决这个问题的。如果你不是已有上线代码的基础上发展的案子,那重新架构其实是非常大的开发风险。熬过上线期,才能算松了口气。很多时候,团队作品的失败不见得是思路而是技术。这也是后期上线的精力给予我的教训,我把这些都用在了后面的案子里,所以路才走的越来越顺。其实真的是经历的越多,才做事越有底气,有思路。

       回头说之前的那个经验尚浅时的项目。团队刚组建,我着手开始理顺各个部门的沟通机制,文件制作规范,这个给我了甜头,因为后来的经历里我见到了各个部门间沟通机制不畅,文件制作规范没有导致的没必要的时间浪费,很多时间花在文件的命名,文件的格式修改上。这些其实也是成熟的团队或者成立已久的公司不会再犯的错误。

        但是没经验导致了另外的1个问题,源码,源码始终保留在程序员手里,而当时也没有建立代码库来强制要求,也没有封内外网之分,导致程序员在代码的交接上混乱,以至于后来我为了完工,额外出钱联系程序外包做完了项目。

        接着项目完工,老板不准备继续做。遣散,各自离开。



       这个团队的从创建,到开发过程,到结束,给我很多的思路,以至于我都用在了后来的项目开发中。

1、团队的基础开发速度,取决于最终成品的那个环节,程序部门,而这个环节的关系,是制作人首要要打理的。
2、团队的开发效率的上升空间,取决于部门间的沟通机制,文件交流的便捷和规范。这些是基础的基础,最先要捋顺的。
3、新团队,是没有忠诚度的。也不要一开始就培养。新团队最初还是很单纯的买卖关系,这个时期,团队需要的是利益目标。比如说,分红,奖金,这些在前期调动团队的积极性是非常有效的。没必要一上来就喊着要改变游戏业,改变规则,这样的口号不适合新组建的团队。激情,很容易就磨灭在不加班和赶工中了。
4、各个岗位上的人,尤其是程序,不可以只有1个,一方面需要通过协作,相互监督代码。一方面程序员如果有比较,就不会有很多独大的想法出来,执行效率上会以做事为主,不会慢慢开始干涉制作。

        然后就到了下个项目,下个项目里遇到的情况是这样的。公司已有团队,但是想扩充人员尝试新类型。于是招了1大批新员工组建了团队,但是其中安插在重要的位置上,安了2个人。我也听到不少公司采用这样的方式。确实在表面上看了,既有原来公司的人在把控,监督,能确保案子不离开公司的眼睛,又可以扩充产品线。

        弊病就显而易见,团队本身在制作上是一定会出现分歧的,哪有风平浪静的开发过程啊,不可能。
        决策人是母公司的,那他的个人影响就决定了案子安不安宁了。

        为什么说个人影响呢,因为我遇到过不安宁的团队,也见识过安定的多的团队,确实和制作人的处事,经验有关系。后面慢慢说。

        这个项目决策人是独断的人,但是他犯了一个错误,独断的人要拥有绝对独断的权力和很强的交际能力,起码独断犯错后可以化解对自己伤害最大的言论。

        独断的好处是,如果你手下的人都是新人,那这个团队的执行效率会非常的好,效率高而且容易把他们的执行力释放出来。因为新人是想做事情的,实现系统制作出来玩得到,这个兴奋会持续大概半年到1年的,他们这个时候表现出来的执行力是让人惊讶的。所以这也是我后来喜欢启用沟通好的毕业生的原因,他们对游戏还抱有极高的热情,实现系统又可以让他们保持热情,执行的效率很高。但如果都是新人,坏处也来了,就是你作为决策者需要做大量的决策,以为新人是没法子放手的让他们做决定的。于是决策者自身非常累而且离开了决策者,项目就陷入到踩了刹车后的惯性距离里了,节奏会被慢慢打断并开始混乱。面对这个问题,我后来的方法是,培养1个二级决策者,慢慢的从细节决策放手,到后来的系统放手,这个过程很长而且要看准人,我觉得稳重、善沟通、游戏经历丰富这样的人,适合这个位子,这个思路是我培养了2个二级决策者以后的经验,倒是不一定是真理,毕竟每个人带案子的风格不同。

        我为什么会选这样的人呢?首先,在大决策上,稳重的人不会与你激辩,不会正面冲突,他也会选择已执行为最终的衡量标准。其次,善沟通的人可以同决策者一样带动团队,再次,游戏经历丰富,他起码不会设计出太离谱的游戏设计细节。这些都有助于案子的最基础的目标。做出来。

        独断的坏处呢,这个就有意思了,亲身经历的过程中,遇到过如果团队里有和你一样资历的老人的情况下,有没差你几年的新人的情况下,有另外的强势上升的技术性人才的情况下,这个团队leader如果继续独断,团队就吵架度日了。

        因为这种情况下,独断者镇不住其他人,推行遇到阻碍,若是在人际关系上安抚不了这些人,那执行就会遇到阻碍。团队在决策的事情上就每天你一言我一语,到后来直接发展到程序不执行,过来和你讨论游戏玩家的品味,美术拒绝修改,过来和你讨论UI的设计原则。呵呵,这个是我遇到的最郁闷的开发过程了。

        如果决策者继续独断,并开始拿权力硬压,没多久就开始发现人员流动了,那些有棱有角的人主动离开了,那些容易被左右的人就也跟着走了。

        上面的结局是我推测的,因为我后来解决了这个问题,没有出现上面的结局。不过看到很多其他的团队里人走时的义无反顾,义愤填膺,我认为,如果继续下去,结果差不到哪里去。

        这个过程如何缓解呢?答案是片面的,因为虽然对这个团队生效了,不过未必是通用答案。方法是找一个缓冲,这个局面下,你的决策任何时候就会被质疑,被否定,执行不下去,你要找一段时间,缓冲,放弃独断,找到处理团队的几个主要反对者的关系如何处理。如果人家单纯就是想你下台,那没法子了,这不是我可以讲的范畴了。如果他们只是有不同的建议,那这个时候需要缓冲关系,先民主,开会,听取意见,然后导引这些人的思路,一段时间内开会先先缓冲成他们的意见,然后接下来一段时间内开会缓冲到折中意见,最后在找一段时间开会缓冲到离自己的意见比较近的想法。这也是我从中学到的会议处理技巧。

        做会议,一个leader最忌讳说别人的想法不好,最忌讳整天挑别人的毛病,嘲笑别人的逻辑错误。这样开会没任何好处。开会,首先要明确,我们做这件事情的最终方向,然后开始挑出大家思路里 符合这方向的闪光点,然后再汇聚闪光点,然后大家思考如何囊括这些闪光点的方案。然后改进这个方案。

        这是我学习到的最有效的会议方式。当然,也是从争吵到缓冲到最后引导会议节奏的经验里学会的。

        所以,一个leader对一个团队至关重要,他如何处理事情,如果处理关系,影响了整个团队。leader没有好不好之分,只有风格的不同。我也见过独断的人把下面的团队吃的很死的那种,那个团队里,他拥有绝对的威严,一帮老人在下面很佩服的做事,那个制作效率真是高啊。

        所以,这个项目又给了我些好的处理分歧的经验和曾经有效过的处理思路。

        后来的几个案子我的团队很有效率而且气氛很好,就很得益于曾经的经验。

        所以,案子遇到问题是难免的,关键在于如何去吸取教训,解决问题。

原文链接

著作权归作者所有,商业转载请联系作者获得授权,非商业转载请注明出处。

如社区发表内容存在侵权行为,您可以点击这里查看侵权投诉指引

游戏学院公众号二维码
腾讯游戏学院
微信公众号

提供更专业的游戏知识学习平台