屠龙刀——美术PM 的计划制定和进度管理 Planning and Schedule Management-Art PM 03 项目管理的七大兵器 屠龙刀——美术PM 的计划制定和进度管理 图3-1 项目管理的三要素 PM 是做什么的呢？相信大家最直观的感受就是排计划和推进度。虽然PM 工作内容远不止这些， 但也间接说明了这部分工作——计划制定与进度管理的重要性。 项目是为了创造独特的产品服务或成果而进行临时性工作（PMBOK 指南中对项目的定义）。项 目的临时性是指项目有明确的起点和终点。时间上的限制意味着我们需要对项目进行严格的时间 管理。 项目时间管理，包括为管理项目按时完成所需的各个过程。PMBOK 指南把计划制定和进度跟 进，都归类在时间管理过程组中，因此后文也把这两部分内容简称为时间管理。 项目时间管理的重要性毋庸置疑，总结以下几点，方便大家了解游戏时间管理的目的和本质。 3 .1.1　范围和成本的确认与时间计划互相依赖 图3-1 是大家熟悉的项目管理三要素。只有确认了另外两 个要素，第三个要素才能基本确认，范围和成本的确认与时 间计划互相依赖。项目没有时间的规划，我们就没有办法知 道在目标时间内，能否完成项目，能以怎样的质量来完成， 能完成多少？我们需要投入多少人力和成本？没有时间管 理，成本、范围和质量都将无法管理。 3.1　项目时间管理的重要性 053 Planning and Schedule Management-Art PM 02/03 3 .1.2　清楚每一步的内容和目标 有了时间规划和管理，项目进行到了什么阶段，这个阶段的需求及目标是什么，当前的工作要做 几天，接下去的任务是什么，大家都可以做到心中有数，每一步工作都会有条不紊地进行。项目 中最怕的就是失控，一旦发生就容易恶性循环，忙于救火。 3 .1.3　发现问题，暴露瓶颈，避免后期爆发灾难 这是项目时间管理最重要的一点。游戏敏捷开发中，时间规划和进度跟进的主要目的不是为了严 格执行既定的计划，更重要的是将计划作为当前进度的一个重要参考，及时发现导致进度滞后的 问题，不让问题在最后爆发。 举个例子，项目计划年底完成一个里程碑需求，在时间进行了一半时，项目的完成度没有达到 50%。这时我们要做的不是不惜一切代价地按原计划完成需求，甚至牺牲品质，亦或浪费成本， 这样就本末倒置了。我们要做的是在进度跟进的过程中及时发现问题。如果我们发现任务完成是 有风险的，目前的进度出现了滞后，那我们应该及时去找出导致滞后的原因，及时去纠正偏差， 避免问题持续发酵而导致进度愈加落后。若等到里程碑需求要交付的那天才发现无法交付，很多 问题未被解决，就非常严重了。 3 .1.4　合理的开发顺序，让开发更高效，产出更有价值 游戏开发采用周版本进行快速迭代，每个版本都应该产出当前认为最有价值的内容。在做时间规 划时，应将最有价值的需求尽早实现，并在快速迭代中完善，而低价值的需求我们放在后续的计 划中。因为在开发的过程中，这些低价值的功能有可能会变更或者删除，这样做可以避免更多时间、 成本的浪费。 项目时间管理基础理论知识包括计划制定和进度跟进两部分。明确的范围是计划制定和进度跟进 的前提，同时因为需求变更比较频繁，范围的管理也一直贯穿在时间管理中进行。这部分内容可 以通过阅读本书范围管理专题来了解。 3.2　项目时间管理基础知识 054 项目管理的七大兵器 屠龙刀——美术PM 的计划制定和进度管理 3 .2.1　计划制定 计划制定在创建完工作分解结构（WBS）以后， 我们需要经历以下步骤：排列顺序，预估时间 和制订计划。 / 排列顺序 排列任务先后顺序考虑的因素比较多，项目复 杂、参与人员多、和外界因素相关性大，排列 顺序的难度都会更大。 下面列举一些主要因素：①优先级。需求的重 要性，紧急度和性价比高的需求优先级更高， 我们需要优先安排。②周期长短。周期长的需 求要考虑提前进行。例如一个需求虽然暂时不 紧急，但制作周期需要半年，等到临近交付的 两个月开始肯定来不及。③需求难度。技术难 度高的需求，要提前预研和试错，做好技术和 人才的储备。④依赖关系。大家很容易考虑到 内部的依赖，如环节间的前后依赖关系。同时 我们不能忽略外部依赖，比如IP 合作方的审核、 运营需要等。⑤制作流程。制作流程不同会影 响需求的先后安排，这个是需要根据项目的实 际情况来看的。 / 预估时间 预估时间就是对WBS 拆分出来的各项需求、 各个任务进行制作时长或人天的预估，最实用 的方法是专家判断。这里并不是指职级上的专 家，而是最了解需求和制作的人，通常就是制 作人自己。如果制作人是缺乏经验的新人，考 虑到专业度的问题，可以由接口人或负责人做 审核达到双重保险。 让实际制作人参与计划制定是非常重要的。首 先，制作人最清楚自己要做什么，要花多长时 间，他最能考虑到各方面工作，而不会遗漏， 他最清楚自己擅长什么，会有哪些经验可以节 省时间。举个例子，某项目主美觉得里程碑中 某个特效需要做三天，但是问到特效本人，得 到的结果是一天就够了，因为他做过风格相似 的素材，稍做改动便可用到现在的项目中。另 外，更重要的一点是制作人为自己预估的计划 负责，他们会有更强的进度意识和主人翁意识。 在此要重点说明的是标准人天是工作量的参 考，不可以直接用来排计划。 关于预估时间，我们说一下PMBOK R指南上 面提到的三点预估的知识点。其实这个预估方 法在我们日常的工作中用的并不多，通常预估 时间不会通过公式来一一计算。但是大家了解 这个方法的思路，对于时间预估的准确性提高 以及判断是有帮助的，也可以在自己项目中尝 试使用。 三点估算有两个公式，分别是三角分布和贝塔 分布，其中贝塔分布认可度更高： 三角分布　tE=(tO+tM+tP)/3 贝塔分布　tE=(tO+4tM+tP)/6 三点估算有三个参数： 最可能时间（tM）。基于最可能获得的资源、 最可能取得的资源生产率、对资源可用时间的 现实预计、资源对其他参与者的可能依赖及可 能发生的各种干扰等，所估算的活动持续时间。 在实际工作中，简单的理解就是考虑了最主要 （大概率发生，影响大）风险所估算出的最可 能需要的时间。 最乐观时间（tO）。基于活动的最好情况，所 估算的活动持续时间。实际工作中可理解为几 乎不考虑风险和变更，估算出所需要的最短 时间。 最悲观时间（tP）。基于活动的最差情况，所 估算的活动持续时间。实际工作中可理解为将 所能想到的风险和变化都考虑在内，估算出所 需要的最长时间。 三角分布即三个参数的平均值。贝塔分布在三 角分布基础上增加了最可能时间的一个权重。 我们通过一个小案例来帮助理解这个估算方法 的思路，并从中延伸一些启示，以帮助我们更 科学地管理时间估算工作。问题：你上班要花 多长时间？回答者说：一般开车上班要30 分 055 Planning and Schedule Management-Art PM 02/03 钟，但开车速度较快或者路况特别好时，只要 25 分钟，如果天气不好或者遇到堵车，时间会 久一些，最长的一次用了一个小时。 公式中的三个参数其实都已经包括在案例中 了，最短的时间就是25 分钟，最长的时间就 是60 分钟，最可能时间是30 分钟。 tE=(tO+4tM+tP)/6=（25+4*30+60）/6=34.2 通过公式我们得出的时间预估应该是34.2 分 钟。在此案例基础上我们假设两个场景。 场景1：老板临时约你商量重要工作，问你多 久后能到公司，你怎么回答呢？约迟到就不好 了，那留足缓冲时间，考虑曾用过一个小时， 于是和老板约在一小时后见面。最后实际结果 会是：一如往常半个小时后到了公司，提前了 20 多分钟。 场景2：关系很好的同事公司遇到急事需要帮 忙，问你多久能到，你怎么回答呢？这时出于 同事的期待及你急于帮助他的心理，你会觉得 可以用最快时间即25 分钟赶到。然而实际结 果会是：路况没有你想像的那么好，如往常一 样，仍然花了30 多分钟。 因此以上两种情形，我们预估的时间都是不准 的，预估时间应该建立在典型的时间基础上。 而三点估算的思维也是和这个结论完美吻合的。 怎样让团队成员尽量合理准确地预估时间呢？ 我们继续看以下两个情景： 情景1：有个同学今天完成需求的时间比预估 提前了，下次排计划时，我们把他的时间压缩 一下。 情景2：加入惩罚机制，只要有延期，我们就 对他进行惩罚。 这两个做法其实都是不可取的。第一个情景带 来的后果是，该同学发现自己的高效率并没有 给自己带来好处，反而是让自己以后的进度压 力更大。那么他下次一定会在明知自己可以更 早完成的情况下故意放慢速度，避免提前完成 任务。第二个情景带来的后果是，一旦延期就 会得到惩罚，那为了确保自己不会受到惩罚， 时间都预估得长一点，留足缓冲，将延期的可 能性降至几乎为0。这两个情形共同导致的后 果就是预估时间越来越保守，大家的效率也越 来越低。著名的帕金森法则——工作总是会拖 到规定的时间才能完成，从来不会提前完成， 也印证了这两种情形会带来的恶性循环。 因此我们要杜绝这两个情形，减小帕金森定律 带来的负面影响。正确的做法是：①预估时间 建立在典型的时间基础上，并施加一定的进度 压力；②计划要预留缓冲时间，但建议当成一 个独立的时间段设在最后，如果设在中间，帕 金森法则会导致大家在中间就把缓冲时间用完 了；③我们要有这样的意识：任务完成时间有 些偏差没有关系，关键是按时完成整个项目， 有的早一些，有的晚一些就可以抵消（观点出 自自詹姆斯·刘易斯的《项目计划、进度与控 制》）。我们既要鼓励有的同学能够高效率地 提前完成需求，也要能接受有些同学偶尔延期 的偏差。 3 .2.2　制订计划 制订计划中一个很重要的概念叫关键路径，关 键路径是项目中时间最长的活动顺序，决定着 可能的项目最短工期。跟进项目进度最主要关 注的就是这条关键路径的进度情况，如果关键 路径的进度有可能延期，这个项目的延期风险 就会非常大。 我们通过一个小朋友的智力题，理解什么是关 键路径。题目：根据以下时间预估，判断多久 能吃到美味的晚餐？买菜15 分钟，洗菜15 分 钟，烧水25 分钟，煮饭30 分钟，做菜（需 要用到开水）10 分钟。 如图３-2 所示，我们对一系列的活动进行排序。 先买菜，之后的洗菜，烧水，煮饭三步互相没 有依赖，可以同时进行。烧水，洗菜完成以后 才能开始做菜。可以看到做晚餐项目的最短工 期可以通过关键路径（即图３-2 中蓝色虚线 056 项目管理的七大兵器 屠龙刀——美术PM 的计划制定和进度管理 所示）得出，为50 分钟。这条虚线贯穿的任 何一个活动，如果耗时超过了时间预估，吃晚 饭的时间就需要延迟了。但在虚线以外即非关 键路径上的活动，如洗菜，我们时间花的多一 点，只要不超出时间T，对最终完成的时间是 没有影响的。 图3-2 案例关键路径示意图 图3-3 案例关键路径变更但需要注意的是， 非关键路径上的活动延期超出范围，则会带来 关键路径的变更，从而造成整体的计划延期。 图3-3 所示，当洗菜这个原来不在关键路径上 的活动延期时间t1 超过图3-2 中的T，则这 条非关键路径的时长大于原来的关键路径，从 而成为新的关键路径。最终整个晚餐项目的最 短时长增加了t 2。 图3-3 案例关键路径变更 / 正推法和逆推法 制订计划的两个思路，分别是正推法和逆推法。 正推法是以项目或里程碑开始时间为起点，按 排列好的顺序及预估的时间向后安排，即计算 各个任务最早开始的时间和最早结束的时间。 这个方法在我们项目的中期之前用的比较多， 因为项目前期里程碑间隔相对较长，时间压力 不会太大，更看重基础功能实现和品质，里程 碑节点和内容可商量的余地较大。这个时候我 们可以通过正推法来推算出里程碑需求最早完 成时间是什么时候，同时加上合理的缓冲时间 来作为我们里程碑的完成时间。 逆推法是按各活动所需的时间，从项目已定好 的完成时间或里程碑节点开始往前安排，计算 各个任务的最晚开始和最晚结束时间。这在我 们项目中后期，甚至在项目最开始按期望的上 线时间做里程碑规划时都会采用。游戏开发因 为节奏快，往往逆推法更为常用。特别是测试 阶段开始，测试密度大导致里程碑间隔短。这 时基本采用逆推法来推算任务最迟什么时候开 始和结束，来判断是否能达成项目的要求，如 果达不成，我们需要去思考进度压缩方案，甚 至去缩减范围。 / 进度压缩 在制订计划过程中，往往第一版计划无法达到 预期的目标，这个时候我们需要进行进度压 缩，即在不缩减项目范围的前提下，缩短进度 工期。进度压缩主要有两个方式：赶工和快速 跟进。 （1）赶工。通过增加资源，以最小的成本增加 来压缩进度工期的一种技术。常见的是加班、 加人力和增加预算，比如支付加急费用等。这 种只适用于增加资源就能缩短关键路径上活动 持续时间的情况。 图3-4 为赶工的示意图。这个方法压缩了每个 需求的制作周期，因此赶工可能会导致风险和 成本的增加。 图3-4 赶工的简单示意图 《人月神话》中提到了布鲁斯法则：向进度落 后的项目中增加人手只会使进度更加落后。这 描述的是软件开发行业的普遍情况。事实上在 游戏美术开发中，虽然没有这么夸张，但是也 基本达不到1+1=2 的效果。因为在增加了新的 人力以后，原来的人力需要花一定的时间来进 行工作交接以及培训，同时新的人力在前期需 要先熟悉游戏的风格、世界观、甚至是新引擎， 无法马上进入工作状态。由于熟悉和理解程度 不够导致完成质量达不到预期，需要原项目人 057 Planning and Schedule Management-Art PM 02/03 力帮助修改，甚至重做的情况也不在少数。当 然，如果新人力是该方面以一当十的技术专家， 不论什么时候加入都是可以给项目助力的。因 此增加普通人力其实有比较大的风险，我们在 采用增加人力赶工这个方法的时候，需要考虑 到增加一定的缓冲时间。 我们项目中用得最多的赶工方式就是加班，而 且偶尔加班是非常有效果的，但是长时间接连 不断的加班，会带来一定的问题。图3-5 可以 看出过度加班会带来恶性循环，如果我们掉进 了这个恶性循环的陷阱，对项目来说是弊端更 多的。 图3-5 加班的恶性循环( 图片出自【美】詹姆斯 · 刘易斯《项 目计划、进度与控制》中的图1-4 返工循环) 做项目管理时，我们不光要关注进度、质量、 范围和成本等常关注的因素，同时要做好冰山 下的管理，其管理内容是一些隐性的、无法直 观看到或影响不会马上体现出的因素，比如说 团队氛围、成员认同感、成就感等。这些冰山 下的因素对项目的影响是非常大的，然而却容 易受到被大家忽视。如果冰山下的问题不及时 发现和解决，容易量变引起质变，隐患更大。 例如一个人心涣散的团队，成员合作不畅，效 率会非常低下，甚至互相拆台导致项目失败。 一个压抑很久的团队，一个成员的离职可能会 带来整个团队的动荡。 （2）快速跟进。实际上正常情况下按顺序进 行的活动或阶段，改为至少是部分并行开展。 如图3-6 所示，原来串行的两个任务，我们通 过并行来压短了整体制作工期，快速跟进可能 会造成返工，增加项目风险。 图3-6 快速跟进的简单示意图 关于快速跟进，美术制作中也经常用到这个方 法。一个典型的案例是在时间紧迫的情况下， 原画只出了草图就开始模型制作。草图只能确 定外形，内部细节都没有清楚表达，如果原画 完成的效果和草图差别较大，就会带来模型的 返工。如果效果一致，就成功压缩了制作周期。 如今公司3A 项目越来越多，品质要求更高， 返工带来的成本浪费更大，例子中的方法是不 建议尝试的。 图3-7 是3D 游戏美术开发的常用流程：模型 只要完成粗模或中模并确定符合项目要求，就 可以开始做动画了，高模及贴图可以和后续环 节并行制作。动画在完成粗版，确定了关键帧 姿态和节奏后，我们就可以开始考虑特效的设 计以及部分制作了。这样比所有环节串行制作 的流程周期压缩了很多，这个流程和快速跟进 很相似。但事实上快速跟进的主要目的是在原 来最合理的时间安排基础上压缩周期，同时会 带来风险。而这个流程的主要目的是为了模型、 动作能够更早的在游戏中验证效果和功能，达 到要求以后再进行下一步细化，这样反而可以 降低整体风险，同时也达到了压缩制作周期的 效果。因此这个流程本身就是一个更为合理的 安排，和快速跟进是有区别的。 图3-7 游戏3D 美术开发常用流程 058 项目管理的七大兵器 屠龙刀——美术PM 的计划制定和进度管理 / 进度表 我们计划制定最常用，最平民的工具就是Excel，此外有project 这样的专业的项目管理软件， 另外还有X-mind、看板等一系列辅助工具，这里就不一一列举了。最常见的表现形式就是大家 熟悉的表格、甘特图、思维脑图，物理或者电子看板等现在用得也比较多。大家可以选择适合自 己和团队的工具和表现形式，结合项目的实际需求。工具和表现形式都是为管理服务的，重要的 是思路和方法。 下面我们来看一些进度表的实例。图3-8 是project 制作的甘特图，project 的优势在能够按照 你设置的信息自动生成甘特图，通过前置任务设置会有箭头清楚表示任务的前后依赖关系。但由 于project 软件不够普及，项目其他岗位同学查看不是很方便，因此用Excel 手动制作甘特图更 为常见。甘特图的优势在能直观展示任务什么时候开始和结束，持续时间长短及处在整体安排的 哪一阶段。图3-9 是我们常见的计划跟进表，该表格信息比较全面，涵盖的信息量比较大，检索 起来也比较方便，同时也适合用于做数据分析。图3-10 是思维脑图形式的项目计划，个人认为 思维脑图特别适用于做需求类别复杂、量非常大的规划，里程碑规划、测试版本计划等。因为通 过脑图的形式可将需求按类型、批次等不同维度来进行归类，并划分需求层级（父任务和子任务）， 让整个规划清晰明了，旁人也易看懂且能理解整个规划的思路。图3-11 是一个典型的物理看板， 通过看板可以看到我们当前制作中及待制作的任务、各任务所处阶段、在需求流转过程中有没有 遇到阻碍。一般会结合站会的形式来维护这个看板，这也是精益开发的一部分内容。大家在易协 作中都会用到电子看板，这里就不做过多说明了。 图3-8 甘特图范例 图3-9 Excel 计划表范例 059 Planning and Schedule Management-Art PM 02/03 图3-10 思维脑图形式计划范例 图3-11 物理看板范例 关于进度表有几点需要新职员注意的。 （1）进度表不是越细越好，千万不要让你的进度表失去控制。有同学的计划表非常详细，包括了 需求相关重要和不重要的所有信息，完成时间也精确到某天的某个时间段。如果不是针对特殊状 况和特殊需求，是很没有必要的。因为维护这样的一个进度表会非常耗时，这就本末倒置了。不 要让自己成为表格的记录员，因为你有更重要更有意义的工作要做。 060 项目管理的七大兵器 屠龙刀——美术PM 的计划制定和进度管理 （2）滚动规划。有的同学几个月后才开始的 需求都已经计划到哪一天完成了，其实这样有 些浪费时间。我们可以把前期工作仔细规划好， 几个月后的需求因为变数大，到时候的实际情 况和现在排好的计划是完全不一样的。如果针 对每次变更都重新更新一次几个月需求的计 划，这个工作量是非常大的，很浪费精力。 （3）计划不宜过于粗略。控制周期过长的需 求很容易延期，如果周期超过2 周以上，建议 设立中间节点。 （4）进度表一定要经历多次迭代和优化，并 经过大家确认。一次性完成的进度表一般可行 性不大，我们需要跟大家确认这个计划是切实 可行的，否则一个有问题的进度表会让PM 被 质疑，并失去大家的信任。 / 人力安排 制订计划时还要注意人力安排情况。 （1）人力一定时，我们要看计划是否符合项目 预期。如果需要压缩周期且人力不足，那需要 在前期考虑增加人力，在项目出现延期时增加 人力风险会很大。 （2）重要的、高难度的、研发性、预研性质 的需求由内部完成，也就是内部做更有价值的 工作，且这类工作需要更多与程序、策划等其 他岗位沟通。批量生产等低技术含量的工作一 定由外包进行。 （3）发挥人力所长，安排合适的工作内容。 由于美术属于设计型的工作，同一个人在不合 适与合适的项目中，设计能力得到的发挥差别 很大。这在很多项目都有实际案例，曾有同学 在A 项目一直得不到肯定，几乎要被淘汰，结 果去B 项目后如鱼得水。因此我们需要配合美 术经理一起发挥人力所长。 / 确认计划 确认计划，就是上文提到的与相关干系人确认 计划内容。 首先与美术确认计划，再一次确保计划合理， 没有漏洞，美术确认计划的同时其实就在做承 诺，这样计划的执行会更顺利。然后与产品确 认计划，再次确保计划符合项目目标，得到产 品确认的计划，会更有公信力和约束力。 我们需要确认以下内容：①具体需求。我们首 先是要确保每个需求都在我们的计划安排之 内，没有遗漏。②需求的验收标准。这里要强 调的是一定要以游戏中看到的效果为准。③重 要的时间节点。这里要注意，对于不善于拒绝 的美术同事，一定要再三确认。因为有的美术 同事对于需求能否按时完成的问题，第一次回 答永远是没问题。只有到期当天面对延期的现 实才会不好意思的说：我当时也觉得难度有点 大，但是我想试一试。这种情况都是令PM 很 头疼的。 3 .2.3　进度跟进 / 控制进度 PMBOK 指南描述的控制进度过程，就是监督 项目活动状态、更新进度、更新项目进展、 管理进度基准变更与实现计划的一个过程。 控制进度首先是判断项目进度的当前状态是否 已经发生变更，对于引起进度变更的因素施加 影响，在变更实际发生时对其进行管理。 / 跟进方法 常用的跟进方法有趋势分析法、关键路径法和 挣值管理。 趋势分析的工具有燃尽图、累积图等，燃尽图 可以查看剩余工作量的变化趋势是否与预期相 符合，及时发现项目的提前与滞后，并预估完 成时间。图3-12 的燃尽图中，项目在1 月5 日前后剩余工作量大于预期，进度出现滞后， 而在1 月7 日以后追赶上了进度，并保持比原 计划高的开发效率。虽然还没到截止日期，但 如绿色的虚线所示，按当前的进展可以估计出 1 月13 日提前完成需求。在实际项目跟进中， 大家也可以尝试这个方法。 061 Planning and Schedule Management-Art PM 02/03 图3-12 燃尽图 图3-13 是从我们产品周报中截取的累积图。累积图主要是反映项目需求开发的进度趋势。图中 红色区域表示新建需求，黄色为完成待测需求，粉红色、蓝色和绿色区域分别为等待修复、测试 中和关闭的需求。而灰色区域即版本日的延单需求，影响到周版本的完成度。通过这张图我们可 以看出这个周版本内每一时刻需求的进展情况，这个累积图展示的是一个比较健康的趋势。项目 在周一开始总需求数量变化不大，需求完成的趋势比较平缓，没有出现所有需求集中在最后一天 完成并测试的情况，最后的延单率也不高。这个累积图由易协作自动生成，反映产品开发节奏的 健康状况。而美术开发的项目管理也可以借鉴这样的思路。 图3-13 累积图 项目管理的方法很多，大家可以多了解、多沟通、多思考，自己通过数据分析等方式来改进和 创新。 下面我们来说一下控制进度中的挣值管理。其实在日常跟进中，直接应用挣值管理公式的情况很 少，我们更多应用的是这个管理方法的思路，即偏差估算的思路。以下对挣值管理做简单介绍。 先看以下几个概念： 计划价值。计划价值（PV）是为计划工作分配的经批准的预算。我们可以理解为计划的工作量。 挣值。挣值（EV）是对已完成工作的测量值，用分配给该工作的预算来表示。我们可以理解为已 经完成的工作量。 062 项目管理的七大兵器 屠龙刀——美术PM 的计划制定和进度管理 实际成本。实际成本（AC）是在给定时段内，执行某工作而实际发生的成本，是为完成与EV 相对应的工作而发生的总成本。我们可以理解为已经完成的工作量所实际花费的成本。 进度偏差。进度偏差（SV）是测量进度绩效的一种指标，表示为挣值与计划价值之差， SV=EV-PV。可以理解为实际完成的工作量，减去计划完成的工作量得到的差值。如果 EV-PV 大于零，那说明实际完成的工作量比计划完成的工作量大，进度超前。如果EV-PV 是 负值，则说明进度是落后的。 成本偏差。成本偏差（CV）是在某个给定时间点的预算亏空或盈余量，表示为挣值与实际成本 之差，CV=EV-AC。成本偏差用于评估项目当前成本花费的情况，这个不在进度管理的范围内， 原理与进度偏差相同，是我们制作完成的需求计划花费的成本与实际花费成本的差值。 图3-14 是采用挣值管理思路进行偏差管理的案例。用完成度与时间轴的对比，来反映上线需求 的进度情况。左侧任务表是对上线需求的整体预估，例如通过主角、宠物等类别的上线需求规划 数量及当前完成数量，得出当前的整体完成度，并与当前的时间轴作对比。图中当前时间轴进度 是57%，总需求的完成度是61%，因此整体进度是略微提前的。但我们仔细看各类别需求的完 成度，角色是67%，但场景只有47%，GUI 只有32%，场景和GUI 相对时间轴来说是滞后的， 仍然存在一定风险，需要重点关注。以上就是挣值管理思路的实际应用，对于里程碑需求，月需 求的进度的偏差分析也可以用这样的方法。 图3-14 偏差管理表格案例 / 处理偏差 出现偏差后，首先要关注真实的进度情况如何？出现偏差的原因是什么？需要采取什么样的行动 来纠正偏差？我们可以用根本问题分析的方法寻找出现偏差的原因。 图3-15 是一个鱼骨图图例，针对问题我们分析出5 个直接因素，在各个原因的基础上，我们要 深入地挖掘其更为根本的原因，直至原因无法进一步剖析，从而得到各项根本原因。如果我们在 分析问题时只寻找到直接原因，是没有意义的。 063 Planning and Schedule Management-Art PM 02/03 图3-15 鱼骨图 拿一个真实的案例来举例。某新项目刚开始外包制作，就有需求延期了。直接向接口人了解原 因，得到的答案是外包人力不行，进度太慢。如果我们只是止步于这个原因，那这个问题是永 远解决不了的。为了深入挖掘原因，我们和外包商也了解情况，用鱼骨图分析出了一系列根本 原因：需求规范特别的不明确，制作人不知道具体要做成怎样的风格和效果。接口人反馈很不 专业，反馈经常有反复，导致原人力不愿意继续这个项目，外包只好临时换了新的人力，该人 力对项目不够了解，做的质量就更差了。此外项目的标准人天定得比较低，给外包的报价也 低于平均水平，外包出于成本考虑也不会安排好的人力。以上因素综合起来才导致了这样的 问题。 找到了根本原因以后，我们就可以对症下药，直接确定解决问题的方法。首先我们迭代了制作规范， 进一步明确了质量标准，让外包清楚知道我们的需求。其次，我们横向调研了同类型项目，迭代 了标准效率库。另外我们优化了反馈机制和流程。执行一个月左右出现了明显的成效，问题最终 解决，外包也给我们安排了优秀的人力，质量明显提高，进度自然也不会受到影响了。 在偏差的原因找到后就是想办法纠正偏差。首先当然是追赶进度，看看能否减少偏差，甚至将偏 差降为零。其次是优化流程，精益开发，减少浪费。其实在制作过程中，每个流程的流转经常会 有时间上的浪费，我们可以从这方面入手消除明显的浪费。再次是接受偏差并进行风险评估和风 险管理。其实出现偏差没什么大不了问题，因为我们进度跟进中，不可能所有的需求都是按时完 成的。任务完成有偏差是没有关系的，关键是要站在整体的角度来考虑问题，看项目整体有没有 风险。如果有风险，则思考整体的问题该如何去解决。最后如果偏差无法纠正，带来的风险无法 规避，那就需要告知产品及相关干系人，考虑变更。 以上是项目时间管理基础知识，我们做个总结。这部分主要包括两块内容：计划制定和进度跟进。 计划制订包括排列顺序、预估时间和制订计划。预估时间主要方法是专家判断和三点估算，重点 是用典型的时间来估算。制订计划主要方法有关键路径法，正推逆推法。进度压缩包括赶工和快 速跟进两个方法。进度跟进主要包含三个内容：控制进度、跟进方法、处理偏差和纠正偏差，其 中跟进方法有趋势分析、挣值管理。 064 项目管理的七大兵器 屠龙刀——美术PM 的计划制定和进度管理 接下来我们介绍游戏美术时间管理。这部分内容分为五部分，第一部分是敏捷开发的简介，后 面四部分是游戏的四个阶段，Demo、Alpha、测试和运营阶段，分别介绍各个阶段的一些经 验总结。 3 .3.1　敏捷开发 / Scrum 简介 敏捷开发是迭代式增量软件开发过程。游戏项目通过一系列Sprint（迭代），取得进展并发布可 玩的版本。采用敏捷流程开发游戏项目在国外实践得比较早，Sprint 的周期一般是2 到4 周，而 我们公司把这个周期缩短为一周，以便适应更快的迭代，我们称之为周版本制度。甚至我们还实 践了日版本，周双版本等，这些都是为了更快的迭代过程。 图3-16 可以直观看到scrum 游戏开发的流程：从概念原型到正式制作、后期制作，都是通过 一系列的周期发布以切片的形式进行的，通过不断的迭代来完成游戏的开发。我们产品采用敏捷 开发的过程：首先是原型验证（即最小可玩版本），早期的想法应对不确定性，通过快速迭代优 先高价值的增量开发，及时调整原来不合适的目标，拥抱变化，快速响应。产品采用的是这样的 敏捷开发方法，那美术是怎样的呢？美术周期长，成本比较高，如果变化的话代价会比较大。同 时美术开发还是需要相对明确的一个需求文档和质量标准的。那我们美术只能采用瀑布式开发吗？ 其实美术开发可以采用瀑布与敏捷相结合的方式。 图3-16 Scrum 游戏开发流程 3.3　游戏美术时间管理 065 Planning and Schedule Management-Art PM 02/03 首先美术本身其实就不是瀑布式的。例如绘制一只小狗，首先绘制大体的轮廓，确定它的造型。 造型没有问题以后，再进行细化上色，然后进一步完成作品。其实这就是一个迭代的过程。而我 们从来不会用这样的方式：先画脸，脸完成后再画五官，接着画身体和脚，这是一个很不专业的 画法。其实这两种画法就是瀑布式开发和敏捷开发的区别。前一种制作过程是一个敏捷开发的过程， 而后者是瀑布式开发的过程。 传统的游戏美术是采用瀑布式开发的。如图3-17 所示，原画、模型、动画、特效、音视频串行制作。 如何让游戏美术开发敏捷起来呢？这有两个矛盾点。第一是制作周期长，一个角色从原画设计到 音效完成，往往需要近2 个月的周期，而产品周版本里的一个功能开发单，大多开发周期小于一 个星期。第二是成本高，变更的代价大，比如如果一个角色的原画设计变更，则模型、动画环节 都要重新制作。但这一点也是我们进行游戏敏捷开发的推动力。如果在原画环节就验证了效果， 同时模型、动画制作阶段在早期进行效果功能上的验证，就可以避免后期因功能和效果不满意带 来的变更，避免更多的浪费。 图3-17 传统游戏美术瀑布开发流程 / 美术敏捷开发流程 美术敏捷开发流程就是让美术开发尽可能参与到产品周版本的迭代计划中，让美术设计尽早在功 能和效果上得到验证，让美术资源对产品的变更做出更快的响应。 正如图3-18 的流程所示，美术需求在粗版完成，就在游戏中进行测试迭代，达到满意的效果后 进行细化制作，细化完成后继续测试迭代，最后完成高质量的最终版。这样最大优势如图3-19 所描述，红线表示预期目标，黑线表示实际开发的结果。左边描述的是瀑布流程的情型，实际得 出的结果往往离目标有偏差，我们只有在最后完成时，才会发现离目标有这样大的偏差。而采用 敏捷开发以后，在中间过程不断进行验证，不断地进行偏差纠错，正如图3-19（a）所示，在不 断的迭代的过程中向目标靠近，最后实际结果也早在预期范围内，和目标偏差较小。 图3-18 美术单个需求的敏捷流程 图3-19　敏捷开发在目标达成上的优势 066 项目管理的七大兵器 屠龙刀——美术PM 的计划制定和进度管理 不仅是单个需求，在多个需求组成的功能模块上也可采用敏捷的方法。图3-20 所示，模块中各 需求各环节的粗版，可以组成临时的可玩版本，我们在可玩版本的基础上进行测试调优，使可玩 版本达到预期效果，然后在大家认可的版本上细化，完成细化后再测试迭代，打磨出更好效果的 完成版。可以看到其中的每个环节都经历了多次的迭代，同时整合在一起又进行了多次调优，这 样的完成版是经过多次迭代完成的，它的效果一定是更符合项目要求的。 图3-20 美术功能模块的敏捷流程 我们在整体的游戏开发过程中也是这样做的。美术预研阶段的Demo 资源，通过不断的迭代，得 到一个初步验证的核心玩法的最佳美术效果。进入Alpha 开发阶段，虽然以批量制作为主，但我 们的整体开发思路也是量产- 迭代- 量产- 迭代的方式，在一次又一次的批量制作完成以后，我 们进行整体的迭代，进行效果提升。到了测试阶段，迭代频率会增加，量产- 迭代和迭代- 迭代 同时并行，不断提高我们的游戏效果，游戏在达到项目及玩家满意的效果后上线（见图3-21）。 图3-21 游戏美术整体开发敏捷思路 067 Planning and Schedule Management-Art PM 02/03 说了这么多敏捷开发的内容，大家一定很奇怪，这跟美术时间管理有什么关系呢？我们游戏美术 时间管理一定要有敏捷开发的思路，否则将无法适应游戏开发的快节奏。因此我们在进行时间管 理计划安排的过程中，一定要用敏捷开发的思路来进行安排。 接下来我们来了解游戏不同开发阶段的时间管理。 3 .3.2　Demo 阶段 Demo 阶段需要进行美术竞品分析，原画风格预研及Demo 美术全流程的制作，同时我们还不 能遗漏音视频的替代资源。 / Demo 前期 大多数项目的Demo 前期处于在偷跑阶段，也就是Demo 还没有立项时，提前进行项目前期 工作。 这个阶段产品重心在世界观和核心玩法确定上。我们通过与产品的沟通，收集项目最前期的需求 并确认范围，这个范围其实就是竞品分析的目标以及替代资源的方向。该阶段需求内容有两条线， 一条线是风格预研线：完成竞品分析以后，需要进行美术风格预研，一般会进行风格竞稿，有时 会有很多原画同学参与进来（看美术组的人力情况），选出最合适的风格并进行原画标杆制作。 另一条线是替代资源的制作。策划需要确定核心玩法的最核心部分，并与美术确定主要的功能表 现，之后美术同学就可以针对性寻找合适的美术资源，我们需要寻找与策划希望能够实现的美术 风格相接近的替代资源，可以拿其他项目的资源，也可以去网上购买一些素材。寻找到替代资源 以后，有些还需要做少量的调整，才能完全符合Demo 功能的需要。 在Demo 前期，项目一般是没有固定的周版本，因为在前期基本上还没有可视化的产出，打包也 不是很定时，偶尔需要看下效果时会临时打个包。这个时期，我们看看美术需求的两条线是如何 做时间管理的。 美术风格预研其实是一个比较长的过程。有的项目从偷跑阶段开始一直到Demo 立项以后的一段 时间一直在做这样的工作，因为这个工作决定着未来整个项目的风格方向，不可急于求成，一定 要做出最好的效果，效果上的妥协会为后面埋下返工和大量迭代的隐患。 替代资源的制作周期都比较短，因为只需要在原有资源基础上改，且仅用于功能验证的资源无需 细化。同时功能开发依赖非常严重，产品如果没有这些美术资源，往往就无法进行进一步的功能 开发。这时我们可以以周为目标，保证每周有一定的产出，特别是功能性需求，我们要随时沟通 进展，及时响应，保证策划能够及时地拿到资源进行开发。 图3-22 为一个Demo 前期项目的整体规划情况。这个项目每周都明确了可视化目标方便跟进 验改。上半图是整体规划，整体规划完成以后继续明细了每周所需要实现的一些功能目标。可以 看到策划、程序、美术、UI 都会列出这周需要完成的一个目标，然后进行跟进。 图中的该周有很多内容都是没有完成的，因为Demo 前期的变化比较大，我们并不是要求每周的 目标一定百分之百完成，但是我们通过这样每周的回顾，可以看出当前的进展如何，遇到了什么 问题，而且美术、程序、策划不同岗位间都互相了解对方的进展，对互相之间开发的配合是很有 好处的。 068 项目管理的七大兵器 屠龙刀——美术PM 的计划制定和进度管理 图3-22 Demo 前期进度跟进表参考 / Demo 中后期 到了Demo 中后期，风格确定下来了，游戏有了简单的可玩版本，核心玩法得到了初步验证。 这时候美术需要为Demo 评审做准备，大部分项目都会完成一套有两个主角，一个完整的场景 的核心玩法的流程。这个时候产品需要确认Demo 评审的范围，需要实现哪些玩法功能，并与 美术一起确认对应需要哪些资源，哪些需要全新的制作，哪些只需要替代资源，要完成怎样的 一个完成度。这些确认下来以后，美术PM 和美术经理、主美再次确认需求范围的合理性。因 为Demo 团队往往是一个项目新孵化出来的一个团队，产品经验不足，有时候会提出一些不太 合理的需求，如有些需求开发是没有必要的，会造成浪费，这些都需要有经验的美术经理和主 美来共同保证范围的合理性。 另外很重要的一点是一定要将他的工作纳入计划。他的工作比较琐碎，而且因为专业度特别高， 我们在排计划很容易忽视。其实这个阶段美术技术规范的工作已经开始了，我们需要及时的把这 部分纳入计划中，尽量在Demo 阶段完成技术规范制定，让Alpha 阶段更加顺利。Demo 评审 往往是项目的第一个里程碑，从立项开始到评审只有短短的三个月时间，质量要求高，缺乏经验， 问题和Bug 都比较多。这时候我们制定Demo 评审里程碑的规划，可以按周制定目标，以确保 最终目标是可以实现的。我们还要注意留出更多的缓冲时间来。提前一周我们要提交UE 测试 包，为了UE 测试包的稳定性，会再提前1 到2 周打出UE 测试包，以保证有更多的时间来修改 bug。这种情况下美术制作周期很短，很多资源都需要到UE 测试包提交的那一周才能完成最终 的资源。针对这种情况，我们可以提前将中间版本上传，降低需求完成后替代进游戏出现大问题 的概率。比如场景可以先将模型的粗贴版本提交到游戏中，等到UE 测试包提交那一周，我们只 需要替换它的贴图，这样生成Bug 的概率就相对较小。另外就是准备退一步的方案，如果到UE 测试包提交以后，我们还没有办法完成这个需求怎么办？有没有一个替代的方案？比如有没有一 个替代版本，至少能保证游戏流程的完整性。事实就有项目就采用这样的方式，通过退一步的方 案，保证了评审时游戏流程的完整，但同时也将后来完成的最终效果带到了评审的现场，让评审 委员会看到目前实际能达到的质量标准。如果仍然无法达成目标怎么办？那就只能考虑增加人力 或者削减范围的方式。削减范围其实也可以考虑多用替代资源，以保证几个出彩的亮点能有更多 069 Planning and Schedule Management-Art PM 02/03 的时间来制作。事实上现在公司杜绝开发成本 的浪费，非常鼓励Demo 阶段采用替代资源， 评审更看重游戏的可玩性和市场潜力，因此 Demo 阶段美术开发的进度压力可以通过替代 资源降到最小。 产品在Demo 期一般采用轻计划轻版本的项 目管理流程，产品计划有简单的周版本任务列 表，美术PM 可以将周期较短的需求用同样的 方法整合进周版本需求列表中，这样可与产品 更加无缝配合，同时跟进起来也比较方便。 周期较长的制作需求，我们要排好详细的计划， 确保按时到位。这类需求的计划安排和批量制 作时期的相似，具体的跟进方法我们可以考虑 定期会议等，可以通过每周的会议来查看每周 大家的进展，或者通过每日发图的方式，查看 每天大家的进展情况。 要注意粗版及时进入游戏验证，配合产品的功 能开发。 迭代修改需求需要专项跟进，因为在Demo 中后期有很多的迭代修改需求，不仅是功能的 迭代修改，还有很多美术效果提升的修改。我 们要排好优先级，可以通过易协作提单的方式 进行，保证需求没有遗漏。也可以通过泡泡机 器人收集需求，导出表格来跟进。 要关注质量标杆的制作及规范的制定，这两部 分对Alpha 阶段能否顺利开始影响很大。 要随时做好调整计划的准备，如有风险及时沟 通解决方案。因为Demo 时期变化比较多，我 们要随时顺应变化，拥抱变化，但同时Demo 的周期比较短，风险的影响也比较大。 另外有的项目Demo 后期采用日版本快速迭 代的方式，美术也可以积极参与进去。 3 .3.3　Alpha 阶段 / Alpha 阶段的规划 Alpha 阶段我们会进行一系列的规划：上线需 求总规划，里程碑规划，月度规划，周版本规 划等。 刚进入Alpha 阶段首先要做的就是上线前的整 体规划，需要先进行美术上线前总需求的预估， 其实这个工作我们在Demo 评审前做上线预 算时就会进行。有了上线需求后结合以往的开 发经验，就可以得到一个大概的规划。这个规 划可以用于整体完成度的预估，整体进度情况 评估和人力估算，以做到心中有数。 有了上线整体规划以后，产品就可以将上线需 求规划到各个里程碑，在里程碑里面需要到位 的美术需求也可以相应的列出来。里程碑规划 的目的是进行里程碑目标的评估，并进行里程 碑计划的制定。而对于整个游戏开发而言，每 个里程碑目标的达成情况可判断项目是否按原 来的上线规划进行。 月度计划不是每个产品都会有，但很多项目在 Alpha 开始阶段把每个月设为一个里程碑。美 术的月度规划需要了解月度需要到位的美术需 求并安排月度计划。 周版本规划，就是每周版本需要到位的美术 需求。 从上线整体规划到周版本规划，它的一个精确 度是从低到高的。上线整体规划过程中，我们 不会对上线需求进行详细的计划排期，这个计 划做出是没有意义的。而上线规划到周版本的 过程，也是一个滚动规划的过程，我们仅仅对 已有明确需求，并且在近期里程碑需要交付的 需求，做到月度或者周版本这样细致程度的 计划。 070 项目管理的七大兵器 屠龙刀——美术PM 的计划制定和进度管理 / Alpha 前期 我们要注意的是，Demo 期结束不等于批量制作的开始。在Alpha 初期排计划时，我们要先确 认以下问题：美术各环节的风格和质量标杆是否已经完全确认？技术规范、制作规范以及验收标 准是否已经明确？是否有合理的制作流程？当以上都满足，才可以做批量制作的计划，否则我们 要先进行以上工作的计划安排。 / 批量制作阶段 批量制作阶段进行计划安排，最重要的就是需求沟通。我们要注重前期设计，原画设计是最容易 延期的一个环节，要注意留足够的缓冲时间。特别是Alpha 阶段前期，因为原画设计还不是特别 有经验，反复修改的情况会比较多。同时我们要提醒产品提前规划下一批的需求，以防阶段性的 需求井喷和人力空出。 如图3-23 所示，在批量开发中，先进行原画制作，而在第一批模型制作的过程中，原画人力就 已经空出，而原画制作往往又比较花时间，难以很多需求同时并行，因此在原画进行第二批制作时， 模型、动画人力，特别是外包人力都有可能空闲，这样会带来需求阶段性空窗和井喷。而外包人 力的空出会导致人力的流失，严重影响项目的稳定性。这时我们就需要在图示箭头所指的时间点 来提醒、推动产品提前提出下一批的资源内容，这样原画的第二批就可以提前开始，给项目更多 的原画储备，模型的第二批就可以紧接着第一批完成后顺利开始，保证了需求量的平稳。 图3-23 批量开发阶段需求制作示意图 需求各环节初版要设计划节点，严格跟进。因为这些初版会涉及各个环节之间的交接，影响到功 能版本的实现时间点。内包需求的计划节点周期尽量不要超过一周，这也是我们前面所提到的跟 进粒度。外包需求我们需要前后留有缓冲时间，因为在发包之前，我们需要沟通人·天，沟通制 作要求，这些沟通时间是无法压缩的。在后期我们要留有更多的缓冲时间，因为外包的制作质量 是难以达到内部的要求，我们往往需要收回来进行修改。在计划无法达成产品预期时，我们要先 考虑是否有解决方案，如果实在没有办法解决，再和产品沟通优先级，削减范围。 下面我们来说一下批量制作阶段的进度跟进。首先环节依赖节点是重点跟进的，这样才能保证各 环节之间的顺畅流转。另外要培养大家的进度意识，做到人人都是PM。我们知道Alpha 阶段的 制作量是非常大的，如果一个进度表上众多需求的所有环节节点全部由美术PM 一个人来跟进是 不可能的，而且非常容易遗漏，这时候就需要培养大家的进度意识，要自己对自己制作的需求进 度负责，这样才能保证每个需求都是在进度把控中的。另外沟通协作是重中之重，这么多的需求， 071 Planning and Schedule Management-Art PM 02/03 这么多环节，我们如何通知到每个人？上一个环节完成了，下一个环节如何知道自己要开始了呢？ 这时就需要大家协作起来。首先我们可以用协作工具，比如说svn、NXN 等，每个需求每个环 节的状态由制作人自己来更新，这样子大家才能知道各个环节具体做到了什么样的阶段。另外可 以设置泡泡机器人提醒，通过泡泡@ 各环节的同事来通知下一个环节的同学可以开始制作了， 保证流转过程没有时间的耽误。另外看板也是一个很好的方法，利用精益开发的思想理清障碍和 减少时间的浪费。此外进度问题我们要进行根本原因的分析，具体的方法前面已经介绍过了。此 外需求一定要跟进到资源进游戏。我们常遇到这样的问题，美术认为这个需求已经制作完成了， 美术PM 也已经把这个需求标注成完成状态，但是策划认为这个需求并没有完成，因为他在游戏 里面并没有看到这个资源，甚至这个资源还没有上传到svn。就是我们对完成定义标准的不同， 我们需要统一完成的标准，就是在游戏里面看到这资源且效果确认通过。我们要优化流程尽早将 资源放入游戏验证效果、确定方案、减少返工、缩短周期。图3-24 是一个流程优化的案例，一 般来说我们特效资源都会在动画资源完成或者初版确定下来以后才会开始制作，这时特效的方案 确认就会比较迟。那如何能够早点知道特效的效果是否符合项目预期呢，该项目在原画完成了以后， 就开始进行特效的方案设计。通过原画的形式将特效方案表现出来，并通过迭代达到项目和美术 共同认可的质量标准。 图3-24 特效方案原画设计案例 某个项目在做动做前期设计时用采用真人动作演示的方法，这个方法的好处就是能够让动画设计 在很早的阶段就确认下来，通过真人表演直观的表现，比用原画设计方案更便捷。同时这样的直 观的表现方法，也可以让外包在制作的过程中清楚地了解我们想要做的动作，做出的效果更符合 预期。 另外批量制作阶段，我们要保持和外包的长期友好联系。我们需要保持核心外包的稳定性，掌握 核心外包的人力情况、外包的意见和建议。我们要及时采纳，并积极去了解后续进展。要把外包 要看成项目的一分子，共同攻克项目的难题，因为在某些方面外包其实很有经验，他们的长处我 们也可以积极去学习。此外我们要积极培养外包的能力，外包能力强并且稳定在项目中，对项目 的长期开发是非常有好处的。定期走访主要的供应商，也是我们保持与供应商良好关系的一个主 要方式。另外在项目的沟通中，我们可以多采用电话会议沟通的方式，这样的沟通方式是非常有 效率的。 072 项目管理的七大兵器 屠龙刀——美术PM 的计划制定和进度管理 3 .3.4　测试阶段 / 测试阶段特点及管理方案 测试阶段会经历一系列密度较高的大小测试。 与Alpha 阶段最大的不同点：Alpha 阶段是经历批量制作- 迭代- 批量制作- 迭代这样交错进 行的过程。而测试阶段，我们不光要进行批量迭代，同时会并行进行针对测试的一系列迭代，因 此测试阶段迭代密度是非常大的，如图3-25 所示。 图3-25 alpha 阶段与测试阶段对比 测试阶段美术需求有其特点： ● 紧急需求量大增，变更频繁。在批量开发阶段，项目主要在铺量，而测试阶段受市场、玩家、 测评等影响大，经常会新增紧急的迭代需求，因此变更也更加频繁。 ● 美术迭代需求量增大，开始进行质量上的打磨。 ● 批量开发的需求没有减少，因为每次测试都会考虑投放一些新的内容，同时我们还要考虑上线 后的资源储备，因此批量开发是持续进行的。 ● 时间节点更加严格。在Alpha 阶段，里程碑版本的节点并没有那么严格的限定，如果时间来不 及，大概率会调整计划。但是在测试阶段，项目首先对玩家、合作商等是有时间承诺的，其次 为了项目尽早上线，尽快地打入市场占领先机，项目测试也需要有严格的时间计划。 而产品开发的情况是： ● 里程碑的密度增大了，一般1-2 个月有一次测试版本，因此项目开发的节奏加快，项目开始实 行周双版本，甚至是日版本等更加快速的迭代方式。 ● 项目实行多分支管理，版本控制更加严格。 针对测试阶段以上特点，分享一些测试阶段时间管理的经验。 （1）增加优先级别的选择范围。一般我们优先级别都是用高中低来表示，这样选择范围比较小。 产品习惯性将需求优先级填为高或中，这样你会发现项目很少有优先级低的需求，在进行计划安 排时，这样的优先级是没有意义的。增加优先级选择范围，可以将优先级用数字表示，比如从1 到10，这样更能区分开它的优先级差别，保证最有价值的需求最先制作，同时要及时更新和定期 确认优先级的排序。 073 Planning and Schedule Management-Art PM 02/03 （2）倒排计划，正向推动，制作方法适应周 期时间。因为每个测试制作周期都比较短， 我们必须要采用倒推法，看看这样的时间周 期内到底能制作多少需求，如果需求量超出 预期但无法缩减，我们就用制作方法去适应 制作周期。比如某需求原本需要全新制作， 但因周期限制，我们采用复用的方法来缩短 制作时间。 （3）除周期较长的纯效果迭代需求外，功能 性迭代需求设定迭代周目标，尽量加入项目的 周版本规划中。 （4）新手、性能优化等任务专项排期跟进， 负责人在负责效果同时要协助PM 一起来把控 这个进度。有必要时我们可以成立类似特性团 队的攻坚小组，坐在一起及时沟通问题，遇到 难题通过攻坚会议来讨论解决。每周更新相关 需求，审核进展。相当于这两个专项任务安排 了美术环节内部的周版本。 （5）需求规划可以采用思维脑图的形式，让 各类型繁杂的需求更加有条理。 （6）在进度和质量上我们要找到平衡点。如 果我们光注重进度，而忽视了质量，这样会流 失一部分对质量要求比较高的玩家。如果我们 只重视质量而忽视了进度，那么我们游戏上线 会遥遥无期，在市场竞争中错失机会。因此有 些需求虽然没有完成，但玩家可以接受，我们 就可以提前投放测试，有总比没有好，不要在 一个点上持续打磨而误了大局。 （7）提前规划好可预知的重要非紧急需求， 如KV 海报、后续测试要投放的内容等，上线 后的资料片储备也可以提前做起来，以达到良 性循环。 （8）我们要严格遵守svn 资源提交的规范， 一方面确保资源及时放进游戏，另外一方面保 证美术的资源提交不会给产品对外测试版本带 来重大的Bug。 3 .3.5　运营阶段 / 运营阶段特点及管理方案 不同项目运营期差别非常大，不同类型不同营 销策略和不同的上线成绩都会带来完全不同的 结果。这里假设为一款成功项目，那么我们在 运营阶段需要注意什么呢？ 运营阶段的需求特点：①进度要求非常高，时 间节点几乎没有商量的余地。这非常好理解， 上线后的项目，其内容投放规划是有营收和吸 量策略的，这关系到项目的收入、玩家的粘度。 ②质量和性能要求都不能出现差错。③紧急需 求多，变更量大。④节日版本、资料篇需求量 大，版本密度非常的高。 针对以上特点，我们看看运营阶段的时间管理 方案。①用成本换进度和质量，上线以后的成 功项目本身是有一定的收入的，这个时候进度 和质量就显得更为重要。②各类需求灵活安排。 节日需求、资料片需求要提前规划，变重要紧 急需求为重要不紧急需求。迭代需求长线规划 穿插进行。我们看图3-26 运营期需求的象限 图。横坐标是重要程度的坐标，纵坐标是紧急 程度坐标。第一象限就是重要又紧急的需求， 可以看到活动资源、节日资源、重大Bug 等， 很多的需求类型都落在这个象限，而其他像零 砰的增补资源、小型Bug、迭代需求、储备资 源等都落在其它不同的三个象限，这三个象限 图3-26 运营期需求的象限分布 074 项目管理的七大兵器 屠龙刀——美术PM 的计划制定和进度管理 内需求类型比较少。所以运营阶段时间管理难度比较大，很重要的原因就是有很多资源都属于紧 急又重要的需求。像重大Bug、玩家的重要反馈、一些临时的战略需求，它们的重要程度我们无 法改变，而紧急程度往往也无法控制。那么我们能控制的就是活动资源、节日资源、资料片资源， 这些我们可以进行提前规划，把它从重要紧急需求变为重要不紧急需求。图3-27 是广州某项目 的美术资源进度日历，通过该日历将每个节日都列出了对应的规划，这样提前规划提前制作，进 而把项目带进良性循环。③我们要主动沟通，通过取巧的方法缩小范围，比如如果有资源可以复用， 这样可以大大的缩短制作周期。④人力和需求进行分级，对应安排合适的难度和重要度的需求。 图3-27 美术资源进度日历 以上就是游戏美术时间管理的一些基础知识和经验分享，总结一些关键要点: 计划制定主要步骤 为排列顺序、预估时间和制订计划。排列顺序要考虑优先级、周期、难度等多方面因素。预估时 间的重点是建立在典型时间的基础上，减少帕金森定律带来的负面影响。制订计划要滚动规划， 计划需要得到相关干系人的确认。进度跟进可采用关键路径法和挣值管理，及时发现偏差和纠正 偏差。游戏美术时间管理中要有敏捷开发思维，尽早进行功能和效果验证，再进行细化迭代。项 目不同开发阶段的时间管理有不同的注意要点，这些都来源于项目实践，不同的项目也有自己的 特点，因此仅供参考。纸上得来终觉浅，绝知此事要躬行。本篇内容的学习还需要大家在实践中 多体会。