项目管理流程及版本规划方案.docx

项目管理流程及版本规划方案.docx

《项目管理流程及版本规划方案.docx》由会员分享，可在线阅读，更多相关《项目管理流程及版本规划方案.docx（5页珍藏版）》请在冰豆网上搜索。

项目管理流程

一个项目研发的项目组成员主要有：

产品经理、UI设计师、前端开发、后端开发、测试、运营等。

基于合理安排项目成员工作、确保项目顺利进行的角度，一个清晰合理的项目研发流程控制很重要。

需求宣讲

需求可行性

UI设计

需求讨论

需求阶段

产品内部产品+开发产品+设计+前端所有人

项目启动

测试用例

研发功能

提测

研发阶段

测试+开发测试+开发产品+设计+前端产品（周期、发版时间）

运营报告

发布上线

升级运维

DEBUG

发布阶段

测试+开发产品+运营+开发运营+开发运营

项目研发流程一般来说分3个阶段

第一阶段：

需求阶段。

在需求阶段产品经理内部进行需求讨论：

讨论下版本需求重点是什么，做什么功能，怎么做。

需求讨论及可行性讨论：

由于需求的接入来源有内外部两个方面，整体流程会经历需求收集、需求梳理、需求分发、需求实现、需求验证及需求评估的六个阶段。

内容如下：

需求接入流程如下：

UI设计：

设计师将产品输出的交互方案变得更生动精美，在这个过程中产品经理需要协调设计师和前端人员的沟通，制定设计规范。

同时保证设计稿的质量，出稿进度。

需求宣讲：

产品经理将交互方案和实现逻辑完善以及将上版本的bug、其他优化需求等整合后，对项目组所有成员进行宣讲。

宣讲目的主要让项目组成员清楚新版本需求的重点功能及功能的意义，讲解交互方案或设计稿，给大家有一个整体的印象，让大家都了解版本功能。

第二阶段：

需求研发。

项目启动：

需求宣讲后，开发根据产品原型及相关文档进行需求评审，评估出研发周期、提测时间、预发布时间点、正式发布时间点。

产品根据评审结果发送项目启动邮件。

研发：

需求研发过程中，产品跟进研发进度，保持与开发沟通确保需求被正确理解，及时解决研发过程中发现的新问题。

测试用例：

测试、开发共同确认版本测试用例，并同步研发过程中变更的细节。

提测：

产品核准开发输出的功能模块，并输出至测试部门；测试根据用例验证需求逻辑，提bug、优化给开发。

内网环境测试通过后，测试继续验证预发布环境、正式环境。

第三阶段：

版本发布。

DEBUG：

测试验证的过程及版本发布前，测试需协助开发人员进行验收测试，并出具终版验收报告及安全性报告。

发布上线：

如为APP项目：

后端开发、运维人员将代码发布外网环境，前端开发输出外网正式包。

运营将正式包上传各大安卓市场或APP-store提审。

如为PC项目：

前端开发后端开发及运维人员需将代码发布外网环境，。

升级运维：

所有安卓渠道包更新好，或者APP-storesore审核通过，新版本也无问题时，后端开发和运营人员开启升级配置，并发送升级通知。

运营报告：

版本发布完成后，运营人员在新版本发布后，收集用户反馈，进行数据监测、数据分析；评估新版本功能效果和影响，验证新版本功能以及输出下版本需求开发和优化建议。

版本规划方案

从项目研发流程来看，每一个版本研发都要经历以上3个阶段12环节，理论图上看是一条完整的流水线。

要保证流水线顺畅，理想情况产品需求要领先前端开发2个版本，设计领先前端开发1个版本，后端开发领先前端开发半个版本。

即在当前项目启动同时，产品经理已经在调研讨论下下版本需求；设计开始设计下版本的规划需求；当前项目进行到2/3时，后端已经完成当前版本的需求，并开始准备下版本的需求预研。

版本规划是产品经理根据需求优先级和开发进度预估定出来的，即每个版本要做什么，重点是什么，研发时间，上线时间等。

一般来说，项目每发布一个版本都应该有它的意义和主打功能。

首个版本相对来说时间较长：

需要搭配开发环境，确定技术框架，以及研发各种基础系统等。

像这样时间较长的版本研发，产品经理和技术在需求评估时要将开发需求分阶段进行并且设置里程碑（尽量不超过3个），在每个里程碑（最长不超过1周）时间点，产品经理需要确认完成的情况，发现问题及时调整研发计划，控制项目风险，保证项目如期完成。

后续开发的每一个版本都应该至少有一个重要功能，版本研发周期最好控制在2周-4周内。

这样的好处一方面是保证项目成员有个良好的开发节奏，使研发效率最大化；另一方面保证每个版本有新东西给到用户体验。

（APP符合各大市场申请首发条件，获得免费的推广资源ps：

一般首发活动可以获得几千到几万的免费用户）。

当然重大功能上线的话，确保上线后版本的稳定性，可以将研发周期延至1个月，或者进行灰度发布。

要尽量避免安排超过一个月研发周期的版本，否则要将长版本设置为若干个里程碑验收。

经验来看研发周期过长往往会导致研发技术人员精力分散，积极性下降。

一般情况不建议频繁发布小版本，因为每个版本发布都需要测试，打包，发布，发升级配置和升级提醒等。

频繁发布小版本造成测试和运营重复性工作增加，造成资源浪费；用户侧看频繁的升级提醒也是件很讨厌的事情。

另外，建议外网运营客户端版本最多不要超过4个。

维护老版本成本还是比较高的，比如做新功能还要考虑新老版本兼容情况，和各种后台数据接口升级、更新的兼容问题等。

在特殊的情况下，有紧急的bug和漏洞时，才建议紧急发布一个bug修订版本。