下载掌阅APP，畅读海量书库
立即打开
上节主要从宏观的角度讲述了一款游戏的生命历程和涉及的岗位。本节将从微观的角度来讲述一个典型系统的制作过程，同时介绍在这个过程中各个岗位是如何分工合作的。
一个典型系统的制作过程可以分为需求准备阶段、开发阶段和开发后阶段。每个阶段又可以分成一些子阶段，其中，需求准备阶段可以分为目标制定阶段、需求细化阶段、文档评审阶段和开发评审阶段；开发阶段可以分为功能开发阶段、内部优化阶段、功能体验和功能验收阶段。下面以一个相对独立的邮件系统为例来讲述整个过程。
需求准备阶段的工作主要由策划人员完成，核心目标是细分需求，并写出对应的开发文档。此阶段主要分为目标制定、需求细化、文档评审和开发评审四个子阶段。
▎目标制定阶段
在目标制定阶段，上级（主策划或系统组组长）传达系统目标给执行策划，即上级会告知执行策划需要制作的内容并进行简单讲解。这个目标一般会被描述得比较模糊，因此在这个阶段执行策划最主要的工作是弄清楚主策划的核心目的和要求，千万不要因为害羞或害怕而不敢继续追问细节需求。
案例： 一天，主策划找到了小王，让小王负责制作邮件系统，小王立刻追问这个邮件系统主要用于做什么。主策划简单介绍了一下：他需要一个较为通用的邮件系统，可以接收和查看邮件；目前主要用于系统消息、好友请求及奖励发放等信息的传达，将来可能还会需要其他功能。
小王回去之后开始深思，觉得主策划需要的邮件本质上是系统和玩家之间进行非实时交互的信息，而邮件系统则是所有邮件的收发管理中心。因此，小王将邮件从用途上分为几大类并在界面上显示出来，又从邮件内容上将邮件分为纯文字、带附件和带链接三类。在设计的过程中，小王觉得后者才是这个邮件系统的关键。
厘清需求之后，小王把自己的想法告知主策划，得到了肯定的答复，于是开启下一个阶段。
▎需求细化阶段
策划人员（或其他需求方，如运营人员）会在这个阶段将核心目标不断细化，直到形成开发文档和资源需求列表。这个阶段的工作内容是策划人员将大脑中的想法逐步细化，并转化成其他人可以理解的文字或其他类型的展示文件。因此，这个阶段的核心目标可以分为两部分：一是将需求厘清并细化，二是将需求转化成其他人容易理解的样式。我建议在此期间，策划人员可以优先将需求细化，不必过于关注如何写文档，当整个系统细化得差不多时，再将其正式文档化。这时因为策划人员需要考虑如何让需求更容易被其他人理解，所以在写文档之前应该进行更深刻、更清晰的思考，从而进一步优化设计质量。
案例： 小王首先对邮件系统进行思考和拆分，将其分为系统邮件的收发和邮件样式、好友邮件的收发和邮件样式、商城邮件的收发和邮件样式，以及邮件系统的入口、表现和对应的红点规则等功能，然后一一制定对应功能的规则。
在完成这一步之后，小王开始准备开发文档和资源需求列表。开发文档就是规则的书面化描述；而资源需求列表则是需要其他人帮助制作的资源内容，包括系统所需的交互、图标（邮件系统入口的样式）、音效、特效（收集奖励时的表现）和数据埋点等。小王将全部工作整理完毕后，通知主策划文档完成，并开始准备下一步工作。
▎文档评审阶段
文档写完后，策划组内部会对文档进行审核，即文档评审。在文档评审期间，策划组成员会一起聆听撰写者的讲述，并在这个过程中发现文档中可以优化的地方或明显的错误，然后反馈给撰写者。如果问题不多且不大，则文档评审结束，直接进入下一个阶段；如果问题很多或很大，则撰写者需要重新思考和撰写文档，准备完毕后需再次启动文档评审。
有些团队为了节省时间而忽略文档评审这一步，这实际上是得不偿失的。因为文档评审会提高文档的质量，从而降低未来返工的可能性，要知道，制作期返工浪费的时间会比文档返工浪费的时间多得多。文档评审还会加深大家对系统设定的认知及对同伴想法的理解，这可以进一步提升开发效率（因为了解了对方想要做什么及怎么做，所以更易于配合），培养大家对项目和团队的归属感。因此，建议不要越过这一步。
案例： 小王预约了一间会议室并组织策划组全体成员进行邮件系统文档评审。大家听完小王的讲解都觉得整体质量很好，只有两处小问题：①未写明邮件系统可存储邮件数量的上限；②如果达到存储上限，那系统会根据什么规则来删除邮件。
小王听后觉得这两个问题很有意义，决定进行补充。补充完毕后，小王提交了对应的开发文档和资源需求列表，并通知了主策划和项目经理。接着，进入下一个阶段。
▎开发评审阶段
开发评审就是该系统的全体开发人员（含美术人员、程序人员等）聚在一起，共同听取策划人员的具体需求并提出疑问的过程。
在收到开发文档已经完工的信息后，项目经理就会根据大家的时间预约开发评审。在开发评审期间，策划人员会讲解自己的需求，而开发人员会提出疑问或进行补充，其中程序人员会更关注功能的一些边际条件，而美术人员会更关注资源需求是否有遗漏。
如果在开发评审中发现问题不大，则策划人员在评审结束后将自行修改文档。项目经理会创建对应的任务列表并发给所有参与功能制作的人员。相关人员开始评审所需的开发时间，项目经理再根据相关人员的工作状态决定任务何时开始、何时结束。至此，需求准备阶段结束，并进入开发阶段。
案例： 小王在开发评审会上讲解了自己的文档，程序人员表明可存储邮件数量的上限是100封，小王表示接受。同时，程序人员提出疑问，红点出现的条件并未讲清楚，小王也表示接受。美术人员则没有什么问题。
小王修改完文档后发给了项目经理，相关人员也把所需的时间发给了项目经理。项目经理建立了任务列表并填写了对应的开始和结束时间。
开发阶段一般分为功能开发、内部优化、功能体验和功能验收三个子阶段。
开发阶段的核心目标是将需求落地。虽然经过了开发评审阶段，但在实际开发过程中还会遇到新的问题。随着实际产品逐渐成形，开发人员可以在实际场景中体验功能，进而发现新的细化需求和需要优化的需求。这些问题一般会在开发过程中直接解决，来不及解决的重大疏漏与优化会排在后续需求里，择期再做。
在开发阶段，还有其他重要的事情需要做，如沟通交流和制定完成标准。在遇到困难和问题时，策划人员需要通过各种沟通来让多方快速准确地获取相应的信息，进而推动大家一起解决问题。完成标准则决定了系统究竟达到什么状态，才算已经开发完成。
▎功能开发阶段
功能开发阶段的工作是将已经制定好的内容制作出来。因为每个功能被分为多个功能点，每个功能点之间可能存在前后依赖关系，所以程序人员和美术人员会先为每个功能点排序并制定时间点，再按顺序做出来。
在此阶段，因为功能已经比较清晰，所以功能本身的验收会相对简单。而真正的麻烦在于可能存在开发顺序不清晰或有灰色地带的情况。在实际工作中的难点主要有两个：①对任务进行足够的细化并弄清楚各个子任务的前后关系和协作关系；②弄清楚各个子任务对应的负责人。
很多时候，一些工作需要前置工作完成或前置资源到位后才能开展。比如，若没有对应的交互界面资源，则前端人员难以开发对应的交互逻辑。一旦开发顺序不清晰，就会导致整体工作延误，很多人就只能待在原地等着，直到上游开发完对应功能或给出对应资源。这就像交通堵塞，前面的路不通后面的车只能在原地等候。因此，在初始时大家就要明确自己的前置需求及所需的协助。
灰色地带一般出现在岗位交接的领域，具体表现为A认为这是B的工作，而B认为这是A的工作。灰色地带很多是由工作疏忽或权责划分不清晰所致的，但也有某些团队成员会有“除某某外我都不管”的思维，这直接导致大量灰色地带的产生。
灰色地带产生后，会造成开发顺序不清晰，从而对开发效率造成很大的影响。同时，灰色地带还会破坏团队合作的氛围。因此，策划人员需要在整个开发过程中不停追问，弄清楚到底还有哪些细节工作没有完成，还有哪些工作无人认领。通过开会、劝说或向上级反映等方式，消除灰色地带。
案例： 整个开发过程非常顺利，但小王发现了一个问题——邮件的模板没有人制定。他单独询问了前、后端的人，发现他们都认为需要对方制定。于是，小王把前、后端的人拉到一起开会商讨，最后共同决定由后端人员提供配置文件，小王提供模板文字。配置文件完工后，前、后端的人都会使用该配置文件。在后续的开发工作中，后端人员只需把模板编号告诉前端人员，前端人员就可以凭借模板编号提供对应的标准文字了。到此，灰色地带被消除，问题得到了完美的解决。
▎内部优化阶段
内部优化是开发人员对系统进行细化和打磨，使其品质得到提升的过程。
这个阶段最重要的工作是制定完成标准。一般而言，因为在需求准备阶段大家对开发文档进行过评审，所以开发人员会认为完成开发文档中的各种功能和细节就算完成任务了，而功能开发阶段结束就算整个开发阶段结束。我认为这是一种错误的想法，在实际工作中，功能开发工作最多占据实际开发时间的三分之二，剩下的时间都在做优化和修改BUG。
这是因为在需求准备阶段，大家的很多想法都是凭空构思出来的，这直接导致两个常见的问题：一是在开发过程中大家发现了更多的困难或实际困难比自己想象中难很多；二是在功能开发后发现实际效果与预想有偏差或感觉有很多优化点。抛开第一个问题不谈，我们看第二个问题。
我们提供的是一款产品而非一个功能，因此玩家的体验才是最重要的。如果只满足于实现功能，那距离体验良好还有很大的差距。这就像提供了一辆做工粗糙、体验不佳的汽车，虽然汽车肯定可以跑，也能满足拉人、载货的需求，但别指望市场上的消费者为此买单。令人悲伤的是，在实际工作中，大部分团队的功能完成标准仅指功能可用且逻辑正确即可。这里面不乏主观因素，但很多时候是由于开发时间不足，导致团队有所妥协。
抛开主观意愿不谈，至少有以下两种办法可以减少或消除由于开发时间不足导致优化无法完成的情况出现。第一种办法是在任务开始时直接划分对应的时间段，这样能减少前期节奏不够紧凑而导致后期无时间优化的情况出现；第二种办法是一旦发现问题就录入优化清单，待后续有额外时间再一起进行优化。
当整个团队都觉得系统已经优化到一定程度（或时间点已到）时，就可以通知项目经理，进入功能体验和功能验收阶段。
案例： 邮件系统的主要功能开发完毕后，小王开始体验，发现有两个地方可以优化。一是系统自动删除邮件的顺序，可以按先删除文字邮件再删除有附件（奖励）邮件的顺序来进行，这样能够减少删除奖励邮件导致玩家产生损失的情况出现；二是可以提供“一键领取”功能，方便玩家一次领取所有奖励。
目前已经临近任务结束的时间点，小组决定优先做完第二个地方，把第一个地方记录在案，后续有时间再处理。做完“一键领取”功能后，小王通知项目经理可以进行功能体验和功能验收了。至此，内部优化阶段结束。
▎功能体验和功能验收阶段
系统功能完成后，一般会安排进行功能体验和功能验收。功能体验一般由老板和项目组其他人完成，主要工作是查看系统的体验是否足够优秀；功能验收一般由测试人员完成，主要工作是查看BUG及程序稳定性是否达到上线标准。
功能体验一般分为专项体验（针对单一系统或功能组织相应的人去体验）和集体体验（将多个新系统或新功能融入一个版本里让大家集体体验）。相关人员体验最新完成的系统或功能并给出对应的建议、看法和方案之后，策划人员再根据项目剩余时间、人力等进行处理，一般严重的BUG和非常重要的优化工作会马上处理，而其他问题则记入对应的列表中，等待后续处理。
至此，开发阶段结束。这对很多团队来说也意味着这个系统制作完毕，除非后续发现其他BUG，否则不会再关注这个系统。但实际上，这还应该有一个开发后阶段。
所谓开发后阶段，是指系统上线之后，根据实际反馈对系统进行优化，对新BUG进行检修。这里着重讲一下系统优化。
一般而言，系统优化的起因有三个：数据表现、玩家反馈、策划人员主观优化。数据表现是指根据数据埋点获取玩家的行为数据，进而推测出玩家的行为；玩家反馈是指通过问卷或论坛等收集玩家的反馈；策划人员主观优化是指上线后策划人员认为有些地方需要优化。
在这三个起因中，我认为数据表现最为重要，玩家反馈次之，策划人员主观优化排在最后。这是因为数据一般不会“说谎”，代表着最为真实的情况。而在玩家反馈方面，一般肯发声的玩家未必是主流玩家，他们的意愿极有可能与主流玩家的期待正好相反，策划人员需要谨慎挑选和处理。策划人员主观优化源于策划人员的主观感受，除非逻辑清晰，否则不具备客观性。
我认为在系统设计和完成后，策划人员需要对系统的表现有一个简单的期待。如果想验证系统的表现是否达到自己的期待，策划人员就需要在开发系统时进行对应的数据埋点（如玩家点击界面中的某个按钮则对应计数加一）工作。待系统上线后，策划人员会根据数据埋点得到相应的数据，对数据进行分析后，就会知道整个系统中哪里表现得好、哪里表现得不尽如人意。通过这种数据分析方式，策划人员可以持续加深对系统设计的认知，提升自身设计水平，使系统表现越来越好，这是一项双赢的工作。我推荐在系统的生命周期内，数据反馈和优化应不断进行，这是一种非常好的工作习惯。
至此，我们了解了一款游戏的宏观制作过程和一个系统的微观制作过程。下节会简单讲述游戏的中间关联部分——版本的制作过程。