整个项目管理实践部分，分为立项-启动-版本循环-适应变更-迭代循环-收尾。 因为内容量很大，所以本文主要介绍 立项和启动 两个部分。

敏捷项目管理实践，是 以一个实际的项目来和大家分享下，我是怎么运用敏捷思维来做项目的。

因为当前这个项目还在研发期，也处于保密期，所以更详细的信息也不便于透露，只能说下，我们的团队规模是100+。一旦涉及到百人团队，整个管理就要成体系化。

因为项目经理这个时候凭借一己之力，是没有办法去很好的管控的。这个时候，就需要搭建框架和赋能，让团队可以被赋能在框架之内运转。

因为一直在讲的是运用敏捷思维做中大型项目，所以我们团队其实并没有完全的使用敏捷的 某种方法论。

根据我自己的理解和团队实际的情况，我总结梳理了下我们项目的整个项目管理过程，分为立项-启动-版本循环-适应变更-迭代循环-收尾。

接下来就来分别介绍一下，每个过程应该怎么做。

一、立项

关于立项，分两种情况来说：

第一种情况，未参与立项过程，直接接到老板分派的项目。

这是非常常见的一种情况，我们很大一部分项目经理并未实际的参与立项，大都是接到老板/领导安排的一个项目，就开始正式启动了。因此这里先聊一聊，这种情况下，项目经理专业的做法是怎样的。

项目经理在开始负责一个项目的时候，不是一上来就开始着手安排工作的，更不要接到项目时，和老板讨价还价，或直接拍胸脯说什么时候做完。

而应该是在项目正式启动之前，需要花大量的时间去详细了解项目的背景。作为项目经理，必须要清楚自己负责的项目是一个怎样的项目，这点非常关键。

当了解清楚项目的背景之后，只能说项目经理对项目是有了一个清晰的认知。这个时候，还需要和管理层去对齐预期。当然，因为项目一切都才刚刚启动，这个预期初始是不准确的，但为什么还需要去对齐。

这是因为，项目经理需要清楚的知道，部门或公司，以及管理层为什么要花这么多成本去做这个项目，他们的期望是什么？这些期望包括但不限于：做这个项目的真实目的；战略目标；第一个demo版本时间；阿尔法和贝塔版本的重要里程碑；最后上线的时间。等等。

当详细了解清楚了项目的背景和管理层的预期之后，这是有助于我们更好的去制定目标，并且在制定详细规划和执行时有的放矢。

所以，对于第一种情况，未参与立项阶段，项目经理专业的做法就是要花大量的时间，去详细了解清楚项目的背景、老板为什么要做这个项目、核心管理层的预期是什么，然后根据获取的这些信息，梳理给出整体的规划和目标，再和项目核心管理层沟通对齐。

第二种情况，有机会参与到整个立项的过程。

当项目经理有机会参与到立项的整个过程时，要清楚的知道，立项的整个过程，三件大事： 设 置激动人心的目标、论证项目价值（商业论证），还有做出 MVP 版本。

1、设置激动人心的目标

目标设定被认为项目成功的关键因素。激动人心的目标能让项目团队了解产品的价值，建立共同的方向并激发团队士气。

换句话说，从公司到部门，到项目发起人，到整个项目的核心管理层，都需要理清楚，为什么要投入成本做这个项目。

那么对于目标的设定，有 三个重要衡量要素：

（1）重要性

这是来自组织的要求。体现在为客户创造价值。为客户创造价值，回答的是我们的关键客户/用户是谁？我们为客户/用户提供什么样的价值主张？价值主张就是客户/用户选择我们而不选择其他人的原因。对于产品或项目来说，就是产品或项目的核心卖点或竞争力是什么？

公司，部门，到项目组，投入成本做一个项目，总不能是为了做一个项目而做一个项目，做这个项目一定是有它的核心价值所在的。哪怕是一开始模仿或借鉴他人的产品，也要做出差异化，在细分市场找到竞争力。

（2）明确性

是团队成员成功的标准。体现在个体实现价值，回答是组织对大家的期待是什么？大家的各自主要价值是什么？对于个体价值实现，需要回答3个问题：组织对你意味着什么？你对组织意味着什么？在他人眼中你对组织意味着什么？

也就是说，团队参与到整个项目中时，最终这产品做成了，在行业里面是一个怎样的定位？团队成员是否也会成为行业的牛人或者专家。或者至少团队成员经过这个项目的历练，是否可以取得组织期望的成长和进步。

（3） 挑战性

团队理想未来的目标。聚焦的是回报体现价值。 回答的是成功时，将获得怎样的回报？ 回报是否具有较强的激励性。

项目的成功也要给团队带来收益和价值，不能说团队辛辛苦苦做完了一个项目，结果项目收益，团队却获取不到预期的收益，那对于组织的稳定性来说，也是一种伤害。

所以，设置激动人心的目标，应该是包括三个维度的。因为保密项目的关系，这里就不给大家展示我们项目的目标了，但最终大家如果要去设置这个目标，可以从这些维度出发去考虑。模板参考如下：

一款xxx的产品，具备xxx的核心竞争力，预期的流水是xxx；

产品是行业的标杆或者xxx，团队成员是各自领域的行家，牛人；

成为一个有x，有x，有x的高效能团队，具体怎么定义高效能，可以根据实际情况增加定语。

2、论证项目的价值

有了激动人心的目标，并不代表着项目可以马上启动。如果项目团队中，发起人或者项目高管有直接开始进入到论证，则是更好，说明真正启动一个项目的时候的慎重，而且项目的重要性也不言而喻。但假设作为项目经理的我们，在接手这个项目时，团队并没有进行论证，则作为高阶的项目经理需要建议项目高管对项目的价值再次进行论证。

那么如何论证项目价值？有三个维度：是否值得做、是否有能力交付、是否能实现收益。

（1）项目是否值得做

以19年我们开始做的这款游戏项目为例，当时准备接手这个项目的时候，前期是做了大量的论证工作的。当工作室总经理确定要做这个品类的游戏时，并没有直接让团队开始做设计和进入到研发阶段，而是做了大量的论证，比如一系列的工作：

团队内部对市场各个品类的游戏进行方案的梳理和设计；

团队内部基于当前这个品类游戏进行SWOT分析；

团队内部多次开会讨论，最终明确品类的细分方向；

而后开始进行市场的用研（CE），分析这个游戏品类的市场，分析IP的价值，分析IP和这个品类的融合；

进而再对该品类细分领域进行商业化的推算；

除此之外，还有一个重要的点，就是投入成本和预期收益进行对比（ROI），最终才落定项目立项和启动。

对于这些，在游戏项目中来说，可能大都是制作人和策划要做的事情，但今天谈及这个论证点时，是期望作为项目经理，可以积极的参与其中，也可以基于自己对业务的理解献言献策。

（2）项目团队是否有能力交付

关于这个维度，大部分项目经理应该都是有实际参与其中的。

作为一名项目经理，我们都需要清楚的是，项目是立项启动了，有它的价值所在，但必须要思考的是，团队得有能力交付才行。

比如老板觉得当前有一个项目非常值得投资，但部门内本身就已经有很多其他事情在做，日常的运营资源就已经饱和了，几乎没有人力资源可以释放出来投入新项目里面，这样一来，是很难在预期时间内交付的。

再比如，团队之前一直做2D项目，但这个项目是一个3A大作，在交付方面则是一个大风险，因为没有3D方面的人才，要承接这个项目，就得想办法解决这个问题。

（3）项目能实现收益

项目实现收益这个维度，以游戏项目为例，大多是产品（策划）团队对项目正式上线后，其商业化进行推演。

要根据一些数据模型，去推演结算得出上线后的DAU、MAU，付费ARUP，以及每个月大概的流程和全年的流水，包括未来三年的流水。

然后结合实际团队投入的成本，估算实际获得的利润，并计算出利润率。

整个过程，都是在计算ROI，也即投入产出比，就等于说，投入了两个亿的成本做这个项目，结果最后成本都收不回来。那做这个项目的意义又何在呢？

3、做出MVP

MVP是精益创业里面的概念，意思是最小可行性产品（Minimum Viable Prouduct）。

最小可行性产品，指的是一个产品的雏形，是指将创业者或新产品的创意用最简洁的方式开发出来，可能是产品界面，也可能是交互操作的胚胎原型。

MVP有四个特点：体现了项目的创意；能够测试和演示；功能极简；开发成本最低。

以游戏项目为例，MVP我们时常也称之为demo版本。那具体怎么来确定MVP的范围和目标呢？

（1）打靶法确定最小范围

要做出MVP版本，首要的必须是确定最小范围。打靶法是最常用的一种方式。打靶法就是把一定要做的内容放在靶心的位置，其他可做，可不做的则在此之外。

这点 在敏捷scrum方法论里面，也有专业术语，叫做 MoSCoW 优先级排序法，是项目管理定义范围、确定功能质量、变更管理中常用的工具法则，以便项目团队对项目中的每个需求交付的重要性和紧急性达成共识。 M—o-S-C—o-W，是四个优先级别的首字母的缩写，再加上O使之能够形成便于记忆的名称——MoSCoW。

其中 Must have： 必须有。 如果不包含，则产品不可行。 Must Have的功能，通常就是最小可行产品（MVP）的功能。

怎么来确定这个Must Have功能呢？如果有竞品，最高效的方法就是体验竞品的前30分钟，把涉及到的重点系统功能都记录下来，然后和产品团队一起再次聚焦Must have功能。但如果没有竞品，那就只能采用逐级打靶法了，根据产品团队给出的需求框架，逐级的精确Must have功能。

（2）投入最少的人力资源，快速开发

Must have功能确定之后，也是对齐确认最少可投入人力资源的情况。很多时候，对于项目团队来说，人员不一定是可以全部快速到位，往往最开始的时候，只有一部分核心骨干，这个时候，明确Must have功能之后，核心骨干就可以直接参与到功能需求的实现中，以最快的速度实现MVP。

（3）团队内部确认MVP

MVP功能开发完成，是需要得到团队内部的一致认可，至少是要在核心管理团队中达成共识，一致觉得MVP已经达成，可以代表项目的核心意图。

（4）向高层汇报

MVP在团队内达成共识之后，最终确定是否立项，需要向公司高层汇报，以最终确定是否可以立项。

以我们公司为例，绝大部分的项目，都是需要走这个流程的，除非是高层直接钦点的项目，但MVP的过程也少不了。

二、启动

项目正式立项之后，就进入到启动阶段了，在启动阶段，重要的几件事情：

搭建项目管理体系、落实需求规划、明确版本管理流程、开好项目启动大会。

1、搭建项目管理体系

小规模团队的时候，项目经理一个人是可以沉浸到团队的细节中去，帮助团队解决具体的困难。但当团队达到一定的规模时，项目经理则需要根据项目和团队的特点，搭建更加适合的项目管理体系，或者受控环境。那么具体来说：

（1）识别干系人

项目启动之 初 ，识 别干系人是必备步骤，作为项目经理 ，得知道团队成员中各个人员的情况，尤其是核心管理层和核心骨干。

对于干系人登记造册，有很多相关的工具。登记干系人的情况不仅仅只是登记他们的姓名，职位和角色，更重要的是通过沟通交流，了解他们的需求和期望，判断对项目的影响，以便在后续重点管理。

（2）搭建团队组织架构

当然，识别干系人不仅仅是登记一个册子，更重要的是明确权责，搭建团队组织架构。项目的职能组织架构是下图的弱矩阵架构，这种架构是组织的需要，但没办法很好的应用到项目管理体系中。

所以，对于中大型项目团队来说，有一个非常关键的步骤，就是要根据项目的实际情况，把项目分为不同的领域群，类似于把一个大项目进行有机的切分，进而搭建一个更加适合项目快速推进的组织架构。参考如下图：

这个有机的切分是有讲究的，不是随便的根据系统功能模块来进行切分的，而是要根据整个项目的内在逻辑关系来进行划分。

当划分好了这个领域群之后，就可以根据不同的领域，分别确定对应的产品、前后台开发、美术和测试负责人。

尤其是产品负责人，要能够对该领域群所涉及到的系统功能有全局观和良好的把控能力。因为产品是源头嘛，所以需要对该领域的需求非常了解，或者一开始至少有这样的一个能力。对于产品领域群的负责人，是在需求审核环节要起到非常重要的效用。

那么这里还有一点项目经理要持续关注的就是，领域群的负责人并不是一成不变的，随着项目的推进，发现负责人不合适，则可以和核心团队沟通进行更换，以便更换的为项目服务。

划分领域群的目的，是为了接下来各版本持续迭代，持续交付时，更好地组建特性小组。这点在后面会详细说明。

（3）建立沟通体系和机制

我们都知道，在PMBOK管理体系中，项目经理是沟通的桥梁，这对于小规模团队来说（比如小于40人），基本上也不会成为瓶颈。

当团队规模大于40，达到百人，乃至更大时，整个项目的沟通，运行，不能完全凭借项目经理一个人的上传下达。这个时候，就需要建立项目的沟通体系和相应的沟通机制。

关于沟通机制，一个项目中，是有多个维度的，比如对上，对内，对外，有正式的和非正式的。以我们项目在运转过程中的项目信息沟通同步机制为例：5级企业微信沟通体系。

这个企业微信群，是我们项目信息日常沟通的一个机制和体系。这5个群的人员、功能效用都分别不一样，但我们通过这5个企业微信群，使得整个项目信息在推进过程中得以顺畅的沟通：

1）核心管理群： 人员主要是高层管理者、项目组的制作人、各小组的leader、项目经理； 主要的效用是项目的重要决策，重要里程碑目标的同步，让高层管理者及时的掌握项目的进度和信息。 这个群基本上不会讨论具体的方案。 建立主要一个核心管理群，还有一个重要的效用，就是获取高层管理的支持和肯定。 一旦获得这方面的肯定，项目经理就会把这个信息及时地同步到项目的研发大群。 比如某个大版本发布之后，项目经理汇总项目的数据同步到高层管理者，高层领导看到之后，认可点赞，那这就是非常积极的反馈。 当 把这个认可，点赞同步到项目大群时，团队成员看到之后也会备受鼓舞。

2） 工作统筹群： 人员主要是项目组制作人、各小组的leader、项目经理、美术项目经理、测试经理。 这个群 侧 重点是项目主要事项的一些沟通，讨论，或者是一些重要会议线下当面沟通对齐之后，项目经理汇总信息同步到这里，让各主要干系人都清楚项目的信息和结论。 如果是一些需要高层领导知道的事情，经过大家的确认之后，再同步到核心管理群。（运行一年后，这个群逐渐被FO群所替代了）

3） 项目研发群：项目组的所有成员。这个群主要是项目经理同步项目的整体目标、里程碑计划、版本计划，项目阶段性成果，或者是项目的信息，以及项目全员的一些通知。

4） 项目特性群：项目制作人、各leader、项目经理、测试经理、各特性负责人、特性成员。特性群是对于中大型项目来说的，需要进行拆分多个特性来进行管理。那这个群的目的就是各特性线下的版本计划，项目的信息，包括测试过程中的沟通和进展同步

5） 功能模块群：项目经理、各leader、测试经理、各特性负责人、模块成员。功能模块群就是具体到各个功能模块的开发，模块成员的沟通交流，联调及问题的反馈。

这个沟通体系的建立，是自上而下，也是自下而上的信息沟通闭环。

还有对上的沟通机制，我们在项目启动之初，就确定了每周五下午2点，开项目周会，周会的议题重点是版本的整体进度同步、下周的计划安排、问题或风险、产品相关工作进展、美术进度同步和本周资源产出展示。

以及项目到推进到一定阶段之后，也即有可玩的版本，确定每周三为核心管理团队集中体验版本。这个机制一来是重点体验上周的版本输出情况，二来是讨论一些重要的事项。

（4）搭建知识共享平台

对于一个新项目来说，组织过程资产的沉淀，也是重中之重，需要和项目推进同步进行。我们内部有一个强大的TAPD工具，可以直接创建wiki。所以在项目正式启动的时候，就搭建好了知识贡献平台，设置了各个角色，各角色按照模块将项目过程的相关知识都沉淀到wiki，便于积累和查阅。

2、做好项目全局规划

项目在启动阶段，重要事项之二就是做好项目的全局规划。有全局的规划，才可以更好地进行阶段的管控。具体来说：

（1）梳理需求框架

梳理需求框架，这部分可以和识别干系人，明确职责同步进行，因为这部分的工作，主要是产品（策划）团队要去做的。

项目正式启动之后，项目经理需要要求产品（策划）团队把整个需求框架梳理出来，这和scrum里面提的梳理产品待办事项列表是一个意思来的。

这个梳理出来之后，可以让团队对整体的功能需求有一个全貌。有两种表现形式，左边的思维导图用于规模相对较小的项目，思维导图一目了然。右边是大项目，系统功能和子系统功能，通常都是以百记的，采用在线表格的形式。

（2）明确需求优先级

在梳理需求框架的时候，其实也是明确需求优先级的过程。表格的优势也体现在这里，可以直接在具体工作拆分的后面加上优先级这一列。优先级的明确，目的不言而喻，就是进行项目全局规划的时候有的放矢。

（3）进行项目全局规划

一个大的项目，在具体落实的时候，一定是分阶段管理的，所以需要把一个大项目，拆分成多个版本来进行管理。参考如下图：

之所以要对项目进行一个全局规划，一方面是便于分阶段管理，另一方面更重要的是对大目标进行分解，分解的同时，也是进一步评估可能的风险，存在的瓶颈和关键路径。除此两点以外，还可以在这个过程中，更细致地对 人力进行盘点。

具体怎么来做全局规划呢？项目经理在初始做规划的时候，一个很重要的依据就是来源于对项目背景的详细了解以及管理层的预期。项目经理要避免自己独自拍脑袋地去做一份项目的全局规划，这其实是不专业的。

我认为比较好的做法就是先有第一步，详细了解项目背景和管理层预期，根据这个来指导做第一版的规划。因为这样可以节省在对齐整体规划时的大量时间。

假设一开始没有和管理层沟通对齐预期，按照自己的理解去做了一份规划，结果和管理层去沟通的时候，发现和预期偏差很远，再回过来进行调整，是需要花费更多的时间的。

反之，先了解预期，根据所掌握的信息和管理层的预期，结合自己的专业，第一版规划做出来之后，和管理层沟通对齐，有细节的调整则微调，没有大的问题，整体规划就达成共识了。

这里有一点要特别强调，在做整体规划的时候，项目经理需要和产品负责人进行深入的沟通和交流，确保彼此的理解一致。项目经理不能完全的去拍个脑袋做一份规划，哪怕是有管理层的预期做支撑。

（4）制定整体里程碑计划

整体版本规划输出之后，就可以根据初步的估算，做出整个项目的里程碑，这个里程碑是比较粗略的，主要是让项目团队心里有一个预期，尤其是可以初步了解到项目进行中的几个关键里程碑。比如说，第一个重要节点版本，第一个垂直切片版本，第一个完整测试版本和最终上线版本的时间节点。

这个是对整体项目的推进有一定的指导意义的。当然第一版是粗略估算，那么后续就是根据实际版本跑的情况，变化的情况，及时调整更新，并同步给项目团队。

3、明确版本管理流程

持续迭代，持续交付都是以一个个版本来进行的，那么整个项目的研发流程，版本的开发模式以及版本合流就显得尤为的重要。

（1）规范项目研发流程

下图是以某一个迭代版本目标为例，从下图中不难看出，整个项目研发流程的定义是比较清晰的，而且也应该要界定清晰。

中大型团队，如果没有一个比较清晰的研发流程，团队间各成员间的协作很可能会产生某种内耗。尤其是项目刚刚启动开发阶段。

当然一开始的时候，研发流程一开始不一定要很详细或很全，可以在实际运行的过程中逐步优化和调整。

但有一点是需要特别强调的，项目经理在和团队明确好流程和规范时，就要去守护这个流程和规范了。这本身也是项目经理的一个价值体现。

如果发现团队中有不遵守的，就要进行沟通对齐，可以允许有不同的声音，但在当下某个阶段或者某个版本中，先遵守执行，回顾会上的时候，再和团队一起讨论优化。

除非是当前的研发流程，严重阻塞项目研发进程，否则一般不建议在当前迭代更改研发流程。

（2）明确版本开发模式

这个版本开发模式，我取名为流水线分支开发模式，简而言之，就是拉分支开发，各系统功能或特性之间，开发节奏不受影响。更细节的在迭代循环的部分详细介绍。

（3）明确版本合流流程 因为是流水线分支开发模式，所以必然会涉及到一个版本合流的流程，具体参照如下：

（4）推动落实工具建设

工欲善其事必先利其器。对于中大型项目来说，一定不可忽视的就是工具的建设。工具和业务开发并行，甚至先行，往往是可以大大提升效率的。

看着需求开发的过程是节省了不少时间，但事实上，验收和测试环节，则不够便利，影响整体效率。

所以，作为项目经理，要推动并落实工具的建设，要从全局考虑出发，项目的整体节奏和周期不仅仅只的是开发过程，还包括验收和测试环节，尤其是在敏捷思维下，需要的持续迭代，持续交付。下图就是我们持续建设并不断优化的工具体系。

4、开好项目启动大会

关于如何开好项目启动大会，其实在很多书本，文章中都有介绍了，这里也就不细说。分享两个要点：

（1）做好全员信息同步

项目启动大会，是一次全体项目的大会，那么在这个大会上，需要做好全员信息的同步。包括项目的整体目标、阶段性的里程碑目标、团队成员角色和职责、主导项目经理（中大型项目团队，项目经理往往不止一个人，需要有一个主项目经理，或称之为大项目经理）、项目的组织架构、各种流程和目的

（2）对齐项目目标

传达了项目目标并不等于就对齐了，我这里讲的对齐目标，更多的是指，需要项目高管从产品的愿景，部门或公司的期望等更高维度来阐述，包括市场情况、产品竞争力、未来的卖点和亮点，给团队传达和注入强自信心。

不仅如此，还可以阐述为什么要做这个项目以及相关的背景。这个可以更好的让团队成员去真正理解项目目标，也可以知道自己从这个项目中可以收获什么，让团队成员都可以积极的参与到项目中来，为实现自己的目标而不懈努力。

以上就是立项和启动两个项目管理实践的部分。后面继续分享版本循环-适应变更-迭代循环-收尾。