在项目开发的过程中，做好项目管理能够及时解决一些麻烦和突增的需求。本文从项目排期表、项目进度跟进、需求变更、技术因素四个方面，分享关于怎么轻松做好项目进度管理。

经过产品需求评审，UI、研发、测试同事都已经评估了工作量，确定了产品功能提测时间和上线时间，那么对于产品经理来讲是不是就可以去分析下个版本的需求，坐等产品上线了呢？

在实际版本开发的过程中，可能会出现这样的问题，运营同学反馈有一个影响用户的产品功能马上需要优化，领导增加了新的需求，已经评审的需求出现了需求变更。技术由于处理线上问题原来的需求计划有所延迟，研发处理各种线上BUG影响了开发正常工作。本文主要分析项目开发中的影响因素及其对应的解决方法。

1. 项目排期表

项目排期表是进行项目进度管理的重要手段，通过项目排期表可以非常直观地看到该项目有哪些开发任务要做，这些任务是由谁来做，开始时间和完成时间，完成的前置条件是有哪些。项目排期表确定了该版本要开发的产品功能的范围，每个功能中需要的开发工作量，也就是本次版本迭代的迭代周期。

由于产品功能的开发一般需要UI设计师，前端开发工程师，后台开发工程,共同完成，前端开发可能又会分为web、APP-Android、APP-iOS，小程序，h5，那么项目排期表中除了承载任务安排的关系，还代表了一个产品功能下面需要的不同类型研发工程师的关系。

项目排期表也是一个沟通的工具，前端工程师根据排期表和UI设计师进行UI问题的沟通，和后台工程师进行产品功能的联调，测试工程师可以针对测试过程中出现的BUG直接指定对应的研发工程师。

在时间安排上，可以很直观地通过项目排期表看到各个研发人员的时间安排，各个产品功能开发时间端，产品功能开发的先后关系。同时呢，也会从整个版本迭代过程中发现关键任务（重点关注进度的产品功能）和关键人员（重点关注进度的研发人员），关键任务在整个项目排期中至关重要，不允许有延期的情况。

同时也会调整研发人员的排期，对于有空闲时间的研发人员可以安排其他项目或者进行其他产品功能的开发。一份完善的排期表会大大减少开发过程的沟通和需求问题。

在项目启动开发之后，除了项目排期表之外，可以同步输出版本范围列表，产品功能路径图会有助于项目团队中各个人员对本次产品迭代范围及注意事项的整体理解。

2. 项目进度跟进

在输出项目排期表和版本需求范围，确定了关键任务和关键人员，还需要定期跟进项目进度。在敏捷项目管理中会采用每天站会的方式同步开发进度和需要解决的问题，每天站会显得比较繁琐而且至少会占用30分钟的时间。

采用在线文档的方式进行项目进度的跟进成了一种不错的选择。在原来项目排期表中增加【进度】和【备注】两列，其中进度用于同步每条任务的完成情况，备注用于增加对该条任务以外情况的描述，比如后台未提供接口，第三方未提供接口等等。

通过对项目排期表中进度的描述，项目管理人员可以很清楚和直观地了解到目前项目进行的状态，正常进行，延期还是提前完成，并且可以了解研发人员的反馈，及时处理开发过程中出现的意外情况。

可以利用project中的报表工具对项目进行的状态和开发进度进行评估，直观的了解项目状态。项目经理每周将需求开发情况，出现的问题及解决情况同步至项目组成员和领导，以便大家及时了解项目最新进展。

3. 需求变更

在理想情况下项目进度会按照项目排期表有条不紊地进行，完成一个个产品功能的提测，完成一个个产品功能的测试，验收和上线。但是实际情况中，往往会出现各种情况影响正常的开发迭代，其中最常见的就是产品需求变更和技术因素。

俗话说，计划就是用来改变的，在互联网产品开发过程中，产品需求变更往往也是避免不了的。虽然说需求变更备受UI、研发和测试同事的吐槽，但是需求变更来了的时候，还不得不进行需求变更。针对产品功能的变更首先是要了解变更的来源在哪里，是否有必要变更，开发的工作量有多少，是不是一定要在这个版本上线，放在下个版本开发是否可行。

3.1 产品功能补充/小改动

在开发的过程中，产品经理突然发现遗漏了某种场景或特殊情况，对产品需求进行的补充和修订。客户需求发生变化，需要产品功能进行对应的更改。这个时候需要产品经理根据最新的需求补充产品文档，并同步至研发、测试和项目经理，项目经理根据产品需求变更带来的工作量对项目排期表进行调整。

调整的原则为保证关键任务和关键人员的进度，对新增需求开发工作量进行评估并增加到项目排期表中，同时根据变更后的项目排期表调整部分需求的提测时间。这部分需求变更的管理有一个前提就是不影响关键任务和关键人员的安排，或者是对该部分影响较小。

3.2 产品功能的增加

有时候出现大的产品功能的增加，这往往可能来自于业务方面迫切的需求或是领导对整体规划的调整。这里所说的产品功能的增加指的是增加一个完整的功能，并且会需要较大的工作量，直接加上该功能会对原有项目排期产生重大的影响。

在这种情况下，一般是要确定产品需求，确定产品需求文档，避免出现后期需求变更的问题，评估整体的工作量，查看新增工作量对于整体迭代周期的影响。然后对版本范围中为开发的，优先级相对来说比较低的需求安排在下个版本上线。如果时间还是比较紧张，可以向领导说明情况并根据实际情况进行适当延迟。

3.3 产品需求变更流程

在需求变更过程中非常重要的环节就是注意变更流程和变更规范，以保证整体的上线质量和上线效果。首先由需求方（运营/产品）填写《需求变更申请表》提出需求变更的原因和内容，由产品更改产品PRD，再进行需求评审，如果是小更改可以直接在群聊中解决的就不用再进行需求评审会。

最后项目经理作为统一的归口同步更新《版本范围列表》和《项目排期表》，项目组的各项成员统一以最新的产品PRD，《版本范围列表》，《项目排期表》进行产品功能的开发，测试及验收。

需求变更的规则还有：

1. 尽量在开发早期提出需求变更；
2. 提测之后不接受需求变更；
3. 变更后的需求一定在产品PRD中标注，并在微信群中@相关人员；
4. 产品上线统一由项目经理做为归口，以《版本范围列表》为准；
5. 采用在线文档或是公司网盘的方式同步文档，以确保所有人获得的是最新版本的文档；
6. 所有文档如有变更，必须进行记录。

最后项目经理要对每次项目迭代过程需求变更进行记录和总结，反应在项目总结当中。如果是在需求理解或是需求设计中出现的问题要吸取教训，在以后的产品设计中进行改进。

4. 技术因素

随着产品功能的增加，用户数量的增加，在实际开发的过程中，技术研发人员往往会在开发新需求的同时修复线上BUG的问题。对于线上BUG的及时响应，及时修复，在占用研发时间中很大一部分用在和运营/产品的沟通中。

那么此时需要对BUG的处理进行优先级和处理时间的分类。对于影响用户量很大，非常影响用户体验的BUG，问题提出当天进行反馈，尽量在当天或第二天上线。

同时BUG处理流程会按照下图严格实施，以减少技术沟通时间，提高研发效率。对于不太紧急的BUG，在开发任务比较紧张的情况下，会在版本上线之后的一周内上线，在开发任务比较宽松的情况下，会在一周之内统一解决，统一验收，统一上线。

在项目进度管理的过程中做好来自以上几个方面风险的应对基本能够控制项目整体进度，保证产品功能上线。在项目进度管理中最核心的内容就是让项目成员了解项目概况，了解自己的工作内容和上下游关系。当出现不可避免的需求变更时，积极应对，拥抱变化，随和和团队同步最新需求和最新进展。

本文由 @Anne 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议