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

团队论 一位游戏制作人的团队建设感悟 团队论这篇文章，只是我带领团队做游戏的一个缩写。里面不乏很多人遇到的问题，也不乏很多问题的解决思路。实战经验，各位在以后的日子里，如果遇到这样的问题，能避免些就避免些。 人员构成上来说，同制作人的经验是有很大关系的。当我经验尚浅的时候，我也组建过团队，当时记得是招了几个行外的美术，招了一个火石的做了2年的程序员，当时做的游戏也是比较简单，所以在配备上，以能做出东西为主，我觉的，这个思路现在我仍然受用，不见得一定要招各种厉害的人士，厉害人士未必会很好沟通，有时候反而因为他自己的想法阻碍了案子的成型。 后面有经验了，在招人的过程中，开始考虑的是上线处理的问题了，如果一个团队中没有有能力的核心，那在上线后，问题暴漏的会特别的厉害。解决乏力。所以后期的案子中，我起码会在项目中留2个很有能力的技术力量，而且会同外部的技术大牛建立联系，以备后用。因为上线后才是bug大批量爆发的日期，再多的提前测试也不会解决这个问题的。如果你不是已有上线代码的基础上发展的案子，那重新架构其实是非常大的开发风险。熬过上线期，才能算松了口气。很多时候，团队作品的失败不见得是思路而是技术。这也是后期上线的精力给予我的教训，我把这些都用在了后面的案子里，所以路才走的越来越顺。其实真的是经历的越多，才做事越有底气，有思路。 回头说之前的那个经验尚浅时的项目。团队刚组建，我着手开始理顺各个部门的沟通机制，文件制作规范，这个给我了甜头，因为后来的经历里我见到了各个部门间沟通机制不畅，文件制作规范没有导致的没必要的时间浪费，很多时间花在文件的命名，文件的格式修改上。这些其实也是成熟的团队或者成立已久的公司不会再犯的错误。 但是没经验导致了另外的1个问题，源码，源码始终保留在程序员手里，而当时也没有建立代码库来强制要求，也没有封内外网之分，导致程序员在代码的交接上混乱，以至于后来我为了完工，额外出钱联系程序外包做完了项目。 接着项目完工，老板不准备继续做。遣散，各自离开。 这个团队的从创建，到开发过程，到结束，给我很多的思路，以至于我都用在了后来的项目开发中。 1，团队的基础开发速度，取决于最终成品的那个环节，程序部门，而这个环节的关系，是制作人首要要打理的。 2，团队的开发效率的上升空间，取决于部门间的沟通机制，文件交流的便捷和规范。这些是基础的基础，最先要捋顺的。 3，新团队，是没有忠诚度的。也不要一开始就培养。新团队最初还是很单纯的买卖关系，这个时期，团队需要的是利益目标。比如说，分红，奖金，这些在前期调动团队的积极性是非常有效的。没必要一上来就喊着要改变游戏业，改变规则，这样的口号不适合新组建的团队。激情，很容易就磨灭在不加班和赶工中了。 4，各个岗位上的人，尤其是程序，不可以只有1个，一方面需要通过协作，相互监督代码。一方面程序员如果有比较，就不会有很多独大的想法出来，执行效率上会以做事为主，不会慢慢开始干涉制作。 然后就到了下个项目，下个项目里，遇到的情况是这样的。公司已有团队，但是想扩充人员尝试新类型。于是招了1大批新员工组建了团队，但是其中安插在重要的位置上，安了2个人。我也听到不少公司采用这样的方式。确实在表面上看了，既有原来公司的人在把控，监督，能确保案子不离开公司的眼睛，又可以扩充产品线。 弊病就显而易见，团队本身在制作上是一定会出现分歧的，哪有风平浪静的开发过程啊，不可能。 决策人是母公司的，那他的个人影响就决定了案子安不安宁了。 为什么说个人影响那，因为我遇到过不安宁的团队，也见识过安定的多的团队，确实和制作人的处事，经验有关系。后面慢慢说 这个项目决策人是独断的人，但是他犯了一个错误，独断的人要拥有绝对独断的权力和很强的交际能力，起码独断犯错后可以化解对自己伤害最大的言论。 独断的好处是，如果你手下的人都是新人，那这个团队的执行效率会非常的好，效率高而且容易把他们的执行力释放出来。因为新人是想做事情的，实现系统制作出来玩得到，这个兴奋会持续大概半年到1年的，他们这个时候表现出来的执行力是让人惊讶的。所以这也是我后来喜欢启用沟通好的毕业生的原因，他们对游戏还抱有极高的热情，实现系统又可以让他们保持热情，执行的效率很高。但如果都是新人，坏处也来了，就是你作为决策者需要做大量的决策，以为新人是没法子放手的让他们做决定的。于是决策者自身非常累而且离开了决策者，项目就陷入到踩了刹车后的惯性距离里了，节奏会被慢慢打断并开始混乱。面对这个问题，我后来的方法是，培养1个二级决策者，慢慢的从细节决策放手，到后来的系统放手，这个过程很长而且要看准人，我觉的，稳重，善沟通，游戏经历丰富这样的人，适合这个位子，这个思路是我培养了2个二级决策者以后的经验，倒是不一定是真理，毕竟每个人带案子的风格不同。 我为什么会选这样的人那？