研发期的项目，是一个个版本的开发和交付循环往复的。版本管理就是项目经理最基本也是最重要的能力项之一。所以也有说，项目管理是从版本管理开始的。

当项目经理开始负责一个全新的项目时，往往不知道从何处入手来开展版本的管理？考虑到很大一部分项目经理初始经历的都是中小型项目（20-40人团队规模），本文主要从这个视角来谈一谈研发期项目版本管理的实际操作和步骤。分别是：

一、梳理需求框架

二、进行版本规划

三、制定版本计划

四、版本开发和验收

五、版本测试

六、版本review

七、跟进和执行

八、版本流程

九、持续集成

---------------------------------------------

---------------------------------------------

一、梳理需求框架

版本是由一个个需求组合而成，新项目立项后正式启动，第一步就是先梳理需求框架。因为有了需求，才好进行版本的规划。

这里的需求梳理，初始的时候通常是指的产品本身的需求。项目经理和产品负责人沟通，输出一份需求的整体框架。功能需求比较少的可以直接用思维导图（如左图），功能相对较多的可以用在线表格（如右图）

之所以是先梳理需求框架，是因为对于互联网行业的产品来说，项目正式立项之后，需求可能一开始并没有完全写完，而是一个逐步输出的过程。

这也是需求框架梳理的必要性，当有了整个项目的需求框架之后，可以让项目团队清楚的知道项目有多少功能需求要完成。

在需求框架输出的同时，也需要进一步明确需求的优先级。

二、进行版本规划

需求框架输出之后，接下来第二步就是进行版本规划。

在对版本规划的时候，可能不少项目经理会不知道怎么具体开展，或者存在不少疑惑。这里的疑惑点在于版本规划的节奏究竟怎么才是合适的，是周迭代，还是双周迭代，抑或是其他节奏。

涉及到版本节奏的问题，一开始不清楚是很正常的，因为项目第一个版本都还没有正式开始，没有可以参考的依据。

所以，通常的做法是，先明确第一个版本的需求内容。对于很多互联网产品来说，第一个版本通常是最核心的内容（demo版本或MVP）。

比如第一个MVP要做的功能有5个，这个时候可以和开发leader一起，盘点确定人员安排，然后快速评估一个粗略的时间，以便确定这5个功能的大致开发时间。

这个粗略的评估不做最终的版本计划，只作为初始迭代周期的一个基本判断。假设是需要两周完成，那迭代周期可以暂定为2个周。其他的功能需求，则也先初始按照两个周5个功能进行初步的规划。

之所以说是初步的规划，是因为这个规划是动态调整的，等第一个迭代做完之后，甚至第二个迭代做完之后，再进行全局的调整。

三、制定版本计划

版本规划好之后，接下来就要制定版本计划了。

版本计划的制定，一定是基于需求的详细评估来的，所以一系列的事项：

1、进行需求评审

需要全版本人员参与需求的评审，包括开发、产品、测试、美术、项目经理。一些重大的需求，还可以拉上项目总负责人一起。

2、输出设计方案和详细工作量评估

需求评审完成后，需要和开发人员确认设计方案的输出时间，以及详细工作量评估的时间。也即开展WBS。这里的详细工作量评估是有要求的，也即需要细化至0.5-2d的颗粒度：

可能这里有很多项目经理也会受阻。受阻的原因在于，开发人员不一定会配合或者按照这个要求来进行。所以，在功能需求评审前，项目经理需要先和开发leader沟通达成共识，详细说明细化颗粒度的用途和目的。通常来说，细化颗粒度是一方面可以检验开发人员是否对需求的细节有更深入的理解；另一方面，计划制定更准确，更便于对进度的管理和风险的管理。

如果遇到开发leader不支持怎么办？不要急于去说服对方，更不要起冲突，认为他们不支持你。这个时候可以建议是否可以在某个模块进行试点，拿到某一个版本的数据之后，再来沟通对齐。

同时，也可以和项目管理层一起达成共识，从上至下的进行推行这个规则。从我这么些年经历的项目来看，开发leader在这个维度上通常都是会比较配合的。

3、制定计划

当拿到详细的工作量评估之后，项目经理就可以开始制定一份详细的版本计划了。我们的项目需求是TAPD工具进行管理，但我自己做详细计划是习惯用project。参照如下：

制定详细计划，不是简简单单的搬运工。上面这个事例相对来说是比较简单的，但事实上，要做好一份项目计划，并不是一件容易的事情。后续准备有专门的一篇文章来介绍，如何做好一份项目计划。

4、输出关键时间节点

计划制定好之后，项目的关键时间节点也就都出来了，项目经理需要做好信息的同步，能够将可视化的都可视化出来。

详细计划项目经理自己看就可以了，而关键时间节点，是需要全员同步，要尽可能的可视化呈现出来。比如我们会在企业微信群公告里面同步，参与版本的全员都可以看到。也会将详细的计划放置TAPD-WIKI里面，便于大家查阅。

更早前的时候，还会打印出来，张贴到看板或更显眼的位置。（现在提倡环保，都是呈现在项目管理工具上了）

若一个版本里面设计到多个功能点，还可以以里程碑的形式呈现出来，参考如下图：

作为项目经理，我们需要思考的是，管理层重点关注的是什么。对于版本内的需求功能，他们更关心的是每个功能的交付时间，而不是去看projcet的详细计划。

输出关键时间节点和这个里程碑图，还有一个好处，就在于当版本计划出现变化时，不用特别去调整project了，这样费时费力，只需要更新关键时间节点和里程碑即可。

因为详细工作量输出的时候是有严格的规范的，必须是在0.5d-2d的范围，而且如果是有2d的还需要给出说明，为什么拆不了。

在这个维度严格规范之后，当出现一些变化的时候，我们就只看对整体周期的影响时间。举个例子，比如开发的过程中发现有新增的需求点，这个需求点要额外新增2d的时间，那么针对这个时间节点，原来的开发周期是5.26-6.7，则会变成5.26-6.9，其他各项整体顺延2d。除非是版本计划制定好之后，全部推翻重来，那就等于是重新制作project了。

四、版本的开发和交付验收

版本计划制定好之后，就进入到开发和交付阶段。

1、版本开发

开发阶段，要定义好版本线的安排，是全部功能在主干开发，还是分支流水线开发。这个通常是在正式开始编码的时候就要明确的。

从项目管理的角度来说，无论是主干开发还是拉分支开发，没有绝对的好与不好，各有优劣，只要是合适自己项目的就最好。

我们项目是采用流水线分支的开发模式，比如一个版本有5个功能，这5个功能，有两个功能是有关联，那么这两个功能会在一个分支进行开发；其他3个功能是互相独立的，则会各自拉分支进行开发。

流水线分支开发模式的好处在于，彼此开发期间是独立的，互不干扰，可以快速提升研发效率和后面的分支版本验收；缺点就在于，合版本的时候需要有严格的规范和流程，而且合版本也会带来一定的成本。

2、交付验收

在验收环节，我们采用的是双闭环的验收模式。简易模型图参考如下：

版本管理的重要环节之一就是验收环节。版本的过程如何如何的好，最终的检验就在验收环节。

事实上，我们项目是采用的敏捷思维下的研发模式，整体上看起来像是瀑布式，但实际每个功能的开发，都可以采用敏捷的思维。

我们通常会根据系统功能的大小，把一个长周期的版本有机化为多个迭代版本来进行，每个迭代版本的交付，都是按照可交付来进行。

当然，由于项目本身的特点，不能为了划分迭代而划分迭代，这点非常关键，千万别以为用了敏捷思维，就一定需要生搬硬套敏捷的方法论。

那么在验收环节的时候，具体是怎么做的呢？

1）在计划输出之后，会同步关键时间节点给到测试人员，比如这个功能的开发联调完成时间是6月7日，那么会要求测试团队在6月7日下班前提供自测用例。

2）自测用例提前输出，有两个好处，一是自测用例输出前，测试人员需要和开发、产品一起进行用例的评审，那么评审的时候，是对需求的进一步理解和查漏补缺，以及对一些边界、异常情况的补充，这样便于一些问题在开发阶段就直接先行处理了；二是便于开发自测联调完成后，跑这部分自测用例，这样交付的版本质量则更加有保障。

这里有一点需要特别的关注，当出现需求的查漏补缺，或者一些边界、异常情况的处理需要额外增加时间时，按照客观情况来看，相应的计划是需要进行顺延的，这个时候项目经理需要详细了解清楚情况，支持团队这样去做，然后将详细情况汇报给管理层，并说明原因。

当出现这种情况的时候，项目经理不要因为多增加的一些时间，对原来的版本进度有影响，认为不好向管理层交代。项目经理需要从全局出发去看整个版本的周期，问题的前置解决和处理，反而是更加有利于产品的验收和测试环节。看着像是原来的计划有延误，但实际上，整个版本的周期可能会比之前更短。

3）开发在编码完成之后，需要先进行自测联调。这里的自测联调是对于客户端和服务端的交付来说的。一个功能的开发完成，是包括客户端和服务端的交互，所以需要联调自测完，确保功能都跑通。

4）在开发过程中，对于客户端来说，还需要进行自检。在过去做一些版本的时候，我们经常会发现，在验收环节出现很多各类的细节问题，导致花费了不少时间，所以，在新版本开始的时候，我们也对这些问题进行了归类整理，把这部分自检全部前置到开发周期内。具体参考如下：

1-弹窗类界面

（1）是否具有通用蒙板遮罩。

（2）是否具有通用弹窗动画

（3）背景的图片、花纹、线条是否与效果图一致，透明度是否一致

2-全屏类界面

（1）背景底图是否进行了多分辨率适配（放在页面根节点，命名为BG）。

（2）页面整体适配情况，最少需要测试【宽屏2048x1536】，【标准1334x750】，【窄屏2340x1080】三种分辨率下的情况。

（3）是否需要支持异形屏适配。（使用异形屏适配节点进行适配）

（4）背景的图片、花纹、线条是否与效果图一致，透明度是否一致

3-窗口内浮层的背景切图及透明度

4-标题、按钮、页签，切图资源与文字的字体、效果

5-关闭按钮的点击区域放大

6-通用的图标Icon大小有无压缩变形

7-将效果图放入unity，运行时校对UI元素位置是否存在误差（列表、新增UI元素容易引入误差，校对完务必删除效果图节点及资源）

8-红点功能

9-按钮点击必有反馈（网络请求失败或后台错误码，请使用tips，文本可以整理一起同步产品）

10-界面关闭功能Check 界面关闭规范

11-自检之后，截图给对应的美术同学进行初步验收，美术同学确认ok后转产品验收

5）开发在自检的同时，需要美术人员在PC上进行验收。对于游戏项目来说，美术的参与度是非常重要的，因为美术要对效果负责。PC上先行验收，同样也是可以在PC端快速的解决一些细节的问题。然后在手机端的时候，只做更细致的确认。因为PC端和手机端有些时候的表现会出现不一致，所以PC端验收完，手机端也还需要进一步验收。

6）开发跑自测用例。这部分自测用例是测试给出的整个功能全用例的一部分，通常是高优先级的，10-20%的用例，量不会太多，通常预留的时间是1-2d的跑自测用例的时间。具体情况，项目经理可以来自产品、开发和测试一起沟通对齐，看具体跑多少用例合适。开发自测用例跑完之后，就可以正式交付产品验收了。

这里需要特别注意，我们的版本目标有一个规则，自测用例的通过率必须要达到90%及以上，才能交付验收。

7）自测用例跑完之后，版本负责人就会输出版本，交付产品和美术进行验收。这里产品和美术的验收，需要根据要求，及时的输出体验意见，便于开发快速的修改。如果涉及的体验问题比较多，或者有理解的偏差，通常是由产品负责人快速拉起会议，和开发，美术一起对齐，避免开发开始修改体验问题时出现理解的偏差。

8）产品和美术在验收完成之后，需求的状态也需要进行流转。以一个功能需求为例，正常的需求流转流程参考如下：

9）在产品和美术验收的同时，开发侧代码也需要进行codereview（CR）。通常是由项目内资深的开发，或 开发leader一起进行评审。关于CR，我们项目内部，也组建了专门的CR小组（资深开发人员兼职，包括开发leader在内）。

当产品和美术验收都完成后，开发的CR问题也解决完，该功能需求会进入到转测试环节。

五、版本测试

版本验收完成后，体验问题的修改完成度需要在90%以上，这个时候就可以开始合并主干进行转测试。我们的转测试周期是每周二、每周四下班前的版本转测试。

转测试的流程是由测试经理负责制定的，版本负责人严格按照测试经理的要求转测试即可。

测试开始时，会分为三个阶段：

1、测试跑自测用例阶段

这里主要的目的是检验开发交付的版本是否真正地达成了90%的目标。总不能开发说跑完了自测用例达到了90%，结果测试人员一跑自测用例的时候，发现都是90%以下。当出现这种情况，项目经理就需要相应地处理了。不过对于我们项目自从这个规则确定以来，99%以上的版本，自测通过率都在90%及以上，有些版本的系统功能，都在100%。

2、首轮测试阶段

首轮测试是指测试人员对该功能的全量测试，以单个功能为例来说，如果版本内有多个功能，就是多个功能的全量测试。

上面我们给的计划里面，通常是没有测试时间，因为测试用例是在计划输出之后才输出。所以，通常在跑完自测用例之后，测试开始进行首轮测试时，才会评估一个时间给到项目经理。当拿到这个时间的时候，项目经理也需要同步给项目团队。

在测试跑自测用例，以及首轮测试阶段，开发人员就可以继续处理一些遗留的体验问题，或者没有体验问题就开始修改bug。

3、bug回归测试阶段

我们的版本目标里面有一个规则，就是版本的完成度，是改版本内的bug修复率不剩余10%。也就是说如果版本开始测试后，首轮测试完成后有100个bug，那么最后版本完结时，剩余的bug不能超过10个。

当然，这是在初中期，到了后期阶段，基本上都是要求每个版本的bug要清理的。项目经理需要特别的关注一个点，对于一个项目来说，初始的几个版本，基本上是很难做到这一点的，不要说bug清零，就连90%的清理都达不到。

这是因为项目在初始阶段的时候，功能本身就不齐全。对于互联网产品，尤其是游戏项目来说，系统功能之间的关联性太强了。不能一味的为了版本目标而为了版本目标。

具体在哪个阶段，可以严格按照这个目标去落实，可以根据项目的实际情况来定。我们项目是在整个项目研发进度超过60%的时候，才开始严格执行这个规则。

六、版本review

每个版本结束前后，我们还需要对版本进行回顾，在版本即将结束前，我们需要回顾版本的达成目标与否，参考如下的规则：

这是中后期我们每个版本必须要遵守的规则。

当项目进行到中后期的时候，一大批正式资源都到位之后，基本上每个版本的完成是按照100%的要求来进行的。也就是说，基本上每个版本都会按照上线的标准来进行。

除了版本目标的review，还有一项重要的事情，就是项目经理需要引导团队开版本回顾会议。回顾会议两个主要议题：

一是版本的总结和复盘。过程中出现的问题和好的方面，经验的总结和沉淀；

二是版本研发过程的心流体验。主要是让每位团队成员都亲自说一说，在做这个版本的过程中，觉得开心的事情有哪些？不开心的事情有哪些？或者有哪些其他的建议。

项目经理可作为回顾会议的主持者，记录过程中开心和不开心的事情，以及相关的建议，并在下一个版本中跟进落实、改进，以便做的更好。

至此，版本的整个过程就结束了。

---------------------------------------------

---------------------------------------------

接下来七、八、九分别介绍一下跟进和执行、版本流程和持续集成。

七、跟进和执行

项目跟踪和控制能力，实际是项目经理最基本的能力之一。

事实上，我们很多初阶项目经理，并不是知道怎么去跟进版本。甚至会以为，项目计划做好之后就万事大吉了。要知道，项目的特点就是不确定性，不懂跟进和执行，仅靠制定一份计划，就想保证版本的顺利推进，基本上是不太现实的。

那什么是项目跟踪和控制能力？是指能熟练掌握及应用项目跟踪的方法和工具，充分调动资源确保项目按计划实施。

以鹅厂项目管理为例，不同的级别，要求也是不一样的。

1、P4-P5级别，是在指导下对项目进行跟踪控制。

*了解项目跟踪控制方法

*能在指导下，对已制定好的项目计划进行跟踪

*能在指导下，利用数据对项目进行分析

*在计划执行中参与一些辅助性的工作，协助解决问题

2、P6-P8级别，独立对单一项目进行跟踪控制。

*熟悉并能掌握运用项目跟踪控制方法

*根据已有的项目计划的具体要求和任务，可以独立的予以推行并加以实施

*在项目进行中能及时发现并反馈问题，并针对变更和突发事件,采取相应纠正措施,保证项目按计划进行

*能撰写一般项目状态报告

*能利用数据分析的方法和工具，分析项目中的问题，并提出解决方案

3、P9-P11级别，随时对项目作出全面的分析预测，提前规避、纠正问题，确保项目高质量完成。

*掌握并熟练运用项目跟踪控制方法，有着丰富的理论和实践经验

*能针对计划合理地调配和充分利用现有资源，使之得以高效的推行和实施

*能在问题发生前发现主要问题,并提前规避,在问题发生后能准确找到问题根本原因，并迅速解决问题

*撰写优秀的项目状态报告,对项目情况给出全面分析,预测

*总结和提炼，进行部门级BU级分享

三个level，不同的能力要求，大家可以对号入座，然后加以训练。

那么对于一个版本来说，怎么去做好最基本的跟进和执行工作呢？

4、做好版本跟进和执行的几个小的tips。

1）计划制定好之后，是和团队成员达成共识，包括核心管理层都是达成共识的，然后要全员公示，可视化地呈现出来；

2）level1主要是校准计划，level2级以上建议以校准目标为主。校准计划就是按照计划制定的每天做什么，每天核对；校准目标则是以整体目标为准，核对关键时间和事项。

初始的阶段，大部分项目经理可能都是以校准计划为主，每天去和开发，产品，美术核对工作进度，以确保每天进度正常。但校准计划有一个弊端，是纯粹以工作任务的角度出发的，而没有考虑人的因素。

事情是由人完成的，严格要求按照0.5-2d的工作拆分，但是人去完成事情，就有人本身的因素所在。今天心情好，可能就完成的多一些，明天心情不好，可能就完成的少一些。所以，如果每天都核对计划，给团队压力其实是非常大的。

而校准目标则是充分的考虑人的因素，更加的人性化，但这里的前提在于，项目经理是非常清楚业务的情况的，对业务线的掌控也是了如指掌的。

3）可以考虑每日晨会或每周一三五晨会，用于识别和提前发现进度的问题。项目经理需要非常清楚项目的计划，通过晨会团队成员讲述昨天做的事情，今天要做的事情，过程中可能出现的问题，去预判是否有和计划有偏离。

比如小明原计划今天是做A任务，要第二天才做完，结果第二天晨会的时候，小明讲到去做B任务去了。这个时候就要提高警惕，可以晨会上直接了解情况，

4）以周报的形式向管理层汇报每周的项目进度，让管理层及时掌握项目的情况，获取反馈

5）项目经理在版本开发过程中，走动式的参与其中。除了晨会以外，走动式地参与到团队成员的沟通，交流中，发现有进度的问题，及时地帮助他们解决问题。也可以在版本一开始的时候就建立相关的反馈机制。但仍旧需要项目经理在日常的工作中，多和团队成员沟通、交流，建立影响力，让反馈机制变被动为主动。

6）更高level的项目经理，在每个版本计划做好之后，还需要准备一份风险应对计划。这个是基于版本计划本身来看，会存在哪些可能的风险，提前做好应对措施，规避风险，不让风险变成问题。详见《如何做好项目风险管理 》

八、版本流程

流程是为效率服务的。项目经理在版本管理的过程中，要根据项目的实际情况制定符合项目的研发流程。一方面要去守护这个流程，另一方面，要根据项目的不同阶段对流程进行优化，以更加适应版本的研发节奏和版本的管理。

参考如下图，是我们项目每个版本（具体到每个功能）的研发流程：包括需求评审、需求评估、需求开发、需求验收、需求转测、需求完结，全链路闭环流程。

除了研发流程，对于每个版本内的功能需求流程，也可以借助项目管理工具进行设置。我们用的是TAPD工具，可以设置需求（功能）的流转流程。参考如下：

九、持续构建

持续构建，也说持续集成。要进行版本管理，一定是离不开持续构建版本的。

对于我们项目来说，我们的版本正式转测试是每周二、周四下班前转测试。

但实际上，当版本可以构建输出时，我们基本上是每日构建，包括Android和iOS一起持续集成。

之所以要持续集成，持续的构建版本，很简单，就是希望可以尽快的看到版本，这样方便快速的体验版本和测试版本，以便可以快速的反馈问题，修复问题，稳定版本，最大程度的降低版本的风险。

在持续构建版本方面，我们是项目启动之初的时候，就搭建了整个构建体系，接入公司的蓝盾平台（每个公司可能都有自己的构建平台）。

那么具体来说，因为我们是采取的流水线分支模式，所以，构建版本也是流水线的模式，通常会有：

转测版本流水线：转测版本流水线也通常称之为主干版本流水线。这条流水线构建的版本主要是用来转测试，以及每周三项目核心组进行体验的。包括Android和iOS版本一起。项目经理和主要开发人员都有权限启动。到现在这个阶段，我们还会设置每周二、每周四下午2点开始每隔两小时自动构建一个版本。以及每日凌晨自动构建一个版本。这样做的目的就是在于，版本的构建不需要人工的强干预，有新版本出来的时候，想体验的就可以直接去下载。

当然，每周二、每周四晚上转体验的版本，我们是会设定版本负责人，这个版本是由版本负责人强干预进行构建的，而且当晚版本构建输出之后，需要开发内部进行自测验证，输出changelist，并同步项目大群，然后再走转测试邮件给到测试团队。

分支流水线：分支流水线是具体到某个功能的流水线构建，因为当版本（以一个系统功能为例）开发完成后，这个版本的功能就可以开始构建版本进行自测和验收了。这样一来，不用等到合入主干，就可以先行有版本给到产品和美术进行验收。

通常，对于每个功能的版本来说，分支流水线可以共用，也可以设置多个，是由具体功能开发的开发人员负责构建，并同步给到对应的产品和美术。

在版本构建输出时，开发的模块负责人也会在我们的企业微信群里面同步输出。

和版本强相关联的就是转测流水线和分支流水线。除此之外，当某个阶段版本在进行特别的一些验证时，也还会有另外的流水线构建版本，比如做性能的优化，做一些方案的重构和验证，也会拉分支进行，这个时候也会有独立的分支线构建版本进行自检。这样可以有效地避免干扰到主干的版本。

---------------------------------------------

---------------------------------------------

最后，我想说，要真正做好一个版本的管理，并不是一件容易的事情，也并非一朝一夕的事情，需要项目经理持续的精进。

项目管理从版本开始，项目经理也是从做每一个版本的过程中，逐步精进的。