某某公司一年间，胜读五年书 2003年6月—2004年12月 在某某公司已有一年半的时间了，在此期间，本人的工作性质发生了很大的转变，但更大的变化则是公司本身，在于公司上层对于游戏界，游戏软件开发这个行业的认识，从一无所知到有所领悟，从拍脑袋到理性的探索。从一个侧面，也能反映出国内的资方对于游戏行业从陌生到熟悉的一个过程，其间经历了很多错误、挫折和迷途，甘苦自知。以下，是我本人，作为浪潮中的一滴浪花，抑或是泡沫中的一个泡泡的经历。 公司建立之初的主旨就是自主开发游戏，将核心技术能力掌握在自己的手中，不要受制于人。对于此想法，当时的我看来，上层核心人物对于游戏业内的客观规律还是能直指其要害的，深谙自主开发的重要性。认为是找到了一位明主贤君，一拍即合。 公司已上马的项目，目标直指联众，要做一个更好的棋牌游戏和社区。由于另有安排，我也就没有加入棋牌的开发项目组中，正是如此，我才能更客观的看待这个项目和由此产生的问题。综合来说，个人认为该产品“夭折”，主要在于技术上的错误判断，使用了商业软件的开发技术，未采用游戏开发中必须的技术，从而导致了产品客户端和服务器端软件运行效率极其低下，对硬件配置过高，抬高了玩家的进入的门槛，就好比犯人躺在断头台上，自己按下了行刑的按钮。 对于技术上所犯的错误，比较致命的问题有以下几点： 1. 所有开发人员无一具有游戏开发经验！！！ 2. 客户端的图形渲染部分使用了Flash，而没有使用业界常用的DirectX或者OpenGL图形库，造成了客户端软件对于系统内存需求过大，耗用过多的CPU使用时间。 3. 客户端主界面，也就是大厅(Lobby)，没有考虑到用户自定义性，甚至窗口大小都不能改变，给用户的感觉就是过于死板，缺乏定制的特性。 4. 服务器端使用Java语言，虽然具有很好的跨平台特性，有易移植和低成本的优点，但是恰恰抛弃了效率这一关键点，并且由于设计上的缺陷，服务器的负载能力非常弱，实际应用中，并发连接数超过400人，就会出现各种异常。 5. 服务器端的数据库系统使用DB2，由于缺乏有经验的数据库优化人员，数据操作的效率也是一个很大的瓶颈。 当然，在看到问题的同时，也不能忽视了科学合理之处，大致如下： 1. 采用品质管理人员(Quality assurance)，比国际上各大游戏开发商对于游戏品质的管理普遍采用的游戏测试人员(Game tester)要更先进一些，游戏软件虽然特殊，但终究还是软件，用标准的软件工程来定义软件开发的各个阶段，QA人员是必不可少的。但是，如果QA不具备超越Programmer的技能，不能编写各种测试用例，不能比开发人员更熟悉功能、模块的话，那么，他们也只能是懂一些程序语言的游戏测试人员而已。 2. Auto build和Daily build。使用anthill来实现自动集成，可以根据脚本，自动编译所有项目，也可以接受指令，定时定量地编译需要的部分。如果编译出错，可以通过浏览器访问它的服务得到比较即时的反馈。这样的话，可以保证随时都有最新的可运行版本发布，供测试人员使用。 3. 版本管理系统。公司使用的是CVS，最流行的开放源码的版本管理软件，基于TCP/IP协议。在公司内部架设服务器后，客户端使用wincvs或者eclipse，就可以很好的发挥它的作用。对于从未使用过版本管理的开发人员来说，刚开始会有抵触情绪，并且确实会影响到开发速度，出现误操作的话，也要费一些周折。但是良药苦口，在攀上了学习曲线的悬崖后，一致性、自动备份、差异比较等版本管理的优点就充分体现出来，可以减少很多人为的操作错误或者由于沟通交流上所导致的问题。 4. 较规范的软件开发流程，如果是开发商业软件的话，那么想不成功都难。软件工程上定义的软件开发过程，可以分为系统的需求分析，系统地设计，系统实施，系统运行，系统维护。如果是开发单机游戏的话，那么就会缺少系统维护这一阶段，因为不需要这一过程，而网络游戏的话，恰恰是完全符合软件工程上的软件开发过程。（玩家就是用户，游戏策划人员根据市场部对于玩家的需求的反馈进行分析，确定出需要开发的游戏软件类型，然后编写创意案、策划案、策划大纲，将之细化量化成为能够使开发人员能理解的具体需求。） 在棋牌项目开发的同时，上层决定还要进行益智类游戏开发，我的入职就是为了这个计划。因此，花费了2个月，寻找合适的引擎并作试验性的开发，曾使用quake2的引擎源代码修改制作游戏原型。一个偶尔的机会，torque游戏快速开发引擎摆在了面前，经过技术总监的研究，认为是一个能满足我们的开发需求的工具。 确定了开发工具之后，便是选择游戏题材。由于torque是一个三维游戏开发工具，并且自带了一个简陋的赛车游戏原型，于是决定做一款仿《Mario赛车》游戏，项目组由1名项目经理、2名程序员、1名美术人员和1名策划组成。 开发初期，进展很快，好似一马平川。一个多月后，在基本完成1根赛道和车辆建模，比赛规则大致实现后，遇到了一个不可逾越的障碍，那就是刚体的碰撞检测问题，由于torque的先天不足，这个问题一直到引擎最新的版本也没能够很好的解决。由于缺乏合适的技术攻关人员，在做了多次尝试后，终于决定暂停该项目的开发，同时，也是公司第一次变革的到来。关于这个项目的失败总结，有以下几点： 1. 缺乏引擎挑选经验 2. 不是根据游戏类型去选择游戏引擎，而是根据引擎来决定游戏类型 3. 在项目真正开始之前，没有进行有深度的技术攻关工作 在20多人的棋牌项目小组辛苦的开发将近1年后，作为成绩汇报，市场部开始了试探性的小范围推广，顶峰时期，同时在线人数也达到了将近400人，也着实让全体惊喜了一下，但是很快，由于以上列出和未列出的问题，使得人数始终无法突破，GM人员对于游戏中存在的问题无法得到开发人员的良好支持，玩家提出的各种问题和建议无法得到反馈，内部开发人员对于付出巨大精力的项目却无法得到良好的经济回报而情绪低落，上层发觉该平台始终未能有所突破也意识到了问题的存在，这一切，作为第一次变革的催化剂，一切都是那么的突然，又是那么的理所应当。 2003年12月1日，周一，由集团总裁召开全体员工大会，宣布了一些如下决定：原公司总裁A由于身体不适修养中，由B担任新副总裁。这一切，明眼人都知道是为什么，也期待接下来的一系列变化。 然后，总裁分批与员工交流，了解公司存在的问题，大家各抒己见，也着实暴露了不少问题。上层经过两个星期的讨论，宣布了如下决定： 1. 公司实行矩阵式管理，研发部门实行项目制度 2. 在2004年6月底之前，必须完成15款自主研发的游戏产品 3. 建立游戏门户网站 4. 购买并运营10款国外的游戏产品 从以上4点可以看出，上层想要建立一个有质有量的游戏门户，出发点非常好也的确是把握住了时代的潮流，但是，问题在于仅仅半年的时间，对于一个没有一点积累的新入行公司来说，无异于登天。 决定下来后，组织结构和人员也发生相应变动，我也被安排为程序开发部部门经理，主要肩负自主研发的游戏产品的任务。接受原来的程序部之后，艰巨的任务就开始了。首先，第一步工作是人员的整合和重新分配。由于先前的工作安排，与程序员接触较少，所以比较陌生，一下子要融入他们原来的圈子，还不是容易的事情。当然，知难而上才有挑战。通过与每个程序员谈话、聊天以及从技术总监和人事处了解每个人的性格和能力。虽然通过了解，发现大多数程序员不适合从事游戏软件开发的工作，公司职能部门安排相当怪异，部门经理没有开除部门员工的权利，所谓的责权不一致，大致如此了吧。技术总监考虑到人员的稳定性和与我的熟悉程度，调拨了一些老程序员转去系统开发部门。 第二步的工作是根据项目的数量决定程序员的人数需求。由于决定使用torque引擎来开发游戏，所以开发部门的架构是底层引擎开发人员+游戏逻辑开发人员。第一批项目由5个项目同时展开，根据游戏的规模，每个项目组大致需要3名程序员，因此总共需要15名程序员。由于项目启动时间是在2004年农历新年后，所以，留给我的，只有1个月时间招聘15名游戏开发程序员，现在想来，要不是借着一部分毕业生找工作和运气，还真是mission impossible。 人员齐备，职能和管理分派完毕，与此同时，项目的开发进度也由技术总监制定完成，从春节后到6月，一共4个月的时间，由5个项目小组每两个月完成一款产品，那么就是十款产品，加上引进以及外包的产品，那么大致能满足上层的要求。由于我也缺乏这方面的经验，所以无法指出计划的不妥之处。从计划上来看，一切都是这么完美，一切可能的问题都会按照计划安排迎刃而解。 作为一个游戏门户网站，那么现在流行的游戏大厅，用来包容所有门户的游戏内容的客户端是必不可少的。从策划角度出发，如何能够将自主开发产品与引进产品以统一的形式放置在该大厅客户端中，是一个颇具争议的问题。当时参考了韩国的许多门户网站、gamespy和QQ游戏的客户端，由于各有千秋或是各有所长，导致了决策层对于采取什么方案无所适从，策划案和设计草图一改再改，技术选型也悬而未决，会议不断但是没有定论，最终，该开发小组的重要人员离职，我认为决策层难辞其咎。

节后，开发人员精神焕发，投入到积极的工作中去。Torque脚本的学习曲线相对来说还是比较平直的，所以各个开发小组很快的就有了各自的游戏原型，对各方面来说都是一个正向的激励。时间一周一周的过去，问题减少到一定数量后，很难看到有继续减少的趋势，引擎组的人员工作安排和工作时间开始增加，而开发小组的程序人员对引擎组人员的工作效率开始抱怨，各个项目经理在工作汇报中，总是会出现“工作进展基本顺利，除了几个暂时没有解决的技术难题”，随着时间的推移，有2个小组的工作进度就完全被几个技术难题耽搁，几乎无法有新的进展。虽然想了很多其他的方法，但未能从实质上解决。引擎组的人员工作压力也日渐增加。很快到了最后期限，然而在实际网络环境的测试中，GM报告反映的是对游戏的表现的不满，主要是反映游戏延时严重，游戏载入耗时过长，哪怕是完成度和质量最高的，也不足以作为一个产品推向市场。而且总体来说，所有的项目都已经延期。劳动节过后，所有人都知道原定的计划已经不可能实现，接踵而来的，只有是新一轮的变化。 对于这批项目的总结，如下： 1. 计划制定太过理想，对于各种可能的风险没有很好的预计。 2. 引擎组人力严重不足，导致了很多关键技术问题不能解决，直接影响了项目进度。 3. 程序开发人员对Torque的了解还不够深入。 4. 游戏工具的缺乏，特别是对于美术人员来说，也是影响项目进度的原因之一。 5. 各项目组开发人员之间的交流不充分，没有很好的共享经验和问题，这一点来说，作为程序开发部的经理的我来说，要担负全责。 6. 测试环境不齐备，测试人员不足，未能尽早的发现一些严重的问题，影响产品质量的问题。 7. 开发后期，由技术问题间接导致了人心涣散，从而影响到项目进度以及其他项目组成员。 很快，上层做出了反应。对目前形势做了仔细深入的考察和探讨。结论认为目前的开发实力的确不足以同时进行如此多的项目开发，需要学习国外有丰富经验的游戏开发公司的组织结构，即工作室形式。在询问了我以及其他几位在欧洲、日本游戏公司工作过的同仁，确认了这一想法并且任命原策划部经理和程序部经理为休闲益智游戏工作室正副总监，即我为游戏工作室副总监。 在接到新的任命后，我和策划部经理开始新的合作，由于是第一次合作，鉴于后者已经在集团工作多年并且完成了棋牌游戏的策划工作，让我对他有了想当然的认识。在工作室规划上，我未使用换位思考，从上层的角度去考虑如何看待现有的开发部状况。想当然的认为集中优势兵力，主攻一个方向，淘汰不合格的人员。结果被上层当场否决。意见产生了分歧，因此上层从策划部指派了一名作为第二工作室的副总监，将原先的项目继续开发、优化，然后再指派一名策划人员作为棋牌工作室副总监，去完成对棋牌游戏市场的占领工作，我们的工作室则按照我们的想法，去实现从无到有的休闲益智游戏平台。这样，开发部的格局就变成了三分天下。 对于这个决策，我的看法如下： 1. 出于从上市公司来看，大规模的人员流动肯定会造成股市的动荡，对集团形象不利，因此，上层肯定不会赞同我们的大规模精简的决定。 2. 从开发来看，将本来就不够强大的资源分为三块，只能是削弱的开发实力，当然，使用购买成熟的商业中间件和人员内部借调能够弥补这方面的不足。 3. 自己考虑欠周全，思维不够全面和缜密，导致了这样的格局的产生，将自己的将来发展造成了很大的障碍。 从2004年6月开始，取消了原先的开发相关的部门，统一成为工作室，由总监管理，为各自的目标努力。然而每次组织结构调整必定会遭致部分员工的不满，最明显的就是从总裁B的离去，具体原因不得而知，但听说是因为不能发挥自己的能力，也没有得到上层的认可。之后，大约有5名开发人员离开了公司，原因大多不满意公司1年多来的发展没有明确的方向，个人的才华和价值不能得到体现，工作安排不合理所致，分别去了上海游戏、九城、浩方、盛大。 动荡之后，又是一段时间的安宁，各个工作室的工作都进行得比较顺利，也有少量的人员补充。到2004年12月，大约半年时间，工作室内一共发生了以下几件可以称之为大事的事情，对很多人来说，都是非常罕见、小概率事件，我想，对于个人的成长来说，也算是丰富阅历，增长经验吧，但还是不希望此类的事情再次重演。 1. 开发部人员的三角恋爱开发部女性资源极度匮乏，在各个软件开发类公司都是正常现象，那么发生这样的事情，可以说是意料之中，也是意料之外的。具体的故事内容可以参考琼大妈的撰写的各种爱情参考手册，结果是败者愤恨的离开公司，还差点导致人员伤害事件，管理人员可引以为鉴。 2. 开发部人员的不幸逝世对于一个平均年龄不到26岁的公司来说，这样的事情，是绝对不会被列入风险的，但是，人有旦夕祸福，最不幸的事情还是发生了。大学刚毕业，与我同一天进某某公司报道的东北小伙，倒在了篮球场边，离开了爱他的父母和女友，在我们心中留下了永远热情、开朗的剪影，是幸福还是自私，我们无法擅作决断，但是，健康第一，身体是革命的本钱，这是千古不变的真理，为了自己，为了不要让家人、爱人伤心，请爱惜自己的身体。 3. 开发部人员的信任危机俗话说，众口铄金，积毁销骨。谣传工作室的某些成员将公司的作品拿出去与其它公司谈判，当事者听到这一消息后，为自己的声誉奋起反抗，经多方的安慰，终将风波压制下去。凡事没有确凿的证据之前，一定要将谣言控制在最小范围，否则，对员工的伤害和信任危机将可能造成轩然大波，扰乱正常的工作。 领导讲话，总喜欢来个总结，那么，我也来凑个热闹，总结总结。加入某某公司，整整一年半，感触颇多，可以看出上层的确想在游戏娱乐这一块做出点成绩，但是从这将近两年的历程中，可以看出以下几点：  摇摆不定，没有找到真正属于自己的方向究竟是自主研发还是代理运营，公司决策层摇摆了很久，最终选择两者并行，这是目前大多数游戏公司采取的权宜之计，但对于本公司来说，这又是花了多大的代价才得来的决定呢，实在是难以估量，不管是时间上还是资金上。  部门职能定位不清晰，职能冲突造成的矛盾数不胜数举个实例，其他各职能部门需要加班还须由行政部门批准，这个决定未免有些可笑，行政作为一个执行部门，对其他部门的具体工作内容无权干涉，同时也不可能了解由于其中的具体技术细节造成的加班需求是否合理，本应当由部门经理提出的，作为部门预算开销的一项支出即可，如此一来，表现为对部门经理的不信任，严重打击工作积极性，节约开支的确是公司持家之道，但是错误的举动所造成的后果，会在日后成倍的体现出来。行政部门是否需要有如此多的权力或者说为什么行政部门的工作人员每天都要加班，为什么不能把原属于其他部门的职能工作归还，双方都可以得到解脱，究竟是谁在背后操控，为什么要这么做，具体原因不得其解。  对于开发部门，没有实行彻底的项目管理制度作为项目的基本支出，本来已经捉襟见肘的项目活动经费50%以上被行政部占用，作为公司每年的拓展训练费用支出，而每年的活动，到底有何成效，员工的反馈如何，无从得知，仅仅是作为一道工序在执行而不进一步讨论是否应该有存在的必要或者是否需要改进。在每个项目开始之前，都会有项目预算，然而，“做好了没奖励，做坏了要惩罚”，这个理念已经深入人心，出尔反尔，令执行人员和基层员工极度郁闷，项目没做好，究竟是谁的责任，决策不当还是执行不力？孰是孰非，难以决断。  没有贯彻“right person in right place”，人员浪费和闲置屡见不鲜多年前的一段相声，“说你行，你就行，不行也行”，实在是从生活中来，在公司中也多出体现，一些中层干部的任命和提升，有何依据，也许就是上层的一个点头吧。  细节决定成败，公司制度的贯彻和执行力度极度缺乏，适得其反之处也颇多。公司的员工手册、规章制度，林林总总，不一而足，若能贯彻实施，也许会遭到员工的抗议，但是也能增加许多生产力，中庸之道，如何去揣摩，还需要时间和经验，制度的修改和完善也是必不可少的，如何找到适合游戏软件开发的制度和规范并不难，困难之处在于如何执行以及针对本公司的实际情况来修改和适应。 然而，对于我本人存在的问题，当然也不是能够忽略的，毕竟，了解自己，才能让自己进步，不断的改进和完善自己：  情绪不够稳定，有时候会表现出消极的情绪，而且不懂得掩饰，影响到其他人的心情。总的来说，还不够成熟。  管理（对人、对事）经验欠缺，需要不断的学习和实践。  不能够坚持自己认为正确的观点，易妥协。  技术知识也需要补充新知识。  要多为别人考虑，多用“换位思考”。 罗罗嗦嗦一大堆，是对自己的总结，整理自己纷乱的头绪，以后也会是我的经验，我想，我没有使用太多的“换位思考”，不知道，从上层的角度来说，故事又会是怎样的呢？黑泽明的《罗生门》，应该会是最好的答案了。 问号 2004-12-12