建议收藏：APP版本迭代如何避免踩坑？
本文由作者 Harryli 发布于社区
这是我之前好友总结整理的APP版本迭代流程与规范，主要涉及到版本迭代过程中的规范流程以及涉及到版本各个角色的职责分工等内容。
为了避免和团队成员撕逼扯皮，可以按照如下规范流程和团队成员宣导，落实每个环节各个角色的职责和内容，保证每个环节都能高效协作，避免踩到坑里，相关干货流程分享给大家。
本文目录如下：
一、引言
二、需求汇总阶段流程
三、需求评审阶段流程
四、需求开发&测试阶段流程
五、内测阶段流程
六、APP版本号命名规则
01
引言
1.1、目的
基于现在的开发流程中缺少的环节进行补足，使得开发流程更加的流畅和正规化，以便以后的查阅与归档使用。面对互联网行业中激烈的竞争，让我们的开发流程更完整、更有效率，产品才能脱颖而出。
1.2、范围
本文档适用于App产品的迭代研发，主要流程包括：需求汇总、需求评审、技术&用例评审、开发&测试排期、开发&测试、内测体验等环节。以后的产品开发流程也可以参考此文档的环节进行开发。
1.3 、读者对象
本文档的目标读者对象主要包括：
产品经理：输出&收集汇总每个版本迭代的需求，同时对App迭代进行体验验收，需求汇总阶段、需求评审阶段、内测体验阶段的主要负责人。
交互设计师：根据相关需求文档，进行交互优化，输出优化原型图，提升产品整体用户体验。
视觉设计师：根据需求文档&交互原型图作为视觉设计的步骤和资源产出的依据。
项目经理：组织发起需求评审，并跟进评审结果及输出开发测试排期，需求评审阶段、发布上线阶段的主要负责人。
开发：主导发起部分复杂需求的技术评审，根据需求文档编写代码，开发测试过程由版本经理主导推进，为迭代上线负责。
测试：根据需求文档设计相关测试用例，并主导发起用例评审，跟进测试阶段的Bug解决。
1.4、App迭代阶段流程图
（点击查看大图）
02
需求汇总阶段
– 负责发起版本迭代 – 输出相关App迭代需求 – 收集其他需求方的App迭代需求 – 汇总并进行需求的初步分类与优先级评定 – 决策相关需求方案是否需要技术介入进行前期初评 – 决策相关需求方案是否需要进行交互优化&视觉设计 – 邮件发送需求汇总清单至相关责任人 – 确认需求汇总完毕后发起需求评审 – 汇总、整理、输出本阶段相关交付结果
阶段参与方&职责：
交互设计师
– 根据需求文档及需求原型图，进行交互层面优化，提升产品的用户体验 – 自发发起用户体验提升相关的需求，并提交给产品经理汇总入版本迭代需求中 – 输出交互优化稿后与产品经理进行评审确认
– 根据需求文档及需求原型图或交互原型图，进行视觉设计 – 输出效果稿进行视觉设计评审确认 – 输出标注稿供客户端开发工程师对照开发 – 输出相关测试用效果切图，供开发&测试过程直观查看效果用
– 根据开发对需求提出的疑问点进行分类汇总 – 组织安排评审会议
– 适时参与产品发起的需求方案初评 – 查阅产品拟定的本版本迭代需求汇总，并初步提出相关疑问点
– 查阅产品拟定的本版本迭代需求汇总，并初步提出相关疑问点
阶段工作描述
阶段交付成果
版本迭代需求汇总 产品需求文档 UE交互优化稿 UI视觉设计稿&标注稿 需求初期疑问点汇总
03
需求评审阶段
3.1、需求评审
（点击查看大图）
阶段推进方：主要由产品主导推进与收尾
– 负责发起版本迭代需求评审 – 配合项目经理组织需求评审会议 – 在需求评审会议中进行需求宣讲讲解 – 针对汇总后的需求疑问点进行答疑与沟通 – 需求的责任人需进行需求讨论记录并在会议的最后进行需求讨论记录的确认
阶段参与方&职责如下
项目经理
– 组织安排评审会议，召集相关人员 – 汇总并与相关方确认最终的需求范围
– 会前确认主流程、主方向、主内容的认可 – 非常细节的内容，不涉及主流程环节可会后单独与产品经理讨论确认 – 参与需求评审，并根据需求讲解情况，提出疑问点，进行讨论确认 – 确认最终的需求范围及需求内容
– 会前确认主流程、主方向、主内容的认可 – 非常细节的内容，不涉及主流程环节可会后单独与产品经理讨论确认 – 参与需求评审，并根据需求讲解情况，提出疑问点，进行讨论确认 – 确认最终的需求范围及需求内容
阶段工作描述
阶段交付成果
各个需求的需求讨论点记录 需求评审总结与会议纪要 需求范围确认后的版本迭代需求汇总清单
3.2、技术/测试用例评审&排期
（点击查看大图）阶段推进方：主要由项目经理主导推进与收尾
– 负责在确认需求范围后，发起开展技术设计评审、测试用例评审 – 负责确认版本经理、测试负责人 – 负责收集各个需求的开发/测试工作量评估 – 负责输出版本迭代排期，并与各方最终确认排期情况
– 参与技术设计/测试用例的评审，并提出疑问并沟通确认 – 确认技术设计/测试用例是否符合需求 – 确认开发/测试的排期情况
– 确认版本经理 – 由版本经理评估相关需求是否需要进行技术设计评审并发起推进 – 根据确认的技术设计方案or需求，进行开发工作量评估 – 参与测试用例评审并确认一级用例范围 – 确认转测条件
– 确认测试负责人 – 输出相关测试用例并分级，发起测试用例评审并推进 – 参与技术设计方案评审 – 根据确认的测试用例，进行测试工作量评估 – 确认转测条件
阶段工作描述
阶段交付成果
技术设计概要 技术设计概要评审会议纪要 测试用例 测试用例评审会议纪要 版本迭代开发&测试排期表
04
开发&测试阶段
（点击查看大图）阶段推进方：主要由版本经理主导推进与收尾
– 对整体开发&测试过程主导推进并负责 – 及时同步进度并进行风险预警 – 推进开发并同时跟进开发进度 – 推进转测并同时跟进测试进度
阶段参与方&职责如下：
产品经理
– 参与进度同步，及时根据风险预警进行调整 – 参与代码开发阶段的讨论，确认细节点 – 参与测试阶段的讨论，确认细节点 – 决策是否需要在开发过程中进行需求变更
– 在测试阶段介入进行视觉还原 – 跟进视觉还原的修复进度 – 确认开发过程中的部分对视觉的问题点
– Coding – 参与转测演示，并对转测演示结果负责 – 在测试阶段及时清理相关Bug与问题 – 与产品积极沟通相关细节点
– 根据转测演示结果，决策是否转测成功 – 发起测试阶段，并根据测试用例进行数轮测试 – 跟进提出的Bug的解决进度 – 与产品积极沟通相关细节点
阶段工作描述
阶段交付成果
相关接口协议文档 测试版本App 版本迭代节点通知 日常进度信息 测试验收报告
05
内测体验阶段
（点击查看大图）
阶段推进方：主要由产品主导推进与收尾
– 推动App迭代内测正常进行，组建内测群，拉内测员 – 整理版本主要更新点并发布内测邀请 – 收集汇总内测员的问题反馈并记录相关反馈人 – 反馈问题的定性与分类，确认是需求orBug，同时进行后续分配与确认 – 判定需求是否采纳，采纳则纳入需求池，酌情安排迭代，不采纳则将原因描述反馈归档 – 归档全部的问题及问题认定后，进行问题反馈分级 – 根据问题反馈分级，对反馈内测员发送对应奖励
阶段参与方&职责如下：
测试
– 确认预发布验证通过，准备内测包并发起内测流程 – 配合产品一起完成对反馈的问题的定性分类分级 – 对分类为Bug的问题反馈，进行确认与复现，同时确认Bug的优先级 – 高优先级Bug，当前版本需解决，录入系统跟进本版本内解决 – 低优先级Bug，可延后解决，录入系统Bug池延后版本解决
– 确认需发布内容的Checklist – 对后台进行逐一发布 – 内测包的打包与准备
– 内测员一般由内部员工或灰度员工参与 – 下载并安装内测包，进行体验 – 重点体验本版本的更新点相关流程 – 轻度体验App的常规常用流程 – 发现问题并在内测群内反馈问题，配合产品完成问题的确定与归集
– 跟进版本迭代的生产环境发布 – 推动最终对外上线发布
阶段工作描述
阶段交付成果
生产环境App 内测体验报告
06
6.1、为什么要规范APP版本号的命名？
6.2、APP版本号的组成与规范
Alpha版：也叫α版（开发环境），此版本主要是以实现软件功能为主，通常只在软件开发者内部交流 Beta版：此版本相对于α版已经有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过多次测试来进一步消除，此版本主要的修改对像是软件的UI。 RC版：此版本已经相当成熟了，基本上不存在导致错误的BUG，与即将发行的正式版相差无几，测试人员基本通过的版本。 Release版：此版本意味着“最终版本”、“上线版本”，，在前面版本的一系列测试版之后，终归会有一个正式版本，是最终交付用户使用的一个版本。该版本有时也称为标准版。一般情况下，Release不会以单词形式出现在软件封面上，取而代之的是符号(R)。
6.3、APP版本号的命名修改规则
当App的多个主要模块有较大的变动，一般情况下比方说APP新增一个TAB，整个产品结构都改变了，或者新增了新的功能或业务。比方说微信上线钱包，抖音上线直播 主版本号起始值为0或者1，具体需要由产品经理来决定是否需要修改主版本号（PS：大多数可能需要老板拍板）
子版本号初始值为0 当APP的较少主要模块发生较大的变动或新增模块（涉及主逻辑变更的）、较多个分支模块发生较大的变动或新增，相对于主版本号而言仅是局部的变动，比方说某个功能上的UI重构，某个页面的优化等，其中较少模块和较多模块需要去定义，一般我们认为较少为小于3个，较多认为是超过3个； 子版本号的最大值需要确定，不同的公司可能有最大的值，比方说最大为9，如果超过9，则需要主版本号进1，也有些公司可能不存在最大值，只会在主版本号+1的情况下才会将子版本号归0。这里没有确定的原则和规范，可以由产品经理自己定规则
阶段版本号初始值为0 什么时候修改阶段版本号，一般是Bug修复、较少个分支模块的变动，比方说视觉、样式、交互、文案等修改的情况。 一般情况下，如果只是修复bug，则阶段版本号+1即可；如果既涉及到bug修复，又涉及到较少分支模块的修改，则阶段版号+2；如果超过3个分支模块的修改，则建议直接子版本号+1。
如何变现？互联网商业产品模式详解 视频场景下，新用户的推荐策略怎么做？ 面试一个人，只问对方这4个问题就够了
点个“在看”吧评论