游戏作为一种特殊的软件产品，比普通的软件开发更为复杂，因此，游戏项目的管理较之一般软件项目也更具挑战性。在软件工程中，需求管 理是关乎项目生死存亡的首要环节。本文将透过游戏研发管理的视角，重点探讨如何通过有效的需求管理保证项目成功。
游戏是一种特殊的软件，尤其是大型网游，通常比一般的软件开发规模大、人数多、周期长、复杂 程度高。首先，正规的游戏开发会包括策划、美术（含2D和3D）、编程和测试等多个团队，如何使这些具备不同工作技能的团队成员协同工作，如何使各个工作 环节衔接顺畅，是一个颇为复杂的问题。其次，网络游戏项目的开发周期较长，虽说一般在1年半到2年之间。另外，游戏项目的成败很大程度上依赖于市场对游戏 的反响和接受意愿，频繁的需求变更再次增添了游戏研发的复杂性。
游戏的需求管理贯穿整个开发过程，是影响游戏开发质量的关键。游戏项目最初的需求是从策划部门提交的游戏创意、玩法、美术风格、大致 背景、特色系统、与同类游戏区别等等一系列繁杂的内容中，通过各部门讨论和评估而总结出来的。虽然通过需求分析会得到《游戏功能描述书》这一结果性文档， 但是，如果不进一步结构化分解，项目成员要进行任务分配和编程仍然很难。
除了最初的需求分析，需求变更管理也是一个难点。游戏项目计划经常改动，往往也是由需求变更引起的。一方面，为了使游戏发布后更具有 竞争力，需求变更不可避免，如果不对变更进行评估取舍，项目的整体目标可能很难达到；另一方面，为了弥补需求变更对项目进程带来的影响，开发人员常常快速 的进行功能修改和增加，而没有遵循统一的流程控制，从而使游戏整体的有序性被破坏，人为地增加了工作量，最后导致跳票。
项目规划准确性。游戏作为大众娱乐的商业产品，通常都会选择在重要档期推出，如圣诞、新年和暑 假等。准确的项目规划能使企业在第一时间收回成本并盈利，游戏跳票就意味着被竞争对手抢占先机；若为了在档期按时发布而忽略了游戏的品质，将给企业带来更 为严重的后果，导致游戏只能降价出售，甚至召回。
项目执行过程规范程度。游戏作为创意产业，很多从业人员都充满智慧、自信、极具创造力，同时也 有些不容易受到流程和规则的约束。例如，一些开发人员喜欢增加不必要的“玩家欣赏”，这些功能并不在需求规格说明书中，也不是玩家所期望的，开发这些功能 必然会影响项目整体进程。因此，游戏的创意虽要无拘无束，但项目管理必须要流程化、规范化，才能使项目往预期的方向发展，直至游戏成功发布。
美术资源管理。游戏设计中会有大量图片、视频等大文件资源，尤其是在3D游戏中，包含模型、贴 图和骨骼等内容。目前的版本控制工具很多都不适合大文件的管理，或者会浪费过多的存储空间。另外，在游戏发布时，都会对资源文件打包，网游的客户端文件中 有很大部分都为美术资源，只有将这些文件按规则存储到相对应的路径并规范命名，才能有序管理这些资源，提高效率。
测试管理。目前国内网游团队的测试能力相对较弱，大部分都没有高效、全面的缺陷管理系统，甚至 有一些测试工作与客户支持任务都由同一团队来负责。相反，测试在欧美游戏公司中起了非常重要的作用，这也是欧美游戏品质上乘的重要原因之一。
从游戏研发项目特点不难发现，目前存在于游戏开发管理中的很多问题都源于需求管理环节。
如前所述，游戏项目通常规模巨大，涉及部门众多。很多欧美视频游戏的开发投入都在千万美元以上，通常需要200人以上的专业团队开 发2到3年时间。游戏项目的需求涉及到很多内容，包括游戏类型、界面类型、引擎、游戏性等。
游戏项目的需求文档最初来源于策划案，内容包括剧情创意、玩法、美术风格等。结合游戏硬件和软件环境等因素，被分解生成《游戏功能 描述书》。不难想象，《游戏功能描述书》中会包含众多内容，若用整篇的文档来指导开发和测试工作，很容易引起任务分配的混乱；当发生需求变更时，也很难追 溯历史版本。
TechExcel从实践中提炼出一个行之有效的解决方法——用规范点（Specification，以下简称Spec）量化需 求，正规表达每一个功能单元。只需打开《游戏功能描述书》的WORD文档，就可以利用插件，将其中的功能单元逐条地复制出来，在需求管理系统 DevSpec中直接生成Spec。相对于需求，Spec是更面向技术人员的语言。
在实际项目中，实现需求变更的成本随着开发进度呈指数级增长。需求变更的流程化管理能保障正常的开发进 度，将变更及时反应到开发和测试等部门。
以下描述的是一个典型过程（如图1）。一项变更请求在需求管理系统中被提交后，与之关联的各个部门，如 市场、程序、美术、测试等，都会有相关人员接到系统通知而介入。他们将组成评估团队，根据实施难度、周期、费用、对其他机制的影响等指标，对该变更进行全 面考察和评估。在理想的游戏研发管理平台中，需求管理与所有规划、开发、测试管理过程相集成。因此，需求的正规表达Spec，以及围绕Spec正在或将要 进行的开发任务和测试任务，都能被纳入综合考虑的范畴，便于评估团队估算该变更造成的“牵一发而动全身”的潜在影响。有时，还要结合商业需求进行考量，为 了赶上最佳发布时机，有些变更将被拒绝。这个过程由独立的工作流控制，通常包括请求、复查、讨论、调整、批准和拒绝等状态，只有具备权限的项目成员才能改 变状态。按照预设的流程，各方审批全部通过后，该变更才能被接受。
变更请求被批准后，与之相关联的开发、测试任务都会在系统中被一一标记出来，以提醒程序和测试部门的相 关负责人，引发这些任务的需求已经变更，请他们做出相应的调整处理。在系统中跟踪这些任务的进展，可以实时掌握该变更的落实情况。变更完成后，也可以核算 它对开发周期和费用的实际影响，与评估时的预测相对比，找出差异的原因，为将来更准确地评估提供参考。
纵使项目最初都有比较全面的计划，延期仍然会时常发生，即便是在管理机制比较成熟的欧美游戏公司，跳票也不可避免。通常情况下，导 致跳票主要有以下几点原因：功能设计规划过多，很多又无法删除，如不增加开发时间，游戏几乎不能完成；缺乏有经验的管理或开发人员，不能准确估计工作量； 任务执行缺乏规范，开发人员随意更改功能设计，影响整体进度；过高的人员流动率，导致知识的流失，任务不能及时跟进。针对以上问题，只要从量化需求入手， 有序管理需求变更，用正规表达、可量化的Spec来指导项目规划、编程和测试，就能把风险降到最低。
基于结构化的Spec集合，可以将项目分解为多个子项目，将Spec直接分配到各自对应的子项目中，以此来规划和估算子项目的工作 量。项目管理人员为每个子项目分配资源，安排优先顺序，确定项目里程碑。在游戏项目中，不同部门协作异常紧密，因此子项目间的优先顺序显得尤为重要。例 如，游戏音效制作与程序开发之间的相关度看似并不非常紧密，但在实际游戏制作中，以战败时播放的音乐为例，若音效人员不实际操作、感受游戏，就很难体会玩 家的心情，当然也就难以创作出应景的音效。
在项目执行时，可以为每一个Spec产生出一系列开发任务。自定义的工作流机制确保每一个任务从提交到最终解决的生命周期都严格符 合业务流程，保证任何时刻都有唯一的负责人、状态和截止日期。这样，不仅能规范游戏制作的过程，还能降低人员流动带来的风险。任务的流转及相关知识文档， 如源代码、美术资源等，都得到系统完整的记录，还能与任务关联，便于追溯。一旦有人离开项目，接替的人员能够查看任务和文档信息，迅速弥补人员空缺。
以上所述的需求管理经验，虽然是从游戏行业的实践中总结得出，却不囿于游戏行业，项目复杂度较低的一般软件企业也可以借鉴，探索出 一条以有效的需求管理推动项目执行的途径。
