六年谈-3.策划的工作内容与工作管理简述
发表于2015-10-19
作者：leoneed
策划可能会干的主要事情列举如下：l 调查研究各种游戏，撰写调研报告（写文档）
l 举行头脑风暴会议（沟通）
l 制作游戏提案PPT（写文档）
l 举行设计讨论会（沟通）
l 撰写游戏系统设计与玩法规划文档（写文档）
l 撰写程序功能需求文档（写文档）
l 撰写美术资源需求文档（写文档）
l 撰写策划数据需求文档（写文档）
l 举行程序功能需求讨论会（沟通）
l 举行美术资源需求讨论会（沟通）
l 撰写游戏设计功能文件（写文档）
l 制作策划数据（做数据）
l 编写游戏脚本（做数据）
l 发布游戏数据（做数据）
l 跟踪、测试、验证程序功能、美术资源和策划数据
l 修改各类需求文档（写文档）
l 调整策划数据（做数据）
l 收集、整理、修改各类设计bug和数据bug（做数据）
可以看出，游戏设计只是游戏策划的大量工作中的很小一部分。绝大部分的策划工作都是执行我们的设计，其中一半是做数据，一半是沟通。数据执行能力、沟通能力，这两项是策划的基本功。这两项不强的策划，再怎么样都是虚的。
想办法把我们的想法写到纸上，具体化出来，并准确有效的告诉其他人，最后验证完善设计，这是一个非常漫长，困难，关键，重要的工作。撰写设计、规划与需求文档，不仅是为了方便沟通，留存记录，很多时候，策划在讲想法写出来的时候，才发现自己想法中的漏洞。因为想法在脑子里终归是主观的，很容易焦点集中到最亮的一处，而忽略其他直观感受上不重要的部分。但，将设计写出来的时候，你需要动用逻辑思维，整理清晰的语义和逻辑，那些缺失的、模糊的地方都会显现出来。只有策划非常清楚自己设计的每一个细节，才有可能让其他人非常正确的做出来。
撰写游戏设计功能文件是一个经常被忽视的工作。这些功能文档是策划写给自己看的，就有点像解数学题的解题过程。我们最终提出的设计和需求，制作的数据和脚本，之所以要这样做，为什么要这么做？这是需要策划留下答案的。因为当结果出了问题，往往无法针对结果进行直接的修改，需要知道上游真正的原因，从出问题的地方顺序下改。只改结果的结果往往是发现改了还是不对，或者改了这里其他地方又不对，因为两个地方来自于通过一个设计原由，而这个原由是有问题的。策划应该知道游戏中的所有细节，并且掌握这些细节为什么是这样的理由。例如，游戏角色等级封顶是70级，为什么是70？法术抗性减伤公式为什么是：抗性值/（2.5*抗性值+80*角色等级+200）？2.5，80，200这几个参数为什么是这个几个值？这个难度的BOSS为什么掉的是这个品质的装备？
整个游戏设计应该是一条非常清晰的思路。从基础设计理念出发直到游戏的每一个细节，都是逐步的思考推理而至。只狭隘的应对某种情况而直接粗暴的修改数据，表面上看很快速的解决的了问题，完成了工作，但后患无穷，经过几次这样的修改，数据的维护难度就越来越大，直到怎么改都不对，忙也忙不过来，直到项目废止或者推翻重做。欲速则不达，有时候即使再小的改动，也应该放慢速度，理清思路，找到源头逐步的同步的修改数据和功能文档。
另外一类功能文档是策划自己使用的，用来批量制作数据或检测数据用的文档，这些文档常常是一些EXCEL文档。从概念的规划落实到实际数据的中间过程文档。例如我们要调高某张地图的所有支线任务的经验值1.5倍。实际上的做法不是找到所有这些任务，一个个的进行调整，很可能的做法是某个功能文档中把某个参数从n调整到1.5n，瞬间大批量的数据就通过功能文档的EXCEL公式完成了修改。由于这类修改是非常非常频繁的，策划存有这样的功能文档也同样很常见。这就需要提前设计好这类功能文档，备用。
这些功能文档的大小有时候是实际数据的好几倍大。如果你还没有任何中间功能文档，那就危险了。
策划的工作常常是细小繁琐的。学会管理自己的工作，才能完成自己的工作。
首先，准备一个工作日志文档。每当接收到新的工作，就将这个工作顺序记录在这个文档中。很多时候，你会接到许多工作，而你只能一个的完成，为了不忘记他们，必须有这个记录。当完成一个工作后，记得将这个记录做状态的修改（通常是标为另一种颜色），已表示自己已经完成了这个工作。这个日志还能够帮助你回忆自己做了哪些工作，以便回头检查这些工作。工作日志进行过记录积累，你可以用他们记录的先后顺序调整优先级，更好的合理安排自己的工作时间。
有时候忙起来，别人问了问题，都没时间回答，只好先记录下来，过了很久才有空回答别人的问题，这样也是一个工作管理。
第二，我们需要准备一个职责列表，将自己职责范围内的系统、数据等列举出来，每当自己增加或减少了新的职能，都需要更新这个表，我们要时刻记住哪些东西是自己负责的，是自己关注的。
第三，更新日志。每当自己做了任何的改动，都将这个改动非常清晰完整的记录下来，当版本提交的时候，可以直接作为更新记录提交，测试能够直接测试的那种程度的更新。也许是很小很快速的改动，但也要停下来花N倍的时间写好更新日志。这是一个良好的习惯的养成，如果不这么做，到版本发布的时候，问题会让人崩溃。你根本不知道自己到底改了什么，没改什么，如何进行验证测试。遗漏、记错、不完整的更新清单只会导致测试频繁的骚扰，占用你更多的时间解决烂摊子问题。
第四，注意时间管理。每项工作都比你预计的时间要长。找到自己的整块时间处理整块的大工作，利用零散的时间完成小问题。永远不要指望加班能解决什么问题。工作太多了，要及时反应。给每天的工作流出缓冲时间，因为突发情况从来都像约好了的一样，如期而至。
第五，准备一个文件，记录自己的所有新想法或观点。总有一个天，你会自己领导团队制作游戏，你需要为此做很长时间的准备。到了那个位置上再去琢磨自己要做什么，能做什么，怎么做，已经晚了。机会都是给那些有准备的人的。当你发现工作中的问题或错误，想到了有趣独特的设计点，总结了某条经验或原理，学习到了他人的优点，这些都值得记录下来，成为自己的战斗力。同时不断地完善自己心目中想要设计出来的游戏的蓝图，思考自己如果做这样类型的游戏会有是什么样，有哪些想法；如果做那样类型的又能做些什么。
最后，一个小建议。建立自己的工作目录，将每个月收到、制作、发出和使用的文档按时间目录分类。说不准什么时候就会要捡回上个月的某个文件来看，可能还要和上上个月的对比，如果没有按时间分目录管理，你很可能丢失或覆盖这些文件。通过每个月经手的这些文件，可以看出自己每个月都在干什么。