欢迎来到网易游戏学院藏书馆
前几个月，我写了一篇文章《测试工作快、狠、准》，本篇文章可以算是一个姐妹篇。如果把高质高效的完成测试工作看成是如何“正确的做事”，那么做好策划文档分析则多多少少有些如何“做正确的事“的意味了。众所周知，”做正确的事“比”正确的做事“要难得多，领导们大多都是负责”做正确的事“的人。一个策划文档，虽然不是决定公司方向的大决策，但也是决定一个系统成败的关键，要完成文档分析这个相对复杂的工作，自然是需要一些方法的。熟悉中医的人会知道，中医中诊断病症需要用到望、闻、问、切这四种手法，我们分析一份文档，也需要灵活的运用这四种手法。
拿到一份策划文档，我们首先会先通读一遍，凭借自己的理解和知识开始做文档分析。排除一些显而易见的文字错误、逻辑矛盾、重大缺失，也撇开高难度的战斗平衡、经济平衡不提，文档分析还是有一些简单的准则的。
首先，文档设定需要符合客观实际。早先梦幻的玩家之家推出了牧场系统，牧场中可以养育鸡、鸭、狐狸、熊这些动物，文档中设定这些动物都借由一个类似“宠物蛋“的道具发到玩家手中，玩家可以把相应道具放到牧场中孵化出来。这些动物中，鸡鸭是卵生的没错，但是狐狸和熊明明是胎生的，怎么可能在”宠物蛋“中呢？我就此和负责的策划提出异议，但是策划觉得这只是游戏里的设定，而且可以把宠物蛋改成仙蛋，仙蛋里面有啥都不稀奇。当然我并没有这样就妥协，我们游戏的宣传方向一向都是绿色网游、寓教于乐，玩家中甚至有很多小学生，显然不能让孩子们在玩了我们的游戏后，产生原来狐狸、熊都是从蛋中孵出来的误解。在经过进一步的讨论后，最终这个道具的名字修改成了宝宝窝，如果道具超过一定时间没有放入牧场中，就会失效，算是里面的动物已经死亡了。举这个例子，是想说明，虽然我们需要创造，对于现实中存在的东西，是不能任意扭曲的。
文档分析要注意细节。文档中重大的缺失，大家肯定都不会放过，但是对于一些细节上的问题，也不能轻视。在早几年，曾有策划对任何NPC必须有闲人对白之类的准则不置可否，虽然现在大家都认可了需要注重细节，但是很多文档在提交的时候，还是有不少细节上的遗漏。策划总想着，大纲我已经写好了，细节可以慢慢完善，于是对着一份缺失了很多NPC对白的文档，程序员开始着手做了，QA也开始测试了，程序员对于所有的缺失，都写了XXX的默认对白来替代。等到QA把流程都测试完毕了，策划才补充完NPC对白，然后，自然QA要把整个流程再跑一遍来验证NPC对白，就这样工作量平白增加了一倍，这种情况显然应该通过文档分析来避免的。前期文档工作做得越细致，后期需要返工的东西就越少，一边写测试用例一边做文档分析是减少遗漏的好方法，大家不妨试一试。
注意细节还有更深一层的意义，细节除了不能遗漏之外，还需要保质保量。我曾经测试过一个活动，任务种类很丰富，但是这个活动的每类战斗，战斗胜利、战斗失败的对白都是一模一样的，分别是”你赢了“、”你输了“，是不是感觉一股浓郁的山寨气息扑面而来？我们在文档分析的时候，类似问题是绝不能姑息的。
说到细节问题，还经常会碰到另一种情况，有同事在群里贴出一些语句，问大家：你们知道这是什么意思么？那些语句要么晦涩难懂，要么绕来绕去，否定的否定的否定……这些语句不是别的，正是某个系统的说明对白，连熟悉游戏、有一定学历的我们解读起来都有难度，让那些新手或者年纪还很小的玩家如何理解呢？在设计一个玩法的背景或者某些特殊玩法的时候，策划大可以采用大量华丽的辞藻，甚至可以用晦涩的古文，因为这些并不是每个玩家必需了解的，但是对于一个常用系统的每句对白提示，都需要力求通俗易懂，曲高和寡是带不来经济效益的。
有句俗话，世间没有免费的午餐，我们在文档分析的时候，防止玩家不法得利是重中之重。梦幻原先有个设定，就是玩家可以在新手区的暗雷场景抓大海龟，然后卖给NPC，换取500块游戏币，在梦幻中，一个玩家参与普通的玩法一个小时至少可以赚几十万，相比起来500块可说是微不足道，别说午餐了，充其量是早餐剩下的面包屑。但是，就是有人捡这些面包屑捡的不亦乐乎，甚至成为工作室的刷钱手段，因为梦幻中，玩家在10级之前是不需要消耗游戏点卡的，这些都是免费的面包屑，而用脚本来做这些事轻而易举，大有赚头。为了杜绝这个现象，策划更改游戏设定，在玩家10级之前，只能贩卖3只海龟。而之后的新手大礼包的物品，也都做了不能转移的限制。天下熙熙，皆为利来，天下攘攘，皆为利往，免费的午餐不是不能给，但是一定要做出很好的限制。
在其它一些无关玩家利益地方，也会使用上述准则。比如我们的游戏中论坛的回帖，虽然不会给玩家带来什么利益，但是玩家频繁的做起来没什么难度，却会造成服务器的大开销，因此消耗一点玩家的体力（体力在游戏中可以换成钱）。另一种情况，玩家在进行帮派联赛存取物品时，需要统一向中心服请求，因此限制了5秒内才能存取一次物品。我们可以这么认为，频繁执行这些操作带来的开销，并不是玩家的游戏点卡可以支付的，因此有大开销就需要有消耗或者有限制。
以上的两个例子，一个是说要防止玩家非法得利，一个是说要控制开销，其实归根结底都是为了保护我们游戏的利益，前面的几条准则也都是为了这个目的。想要保护游戏利益，还有一个准则不得不提，就是要给予玩家合理的利益。前不久我接到了一个文案，玩家可以通过人民币购买道具，把一些游戏截图编辑成故事图册，大家都可以在游戏中观赏并评分。这个文案有个很大的问题，就是这些故事图册是会过期的，据说是因为考虑硬盘空间的问题。我们游戏中有出售给玩家装扮的道具锦衣，只要购买是永久有效的；我们的游戏论坛大家可以免费上传各种图片，也不会超过一定期限就删除的。和以上两种情况相比较，我觉得玩家花钱购买且花了心血创建的画集需要过期删除是不合理的，推出后会买单的玩家不说没有也会很少。而在程序实现上，这些画集都是储存在一个专门的服务器，不影响游戏的其他数据。作为一个单独的服务器，有那么多大型的论坛作为前例，也完全不需要担心画集数据太多而硬盘不够的问题。只有玩家享受到合理的利益，我们才有盈利的机会，因此过期设定是应该取消的。
闻，顾名思义，就是听的意思。一个比较复杂的系统，策划一般都会召集相关人员提前开个小会做个宣讲，如果是比较大型的资料片，则会召集整个项目组做宣讲。这些系统宣讲是不可错过的，需要仔细聆听。策划往往会在在宣讲时表达出很多文档中没有写明的设定和思想，无论怎么样的TT高手，说话似乎总比打字来得更方便容易些。有些比较复杂的设定，经过策划的讲解，也会比自己看文档容易理解的多。宣讲的同时，大家之间的讨论很有可能触发该系统某些设定的改变，作为参与者，自然可以立马获悉这些改变。
除了聆听以外，这里的闻还有更深一层的含义，就是要耳听八方。不知为什么，策划和程序员之间的交流，似乎总比和QC之间频繁的多。经常是你在分析文档或者听宣讲的时候，这个系统是这样的，然后到你开始测试的时候，整个系统已经变成那样了。策划有了新想法，肯定要和程序员说啦，不说程序员不会做。QA？等到测试的时候就会知道了么。而程序员觉得这个设定不合理，自然也会和策划说，这个地方不好实现哦，要改成XXXX。QA？等到测试的时候他自然就知道了啦？于是乎整个系统就在我们不知道的时候改头换面了，或者干脆心肝脾肺肾都换了，而中间的这些修改，是完全没有经过我们的分析的。虽然这些修改大部分是不会有问题的，但是总有一小部分会造成大量的返工，在这种时候“多亏XXX发现了一个重大遗漏“之类的话是无法抚平返工之痛的。
因此，为了避免类似的情况，我们需要多留意周围的情况。眼观六路肯定不行啦，要做事么，那么就只能耳听八方了。相互间合作比较多程序员或策划一般总有一个会坐在附近，如果你发现策划和程序员开起了小会讨论你正在负责的系统，那么立即加入进去吧，所谓三个臭皮匠，顶个诸葛亮，说不定能想出更绝妙的点子，还可以将一些不合理的设定扼杀在萌芽中。就算这些都没有，至少你了解了系统的最新改动，不会在测试的时候因为过期的信息而提一些不存在的bug单。
前面讲的“望“和”闻“，都是了解系统设定的方法。但是在有些时候，单单就”望“和”闻“，并不能让人完全的了解策划的意图，就我个人而言，这种情况经常发生。对于不理解的东西，自然是要”问“了。无论是多老资格的QA，都不可能全知全能，对于某些游戏设定或者实现不能理解并不丢脸，为此请教别人也不要觉得不好意思。对于系统不求甚解，或者不懂装懂，因此造成了重大bug，才是真正丢脸的事。就算没有bug产生，也平白失去了让自己进步的机会。
“问“有什么好处呢？这里可以举个例子来说明。前不久，我收到一个维护单，说要降低某副本中附加的金钱和经验增益buff的优先级。Buff编辑器原先是我负责测试的，和魔兽世界不同，我很清楚梦幻中的buff是没有优先级这一说的，于是我去询问了策划，为啥提这个维护，策划告诉我说，因为副本附加的buff顶掉了更高级的X梦丹附加的经验和金钱增益。梦幻的buff系统，如果身上已经有同样的增益效果，新的有同样增益的buff是不会被附加上去的（这个设定后来有所改变），所以我又去咨询了程序员。原来道具X梦丹写在现在的buff编辑器体系建立之前，独立于该体系之外，就没有受到前面不附加同样增益的buff大规则约束，这些增益效果和buff附加的金钱和经验增益共用同样的变量，因此就被buff编辑器填写的buff所覆盖了。
为了避免这个问题，程序做出了这样的修改，在该副本附加buff前先检测一下，是否玩家身上已经存在相应的经验和金钱变量了，如果有就不再附加同类buff。粗粗看来，程序作出的修改是完全满足策划需求的。但是在详细了解其原因之后，就会发现这个修改是治标不治本，只是满足了策划表面的短期的需求，X梦丹带来的增益可能会在其它地方被顶掉，策划为了实现自己真正的需求，会在每一个冲突被报上来的时候再提新的维护来解决。最好的方法应该是将X梦丹附加的增益变量也纳入buff编辑器大规则的管理中，在附加所有buff之前都做检测，这样才可以一劳永逸解决这个问题。由此，我们可以看出，“问”可以挖掘出真正需求，并据此施行最有效的方法。
切，在中医中是摸脉象的意。在之前的那个关于问的例子里，其实已经有切的存在。问挖掘出策划的真正需求是X梦丹所带来的增益不会被其它buff覆盖，问挖掘出产生这个bug的原因是X梦丹没有纳入buff编辑器的系统管理，而之后由X梦丹的长期存在和Buff编辑器的广泛应用推论出目前的修改并不治本，并提出更有效的方法，这就是切。
就这么看，比起前面三个手法，切似乎要玄妙也更难一些。不过不用担心，和真正看病诊脉不同，我们给游戏诊脉，并非一定要自己完成，切更有切磋之意。你大可以和程序员或者策划讨论：我对于这个设定有XXX以下几点疑虑，我们应该怎样改进对游戏会更好呢？正所谓独切不如众切，群策群力才是王道。
即使你已经想出了很好的点子，切磋仍然是需要的。作为一个文案的创造者，策划总是你需要好好沟通的对象，有了好点子并且让策划接受，才是文档分析的目的。一般，我们会写策划文案分析，通过邮件发给策划，策划也可以回复邮件来答复。但是有时候难免会有这样的情况发生,QA建议:由于A原因改成这样->策划驳回:因为B原因不能改成这样->QA解释:B原因，其实是不用担心的，因为……->策划回复:因为C原因还是不能改成这样…… 比起这个，面对面交流始终是一种更加神奇且有效的方式：你的文案我看了，出于A的原因，XX设定我觉得改成XXX会比较好，或者你出于一些其它的考虑要这么做呢？哦，你是出于B、C……原因啊，其实是不要担心的，因为……无论是快速说服策划还是快速被策划说服，都可以节省不少邮件往返的时间。当然策划文档分析还是要发的，但是我们可以在和策划讨论之后作为总结备忘发出。
一开头说了这是关于如何“做正确的事”的文章，但是写完全篇回顾一下，其实还是一些如何“正确的做事”方法而已，在结尾的时候，总觉得应该要说一些真正和“做正确的事”相关的东西来呼应下开头。
在一开始进入公司做测试工程师的时候，当时还是QC组的组长曾经问我一个问题：“你觉得作为一个测试人员，需要具备哪些条件呢？”当时我答细心、热爱游戏，不喜欢一份工作，当然不可能做得好啦，而我这个人有些时候会比较粗心，因此有这样的答案。组长回答说：“这些当然都很重要，但是作为一个测试人员，最重要的是要有责任心和一定的坚持。”这番话当时就让我印象深刻，现在回味更显真知灼见，作为一个测试人员，在经历相关的培训之后，再抱有责任心和一定的坚持，在工作中“做正确的事”应该都不会太难吧。