MMOG开发中的项目管理Word文档格式.docx
《MMOG开发中的项目管理Word文档格式.docx》由会员分享，可在线阅读，更多相关《MMOG开发中的项目管理Word文档格式.docx（23页珍藏版）》请在冰豆网上搜索。
●游戏特色：
与市场上的同类游戏有什么不同？
用什么来吸引玩家？
这些特色是否真的具备吸引力？
做张表或图示，与同类型游戏来一次横向比较，将会使说明一目了然。
●游戏玩法：
玩家在游戏中感受到的最多的东西，所以这才是玩家是否消费的决定性因素。
游戏主推的是庞大的任务系统？
还是以城战或以阵营战为主的极近平衡的PK系统？
亦或是五花八门的合成系统？
等等。
２．项目的目标定义
●目标用户定义：
根据相关设定一般就可看出游戏的目标用户群体，Q版风格的人设可能瞄准的是20岁以下的低龄玩家或是女性玩家；
推崇游戏的自由度可能是希望吸引重度型玩家；
棋牌类型的游戏可能是将有一定经济收入的上班族作为潜在用户主体，等等。
●目标市场定义：
根据游戏对硬件配置的要求，是主推象北京、上海这样的一级城市？
还是瞄准二三级城市？
如果想面向海外市场，是不是要在人设和文化背景方面更倾向于对方市场的习惯？
是采用免费策略、付费策略还是其它的形式来拓展市场？
在项目启动阶段就应该考虑这种问题，并将决定严格贯穿项目始终。
３．项目的进度计划
项目的进度通常是企业关注的重要方面，它将影响着企业的利益。
一个内容丰满且功能庞杂的MMOG，其正常的进度计划会让投资商和企业负责人正确的估算项目成本，在项目启动前就将未来的不确定因素一定程度的减少。
如果能按时甚至提前完成项目，将能更早地为企业带来赢利的可能性。
此阶段的项目进度计划一般是由项目经理预估的，同项目实施阶段的进度计划肯定会有所不同，甚至相当大，项目经理的经验决定着这种差距的大小。
４．项目的风险评估
风险评估在游戏行业及一些传统行业中制度建立得都很不完善，背后要建立一些复杂的数学模型才能比较真实准确的反映出企业对项目风险的掌控能力。
经过风险评估才能更好的进行风险跟踪与控制，如果风险程度较大使企业没有能力回避，就要考虑变更项目内容，甚至放弃该项目。
如果风险在可以控制的范围内，就可以实施该项目，并制定相应的风险控制措施。
关于数学模型如何建立这里就不详细描述了，每家企业有其自己的特点，所以建立出的模型也不尽相同，不过一般都需要考虑如下内容：
团队的开发能力、项目的进度计划、项目负责人的经验水准、组织机构间的协调能力、项目的规模、可用的资源、市场需求情况、竞争对手的特点等。
按各项的指标系数进行综合计算，根据得出的百分比可以看出分项风险和总体风险，企业可根据自己的承受风险能力，来确定具体的控制指标。
５．项目的综合比较
通过列表与市场上的同类型游戏进行综合比较，客观地将项目中存在的优缺点展示出来，如此才能在今后的项目规划和实施环节有的放矢。
考虑是否存在市场空白点和机遇，是否有潜在的威胁，只有将这些内容在启动阶段全部分析清楚，才能更好的控制项目的走向，加大项目的控制力度。
二、项目构思
项目构思：
又称项目创意，一般是指形成了需求建议书（RequestForProposal，RFP）之后，为实现预定的目标所作的设想。
项目构思阶段的工作主要是对要开发的项目进行一系列的想象和描绘，当然不能是天马行空，一般要受到项目预算、研发实力、目标市场和工期等条件的制约。
此阶段是项目投资的基础和首要步骤，是一种创造性的探索过程，其好坏，不仅直接影响着项目规划的成败，同时还关系到今后的工作任务范围以及进度。
１．项目构思的过程
项目的构思一般分为三个阶段：
收集整理阶段、集思广益阶段、调整完善阶段。
收集整理阶段：
此阶段为项目构思环节进行各种准备工作，一般来说包括如下工作内容：
●明确项目的性质和范围
例如按RFP中描述是要开发一款3DMMORPG，名称暂定为《混沌》，背景故事参考中国古代神话故事《镜花缘》，怪物及场景取自《山海经》等等，显然范围的限定就意味着不能跑到《FIFA》或《NBA》系列中去找灵感。
●调查研究、收集资料和信息
如上例，既然游戏的相关设定取自《镜花缘》和《山海经》，那自然要将相关的内容全部收集起来，文言版、白话版、影视版及与之相似的单机游戏、网络游戏等等都是调查的对象。
如果存在同类游戏的竞争对手，到其网站和论坛中去收集设定资料和玩家的反馈也是非常必要的。
●将收集的信息进行初步整理，去粕存精
庞杂未经整理的资料是难以阅读的，花点时间把不相关和不重要的内容择出去，会为后续的工作带来便利。
●通过分类、归纳、分析等方法，从获得的信息中挖掘出可为我所用的资源
按剧情、人物、道具、怪物、场景等类别，将资料尽可能的归总到一起。
也许对于同一件事物有着两种截然不同的演绎版本，那就在此环节去参考相关说明和分析，最终确定酝酿阶段。
集思广益阶段：
此阶段是头脑激荡的过程，很容易让参与人员全身投入甚至热血澎湃。
以大脑中所积累的知识和智力为基础，通过借鉴、推理、综合、类比、甚至思维跳跃或者灵光一现，产生众多的创意碎片，这些碎片逐步形成了项目的初步轮廓，并用语言、文字、图形等可记录的方式明确地表现出来。
这一阶段是整个项目规划的基础，构思的深入探索往往会将项目整体提升到一个高度，哪怕捕获的只是一瞬间之念，也有可能决定了整个项目的蓝图。
例如某一成员提出要加入怪物图鉴收集功能，并在此基础上导入某些剧情任务或交易系统。
此构思内容就会记录在案，在后面的阶段进一步完善。
调整完善阶段：
本阶段是一个发展整理的环节，将前面讨论的结果一一予以分析评估，并进行进一步的分析和设计，使整个构思尽可能的趋于合理和完善。
在这一过程中，一般需要从各个部门邀请一些与项目相关的人员加入到讨论中，从程序、美术、包括市场运营的角度对形成的构思进行审核和会商，力求完善或符合客观实际条件。
针对怪物图鉴收集功能的构思，美术和策划人员可能希望用Cel-Shading技术来呈现图鉴中的怪物形象，而技术人员则提出现有的引擎无法提供这样的支持，那就会形成会商局面，讨论是改善引擎的功能还是使用现有的引擎进行渲染或是采用2D手绘来实现此构思。
２．项目构思的方法
根据实践的经验，经过长时间的归纳和总结，整理出了一些常用的分析构思方法可供借鉴和参考。
但项目构思是一种创意的发散行为，需要具体情况具体分析，忌默守常规。
根据项目的性质、团队的特点、组织的框架结构，一般常用的方法有“比较分析法”、“项目混合法”、“集体创造法”及在传统方法上继承并创新的“逆向思维法”、“发散思维法”、“信息整合法”、“辐集式创新”等。
限于篇幅，这里只对MMOG开发过程中最常用，也最为符合其特点的“集体创造法”进行详述。
集体创造法，顾名思义，就是发挥集体的力量共同创造。
一款MMOG的开发要涉及的问题和因素很多，需要广阔的知识面、大量的信息以及多方面、多层次的思维，不同思维观点相互交织碰撞，可以相互启发、取长补短，从而得到成功完善的项目构思方案。
集体创造法通常有以下几种：
●头脑风暴法
也有称其为脑力激荡的，是游戏开发行业普遍采用的方法之一。
开展这种集体创造时，根据团队规模尽量将相关的人员都召集到一起，在共同探讨的基础上要遵循两个原则三条规定。
两个原则：
一是参与者自由表达自己的想法，任何人暂时不要对此作成任何评价，使发言者畅所欲言；
二是大量的创意中必定包含有价值的内容，之后要全面的进行综合评价，认真归纳总结，如此才能确定最有价值和最适合的构思。
三条规定：
不许对他人的想法作出批评或让其难堪；
鼓励发言，参与讨论的任何人都要多提设想和看法；
追求综合改进。
这种方法既可在项目创建初始用于方案的构思，也可用来解决项目中的某个具体问题或改进某个局部方案。
●集体问卷法
给每位参与者一份罗列着与项目构思相关的主要问题问卷，要求他们在一定的时间里将答案提交，并写下自己对项目的设想和看法。
在问卷的答案汇集整理后，再提交集体讨论，最后形成一致的方案。
这种方法将意见调查和头脑风暴法进行了综合，在鼓励创意激发的同时避免了思维的过度发散，有一定的引导作用，效率较高，故应作为主要的方法予以实施。
著名的菲利普六·
六群体法，就是以六人为一组，每一组在不同房间讨论六分钟，然后再重新编组，每组再讨论六分钟，直到会议结束。
这种方法，能增强每个人的参与度，使每位成员不受相互影响，都能充分发表自己的意见。
●逆向头脑风暴法
使用此方法一般都是在项目初步方案已经形成的时候，将方案中记录的构思分别拿出予以讨论，查找其中的缺陷，加以改进和完善。
此方法不是进行新的项目构思，常常用于自我审视的环节。
●多学科法
在有了一定的创意积累时，一定要组织相关的技术专家共同研究讨论，专家团可能会涉及多个学科，这样才能尽善尽美。
邀请的专家可能会有美术、程序、运营、市场等企业内部人力资源，如果构思还涉及到复杂的武术动作，则有必要邀请精通此道的专家进行武术指导。
三、项目规划
项目规划：
可以称为项目的“纸上模型”，它将引导工作朝既定的目标前进。
它不仅详细地规定了将要做的工作，也是项目团队间交流的工具。
在任何项目中，项目规划一般都包括三个基本内容：
工作分析结构（workbreakdownstructure，WBS）、项目进度计划、项目预算。
下面，我们就看看如何综合运用这三种方法来进行项目的规划。
１．工作分析结构（WBS）
这里所提到的WBS已经囊括了大家熟悉的DesignDocument，着重项目分解和项目责任的概念。
已有很多的书籍和文章介绍如何构建DesignDocument，这里就不对其的结构和内容进行说明了。
DesignDocument作为WBS的主体，其作用不仅仅是今后工作内容的指导，同时也为项目的分解和责任提供了依据。
●项目分解
把项目整体系统地分解成有内在联系的若干工作任务（工作包）主要有四个原因：
可以按照工作任务的逻辑顺序来实施项目，更容易地掌握各项工作任务的关联、重叠情况，如果一项工作任务不能及时完成就能及时发现其它工作任务是否会被其影响。
可以确定完成项目所需的技术及其人力资源。
工作任务的界定，使项目团队成员方便知道自己相应的职责和权利，使沟通的效率变得更高。
使项目团队成员更清楚地理解任务的性质和需要努力的方向。
如果没有项目分解，面对众多繁杂的工作，将无法理出一个头绪。
所以，严格地建立DesignDocument，按其结构（例如UI、Scene、Characters、Property等）将项目工作进行划分和归类，是项目成功的必备条件。
●项目责任
项目责任矩阵，用表格形式来表示WBS中每项工作任务的责任人，这在项目管理是一种很有用的工具。
它明确表明了每项工作的负责人、执行人，并表明了每个人在整个项目中的地位。
下表是项目《混沌》的责任矩阵，作为一个简单的示例表明如何通过此表确认每项工作任务的具体责任人和执行人。
在该表中，用P（president）表示工作任务的主要负责人，S（service）表示执行人。
在项目生命周期的任何阶段或某一阶段的某一时期，当协调沟通出现困难，工作责任不明，以及项目的实施出现失误，都可运用项目责任矩阵图。
同时，还可针对某个特定的工作任务，分别制定出不同规模的矩阵责任图。
２．项目进度计划
在项目规划阶段，正确的估计项目工期是最为重要的方面，而项目进度冲突也是项目生命周期中最常见的冲突源（关于项目冲突另篆文阐述）。
对一个项目总进度的度量，需要分别估计项目中每一项工作任务所需要的时间，然后根据工作的先后顺序来估计整个项目所需要的时间，但并非是简单加总就可得出的。
制订项目进度计划的第一步就是估算每项工作任务或工作单元，从开始到完成所需要的时间。
一般让某项工作任务的负责人或责任小组来估计完成该工作所需要的具体时间，是一种较好的工作方法。
这样既可得到该负责人对该项工作的承诺，又可避免项目管理层由于对工作的不充分了解而导致时间上的偏差。
不过这种方法有其致命的弱点，通常项目团队队员在估算自己所需的工作时间时，都采取保守的态度，往往要比正常完成时间多出30%左右。
因此，这种情况下，就要综合项目的总体进度要求，略微压缩一下队员的估算时间，并以奖金或休假等形式充分调动人的主观能动性。
同时，还要将资源供应、假期、外包子项目等因素考虑进去，如此才能将估算的时间与实际工期的偏差控制在一定范围内。
我们将以《混沌》项目为例，介绍如何制定项目进度计划。
在此之前，首先要掌握几个相关的时间参数。
项目预计开始时间和结束时间：
项目正式立项，开始着手实施的时间一般作为项目预计开始的时间，投资商或董事会要求项目完结的时间作为项目预计结束时间，这两个时间实际上规定了完成项目的时间限制。
这个时间周期与项目生命周期是不同的，项目生命周期的第一阶段（RFP建立阶段）在预计开始时间之前就已开始。
最早开始时间和最早结束时间：
从名称上讲，这两个时间很容易理解，这就是在制定项目进度时所依据的时间。
唯一要注意的是，最早开始时间可能会依赖于其它工作任务的结束时间，在工作任务处于顺序执行时格外明显。
例如，UI绘制属于美术的工作，如果不完成则程序负责的UI编程则无法开始，所以UI编程工作的最早开始时间只能晚于或与UI绘制工作的最早结束时间相同。
公式：
EF=ES+工作任务的时间估计
公式说明：
ES：
最早开始时间（earlieststarttime，ES）
EF：
最早结束时间（earliestfinishtime，EF）
最迟开始时间和最迟结束时间
这两个时间，是为了保证项目在要求的时间内顺利完工而设定的。
同样，与ES和EF相同，最迟开始时间也可能会依赖于其它工作任务的结束时间。
公式：
LS=LF–工作任务的时间估计
公式说明：
LS：
最迟开始时间（lateststarttime，LS）
LF：
最迟结束时间（latestfinishtime，LF）
时差
如果LS与ES不同，那么该工作任务的开始时间就可以浮动，称之为时差（floatorslack），同样LF与EF之间的差值也是时差，代表着该工作任务的结束时间可以浮动。
对同一工作任务来说，LS与ES的时差等于LF与EF的时差。
公式：
时差=LS–ES
或=LF–EF
制定项目进度计划的技术
在制定项目进度时，一般都会采用甘特图（GanttChart）的方式，MicrosoftProject是制作甘特图时广泛使用的一套工具。
但传统的甘特图由于比较简单，并不能清晰地显示项目中各工作任务之间的关系，所以在绘制时，必须清楚各项工作之间的关系，即哪些可以同时进行，哪些必须在其它工作开始前完成。
如果，某项工作任务无法如期完成，在图中就无法清晰的看出被影响的工作会有哪些。
而且，在比较复杂的项目中，单独一个甘特图不能为项目团队成员间的沟通和协调提供足够的信息。
这里，笔者介绍另一种制定项目进度的技术，项目网络图。
项目网络图可以显示项目的路径、开始时间和结束时间、工作任务的负责人，这对于新加入项目团队的成员只需要稍加研究，就能很快掌握项目的整体状况和目前的进度情况。
网络图是由方框或圆圈、箭线及箭线连成的路径所组成的，路径就是按时间的先后顺序安排的工作任务的连接。
网络图的绘制形式有几种，笔者向大家介绍的是其中的一种——节点式网络图，无论是从绘制方法上还是阅读理解上，都是极其容易的。
下面是节点式网络图的两个简单示例：
示例中方框的上部表示具体的工作任务；
左下角数字表示工作的顺序，即时间上的优先或并列关系；
下部中间的名字表示工作的负责人或具体执行人；
右下角的数字表示该工作任务的工期估计；
连接方框的箭头表示先后次序的方向。
示例一“优先关系网络图”，表示哪些工作在其它工作之前必须完成。
策划人员需要先对界面的功能等方面进行描述，然后美术部门依据策划提交的文档绘制界面，将图素切割后提交给程序部门进行程序编写，这些工作都是要顺序执行的。
示例二“并置关系网络图”，表示哪些工作可以同步进行。
策划人员对游戏中涉及到的角色给出形象、背景等描述，接下来的角色的数学模型、数值方面的设定和角色的绘制工作就可同步进行，这二者之间并不会相互影响。
通过上述两个简单的示例，我们大概了解了网络图的基本组成结构。
网络计划图都有一个起点事项和一个终点事项，然后将相应的各项工作任务填在其间。
绘制网络图有五个基本的步骤：
步骤一：
借助WBS列出工作任务清单；
步骤二：
界定各项工作任务之间的关系；
步骤三：
界定工作任务，细化单元活动；
步骤四：
绘制网络计划图；
步骤五：
检查网络计划图的逻辑结构。
现在笔者要在此基础上绘制《混沌》项目实施环节的框架网络示意图（见图０３），限于文章的布局，例如“经济系统”、“任务系统”、“社群系统”等工作任务将不会包含在里面，QA工作也未在其中涉及，主要是来说明主干的搭建过程，当然我们也可以根据某项工作任务进一步细化为单元活动网络图。
图０３：
标明关键路径的《混沌》项目网络示意图
上图简单的勾勒出《混沌》在项目实施环节的框架网络示意图，这里引出了一个概念——关键路径（图中用“√”标志标明）。
在一个复杂的含有大量并置关系的网络图中，从项目开始到项目完成有许多条路径，其中最长或耗时最多的路径就是关键路径，它的总工期其实就是项目的总工期，这就意味着关键路径上的工作完成时间，与整个项目的工期是息息相关的。
从图中我们还可以看到，估算的项目工期为230个工作日，已经超过了要求完成的时间200个工作日，这时我们有两个选择。
一是经过协商将项目要求完成的时间延长，这自然就表明成本的增加、项目进度的Delay、市场商机可能的丢失等等。
另一个选择就是仔细审视估算的项目工期是否还有“压榨”的空间，审视的重点就是在关键路径上。
用我们前面介绍的各个时间参数，通过简单的数学运算就可从要求的200个工作日倒推查找出可调整的所在。
例如上图中，“场景素材绘制”是否可以通过增加美术部门的人手，使其与“角色、怪物、物件绘制”成为并置关系，这样就可顺利地在要求的时间内完成项目。
图０４：
附有最迟开始和结束时间的角色绘制工作网络图
上图是角色绘制工作的网络图表示，最早开始/结束时间和最迟开始/结束时间都标明在相关的工作活动上。
在网络图的帮助下，项目进度一目了然，当某一工作任务或单元工作活动发生延迟时，可判知项目进度的变化和相关的责任人，并在后续的工作中能得以及时的调整。
3．项目预算
成本预算是每个项目的关键因素，面对既定的成本约束，面对不断变化的项目环境，项目经理该如何把握资金的脉络？
●项目预算的基本原理
记住以下原则，它有助于我们做出一份准确的预算单：
成本都是与既定的项目目标相联系的。
《混沌》项目中，计划囊括四个种族、每个种族十个职业、百种以上的怪物、二十种不同风格的场景，要实现这些势必会带来很大的工作量。
那可不可以在项目一期暂做两个种族、每个种族五个职业、五十种以上的怪物、十个不同风格的场景，然后根据市场和研发情况再考虑是否进行扩充。
显然，实现前一个项目的成本要远远高于实现第二个项目的成本。
成本与项目进度有关，通常项目进度越快，项目的成本越高。
为了赶进度，《混沌》项目中怪物的绘制需要额外增加两名美术人员，同时希望大家都能放弃休假加班加点的工作，这必须多支付一定的工资。
所以，事先尽力做出周密的项目计划，会减轻成本预算的压力。
项目组成员对项目计划的理解和把握
在游戏主界面的实现上，计划是应用引擎的功能来展现众多的3D化特效，但由于信息流通或理解力的问题，新加入的界面程序员却以为采用MFC进行制作，而他并没有及时去了解引擎的相关功能设定，显然项目的进度及其成本都有可能被影响。
●项目预算的基本方法
项目预算有两种基本方法：
自上而下的预算，自下而上的预算。
采用哪一种方法，主要与项目组织的决策系统有关。
自上而下的项目预算
上层、中层项目管理人员利用自己的管理经验、分析判断来估计项目的整体成本及其子项目成本，将这些估计的结果给予低层的管理人员，在此基础上继续对组成项目和子项目的工作任务成本进行估计，然后继续向下一层传递，直到最底的基层。
这种预算工程的缺点是，上下层之间的交流可能会出现问题。
面对上层管理人员对于成本的估计，下层人员可能会持不赞同的意见，但却很难或及时提出其个人的观点。
这样，可能会使项目的正常进行受阻。
其优点是总体预算依据上层管理人员丰富的经验，往往可以正确的映射项目整体的资源需要，且避免了某些任务被过分重视导致预算的不平衡分配，根据任务比重合理获得相应的预算。
自下而上的项目预算
这种预算方法是针对资源进行的，将所有工作任务逐一考量，把每个任务的预算综合起来，形成项目整体成本的直接估计。
针对其间可能出现的意见差异，可由项目经理参与讨论以保证估算的精度。
同时，还要加上适当的间接成本，例如一定的管理费用、意外准备金等。
正如自上而下预算出现的问题，自下而上预算也具有一定的博弈形势。
下层人员一般会高估自己的资源需要，以使其处于比较有利的地位，但最终形成的总体预算结果将会高到一个必须要削减的程度，这就形成了一种恶性循环。
其优点也是显而易见的，直接参与项目的队员比高层管理人员更加清楚所涉及的任务的真实资源需求量。
而且由于预算出自于日后要参与项目实际工作的队员之手，也会一定程度上
升级会员 