5000字干货原创 | APP版本迭代如何避免踩坑？-技术圈

‍‍

这是我之前好友总结整理的APP版本迭代流程与规范，主要涉及到版本迭代过程中的规范流程以及涉及到版本各个角色的职责分工等内容。

为了避免和团队成员撕逼扯皮，可以按照如下规范流程和团队成员宣导，落实每个环节各个角色的职责和内容，保证每个环节都能高效协作，避免踩到坑里，相关干货流程分享给大家。

本文目录如下：

一、引言

二、需求汇总阶段流程

三、需求评审阶段流程

四、需求开发&测试阶段流程

五、内测阶段流程

六、APP版本号命名规则

1、引言

1.1、目的

基于现在的开发流程中缺少的环节进行补足，使得开发流程更加的流畅和正规化，以便以后的查阅与归档使用。面对互联网行业中激烈的竞争，让我们的开发流程更完整、更有效率，产品才能脱颖而出。

1.2、范围

本文档适用于App产品的迭代研发，主要流程包括：需求汇总、需求评审、技术&用例评审、开发&测试排期、开发&测试、内测体验等环节。以后的产品开发流程也可以参考此文档的环节进行开发。

1.3 、读者对象

本文档的目标读者对象主要包括：

产品经理：输出&收集汇总每个版本迭代的需求，同时对App迭代进行体验验收，需求汇总阶段、需求评审阶段、内测体验阶段的主要负责人。

交互设计师：根据相关需求文档，进行交互优化，输出优化原型图，提升产品整体用户体验。

视觉设计师：根据需求文档&交互原型图作为视觉设计的步骤和资源产出的依据。

项目经理：组织发起需求评审，并跟进评审结果及输出开发测试排期，需求评审阶段、发布上线阶段的主要负责人。

开发：主导发起部分复杂需求的技术评审，根据需求文档编写代码，开发测试过程由版本经理主导推进，为迭代上线负责。

测试：根据需求文档设计相关测试用例，并主导发起用例评审，跟进测试阶段的Bug解决。

1.4、App迭代阶段流程图

（点击查看大图）

2、需求汇总阶段

（点击查看大图）

阶段推进方：主要由产品主导推进与收尾

产品部门&版本主要产品经理：

– 负责发起版本迭代
– 输出相关App迭代需求
– 收集其他需求方的App迭代需求
– 汇总并进行需求的初步分类与优先级评定
– 决策相关需求方案是否需要技术介入进行前期初评
– 决策相关需求方案是否需要进行交互优化&视觉设计
– 邮件发送需求汇总清单至相关责任人
– 确认需求汇总完毕后发起需求评审
– 汇总、整理、输出本阶段相关交付结果

阶段参与方&职责：

交互设计师

– 根据需求文档及需求原型图，进行交互层面优化，提升产品的用户体验
– 自发发起用户体验提升相关的需求，并提交给产品经理汇总入版本迭代需求中
– 输出交互优化稿后与产品经理进行评审确认

视觉设计师

– 根据需求文档及需求原型图或交互原型图，进行视觉设计
– 输出效果稿进行视觉设计评审确认
– 输出标注稿供客户端开发工程师对照开发
– 输出相关测试用效果切图，供开发&测试过程直观查看效果用

项目经理

– 根据开发对需求提出的疑问点进行分类汇总
– 组织安排评审会议

开发

– 适时参与产品发起的需求方案初评
– 查阅产品拟定的本版本迭代需求汇总，并初步提出相关疑问点

测试

– 查阅产品拟定的本版本迭代需求汇总，并初步提出相关疑问点

阶段工作描述

需求汇总阶段也是版本迭代的准备阶段，该阶段主要为需求的汇总及UED方面的设计输出，同时也为需求评审准备相应的材料与文档。

阶段交付成果

版本迭代需求汇总
产品需求文档
UE交互优化稿
UI视觉设计稿&标注稿
需求初期疑问点汇总

3、需求评审阶段

3.1、需求评审

（点击查看大图）

阶段推进方：主要由产品主导推进与收尾

– 负责发起版本迭代需求评审
– 配合项目经理组织需求评审会议
– 在需求评审会议中进行需求宣讲讲解
– 针对汇总后的需求疑问点进行答疑与沟通
– 需求的责任人需进行需求讨论记录并在会议的最后进行需求讨论记录的确认

阶段参与方&职责如下

项目经理

– 组织安排评审会议，召集相关人员
– 汇总并与相关方确认最终的需求范围

开发

– 会前确认主流程、主方向、主内容的认可
– 非常细节的内容，不涉及主流程环节可会后单独与产品经理讨论确认
– 参与需求评审，并根据需求讲解情况，提出疑问点，进行讨论确认
– 确认最终的需求范围及需求内容

测试

– 会前确认主流程、主方向、主内容的认可
– 非常细节的内容，不涉及主流程环节可会后单独与产品经理讨论确认
– 参与需求评审，并根据需求讲解情况，提出疑问点，进行讨论确认
– 确认最终的需求范围及需求内容

阶段工作描述

需求评审阶段是版本迭代的关键节点，该阶段主要需要对需求进行严格的审阅与传达，需要需求方与实现方进行完整全面的沟通。同时也是后续技术设计评审、测试用例评审的根基，力求将问题放在初期解决确认。

阶段交付成果

各个需求的需求讨论点记录
需求评审总结与会议纪要
需求范围确认后的版本迭代需求汇总清单

3.2、技术/测试用例评审&排期

（点击查看大图）

阶段推进方：主要由项目经理主导推进与收尾

– 负责在确认需求范围后，发起开展技术设计评审、测试用例评审
– 负责确认版本经理、测试负责人
– 负责收集各个需求的开发/测试工作量评估
– 负责输出版本迭代排期，并与各方最终确认排期情况

阶段参与方&职责如下：

产品经理

– 参与技术设计/测试用例的评审，并提出疑问并沟通确认
– 确认技术设计/测试用例是否符合需求
– 确认开发/测试的排期情况

开发

– 确认版本经理
– 由版本经理评估相关需求是否需要进行技术设计评审并发起推进
– 根据确认的技术设计方案or需求，进行开发工作量评估
– 参与测试用例评审并确认一级用例范围
– 确认转测条件

测试

– 确认测试负责人
– 输出相关测试用例并分级，发起测试用例评审并推进
– 参与技术设计方案评审
– 根据确认的测试用例，进行测试工作量评估
– 确认转测条件

阶段工作描述

技术设计方案评审&测试用例评审及排期是版本迭代的重要节点，此阶段延续需求评审后对需求的理解，从开发/测试的角度出发，制定相关方案，为后续开发/测试工作提供指导与依据。

阶段交付成果

技术设计概要
技术设计概要评审会议纪要
测试用例
测试用例评审会议纪要
版本迭代开发&测试排期表

4、开发&测试阶段

（点击查看大图）

阶段推进方：主要由版本经理主导推进与收尾

– 对整体开发&测试过程主导推进并负责
– 及时同步进度并进行风险预警
– 推进开发并同时跟进开发进度
– 推进转测并同时跟进测试进度

阶段参与方&职责如下：

产品经理

– 参与进度同步，及时根据风险预警进行调整
– 参与代码开发阶段的讨论，确认细节点
– 参与测试阶段的讨论，确认细节点
– 决策是否需要在开发过程中进行需求变更

视觉设计

– 在测试阶段介入进行视觉还原
– 跟进视觉还原的修复进度
– 确认开发过程中的部分对视觉的问题点

开发

– Coding
– 参与转测演示，并对转测演示结果负责
– 在测试阶段及时清理相关Bug与问题
– 与产品积极沟通相关细节点

测试

– 根据转测演示结果，决策是否转测成功
– 发起测试阶段，并根据测试用例进行数轮测试
– 跟进提出的Bug的解决进度
– 与产品积极沟通相关细节点

阶段工作描述

开发&测试阶段是版本迭代的实现阶段，本过程持续时间长，且过程需要大量持续的沟通与工作，需要各方进行紧密的配合。

阶段交付成果

相关接口协议文档
测试版本App
版本迭代节点通知
日常进度信息
测试验收报告

5、内测体验阶段

（点击查看大图）

阶段推进方：主要由产品主导推进与收尾

– 推动App迭代内测正常进行，组建内测群，拉内测员
– 整理版本主要更新点并发布内测邀请
– 收集汇总内测员的问题反馈并记录相关反馈人
– 反馈问题的定性与分类，确认是需求orBug，同时进行后续分配与确认
– 判定需求是否采纳，采纳则纳入需求池，酌情安排迭代，不采纳则将原因描述反馈归档
– 归档全部的问题及问题认定后，进行问题反馈分级
– 根据问题反馈分级，对反馈内测员发送对应奖励

阶段参与方&职责如下：

测试

– 确认预发布验证通过，准备内测包并发起内测流程
– 配合产品一起完成对反馈的问题的定性分类分级
– 对分类为Bug的问题反馈，进行确认与复现，同时确认Bug的优先级
– 高优先级Bug，当前版本需解决，录入系统跟进本版本内解决
– 低优先级Bug，可延后解决，录入系统Bug池延后版本解决

开发

– 确认需发布内容的Checklist
– 对后台进行逐一发布
– 内测包的打包与准备

内测员

– 内测员一般由内部员工或灰度员工参与
– 下载并安装内测包，进行体验
– 重点体验本版本的更新点相关流程
– 轻度体验App的常规常用流程
– 发现问题并在内测群内反馈问题，配合产品完成问题的确定与归集

项目经理

– 跟进版本迭代的生产环境发布
– 推动最终对外上线发布

阶段工作描述

内测阶段是上线前最后一个阶段，在这个阶段需要从常规用户的角度来最终体验，以防存在有未覆盖的点存在问题。

阶段交付成果

生产环境App
内测体验报告

六、APP版本号命名规则

作为移动端产品经理，经常会做APP版本迭代规划，所以不可避免的需要给APP版本确定版号的工作，大多数情况下可能都是拍脑袋确定的版本号。有些公司可能会有专门的项目经理负责版本管理和版本号的命名，但是绝大多数小公司可能都是产品经理来做这项工作。

6.1、为什么要规范APP版本号的命名？

首先需要说明的是哪些人员需要用到APP版本号，第一是产品经理，第二是开发人员，第三是项目经理，第四是用户。

对于产品经理，APP版本迭代基本都是由产品经理发起的，因此很多情况下都是产品经理在进行需求管理和版本规划的时候就大体上划分了版本号，版本号对于产品经理来说可以更好更清晰的筛选和确定每个版本的需求；

对于开发人员，版本号是直接和代码相关的，很多时候不同版本交叉开发，同一时间可能在开发不同版本，为了保障代码的规范和清晰，避免不同版本出现交叉混乱，版本号是极其重要的一环；

对于项目经理来说，版本号是需求管理中唯一标识符，需要根据版本号去管理和分配下发工作，同时也为了在软件产品生命周期中更好的沟通和标记；

对于用户来说，尽管版本号对于用户来说只是一串数字，但是版本号给用户的感知是不断更新的数字，可以通过版本号来判断自己的APP是不是最新的。

6.2、APP版本号的组成与规范

目前很多情况下，版本号可能只遵循了两个原则和规范，即版本号是唯一的，且是一串数字这个基本原则。在介绍APP版本号的命名规范和原则之前，我们首先需要了解一些APP版本号的组成是怎样的。

软件版本号有四部分组成：

<主版本号.><子版本号>.<阶段版本号>.<日期版本号加希腊字母版本号>。希腊字母版本号共有5种：base、alpha、beta、RC、Release。例如：2.1.0.181209_Release。下面对希腊字母版号进行简述：

Alpha版：也叫α版（开发环境），此版本主要是以实现软件功能为主，通常只在软件开发者内部交流
Beta版：此版本相对于α版已经有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过多次测试来进一步消除，此版本主要的修改对像是软件的UI。
RC版：此版本已经相当成熟了，基本上不存在导致错误的BUG，与即将发行的正式版相差无几，测试人员基本通过的版本。
Release版：此版本意味着“最终版本”、“上线版本”，，在前面版本的一系列测试版之后，终归会有一个正式版本，是最终交付用户使用的一个版本。该版本有时也称为标准版。一般情况下，Release不会以单词形式出现在软件封面上，取而代之的是符号(R)。

而对于绝大多数APP来说，一般采用的基本都是GNU风格的版本号管理策略，APP完全版本号的组成包括三组数字<主版本号.><子版本号>.<阶段版本号>，也即X.Y.Z，其中X、Y、Z都为正整数。

6.3、APP版本号的命名修改规则

1、主版本号

当App的多个主要模块有较大的变动，一般情况下比方说APP新增一个TAB，整个产品结构都改变了，或者新增了新的功能或业务。比方说微信上线钱包，抖音上线直播
主版本号起始值为0或者1，具体需要由产品经理来决定是否需要修改主版本号（PS：大多数可能需要老板拍板）

2、子版本号

子版本号初始值为0
当APP的较少主要模块发生较大的变动或新增模块（涉及主逻辑变更的）、较多个分支模块发生较大的变动或新增，相对于主版本号而言仅是局部的变动，比方说某个功能上的UI重构，某个页面的优化等，其中较少模块和较多模块需要去定义，一般我们认为较少为小于3个，较多认为是超过3个；
子版本号的最大值需要确定，不同的公司可能有最大的值，比方说最大为9，如果超过9，则需要主版本号进1，也有些公司可能不存在最大值，只会在主版本号+1的情况下才会将子版本号归0。这里没有确定的原则和规范，可以由产品经理自己定规则

3、阶段版本号

阶段版本号初始值为0
什么时候修改阶段版本号，一般是Bug修复、较少个分支模块的变动，比方说视觉、样式、交互、文案等修改的情况。
一般情况下，如果只是修复bug，则阶段版本号+1即可；如果既涉及到bug修复，又涉及到较少分支模块的修改，则阶段版号+2；如果超过3个分支模块的修改，则建议直接子版本号+1。

尽管说版本号只是一串数字，但是对于产品经理、开发人员以及用户来说，都是有意义的一串数字，既能规范版本的生命周期，也能方便内部人员的沟通和工作，拍脑袋的去命名版本号是一个不严谨和规范的，而产品经理是需要去追求完美的，希望以上的APP版本的命名规范能够给大家一些参考。

以上，就是APP版本迭代涉及到的各阶段流程整理，以及各个阶级涉及到的各角色的职责以及每个阶段需要输出什么交付物，每个公司每个产品涉及到的流程可能都会不一样，但是大体上来说应该有会包含上述环节，大家可以根据自己的实际情况进行调整。

最后，推荐大家关注他的公众号：Harry李先生笔记

最后，也欢迎有问题的小伙伴加微信：yw5201a1 进行交流。

此外我们的官方网站也上线了，每日分享高质量的文章、原型素材和行业报告，小伙伴可自行前往索取，支持搜索，需要的小伙伴可点击底部的阅读原文直接查看，或者复制网址：www.dadaghp.com 打开。

更多干货可关注微信公众号：产品刘

想学习更多关于产品、职场、心理、认知等干货，可长按右边二维码，关注我们。

··················END··················

RECOMMEND