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

       这篇文章，只是我带领团队做游戏的一个缩写。里面不乏很多人遇到的问题，也不乏很多问题的解决思路。实战经验，各位在以后的日子里，如果遇到这样的问题，能避免些就避免些。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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