Chapter 04

老实说，一开始我并不喜欢Scrum。

当然现在也不是很喜欢。最初，我觉得这是一种防止开发团队无所事事——虽然它的目的的确如此——而强加于上的花样，就好像搬新居后给猫爪子涂的黄油。意义不大，但能让你且折腾。在此之前，激励队伍提高效率的方法简单而没有成效，要么就是威逼利诱，要么就是夸大其词，无非就是动员宣讲胡萝卜大棒那一套，空虚而无聊。有时候他们会找一个洋人——多半也是洋人，他们身居要职——走上前来，感谢每一个人难以置信的努力，告诉他们所有人都是不可或缺的——其中一两个听众攥着别的公司发来的聘用信琢磨着在被开除之前找个更好的下家。听得多了你就会发现，那些关于洋人的说法多半都是些道听途说。他们也不是什么道德情操皆高尚的圣人君子，他们也会说囫囵的官话打哈哈，拿车轱辘话先忽悠住你在说。明白了这一点后，动员讲话就变得越来越不起作用了，这个时候不知道谁提出来搞Scrum。

据我所知在Scrum之前IT业也好，普通白领企业也好，都在寻行之有效，甚至是放之四海而皆准的管理方法：这就很像那些初入行的理想主义者，想一劳永逸地找一个至少相对而言比较完美的解决之道。从前我们使用的是所谓基于瀑布式开发的管理，单向、从上至下、常常返工。但是这种方法最终被演变成一种形式主义，很多时候负责人会跳进来横插一脚，大声地嚷嚷着说这个不行，那个也不行，你们都是一班废物，然后撂下剩下一半看都不看一眼，夺门而去。大家面面相觑，不知道该怎么办才好：剩下的东西还等着检阅通过呢，拿主意的人就这么爆走了。于是后来就出现了很奇妙的事情：助理制作人和团队干部事先检阅，揣摩上峰的意思，优先拿过得去的东西给他们看，并且祈祷他们尽可能晚地暴怒槽。用完成度高的部分来稳住人心，讨好他们的心情，随后希望能在负责人最终发怒之前看完整个项目的内容并至少做一些可供参考的批示，以便能够进一步地继续后来的开发。听上去和国营企业的管理方式不乏相似之处不是么？很显然，经历了几次这样的弯路，人们发现这么干对以后并没有什么好处，于是他们开始使用Scrum。

从这种开发方式的几个明显特征来看，我觉得它过分强调自主性而显得带有一些监视色彩。团队被划分成小部分，他们每天在一块白板前站十几分钟，每个人都要说出自己昨天干了什么、接下来要干些什么、以及是什么妨碍了他们所干的事情，然后所有人严格遵循事先订下的计划和工作量，谁都不允许横插一脚。假如你想跑进来说三道四，最起码得先走一个程序上不算简单的流程：提交一个任务，让团队进行工作量和重要性的估算，指定相关的负责人员并监督……基本上都得在第二天的会议上提出并通过。听上去就像小学老师把人一个个拎起来教督导课，或是每天的董事例会。我直觉上觉得这种方式除了流露出不信任感和很多程式化的过场以外，还不利于创造性思维的展开。任务并非由实际开发者所提出，而是由最高的负责人提纲挈领：游戏设计师或者是内容总监。按照我们同事的话来说，就是一个大脑袋带着一帮整合人呼啦呼啦地干：大脑袋负责提供点子和构思，底下的一干小弟就把东西整合进引擎里，完活！既安全，又不会有人背黑锅，负责任的和监督的他就是同一个人，只要按着上头的意思干哪儿有不通过的道理？皆大欢喜皆大欢喜！

按理说，Scrum提倡站着开会，每次会议不超过十五分钟，与会人数不要过多以免造成时间上的冗长，这些都是防止工作人员在枯燥的会议中昏昏欲睡的手段。然而一旦到了估点会——负责人和团队成员遍历下一个进程需要做的任务，为每一个任务估算理想的任务点——好了，你的这三四个钟头就算折进去了。更要命的是，这种会议每两个星期（视乎你们的进程长度）就要开那么一次，而且多半是在快要周末的时候。每到那时，人们都会有“这是周五么？”的错觉。因为只有在周五，惦记着大好周末的时候，大家才会这么拼命地把手头的活儿都结了，无事一身轻地休息。开着这种会，我总会想起Volition的招聘宣传词：瞧，你就像我们这儿的哥们儿一样，爱做游戏，但不只是爱做游戏。你想和富有创意，有些极品但不无才能的人们共事，同时也有自己的生活。也许你想贷个款买个房，上班路上绝对别超过一刻钟，平时可以有时间宅一宅，晚上和家人或相好的一块儿过。星期五晚上坐在酒吧外头拿着瓶凉的瞧西洋景，管他什么3DMax还是Perforce。反差啊，我的朋友们！总之这种星期五我是没有过过。

不过，假如你就像我所提到过的，能够学会乐观思考，那么整个事情其实也不是那么难熬。开那么一两次每日例会以后，我发现这个揭皇榜式的工作模式特别具有漫画喜感。大负责人每个进程开始天把大把的任务写在巴掌见方的纸上，吧唧吧唧地贴一白板。群众们熙熙攘攘地拥过来，七嘴八舌：我能做这个，他能做那个……一边说一边把任务拿下来，放到“进行中”一栏里。有时候那些做好任务的人，则把“进行中”属于他们的任务从磁吸或者透明胶下面拿出来，贴到“终了”那一栏，随后拽着相关的责任人验收，就差没有领赏头了。这种仪式每天举行，周而复始，像极了一群为生计所困的勇者在村子的公告板前面接支线任务。你这么一想，很没劲的工作就会变得滑稽起来。而且它还带着一种方法论的荒谬：本来能够电子化的工作流程，偏偏要搬到纸上来，为的就是更方便监督鞭促，按照同事的话来说：“这个东西会让你变得更有效率，努力工作，不为什么，凭的就是你的羞耻感。”好一个羞耻感！但不无讽刺的是，虽然在提高工作能效上的确卓有成效，但是其方法本身则比以前更花时间，而且违背了一度甚为提倡的无纸办公——我们每个进程两周，每次一个组提交的任务不下两打，平均每个任务的执行人都要在白板上贴一张属于自己的签单。三四个组两周工作下来，扎成捆的废纸得从货运电梯走。

原本是有电子化的程序可以搞定这一切的。Scrum原本就是为了迎合敏捷开发而产生的一种方式，你用一个叫做Effective的东西就能简单地做到跟踪和监控各路人马，看谁没有好好地把屁股揿在自己的凳子上好好干活。但是我们已经有够多乱七八糟的玩具了：除去引擎不算，Google Sketchup、Perforce、Adobe Breeze……还没算上程序自己写的，用来得引擎版本的各种插件和自定义软件。再者说了，采用Scrum的本意就是让大家动起来——虽然这一点咱们做的不是特别好，大部分人还是喜欢懒在自己屁股下的凳子上——你忘记了还有什么东西要做，或者什么东西是急着要的，或者干脆想不起来自己要干什么了，再好不过！站起来，朝白得刺眼的那一大块径直走过去，查看一下你想要知道的信息，不管能够转换心情放松疲惫的身心，还能够理清思路。听上去有些言过其实，但是相信我，经过长期脑力劳动，尤其是盯着显示器上论坛刷开心网什么的，无论你干什么，哪怕是对着双20寸DELL显示器，你的身体也不会因此而减少一丝疲惫。而从是我们这一行的，那可是说要多懒就有多懒。就算你扛着一挺火箭炮对着我们的同事，他的反应可能也仅仅是瞟你一眼，不紧不慢地嘟囔着“给我带瓶喝的吧，钱上来给你……”因此在抽大家鞭子这一点上，我还是比较赞同Scrum的。只是这种理论概念式的东西，很难让人有一个理性的理解，就好像基金证券或者股指期货。它是什么？某种license么？靠贵得离谱的版权来弥补财政支出么？它是一种软件捆绑的方式方法论么？它的盈利依附于软件零售么？对那些一无所知，又很难有直观了解的东西，避而远之一向是我们与生俱来的本能。只不过当后来我了解到，敏捷软件一部分是靠卖它那些个看上去不能再普通，但价格令人咋舌的扑克儿来赚零花的时候，我只能表示哭笑不得。这些扑克用来在给任务估点的时候出价，就像小型的竞标道具。我们倒是买了挺多，但大多数时候大家都不会严格遵守规则去用，最近更是因为低点数的牌不够，直接在多出来的那些个100点上拿油性笔改个数字。是的，你也看出来了，只要你愿意，这些小道具也能自制，没什么不可以的。但是，嘿，那样不是显得不够专业么？！还有那些认证的Scrum讲师，总让人想起IT业里持着一大叠证书却让人完全不明白他究竟能干些什么的角色。好吧，你可以说我持有偏见，也许它并不是最适合于游戏开发。不管怎么说，最后略带官僚主义作风的Scrum还是被我们私底下潜规则了。有些不是那么花时间的任务，大多数基本上只是举手之劳，你会发现有个人匆匆地走过来，手上拿着一张纸，啪地贴在白板上。两分钟以后还是他，还是那张纸，从“进行中”直接贴到“完成”栏，随便找个知情的人签字验收。有时候连这些步骤都省了，不甚重要的工作量又回到了以前私人手工作坊的打黑工模式。模型忘记把Max文件按正确的格式导出了，算了算了，我帮他弄好了上传，不然我的工作都没法儿继续；GPP的数据传不上去了，我这儿帮他在本机改一下上传；甚至说，想要打印任务详细没纸了，打印机连不上了，磁吸不够用了，我活儿都干完了，于是想想自己心里有数就可以了，也未必就会认认真真地朝大白板子一一汇报自己的工作情况。按照老一辈无产阶级革命家的较真劲儿来说，我们这就叫做工作态度不认真，缺乏责任感，精神面貌涣散。虽然表面上看来不会有什么的大问题，但总有一天鸿毳沉舟，追悔莫及云云……

树挪死人挪活这句话，总归是有道理的。

Chapter 03

看文档都是怎么说的。

在项目刚刚立项最开始的那一段时间里，假如你有幸已经参与到了制作中，就会发现很多事情基本上没人知道是怎么回事儿。总的来说，一个项目的引擎，多半都是由别的引擎增减而来。打开引擎，你会看到别的游戏的flash screen。可以说，就连负责引擎的程序都未必有个底：他们接受来自项目各个部门的要求，给这里加点功能那里添行代码。到了最后，编辑器不用说也肯定和原来大不相同了。你没办法追溯这些改动最初的想法和意愿是什么，多次重复的会议也会让你一脑子糨糊，但是文档会安静地躺在sharepoint或者共享文件夹里面，除非有人动它，否则决不会自己个乱成一锅粥。就算是有人捣乱，你也可以根据上面的署名和更改人找到罪魁祸首，跑到他的座位前面一把揪住他的领子，大声质问他这个功能或者那个特性到底是什么意思，怎么实现。

有一段时间我对很多美工的沟通能力挺纳闷的：他们几乎没法儿和公司的洋人们进行有效率的交流，基本上多半是My name is wendy的程度。后来有人一语道破梦中人：关卡设计要写文档的啊！文档能力，尤其是英文文档能力，被作为许多海外或跨国公司招聘时对应聘者硬性的需求之一而重视。根据我的经验，一次项目伊始的培训会议，比方讲，“如何使用Unreal引擎”，在它结束的时候，平均每个与会者只会记住会议内容的百分之三十。具体哪百分之三十固然因人而异，不过大部分都是最开始的那些。考虑到这样的会议往往会持续两个小时左右，通常又会以英文召开，这个数字可能要再打一个折扣。你可能会做这样的联想：就好像是战争，只要牢记培训中所学到的一切，你就能活着做完这个项目的说法纯属扯淡。当然不出意外，不违反公司章程，你多半总能活着做完项目，不过这和是否牢记住了培训内容无关。因为公司不大可能设立一个职位，专司项目引擎的教学与应用。它是那么多变，活像是午夜时分地铁架桥下满是涂鸦的廊洞，可以被程序在一天之内就改得面目全非，没法儿指望一次性的宣讲就能让大家掌握所有将来可能发生的情况。理想的情况下，与会者都尽可能地记住了互不相同的部分，并且在会后互相教授。即便如此，也要浪费大量的时间和精力，其效果差不多相当于和每一个与会者单独开上两个钟头，让人昏昏沉沉的会。因此最好的——尽管未必是最有成效的方式，经过多年经验总结的方法论：看文档，就成了这种问题的解决之道。

即便是一个制作周期少到可怜的小项目：11月立的项，来年2月份就要Alpha，也有数不清的文档。排除人们在这种风险不大周期短的小项目里做各种管理实验的因素：Scrum、数据分列、多平台同步开发、高清低清模型branch、RLD……各个部门也有大量的文档要写：引擎、GPP、游戏设计、关卡设计、美工、QA、人事、管理、模型、音效、数据管理……说起来讽刺，如此多的文档需求量，搞到最后实在是超出了饱和度，导致的结果反而是文档来不及写，真正放在sharepoint上的文档远远不够制作队伍参考和学习的。当然，我们有这样一个人卯足了劲把重要的文档挑选出来优先撰写，以保证制作的基本需要，不过总的来说还是杯水车薪。更要命的是，大家因为实在找不到文档，所以干脆就把这个写文档的人当作活文档，旦分有任何不明白的都会去问他，从而造成这个人更加忙碌，更加没有时间写文档的恶性循环局面。是了，这个人就叫做技术指导。

就个人而言，我十分喜欢技术指导的活。你可以认为是好为人师的虚荣心作祟。没有什么能比联合多方力量解决一个问题，然后告诉大家：“嘿，哥们儿们！打今儿起咱们就可以用spawner生敌人，不用再一个个费劲地拖进编辑器里面去了！”于是所有人都很高兴，弹冠相庆更叫人心旷神怡的事了。而在此之前，基本上你若是多放了些什么东西，出于数据整齐的考虑，打算删掉多余的副本，那么这种电子洁癖多半会要了你的命。有些引擎喜欢把数据结构在出人意料的地方多放那么一份，会导致在进行删除操作的时候丢失连接和参照，不知情的人在每天常规的一百多个警告中漏看了，上传了，一下子就能把数据结构破坏掉，阻滞所有人的工作进度。当然这部分是因为个人工作态度的问题，部分则是因为基于成本控制而自主编写的引擎代码，肯定不如商业引擎结构严谨功能完善纠错率高所致。我知道你们在想什么，“干吗不打从一开始就把事情给收拾好呢？”这种念头并不鲜见。我认识一个资深的美工，在三四个大项目之后还会对反复的工作进度大肆抱怨：他们怎么不一开始就把事情弄好呢？这个习惯直到他成为美工技术指导后还残留着，我总能看见他和关卡设计的Leader在争论，为什么不能一开始就计划好？为什么不能一次性的弄好？为什么不在出问题之前就杜绝？为什么要把地图做这么大？！为什么……你瞧，我并非蔑视美工这个工种，只是这种追究过往责任而不是着眼于解决目前问题的工作方式，实在是对进度无益。假如事先能够有一份详尽的，或者至少尽量详尽的文档，也许情况会要好转许多。

这又回到最初的问题了：我们是否有足够的人手和时间来写完备的文档？在文档不能提供百分之百的帮助以及解决问题的时候，我们是否在对毫不留情地使唤技术指导这件事上，无需抱有人道主义的怜悯？答案是非常肯定的。一个胜任的技术指导，往往忙得口吐白沫，一额头虚汗，还得不停地给各路人马打黑工，平均每天重复三遍某个特性或功能的调用和使用方法。因为和项目预培训会议一样，文档能够灌输给目标对象的，也只有其内容的百分之七十到八十——这个数据是在文档语言为英文，受体以平均工作热情边阅读边在编辑器里实践的条件下统计出来的。也就是说，那些“哦shit是一个英文文档，这怎么看啊！”“金山词霸呢，金山词霸呢？！”或者“办公室好热……”“午饭没吃饱……”“好想打DoTA……”“好我明白了！嗯……咦，第一步是干什么来着？”他们从文档里面获取的信息将更少。这个时候，一张满头虚汗、口吐白沫的脸盯着你，手把手地告诉你应该这样做和那样做，并且在完事之后若有所指地加一句：“文档里都写了呀！”的时候，其威慑效果将会尤其明显——哥们儿您瞧我这头汗，这嘴沫子，劳驾能受累看看文档么？

因此你看，文档能力是如此地重要，以至于那些抱着不切实际的“策划”念头的毛头小伙子们，总以为只要生花妙笔口若悬河，有精妙的设计和划时代的点子，写个长篇累牍就能拯救游戏业……时代又不是腰花儿，哪儿能那么容易就被吴下阿蒙给划开？正确而出色的文档往往显得十分整齐、有条理，但同时非常枯燥。与其说是一份攻略，倒不如说是说明书，而且还是日产电器类的说明书。不厌其烦地告诉你每一步该怎么做，可能会遇到的一百零一个问题，这些问题的解决方式，并且统统配图。同样地，它会显得比较蠢，把著者和读者都置于一个理解和阅读能力的最低限度，这样保证所有人都能读懂它，并且按部就班地就能在工作中实现。从现在开始，事情就和闪闪发光的创意、灵光乍现的设计以及打破常规的新尝试一点儿关系都没有了。游戏设计师的文档讲述的都是关于某些物体的长、宽、高，主角能跳多高、跑多快、从几米高的距离落下来就得摔死而从几米高的距离落下来则只会受伤；关卡设计的文档则是关于如何设置物件的属性，开关量在什么地方，怎样连接不同的路点，该怎么关联触发器的逻辑；美工会读到关于贴图规格，UV的展法，地图大小的限制，靠用单位大小来测量参考图物件比例的小窍门；GPP和程序的文档可能最多最长，在引擎研究的路上他们可谓从项目开始就一路走来，你进办公室的时候几乎都能看到上个月他们编撰出来又废弃掉的代码以微弱的电磁型态在空中飘散。甚至连人事都有一份文档：如何在经济危机的大环境下技巧性地辞退员工，包括一套翔实的流程表和措辞模板，甚至连对方的各种可能反应和表现都有专门针对性的对策。

自然可以理解，既没有色情描写，又缺乏引人入胜的行文，难怪即便出色的文档在灌输信息时也会有可观的损耗比。最好的办法，从长时间的实践总结而言，无非就是将文档置为总在最前，后台开着编辑器，按着上面说的一步步做来。待到唯手熟耳的地步，做他一百多个pokect mockup，进行填鸭式的理论-实践转换。随着项目经验的增多，你会发现虽然不能说每次需要做的事情都是大同小异，但起码能够举一反三。至少，一个三天两头就要换引擎的工作室多半是在瞎折腾。这个时候我们需要做的事情无非就是根据经验——通常我不会用揣测这个字眼——来判断程序写在引擎里面的函数可能是怎样的运作机制，现有地图里的gameplay大概是通过什么方式来实现的，脚本事件该是如何一个制作步骤。然后尝试，失败，再尝试，再失败，喝口茶，上个厕所，尝试，还是失败……直到成功或者碰巧找到一个恰好知道这都是怎么回事的人。摸着石头过河是一个比较不专业的说法，一般我们会美其名曰“调试”。它将是伴随整个关卡设计师项目生命最为痛苦，也最不可避免的噩梦。