4 项目整合，如何把项目做成行业里最靓的仔？人人都是项目经理系列（第4/13篇）

因为游戏行业本身是一个强项目型的组织结构，所以后续的内容上不再明确强调这一点。全部默认都是强项目型的组织架构，即项目经理拥有最高的职权。

另外，PMPOK是一套指南性的成果，也就是说全书都不会告诉你怎么去解决实际问题。而是从成千上万的项目中总结共性，提取相同的流程和最佳实践，把它们编撰成权威的，具有最大化适应的良好实践。

而我这个系列要讲的内容就是，如何在这套最佳实践和框架下指导游戏项目开发。在实际的游戏开发工程中，怎样将实际阶段和PMP对应起来，从而依赖它的最佳实践来反哺实际的项目管理。

这个章节叫做项目整合管理，也就是说它需要整合隶属于项目管理过程中的各种过程，并对项目管理活动进行识别、定义、组合、统一和协调。

它的内容非常多，是一个项目管理总览性质的章节。下面放出了一张图，请一定记住这张图，它包含了项目管理的所有重要流程和领域，红色的部分是当前章节所涉及的知识点。这张图会贯穿我们这个系列文章，直至最后将所有内容串联起来。

接下来我们从不同的角度来阐述项目整合管理所涉及的知识领域。

1 项目中的相关方

什么是相关方？简而言之，就是会受项目的积极或消极影响，或者能对项目施加积极或消极的影响的任何人或者组织。这个定义非常广泛，很多相关方甚至是项目开始之前预料不到的，这会在后面的风险领域详细讲解。

举几个例子，你在公司做项目，那么你看的见的相关方可能就包含：

• 你的老板，他能决定项目是否能继续开展下去。
• 公司高管，他们能决定你的项目资源如何进行分配。
• 财务部门，核算你的工资，加班，打车报销、团建、部门经费预算等等。
• 人力部门，你的项目人员招聘。
• 运维部门，你开发的软硬件。
• 商务发行部门，你的游戏是否能卖个好价钱。
• 版署，你的项目是否能够发行。
• 外包，你们游戏的美术、音效等各种资源进度。

那么看不见的相关方呢？

• 微软，可能时不时的去查你的盗版。
• Unity，是否购买了正版引擎。
• 老板的儿子，你的项目正好符合他的兴趣，项目被追加资源，得到老板器重。
• 老板的老婆，因为游戏太好玩了，老板儿子沉迷于此，影响了家庭和睦，项目被迫解散。
• 扫地的阿姨，项目解散之后，扫地阿姨突然站出来说，她想投资项目，觉得一帮小伙子挺有上进心的。
• 竞争公司，在你游戏上线的时候，雇佣黑客对你进行DOS攻击。
• 未成年，解决了竞争问题之后，被未成年举报防沉迷做的不足，并且下架整改，同时被家长打了1星。

项目经理整合项目的首要任务之一，就是要尽可能多的去识别相关方，这个也会在后续专门的相关方章节进行详细阐述。

2 什么是ITTO

ITTO是几个英文的缩写，代表：输入（Input）-工具和技术（Tool & Technology）-输出（Output）。这个概念非常非常重要，PMP相关的49个子过程都需要使用到这一概念。

简而言之，ITTO就是项目经理在面对一个过程执行的时候，要考虑，我们现在有哪些信息和依据，有什么值得参考和借鉴的内容，应该审核哪些相关联的文件和数据，然后再考虑使用什么样的方法和技术来解决该过程，最后这个过程执行完毕之后，预期能够得到什么，并且是否需要记录和保存，以及如何存储结果。

这里举一个简单的例子：比如我们识别相关方，那么首先我们的输入就是，项目章程（立项书）、法律、市场调研报告等等。而工具和技术可以选择各种会议探讨，比如引导式研讨会，指导式小组讨论会、虚拟小组讨论等等形式，最终输出一份相关方的登记册。

3 核心概念和发展趋势

项目整合管理的主要目的主要包括以下几个方面：

• 资源分配；
• 平衡竞争需求；
• 研究各种备选方案；
• 为实现项目目标而裁剪过程；
• 管理各个项目管理知识领域之间的依赖关系；

它兼具统一、合并、沟通和建立联系的性质，并且这些行动应该贯穿项目始终。项目整合管理由项目经理负责，并且整合管理的责任不能被授权或者转移。项目经理必须对整个项目承担最终责任。另外要注意的是，项目越复杂，涉及的相关方就会越多样化，整合的难度就会越大。

因此，优秀和完善的整合方法就显得至关重要。一些新兴的发展趋势也逐步体现出它的作用，例如：

• 使用自动化工具（如PMIS）
• 使用可视化管理工具（便于看到实时状态，促进知识转移，促进相关方参与到问题解决中）
• 项目知识管理（应对项目人员的流动性和不稳定性）
• 增加项目经理的职责（项目经理被要求介入启动和结束项目，例如开展商业论证和效益管理）
• 混合型方法（敏捷或其他迭代做法、商业分析技术--BA、组织变革管理方法等混合使用）

在游戏开发领域则表现为，使用流水线的管控工具，诸如禅道、RedMine、TAPD等DevOPS工具，项目内的技术分享和复盘会议，各种报表和报告的使用，建立项目Wiki，使用SVN或者GIT管控项目资源和协作，在瀑布的模型基础上，混合复用敏捷或者其他迭代开发模式（外包、委托、模板）等等。

4 制定项目章程

说完了核心和趋势之外，让我们回头看看传统的项目整合包含哪些方面。

下面是一张项目整合管理的概述，它总结了这个阶段的7个子过程。以及每个过程涉及的ITTO。

第一个部分就是项目章程，用游戏行业的话来说就是立项书。立项书的子过程需要用到的最关键的输入就是商业文件，如下图所示，它包含商业论证、效益管理计划。

一个典型的立项书的模板大概如下图所示：

你的立项书里需要明确的指出，要做什么、怎么做，为什么要做。要用多少钱，可能存在多少风险，工期、进度怎么安排，利润怎么分配等等。其主要目的就是给项目正名，同时给项目经理正名。不过需要注意的是，虽然立项书（项目章程）里提到了如何分配利润，但是不能把它看做是合同，因为其中没有承诺具体报酬或者金钱或者用于交换的对价。

这里还需要注意的是，项目经理应该尽早任命，并且应该参与到项目章程的制定，以便对项目需求和相关方等诸多方面有更好的了解。项目章程里还应该明确指明授权的项目经理，以便项目经理在后续的项目管理中正常开展工作。

工具和技术相对来说简单，比如专家判断（这里的专家并不是我们理解的那种“砖家”，而是指具有专业学历、知识、技能、经验或培训经历的任何小组或个人，也就是说，某种意义上而言，人人都是专家。后面我们会多次用到“专家判断”这个工具，后续不一一解释），数据收集，人际关系和团队技能，会议等等（工具和技术有很多是通用的，我们会在不同的时期详解讲解其中的一个或者多个）。

最后，我们输出最终的项目章程。这是一份由项目启动者或发起人发布的，正式批准项目成立，并授权项目经理动用组织资源开展项目活动的文件。（是项目的“宪法”，是项目经理的“尚方宝剑”）

主要包含如下内容：

• 委派的项目经理及其权责；
• 项目的目的、目标、项目的成功标准；
• 高层级的需求、高层级的项目描述、 高层级的战略和运营假设条件和制约因素；
• 总体里程碑进度计划、总体预算、整体项目风险；
• 项目审批要求、关键相关方名单、项目退出标准；

伴随项目章程一同输出的文件还有一个叫“假设日志”。用于记录整个项目生命周期中的所有假设条件和制约因素。并且这些假设条件不需验证即可视为正确、真实或确定的因素。同时还应描述如果这些因素不成立，可能造成的潜在影响。最简单的比如，国内版署版本审批需要约4个月的时间，所以版署提审到正式上线，最少需要4个月的期限，一旦假设不成立，版署被打回，可能再次提交审核，加上上线周期。

（项目章程和各个领域之间的关系）

5 制订项目管理计划

项目管理计划的原始定义为：-定义、准备和协调项目计划的所有组成部分，并把它们整合为一份综合项目管理计划的过程。也就是说，这是一份针对管理计划的计划。有点拗口，举个例子来理解。

通常来说游戏开发，分为若干个小组，策划组负责需求，程序组负责实现、美术组负责资源、质量组负责质量。那么这些组内的需要一些计划来保证内部的工作有序进行。比如，策划组出具一份需求收集、排布计划，质量组出具一份质量控制和检查计划。而项目管理计划就是管理所有的这些组成部分，形成一份综合的项目管理计划。这份计划应该具备下列特点：

这里要解释一下基准这个词。基准的含义就是大家已经一致认可的或者已经正式确定的计划，他可能包含很多种类型。比如范围基准：我们确定了要做一个5V5的Moba类型的游戏，已经和所有人通报过，并且获得了通过。这时候，自走棋的玩法火爆，现在想把MOBA玩法改了，或者在原有的玩法基础上增加自走棋玩法，都是动到了基准。按照约定，如果动了基准，只能通过实施整体变更控制过程，进行基准更新。

项目管理计划通过输入之前指定的项目章程，一些其他过程的输出（比如范围管理计划过程的输出的范围管理计划，风险管理计划过程输出的风险管理计划、风险日志等等），通过一些工具和技术，最终输出一份项目管理计划。

这里的工具比较简单，但要着重介绍一个工具叫做“开工会议”，也叫““kick-off meeting”。召开开工会议，意味着项目正式启动。

项目管理计划输出之后，会得到一份说明项目执行、监控和收尾方式的文件。它整合并综合了所有子管理计划和基准，以及管理项目所需的其他信息。如果简单的总结就是包含：10+2+3基准+3组件。

6 指导与项目管理工作

该过程为实现项目目标而 领导和执行 项目管理计划中确定的工作，并 实施已批准变更 的过程。本过程的主要作用是 对项目工作和可交付成果开展综合管理，以提高项目成功的可能性。

这里解释一个专业词“可交付成果”。可交付成果是指在某一过程、阶段或项目完成时，必须产出的任何独特并可核实的产品、成果或服务能力。通常是项目结果，并可包括项目管理计划的组成部分。比如，这个星期我们需要完成公会、背包的功能开发，公会和背包就是可交付成果。

这个阶段项目经理主要的职责为：

• 实施已计划好的项目活动；
• 管理项目内的各种技术接口和组织接口；
• 回顾所有项目变更的影响，并实施已批准的变更；
• 收集工作绩效数据并传达给合适的控制过程。

这个过程的依据（输入）非常宽泛，项目管理计划的任何组件（10+2+3基准+3组件）都可用作本过程的输入。除此之外，还有可能收到批准的变更请求。这些变更请求一般来自于实施整体变更控制过程的输出，可能是是纠正措施、预防措施或缺陷补救。

除了日常的会议（开工会议、技术会议、敏捷或迭代规划会议、每日站会、指导小组会议、问题解决会议、进展跟进会议、回顾会议）之外，一个非常重要的工具和技术就是PMIS（项目管理信息系统PMIS）。

这里的PMIS并不是一个具体的软件或者系统，而是指用以管理项目所使用到的系统或者软件。比如SVN、禅道、甘特图、Excel表格、共享文档，公司内的OA系统，协作系统等等。这里有个关键词叫“镀金”。和镀金比较类似的概念叫做蔓延。

举个例子，策划给出的需求说，聊天正常显示文字就行，然后开发实现的过程中发现添加表情也很简单，随手给加上了。这叫镀金。也就是说实现过程中自己主动增加了没有的内容。

与之对应的是蔓延，策划给出的需求说，聊天正常显示文字就行，然后开发做了一半，策划说我们想了下，还需要加个表情功能，然后大家私下达成协定，没有走变更流程，最终上线的聊天功能既有文字也有表情，这个叫做蔓延。

无论是镀金还是蔓延都是 不允许 的，请一定切记。这个在后续的范围管理里面会再次提到。

这个过程输出的第一个内容就是我们的可交付成果。第二个是工作绩效数据，第三个叫问题日志。

工作绩效数据是指在执行项目工作的过程中，从每个正在执行的活动中收集到的原始观察结果和测量值。比如某个版本交付验收的时候，QA一共提出了200个BUG，这个就叫做绩效数据。由绩效数据进一步分析之后，QA负责人说，这个版本BUG比较多，主要是因为临时改了一些需求，开发人员请了几天假，匆忙赶工导致的的，这个叫做绩效信息。由不同的绩效信息进行汇总分析，得出一份具有起因、经过、结果、解决方法等内容的文件叫做绩效报告。后面还会详细讲解三者之间的关系。

这个过程还有一个重要输出叫做——问题日志。主要用来做记录和跟进所有问题的项目文件。它在该过程里面首次创建，但是在整个项目生命周期应该随同监控活动更新。它需要包含：问题描述、责任人和解决期限。比如，BUG修复的过程中，某个BUG被修正了N次仍然存在问题，就需要记录在问题日志里，找出根源，以便后续不会再发生。

最后一个输出叫做，变更请求。它是关于修改任何文档、可交付成果或基准的正式提议。可以是直接或间接的，可以由外部或内部提出，可能是自选或由法律/合同所强制的，可口头提，但必须书面记录。

它有两个目的，1是维护基准，2是修改基准。如果是要修改基准，则主要走变更管理过程。

7 管理项目知识

这个过程的核心是使用现有知识并生成新知识，以实现项目目标，并帮助组织学习的过程。主要是指利用已有的组织知识来创造或改进项目成果，并使当前项目创造的知识可用于支持组织运营和未来的项目或阶段。本过程需要在整个项目期间开展。

这里要说明一下显性知识和隐形知识。大多数的人应该会有一些体会，比如有些东西叫“妙不可言”，“可意会而不可言传”，这部分就叫隐形知识。女朋友/老婆打电话给你，车开不动了怎么办？你说，你先看下是不是电瓶亏电了，是不是没油了，是不是水箱过热了，是不是没踩离合器，是不是没挂挡，是不是没松手刹？她会问你哪个是离合器。在这个情境下，你所有的知识都是隐形知识，它需要你根据经验来判定，比起用嘴巴来说，跟在你后面看一遍反而学的更快。

总结一下，就是显性的知识，我们定义为信息。隐形的知识，我们定义为知识。信息的好处是可以记录分享，但缺点是不同人会产生不同的解读，理解上会有偏差。而知识很难编撰出来，但是通过交流和互动很容易让双方理解一致。

在游戏开发的情景下，虽然策划提供了策划文档，但仍然要开评审会，以期待大家能够理解一致。

这个过程输入包括项目文件，看下项目文件包括哪些：

这里面几个比较重要的文件为：

• 经验教训登记册：提供了有效的知识管理实践。
• 项目团队派工单：说明了项目已具有的能力和经验以及可能缺乏的知识。
• 资源分解结构：有助于了解团队拥有和缺乏的知识。
• 相关方登记册：有助于了解相关方可能拥有的知识。

另外的一些工具和技术也比较简单，稍微总结一下：

它的输出就是经验教训登记册，在游戏开发中我们一般叫WiKi。

8 监控项目工作

这个过程持续在项目整个开发周期内，它需要跟踪、审查和报告整体项目进展，以实现项目管理计划中确定的绩效目标。主要作用就是让相关方了解项目的当前状态并认可为处理绩效问题而采取的行动。同时根据成本和进度预测，让相关方了解未来项目状态。它需要输出出工作绩效报告（老板只需要看报告）。

这个过程很好理解，就是要监控项目的各种基准，通过进度预测、成本预测等方式识别风险，或者必要的变更。还记得前面说过的绩效信息嘛，是有绩效数据和各个项目管理计划组件比较分析之后得到的一些小结论。把这些绩效信息输入进过程，然后使用一些分析手法，最后得出绩效报告。

游戏开发里面一般表现为了，总结版本内容和问题，以邮件方式发送给对应处理人，并抄送给老板。

监控过程的数据与分析工具大概如下：

这些关键词，我们会在后面的质量管理里详细介绍。

但在游戏开发中其实成本、进度没有那么严苛的规定。它不像工程项目、或者其他涉及甲方乙方的合同项目。多少钱就干多少事，多出一天工时，项目方就要少一些利润。这个我们会在后面的采购管理里讲合同类型的时候提及，那时候大家可以可以比对比对。

游戏开发内涉及合同的，应该美术或者资源外包会多一些，但基本都是总的总价合同。

9 实施整体变更控制

这个过程非常非常重要，不管是在传统的项目管理还是游戏开发中都非常非常重要。很多很多失败的项目都是因为变更控制把握不好，比如老板的拍大腿，策划的拍脑袋等等行为。未来的项目管理，请记住这5个步骤：

记住，变更的请求可以由任何人发起，比如某个开发说，策划老是在我快完成功能的时候，加一个小调整，要求策划提需求先找PM或者核心组通过。某个策划说，程序老是不自测就提交代码，导致我这边验收一堆问题，要求开发先完成自测。某个QA说，你们老是调整了功能不修改文档，导致我测试用例总是过时，你们下次再调整请先更新文档。

所有人都可以提请变更，但是它需要得到相关方的充分评估，然后提交责任人审批。这里有一个核心的组织叫做"CCB"，它的全程叫“变更控制委员会”。它不是一个固定的组织或者个人，而是一个正式组成的团体，负责审查、评价、批准、推迟或否决项目变更，以及记录和传达变更处理决定，简单来说就是有权批复变更的组织。比如你要求开发先自测再提交，开发负责人觉得很合理，于是批准并要求以后的开发必须先自测完成再提交。假如某个策划说，我们想先让开发出一版效果，看了之后再调整需求，开发负责人说“呸”，然后拒绝了这个变更请求。

不管结果如何，项目经理都要更新变更日志，并且如果变更通过，还要更新项目管理计划。最后一步也是最重要的一步，通知给所有相关方。A开发被要求自测才能提交，通过后，会影响到所有的开发，所以所有受影响的人都应该要知晓这个变更。

这里还要注意几个点，实施整体变更控制过程贯穿项目始终， 项目经理 对此负最终责任。应确保只有经批准的变更才能纳入修改后的基准中。每项记录在案的变更请求都必须由一位责任人批准、推迟或否决，应在项目管理计划或组织程序中指定这位责任人，必要时，应由变更控制委员会（CCB）来开展实施整体变更控制过程。

10 结束项目或者阶段

项目结束有两种原因，第一个成功了，第二失败了。不管哪种方式结束，都应该按照以下流程走一遍：

这里的庆功会，成功了叫庆功会，失败了就是散伙饭。

这个节点项目经理一定要硅谷项目管理计划，确保所有项目工作都已完成以及项目目标均已实现。如果是提前终止的话，还需要制定程序，来调查和记录提前终止的原因。

项目章程里会记录项目成功标准、审批要求，以及由谁来签署项目结束。然后对照商业论证看看是否达到了经济可行性研究的预期结果。对照效益管理计划，看看是否达到了计划的效益。

最后输出最终成果，并且移交成果。游戏开发的话就是把游戏投入运营。最后用一份最终报告来总结项目绩效，大家该开除的开除（有可能），该涨薪的涨薪。

最最后，要更新组织过程资产，把当前项目的历史信息和经验教训存入经验教训知识库，给未来项目使用。

这个章节内容非常非常多，可能需要仔细消化。