5 范围蔓延和镀金，90%的项目死于这两大杀手！人人都是项目经理系列（第5/13篇）

• 敏捷开发 不是极限开发 ，上下班或者工作量随意。
• 敏捷开发拥抱变化 不是随意变化 ，策划往往看了效果再改一版。
• 敏捷开发 不是忽律质量 ，每个迭代的质量仍然需要保证通过验收。
• 敏捷开发 不会缩短开发周期 （相反因为频繁修改还会拉长）。

游戏开发中，绝大多数都是使用的瀑布型，这也是我们这个系列主要介绍的方式。 “范（围）进（度）成（本）”是一个项目的重点，而需求则直是项目管理的重中之重，它是进度、成本的大前提。项目经理需要负责确保这些需求在项目管理计划中都有所安排，并且在预算内按时完成，同时尽可能的创造利润和价值。 在游戏开发领域也是一样，你本来做着《王者荣耀》，突然吃鸡火了，项目做一半去做吃鸡模式，自走棋火了，又去做自走棋，捡树枝火了，又去做捡树枝，范围的变更会导致进度和成本遥遥无期。所以防止范围失控是项目经理首要的责任目标。 所以最后，总结一下：项目范围管理包括 做且只做 所需的全部工作。 2 收集需求 收集需求的原始定义：为实现目标而确定、记录并管理相关方的需要和需求的过程。它为定义产品范围和项目范围奠定基础。 不过在细说收集需求之前，还要先提一个过程，叫做规划范围管理计划。这个是什么意思呢？还记得我们上一个章节里有一个过程叫做规划项目管理，其中的输入就来自于各个子的管理计划的输出。 范围管理计划里面没有定义实际的范围，它是一个流程性的文件，主要描述项目是如何定义、制定、监督、控制和确认项目范围的。 举个例子，在游戏开发中，需求一般是由策划负责的。主策划出具了一份需求规范，里面有写到，需求可以由项目里的任何人提出，然后由主策划评定是否有价值，通过后纳入需求池，然后指定具体的策划出具详细的策划案，最后对已经完成策划案的功能进行版本排期开发。 这就是一份最简单的范围管理计划了。但实际项目里，需求增加会更复杂一些，它可能还需要设计需求的优先级评定，指标测量等等，但是无论如何，范围管理计划里面是一定没有实际范围的，它只是流程性或者管理性的文件。 再反过来说需求，需求的概念是根据特定协议或其他强制性规范，产品、服务或成果必须具备的条件或能力。他包括，发起人、客户和其他相关方的 已量化 且 书面记录 的需要和期望。 你是开发，如果有策划拿着手机过来跟你说，你把这个士兵的颜色调成跟它们这个一样的红色。你可以呸他脸上。策划和程序沟通交流，最基本的礼仪就是文档。士兵ID是多少，颜色的色值是多少，有没有和主策划、PM报备过，有没有评估过实现难度，主程又知不知道。当然如果你们关系比较好，他说下午请你喝个奶茶，你调个效果给他看下，倒是可以考虑下。 需求的收集有很多种方式，这里罗列一下： 这里简单说一个我觉得有意思的地方，工作指导和工作跟随。 女朋友要换新电脑，叫你给方案。你说，CPU应该选I9，显卡应该选2080，内存应该要32GX4（确定是给女朋友配还是给自己？），这叫做指导，能够讲清楚，说明白的。但是淘宝下单，全部到了之后怎么组装？你远程视频教了两个小时，结果女朋友把硅胶涂到CPU的针脚面上了。你吓得赶紧过来，10分钟把主机组装好，为了让女朋友看的清楚，又拆掉装了两遍。然后女朋友在你手把手的方式下，自己把电脑装好了（虽然不知道为什么要插那，但是插上好像就对了）。这种方式叫做工作跟随。有些事情你要描述很困难，但是要实操一下就好。 收集需求的最终输出就是需求文件，很多流程管理里叫做用户故事Story。只有明确的（可测量和可测试的）、可跟踪的、完整的、相互协调的，且主要相关方愿意认可的需求，才能作为基准。 大概有如下分类： 比如：

• 业务需求，这是一个5V5实时对战的MOBA游戏。
• 解决方案需求，为了让对战流畅，我们需要使用帧同步+UDP的方式去实现。
• 相关方需求，要在国内发布，需要接入屏蔽词和防沉迷，还有实名认证。
• 过渡需求，UI资源没到位，先用临时资源拼界面。

最终我们可以把产品从来源到交付成果联系在一起，形成需求跟踪矩阵。 但这个一般在游戏开发中是没有（项目裁剪过程）的，可能在销售、生产行业用的比较多，叫做责任落实到人。 3 定义范围 收集需求的过程搞定了之后，接下来就要筛选已经收集过的需求，以便定义项目范围。 要定义范围的话，我们需要从几个方面去找，第一个是项目章程。还记得项目章程里提供了高层级的需求吗？比如里面会描述，这是一个5V5 实时对战，卡通风格、重社交，重氪金，轻度PVE的MOBA游戏，会同时发行海外和国内。这是范围的大前提，后续的需求收集都是基于此来收集的。 然后是项目文件，比如以往的经验教育库，其他同类项目的过往实践。这里讲到了，要发行国内，你要做防沉迷，实名认证，还要做支付刷脸。发行海外，需要接入翻译，以便不同国家能够在一个服务器畅玩。 这个过程说起来很简单，但实际上十分复杂，最后它会输出一份项目范围说明书。在游戏行业一般叫做游戏大纲。如下，就是一个游戏的大纲描述： 项目范围说明书-是对项目范围、主要可交付成果、假设条件和制约因素的描述。记录了整个范围，包括项目和产品范围。它详细描述了项目的可交付成果，还代表项目相关方之间就项目范围所达成的共识。 为了便于管理相关方的期望，项目范围说明书可明确指出哪些工作不属于本项目范围。当然这个在游戏行业里也基本不会有，没有什么是策划不能做，不敢做的，无所不能【狗头】。 做个总结： 4 创建WBS WBS（Work Breakdown Structure）定义：工作分解结构。主要作用就是把项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程。它组织并定义了项目的总范围（项目范围说明书只定义范围，没有组织范围）。 WBS最底层的组成叫做工作包，一个工作包描述的是该工作所包含的内容，注意这里的“工作”是名词，不是动词。创建WBS的过程就是将整个项目的工作分解为工作包。 但其实在游戏开发的过程中，很难做到一次性把所有内容都拆分出来，大都是按照版本拆分，比如以下就是某游戏在某个阶段版本的内容包： 拆分工作包比较简单，一般来说凭经验就可以了。主要的目的就是把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术。 以下是一个例子（JIM是我的PMP培训老师，素材也来自乐凯培训机构，已经获取授权）： 同样的 游戏开发也是可以拆分需求的： 这里我要稍微说一下，游戏开发的过程中一般都会有评审会，评审会就是把策划的需求拿出来，相关的人员一起参与，把需求拆分成子需求和工时任务。最下层的子需求就可以理解为工作包了。工时任务是进度范畴的内容，我们下个章节会讲。 另外还要说一个原则，除了80小时原则之外，其他都是比较严苛的遵守的，至少我们是这样。 创建WBS完成之后，就有了第一个基准，叫做范围基准。注意，“ 范进成 ”三大基准非常重要，是项目的 根基 。 最后，我们把WBS拆出来的工作包（子需求）形成WBS词典。如下： 解释下图中的控制账户，是一个管理控制点（可以与组织的财务程序链接），在该控制点上，把范围、预算、 实际成本和进度加以整合，并与挣值相比较，以测量绩效。这个游戏开发很少用，所以不介绍了。 5 确认范围 范围管理的重点内容基本上讲完了。现在这个过程叫做确认范围，就是“客户”或“发起人”正式验收已完成的项目可交付成果的过程。通过验收每个可交付成果，来提高最终产品、服务或成果验收的可能性。 如果把策划看成甲方的话，那么程序开发就是乙方。乙方按照策划文档把功能开发，并 自测完毕 （非常重要），之后交付策划验收。主要目的就是看开发是否有遗漏，是否有不符合约定的功能。 验收完毕之后，需要由应该由客户或发起人正式签字批准。这在游戏开发中就没有这么正式，基本上策划说验收过了，就会转到QA组做质量检测。 注意这里有一个问题！一般的实体项目是先由质检组完成检测，确认没问题之后再交付发起人。这和游戏开发是不同的，因为大部分的非游戏项目，发起人（甲方的）和质检组（乙方的）不是一个公司或者项目的，所以乙方在交付成果的时候必须先由自己的之间确认没问题才能交付。 而游戏开发不同，大家都是一个项目的，并且QA部门是游戏上线质量的守门员，拥有较高的话语权。如果质量不达标，它们是可以卡主不让上线的。所以策划先简单验收，而QA会详细验收。 确认范围有两个结果，通过了交给QA做详细测试，不通过，打回给程序开发，重新查补缺漏。 补充一个项目整体流程和节点： 6 控制范围 最后一个过程也很简单，但是简单不代表不重要。PMP里几乎没有废话，每一个句子单独摘出来看都是非常重要的。更别说这是一个单独的过程。 控制范围就是监督项目和产品的范围状态，管理范围基准变更的过程。主要是在整个项目期间保持对范围基准的维护。确保所有变更请求、纠正措施、预防措施都通过实施整体变更控制过程进行处理。 还记得上一章我们有实施整体变更控制的过程嘛？它的一部分输入就来自于这里的输出。同样，上一章节还提到了范围蔓延、镀金的概念，这些都是范围失控的表现。 可能有人会问，为什么镀金也不行呢？明明不会影响，还多做了功能，甲方爸爸为什么不开心呢？那你这么想，为什么《炉石传说》、《皇室战争》在对战的时候只能发表情呢？如果你开发的时候顺手加上了能发文字的功能，接下来你需要一整套的屏蔽词方案来配套解决自由聊天问题。甚至你隐瞒加入的这个功能可能会导致游戏下架整改。 所以，记得，一定是 做且只做 需要做的需求！ 最后，如果范围蔓延或者镀金已经实际发生了怎么办？补变更流程 ！变更通过了，那么省事，你什么也不用干，变更没通过，对不起，请你还原回去。 这就是，范围管理的全部内容了，下一章，介绍进度管理。