2 影响项目立项的外部环境因素是什么？人人都是项目经理系列（第2/13篇）

本章的内容相对而言较为简单，大部分开发人员在大部分时候都不会接触也不会关心。但是对于项目经理、制作人以及高管、老板而言却非常重要，因为它决定项目的进展方向和形式，甚至决定能否项目能否成功。

任何项目的开展都会受到当时所处的环境影响，游戏开发也不例外。这些影响有些是好的方面，有些是不好的方面。作为项目经理，首要的任务就是能尽可能多的找出这些因素，然后登记在册，以供后续的开发工程中随时查阅，以及及时解决和规避即将到来的问题。

这些因素主要来源两大方面，事业环境因素和组织过程资产。

（项目影响）

1 事业环境因素

事业环境因素源于项目外部（往往是企业外部）的环境，它可能会对整个企业、项目组产生关键影响。一般来说项目团队是无法控制事业环境因素的。它们会对项目产生各种限制、影响、或者指令型的条件。

具体表现为很多方面，比如：

• 市场条件：比如，你想在国内市场做MOBA类的手游，那么你得问问王者荣耀同不同意。你得知道MOBA类型游戏的市场份额，近期乃至未来一段时间的市场走向，自己的竞争优势，以及最重要的商业模式。
• 法律限制：也很好理解，10年做棋牌游戏和18年做棋牌游戏就有本质的区别。再比如，防沉迷、实名认证、健康忠告、版署版号、软著等等。
• 社会和文化影响 :这一般会涉及游戏发行地区的文化。有很多东西是当地禁止触碰的内容，比如国内的领土、政治；美国的种族；中东的宗教等等。
• 财务：老板能给你支持多少钱进行项目研发。它会决定你的项目规模和工期。而规模和工期又会进一步限定游戏的玩法和题材。
• 物理或者地理因素：大部分的游戏公司都开在发达的一级城市，因为资源和人才获取容易。

除了这些因素之外，还有很多很多的因素制约着项目的开发，比如内部赛马机制（腾讯）、比如商业数据库，学术研究、政府或者行业标准等等各种外部因素。

除了这些外部条件之外，项目组内还可能存在一些内部因素，比如：组织文化、结构和管理水平（典型的就是领导人的风格）；信息技术软件（DEVOPS 研发流水线）；资源可用性（一般是指人力资源）；员工的个人能力、项目能获得的技术设施（比如，电脑配置、权限）等等。

这里面，比较难以理解的可能是资源可用性。这个我们放在后面组织结构里面解释。

2 组织过程资产

组织过程资产源于企业内部，可能来自企业自身、项目本身、其他项目或它们之间的组合。它主要执行该组织特有并且正在使用的计划、过程、政策、程序以及知识库，这些内容会本质的影响对具体项目的管理方式。任何项目的成员都可以对组织过程资产进行必要的更新和增补。

这些官话要怎么翻译的简单易懂呢？其实就是，你现在项目正在使用的习惯，开发计划，人员之间互相配合的方式，以及在过往过程中积累的经验，教训、踩过的坑，喷过的人，打过的架，闹过的矛盾都是组织过程资产。

它甚至不止是当前正在用的，也可以是以前项目遇见过的，使用过的，解决过的都可以当做组织资产。

如果细分的话，它大概可以分为：

• 工件、实践或者知识。
• 经验教训和历史信息。
• 完成的进度计划、风险数据和挣值数据。

这里比较难理解的名词叫“挣值”。这个大家可以先忽略，后面的章节会有对此专门的阐述。现在粗略的可以理解为判定项目实际进度和预期进度之间偏差的一种数据。

除了上述的类别之外，它还包括 过程、政策和程序的类别，大致为：

• 指南和标准（比如项目开发的边界任务，导表究竟给策划还是程序，美术资源的规格检查交给程序还是美术？）
• 模板 （这个很好理解，就是项目里统一使用的各种文档、报表等模板）
• 供应商清单和合同类型（美术或者音乐外包的执行方式、导量、发行的分成）
• 变更控制程序、组织对沟通的要求

这里要重点讲一下第四条，变更控制程序、组织对沟通的要求。我认为这点要远远重要于其他三点。

前一章节，我们讲过了瀑布类型的开发方式，它是一种预测型的开发方式。这必然会伴随着预测失败，中途调整需求的情况。而变更控制程序就定义了发生这些情况之后要如何处理。涉及的人、事以及解决流程。这个在后面的章节会更进一步，更详细的讲解。

组织对沟通的要求，这个内容也很复杂。PMP里的十大知识领域中有一项就是沟通。这会专门开一个章节来讲述项目的沟通。但总的原则应该是当面沟通>视频>音频/电话>群>邮件>公告/论坛。

当然，除此之外，还有一个类别叫组织知识库，它包括：

• 配置管理知识库（游戏开发里每个功能表的配置情况，以及其他）
• 财务数据库（跟一般人没关系，项目经理、制作人和公司对账）
• 测量指标数据库 （比如，服务器能够承载多少人，导量的转化率，客户端同屏显示多少人等等能量化的指标）
• 经验教训知识库
• 以往项目的档案

这里面最重要也是最常用的应该就是后两项了。经验教训会记录项目碰到的每一个问题，以及解决人员和方式。当再次碰到类似问题的时候，可以快速查阅并制定解决方案。当这个项目终止之后，它会变成最后一项，以往项目的档案。

3 组织结构

除了以上两个因素之外，组织结构也会大幅度影响项目的开发方式和进度。

组织结构并非是大多数公司里的部门架构，部门架构属于项目资源的范畴，这在后面项目资源的领域会重点介绍。组织结构可以理解为，项目经理在组织内的职责、终责和职权的分配情况。

明确的组织结构有助于项目经理有效的行使权力、影响力、能力、领导力以及政治能力来成功完成项目。从项目经理的职权强弱来分类，从弱到强分别为：

• 职能型（集中式）
• 弱矩阵
• 平衡矩阵
• 强矩阵
• 项目型

这里我们着重讲解两个极端，即职能型和项目型。其他三个在中间插值理解就行。

1 职能型

（职能型项目经理）

这是最弱的项目经理，一般是由联络员兼任。也可以理解为它是一个兼职的项目经理。这里可以举很多例子来阐述，但我相信小伙伴都很聪明1个例子就能明白。

我们这个系列的名字叫《人人都是项目经理》，它不是一种噱头，而是任何人都有可能在某一个时刻担任项目经理的职责。当然前提是你要搞清楚项目经理究竟是一个什么样的角色。这个内容我们会在下一章节讲述。

回到刚才的内容上来，我们看看职能型的项目经理怎么工作。

A是客户端人员，在做某个任务的时候，发现需要额外的服务器数据支持。他报告了客户端主程，然后客户端主程了解分析了需求之后，联系了服务器主程，服务器主程安排了B跟A对接，完成该任务。

对应上面的图可以看到，职员A此时是一个兼职的项目经理，由他发起，最终解决了问题。而客户端主程和服务器主程分别对应了职能经理A和职能经理B。

这里大家可以发现，项目经理的职权是远远小于职能经理的。所以人人都是项目经理系列，A自己都没发现自己当了一次项目经理。

总结一下，职能型的特点：

• 是兼职的项目经理
• 职业路径清晰，但横向联系薄弱

2 项目型

（项目型项目经理）

这是最强的项目经理模式，大多数的游戏开发都采用这种模式。项目经理对于项目事物拥有绝对的控制和话语权。能够决定人、事、物的流程和走向。所有的人员决策信息都汇总至项目经理，并由他最终拍板。

很多较小的项目不会常设项目经理职位，一般由制作人+PA共同替代。制作人决策，PA监督。

这里也总结下项目型的特点：

• 全职的项目经理
• 控制度高
• 重复配置
• 无家可归

这里需要解释一下后两个特点的含义。

重复配置是指每个项目都需要一个全职的项目经理，从人力资源上来说就需要对不同的项目重复配置项目经理这个职位。但开发过游戏的小伙伴应该知道，这是必不可少的，非常少见一个项目经理管理多个项目，但是多个项目经理管理同一个项目却比较常见，尤其是大型项目，一个项目经理完全配不过来。从管理学角度来说，每个人管理的极限是6-10个人，所以常规的游戏开发部门，项目经理协调主程（们）、主策、主美、主测试等职能经理，共同完成对项目的管理工作。

无家可归的含义是指，项目一旦终结，项目就需要解散，项目经理和成员就会在这一阶段失去目标，变成“无家可归”。当然实际上，肯定不会项目终结就被解聘变成真正的无家可归，大都会投入下一个项目的工作中。

除了以上2个极端之外，其余还有3个矩阵型的组织结构。

• 弱矩阵型

• 平很矩阵型

• 强矩阵型

这三个从弱到强指的是项目经理的职权。只有最后一个强矩阵会出现特殊的“项目经理的项目经理”。

每种方式都有好处和坏处，矩阵的好处就是资源利用率高，有利于跨部门协作。而坏处就是，领导太多，管理难度大，资源争夺厉害。

这里再举个例子，比如公司有一个美术中心，那么美术中心的老大就是职能经理。公司开了3个游戏项目，每个项目都有一个项目经理，这些项目经理都要争夺对美术中心人力资源的优先权。而对于处在该美术中心的个人来说，他在某个或者某段时期可能需要面对多个“领导”的问询和关照。

当然有人可能会说，统一提需求给美术中心老大不就行了吗？当然可以，那就要看你的组织结构是属于矩阵型的哪一种了。

最后附上一张项目特征图。

4 PMO（项目管理办公室）

上图出现了一个奇怪的名词——PMO。那么，这最后一部分我们讲讲PMO是什么。

把缩写展开就是项目管理办公室。这在很多公司都是没有的职能部门，只有公司到了一定的量级，项目开展多到一定程度，并且高层有相关管理的意识，才会出现这个组织部门。

它不参与具体的项目开发，但是会指导项目经理如何去统筹、管理项目。并且从更高的维度去提供资源、方法论、工具和技术共享等高层级的项目活动。

PMO根据对项目的强硬程度可以分为以下几种类型：

• 支持型 基本不干涉项目开发，从支持的角度出发，你可以把它当做是一个顾问，或者资源库。
• 控制性 支持+要求服从 即会制定项目管理框架或者方法论，并要求使用特定的模板、格式和工具。当项目遇到和PMO发布的规则想抵触的时候，要求项目整改以符合PMO的规则。即它是一个中型的控制，不会干涉具体项目做法，但是要受限于一定的条件或者框架。
• 指令性 指令性的PMP会直接派遣项目经理管理和控制项目。注意 PMO组织本身并不会控制项目，控制项目的仍然是项目经理，只是改项目经理需补单要遵从控制型的框架，还需要想PMO报告。

我遇到过的大部分PMO始于控制型，即基本不干涉项目内容，满足PMO规定的要求即可。但是在一些攻坚的项目或者重点项目中，还是有可能转为指令型的。

项目管理办公室会承担整个组织范围内的职责，在战略支持、调整和创造组织价值方面发挥重要的作用。PMO从组织战略项目中获取数据和信息，然后进行分析、评估如何实现更高级别的战略目标。

另外PMO可以一次支持很多个项目，并且这些项目之间的关联性没有硬性需求，即可相关，也可不相关。

最后做个PMO职能的汇总：

• 管理共享资源，识别和制订最佳实践和标准。（管理功能）
• 通过项目审计，监督对标准的遵守程度。（监督功能）
• 制订和管理政策、程序、模板，提供指导和培训。（指导和培训功能）
• 协调“跨项目”的沟通。（协调功能）

项目运行环境旨在理顺将要开始的项目内在外在的各种关系，它是项目的前置性的、侦查性的过程。如果在前期的梳理过程中发现无法按照预期的过程和收益走下去，那么很可能会终止后面的工作。梳理的内容很多时候会变成商业论证的一部分，也有可能成为项目章程的一部分。

这些等我们后面讲述ITTO的时候，会详细阐述。

下一个章节，我们介绍项目经理本身。