企业产品管理规范
1 产品资料维护
内容：资料类型-存放地址-说明-地址
规则： 1、产品研发层面的边界需要框定在总体架构体系内，设计之前先考虑是否符合
2、产品总体架构需要变动需要经过产品总监评审
3、产品细节功能由产品负责人、交互、关键用户确定即可
4、产品迭代目标需要让内部产品团队评审
|-维护规则【SVN为例】
|- product //顶级目录
|- 大产品线名称 //命名规则：产品名称
|- 子产品线名称 //命名规则：产品序号+产品名称，如：10-缺陷管理
|- 10-产品资料
|- 产品规划 //维护该产品的规划资料
|- 产品版本 //仅维护可对外部署版本资料即可，命名规则：版本+上线时间，如：5.1.5版本-20-12-10，最长不能超过一个季度发布一次可对外版本
|- 产品介绍
|- 帮助手册
|- 功能清单
|- 测试用例
|- 版本特性
|- 20-研发过程资料
|- 版本 //命名规则：版本号+主特性+时间，如：5.1.5版本【移动端支持发起音视频】-20-12-10
|- 版本特性 //维护需求文件，命名规则：如：5.1.5版本特性.ppt
|- 需求 //维护需求文件，命名规则：场景.png
|- 交互/设计 //维护交互/设计源文件和导出文件
|- changelog //维护版本更新记录，如5.15版本changelog.md
|- 30-竞品资料
|- 竞品名称 //命名规则：如钉钉
|- 40-其他资料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、格式要求
|
类型
|
模版地址
|
备注
|
|---|---|---|
| XXXX存档（如PAM里程碑交付物等） | svn://product/100-XXXX/XXXX交付件模版/需求规格说明书-系统名称-内部模版-19-10-17.docx | word格式 |
| XXXX存档（如立项资料/结项资料） |
|
pdf格式 |
| XXXX存档（如ITRDM交付物等） |
svn://product/100-XXXX/XXXX周版本交付件/RS-需求编号-需求规格说明书模板-年-月-日-v版本序号.docx |
word格式 |
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版本，需要的依赖库，外部接口的连通性
后台版本发版管理
原则： 不拉项目分支，只保持一个分支
如何避免发版错误
临时项目分支和统一的产品分支，所有项目特性回收产品
避免产品对项目的影响
- 产品新特性分析要考虑已存在的各个项目需求
- 通过配置、插件化等方法隔离产品和项目差异
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、客户需求与产品迭代
客户升级大部分是为了产品的新特性去满足客户新需求，产品的迭代要尽可能去纳入客户比较好的需求，同时，纳入产品的客户需求要给项目经理或客户有产品时间线的承诺
