时间: 2021-07-30 11:14:33 人气: 9 评论: 0
编辑导读:面对互联网行业中激烈的竞争,让我们的开发流程更完整、更有效率,产品才能脱颖而出。本篇文章总结整理的APP版本迭代流程与规范,主要涉及到版本迭代过程中的规范流程以及涉及到版本各个角色的职责分工等内容,与大家分享。
本篇文章总结整理的APP版本迭代流程与规范,主要涉及到版本迭代过程中的规范流程以及涉及到版本各个角色的职责分工等内容,分享给大家:
本文目录如下:
基于现在的开发流程中缺少的环节进行补足,使得开发流程更加的流畅和正规化,以便以后的查阅与归档使用。面对互联网行业中激烈的竞争,让我们的开发流程更完整、更有效率,产品才能脱颖而出。
本文档适用于App产品的迭代研发,主要流程包括:需求汇总、需求评审、技术&用例评审、开发&测试排期、开发&测试、内测体验等环节。以后的产品开发流程也可以参考此文档的环节进行开发。
本文档的目标读者对象主要包括:
产品经理:输出&收集汇总每个版本迭代的需求,同时对App迭代进行体验验收,需求汇总阶段、需求评审阶段、内测体验阶段的主要负责人。
交互设计师:根据相关需求文档,进行交互优化,输出优化原型图,提升产品整体用户体验。
视觉设计师:根据需求文档&交互原型图作为视觉设计的步骤和资源产出的依据。
项目经理:组织发起需求评审,并跟进评审结果及输出开发测试排期,需求评审阶段、发布上线阶段的主要负责人。
开发:主导发起部分复杂需求的技术评审,根据需求文档编写代码,开发测试过程由版本经理主导推进,为迭代上线负责。
测试:根据需求文档设计相关测试用例,并主导发起用例评审,跟进测试阶段的Bug解决。
阶段推进方:主要由产品主导推进与收尾
产品部门&版本主要产品经理:
阶段参与方&职责:
交互设计师:
视觉设计师:
项目经理:
开发:
测试:
查阅产品拟定的本版本迭代需求汇总,并初步提出相关疑问点
阶段工作描述:
需求汇总阶段也是版本迭代的准备阶段,该阶段主要为需求的汇总及UED方面的设计输出,同时也为需求评审准备相应的材料与文档。
阶段交付成果:
(点击查看大图)
阶段推进方:主要由产品主导推进与收尾
阶段参与方&职责如下:
项目经理:
开发:
测试:
阶段工作描述:
需求评审阶段是版本迭代的关键节点,该阶段主要需要对需求进行严格的审阅与传达,需要需求方与实现方进行完整全面的沟通。同时也是后续技术设计评审、测试用例评审的根基,力求将问题放在初期解决确认。
阶段交付成果:
阶段推进方:主要由项目经理主导推进与收尾
阶段参与方&职责如下:
产品经理:
开发:
测试:
阶段工作描述:
技术设计方案评审&测试用例评审及排期是版本迭代的重要节点,此阶段延续需求评审后对需求的理解,从开发/测试的角度出发,制定相关方案,为后续开发/测试工作提供指导与依据。
阶段交付成果:
阶段推进方:主要由版本经理主导推进与收尾
阶段参与方&职责如下:
产品经理:
视觉设计:
开发:
测试:
阶段工作描述:
开发&测试阶段是版本迭代的实现阶段,本过程持续时间长,且过程需要大量持续的沟通与工作,需要各方进行紧密的配合。
阶段交付成果:
阶段推进方:主要由产品主导推进与收尾
阶段参与方&职责如下:
测试:
开发:
内测员:
项目经理:
阶段工作描述:
内测阶段是上线前最后一个阶段,在这个阶段需要从常规用户的角度来最终体验,以防存在有未覆盖的点存在问题。
阶段交付成果:
作为移动端产品经理,经常**做APP版本迭代规划,所以不可避免的需要给APP版本确定版号的工作,大多数情况下可能都是拍脑袋确定的版本号。有些公司可能**有专门的项目经理负责版本管理和版本号的命名,但是绝大多数小公司可能都是产品经理来做这项工作。
首先需要说明的是哪些人员需要用到APP版本号,第一是产品经理,第二是开发人员,第三是项目经理,第四是用户。
对于产品经理,APP版本迭代基本都是由产品经理发起的,因此很多情况下都是产品经理在进行需求管理和版本规划的时候就大体上划分了版本号,版本号对于产品经理来说可以更好更清晰的筛选和确定每个版本的需求;
对于开发人员,版本号是直接和代码相关的,很多时候不同版本交叉开发,同一时间可能在开发不同版本,为了保障代码的规范和清晰,避免不同版本出现交叉混乱,版本号是极其重要的一环;
对于项目经理来说,版本号是需求管理中唯一标识符,需要根据版本号去管理和分配下发工作,同时也为了在软件产品生命周期中更好的沟通和标记;
对于用户来说,尽管版本号对于用户来说只是一串数字,但是版本号给用户的感知是不断更新的数字,可以通过版本号来判断自己的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.1 主版本号
6.3.2 子版本号
6.3.3 阶段版本号
尽管说版本号只是一串数字,但是对于产品经理、开发人员以及用户来说,都是有意义的一串数字,既能规范版本的生命周期,也能方便内部人员的沟通和工作,拍脑袋的去命名版本号是一个不严谨和规范的,而产品经理是需要去追求完美的,希望以上的APP版本的命名规范能够给大家一些参考。
以上,就是APP版本迭代涉及到的各阶段流程整理,以及各个阶级涉及到的各角色的职责以及每个阶段需要输出什么交付物,每个公司每个产品涉及到的流程可能都**不一样,但是大体上来说应该有**包含上述环节,大家可以根据自己的实际情况进行调整。
Harryli,微信公众号:Harry李先生笔记,人人都是产品经理专栏作家。3年产品经验,主要关注互金、新零售等领域,以及行业热点相关产品、运营内容。
本文原创发布于人人都是产品经理,未经许可,禁止转载
题图来自Pexels,基于CC0协议。