1 产品资料维护

　　内容：资料类型-存放地址-说明-地址

　　规则：　1、产品研发层面的边界需要框定在总体架构体系内，设计之前先考虑是否符合

　　　　　　2、产品总体架构需要变动需要经过产品总监评审

　　　　　　3、产品细节功能由产品负责人、交互、关键用户确定即可

　　　　　　4、产品迭代目标需要让内部产品团队评审

　　|-维护规则【SVN为例】

　　|- product //顶级目录

2 产品设计流程

• • • 1产品 vs 5-10研发（1端1技术负责人）
    • 1交互 vs 2产品
    • 1视觉 vs 4交互

　　　　人员职责

• • • 产品：在最短时间内把握复杂需求并探索和确定产品的价值、可用性、可行性
    • 研发：评估可行性和实现模型、落地及维护
    • 设计：评估概念模型，提高产品可用性

　　2-2 合作模式

　　　　1、重交互型产品（App/H5/复杂web等）——由交互输出原型

　　　　2、轻交互型产品（控制台/后台等）——由产品直接输出原型

　　　　　　⚠️注：输出规范见产品设计流程和交互设计流程，用例图用于框定边界和满足场景

　　　2-3产品设计过程反思

　　　　　　　　　　　　———是否符合直觉思维

• • • 是否能吸引目标消费者的关注
    • 设计是否人性化、是否易于操作
    • 是否能在竞争中取胜
    • 是否能得到目标用户的认可
    • 是否能在两分钟之内向高层解释清楚与竞品的差异、一分钟之内向用户解释清楚
    • 产品是否完整且能正常运行
    • 特色是否鲜明、是否与目标用户想要的一致
    • 如果有人比我定价低，是否他们会抛弃我，为什么
    • 团队成员觉得产品好在哪里

　　　　⚠️注：在过程中不断验证，尽量在研发前验证

　　2-4 产品设计流程

　　　　　　1、需求输出

　　　　　　2、文档输出

　　　　　　　　文档分为2类

• • • • 面向客户：立项需要、售前需要、升级需要等
      • 面向用户：帮助手册

　　　　　　⚠️注：尽量减少不必要文档的输出，产品经理应该做到最小篇幅最大价值，此篇章仅介绍产品所需输出文档，其他文档见研发篇与测试篇

　　　　　　3、关于需求规格说明书

　　　　　　⚠️注：无项目需求、存档需求的情况下，无需输出需求规格说明书

　　　　　　4、命名规则

　　　　　　　　类型-文件名称-其他信息-年-月-日，如：需求规格说明书-API网关-3月份版本-2020-09-09.doc

　　　　　　5、生成方式

　　　　　　　　通过Axure中的生成word文档方式生成

　　　　　　　　⚠️注：Axure

　　　　　　6、Axure目录结构

　　　　　　　　

　　　　　　7、格式要求

　　　　　　8、关于帮助手册

　　　　　　　　1、命名规则

　　　　　　　　　　同上

　　　　　　　　2、生成方式

　　　　　　　　　　通过gitbook编写，并发布在服务器，支持线上预览

　　　　　　9、关于版本特性

　　　　　　　　按特性或者目标划分一个版本，模块小组相互拆分研发任务支持版本目标达成，产品团队需要在开始版本迭代前已ppt的形式输出版本目标or特性，说明价值，如下

　　　　　　　　⚠️注：特性和价值一定需要被团队所有人员认可，特性不包含详细方案

3 产品版本管理规范

　　3-1 后台管理规范

　　　　发版规范

　　　　1. dubbo接口修改只能新增，不能修改和删除，如果返回字段需要修改也要另外新增一个dubbo接口

　　　　　　dubbo声明会发到maven库，生产环境和测试环境公用一套maven库，避免dubbo接口修改导致生产版本临时更新导致调用失败

　　　　2.版本发布说明里新增依赖关系说明

　　　　　　如果模块A修改需要调用模块B中提供的新方法，或者模块B有配合的改动，需要维护A对B的依赖版本号

　　　　　　对于分离包部署环境

　　　　　　版本发布说明书中新增一项内容，检查模块之间的依赖关系

　　　　　　对于合并包部署环境

　　　　　　要求 mxbase 和 mxApps 同步更新

　　　　3.生产分支管理

　　　　　　生产环境使用 devops 发布，只从release更新，严禁未验证的特性合入release分支，紧急bug修复需先合入dev，验证通过后同步合入release

　　　　4.环境检查

　　　　　　版本发布说明新增一章，检查相关环境信息，如 jdk 版本，Glibc版本，需要的依赖库，外部接口的连通性

　　　　后台版本发版管理

　　　　原则： 不拉项目分支，只保持一个分支

　　　　如何避免发版错误

　　　　　　临时项目分支和统一的产品分支，所有项目特性回收产品

　　　　避免产品对项目的影响

1. 1. 产品新特性分析要考虑已存在的各个项目需求
   2. 通过配置、插件化等方法隔离产品和项目差异

4 产品测试流程

　　一、迭代中的测试流程

　　　　1.了解产品目标

      　　　　 参与产品目标设定、产品策划及测试需求分析，充分了解业务场景。

　　　　2.测试需求分析

       　　　　根据产品提供的测试大纲初稿，细化测试大纲，覆盖详细测试点，形成测试要点大纲。包括功能测试需求和性能测试需求。

　　　　3.测试大纲评审

      　　　　 1）测试人员共享测试要点大纲，提交评审

       　　　　2）产品人员、开发人员在规定时间内自行阅读测试要点大纲，开发人员重点评审自己负责的功能模块，提出建议、补充遗漏或隐藏测试点；

       　　　　3）测试人员收集遗漏测试点，完善测试要点大纲，形成终稿。

　　　　4.提测

　　　　　　接口提测条件：

       　　　　1）新功能接口开发完成

       　　　　2）输出完整接口文档

　　　　　　功能提测条件：

       　　　　1）测试环境稳定，只有提测前才更新测试环境；测试过程中禁止随意更新测试环境

       　　　　2）提测需求明确

       　　　　3）开发人员根据冒烟用例完成自测，并自测通过。 

　　　　　　性能需求提测条件：

       　　　　1）功能开发完成

       　　　　2）测试环境稳定，测试过程中禁止随意更新测试环境      

　　　　5.执行测试

       　　　　1）接口测试

              　　测试人员编写接口测试脚本—执行接口测试—接口测试准出—前后端联调

       　　　　2）功能测试

              　　前后端联调通过—开发自测通过—功能提测

       　　　　3）性能测试

              　　确定本阶段的性能测试需求—编写性能测试脚本–执行性能测试—输出性能测试报告

　　　　6.回归测试

       　　　　 回归验证 BUG，更新BUG状态

 　　　　7.主流程冒烟测试

       　　　　主流程冒烟测试逐渐实现自动化测试，实现快速冒烟：

       　　　　1）接口自动化测试—监控接口，及时发现接口问题

       　　　　2）UI自动化冒烟测试—选取稳定功能，实现UI自动化，取代部分手工冒烟

       　　　　3）手工执行冒烟测试—不适合自动化部分手工执行

　　　　8.测试准出

　　　　　　1）测试准出标准：

       　　　　a.测试用例100%执行

       　　　　b.无严重级别以上的缺陷

       　　　　c.总缺陷修复率大于85%

       　　　　d.产品性能达到预期标准。

　　　　　　2）输出产物：测试报告。

       　　　　测试报告应包含如下内容：

       　　　　a.测试环境

       　　　　b.产品版本号，各个服务的版本号

       　　　　c.用例执行情况

       　　　　d.BUG情况

　　二、稳定版测试

       稳定版的测试分为两部分，一部分是按迭代中的测试流程完成迭代功能的测试；另一部分执行总体的性能测试、总体的接口测试，app兼容性测试、全量冒烟测试、app专项测试。

　　1.总性能测试

       汇总每个迭代中的性能需求，合并每个迭代的性能测试脚本；执行一次总体性能测试，保障产品稳定版本输出符合产品预期的性能需求。 

　　2.全量冒烟测试

       冒烟测试用例逐步转化成自动化测试，实现快速冒烟。

       1）接口自动化测试—监控接口，及时发现接口问题

       2）UI自动化冒烟测试—选取稳定功能，实现UI自动化，取代部分手工冒烟

       3）手工执行冒烟测试—不适合自动化部分手工执行

　　3.app兼容性测试

       兼容性测试点：1、安装启动；2、主要功能和流程

       实现步骤：确定兼容性的功能范围—选取UI自动化测试脚本—选取多台不同型号手机在美的云真机上执行脚本—输出测试报告。

　　4.app专项测试

       总结app常见问题，形成专项测试用例，在稳定版测试时执行。

5 项目发版发布规范流程

6 可持续升级客户的版本和运营模式

关于【客户版本升级策略】的问题：

1、如何定义升级

客户版本升级，一定会涉及项目定制的升级问题，上图强调不允许客户定制，这个说法与现实有出入，准确表述应该是：支持客户对标准产品进行升级，但客户定制部分要进行评估，如涉及对客户定制部分的升级实施，需要有实施团队评估定制部分的实施工作量和风险。

这个升级的定义，有一个前提要求，那就是标准产品代码不能进行客户定制，项目需求只能基于标准产品进行扩展定制。但客户端如何在不修改产品代码的前提下进行客户定制，这存在很大的难点，需要考虑我们定义的这种升级是否具备可行性。

2、如何区分标准与定制

在项目实施过程中，有很多的功能开发定制，并没有经过技术架构方案设计，可能会存在定制代码对产品代码的侵入问题，也就会导致升级的时候，很难判断标准与定制的边界，升级方案很难明确定义实施工作量和实施风险。

所以，这个问题要求任何一个项目，基于产品进行客制化时，一定要先进行技术方案设计，不同的定制需求，分别通过调用哪些产品接口、怎样的流程逻辑来实现定制的，这个需要项目管理过程对技术方案有严格的把关，不能等到升级的时候再回过头来去评估。此外，升级一定涉及到产品版本对比，所以客户当前使用的产品版本一定要有明确无误的记录。

3、如何定义升级的流程

客户的产品模块与版本不同、定制范围不同，升级的诉求也不同，有的是功能性版本升级，有的是紧急性bug修复升级，不同升级的场景，应该有不同的流程，需要定义清楚不同情况下的升级流程，流程甚至要细化到操作级别。当然，升级的流程要基于具体的升级过程去总结，不断完善不同场景的流程，不需要一次性去穷举情况写流程，在具体执行中去定义、执行和优化流程。

4、维保与升级的关系

客户维保的内容应该包括：产品升级授权(不含升级实施本身)、运维支持、技术支持、例行巡检。客户的产品如果有定制，那么升级会涉及到实施的工作量，这部分实施的工作量要另外跟客户谈商务，当然，如果客户用的是标准产品，只有基础的用户和认证集成，所以实施的工作量比较小，这种情况就可以赠送升级实施的工作量。

5、客户需求与产品迭代

客户升级大部分是为了产品的新特性去满足客户新需求，产品的迭代要尽可能去纳入客户比较好的需求，同时，纳入产品的客户需求要给项目经理或客户有产品时间线的承诺