产品研发管理流程规范

产品研发管理流程规范

•产品研发整体流程

•产品设计阶段

•产品概念讨论#立项

•输入

•原始业务需求

•规划类需求

•自提自解决需求

•参与人员

•产品经理

•一级中心负责人或二级中心负责人

•产品总监、设计总监、技术总监、架构师、UED负责人、业务负责人

・关键内容

•概念设计目标

•使用场景

•服务对象

•业务流程

•产品量化目标

•核心运营才旨标

•关键彳壬务

•产品经理和一级中心负责人或二级中心负责人或产品总监面对面讨论产品目标、方向、

范围和基本产品雏形设计

•产品经理无需呈现文档,现场口头讲述，结合板书用图文形式辅助自己的表达，将产品

思路表达清楚

•输出

•同意立项，并确定项目级别为集团级或中心一级或中心二级，最终体现在《项目过程确

认单》中

•确定项目范围、相关干系人，关键里程碑评审级别，明确评审组成员

•关键里程碑评审级别确定后，后续的评审专家中必须包含当前级别的专家，可以邀

请高评审级别的专家参与评审

•产品经理以邮件形式发出产品概念讨论会议纪要，告知相关干系人，抄送一级中心负责

人、PMO、QA,并体现上述两点内容

・关键点

•概念讨论可以多次

•项目立项的条件

•产品概念讨论完成

•产品高阶设计及评审#高阶评审

•输入

•讨论通过的产品概念

•参与人员

•产品经理

•一级中心负责人、二级中心负责人

•产品总监、技大总监、架构师、测试负责人、UED、数据部门产品经理、业务负责人

•关键内容

•线框图

•业务流程

•核心业务逻辑1考虑原有逻辑）

•数据概念模型（E-R图）

•提供了表示实体类型、属性和联系的方法，用来描述现实世界的概念模型

•实体在E-R图中用矩形表示，矩形框内写明实体名；比如学生张三、学生李四

都是实体。

•属性在E-R图中用椭圆形表示，并用无向边将具与相应的实体连接起来；比如

学生的姓名、学号、性别、都是属性。

•联系在E-R图中用菱形表示，菱形框内写明联系名，并用无向边分别与有关实

体连蜒来，同时在无向边旁标上联系的类型或m:n）.比如

老师给学生授课存在授课关系，学生选课存在选课关系。

•产品运营指标定义

•明确的非功能需求（性能、安全、兼容性等）

•关键任务

•产品经理对产品进行方案设计并组织评审

•输出

•输出物

•产品设计方案

•输出标准

•产品设计方案开展专家评审,并确定后续各阶段的评审级别和内容（如果涉及到核

心产品逻辑、系统逻辑、关键界面），且评审通过

•评审通过邮件及时发出周知所有干系人，参与高阶设计评审专家执行线下签字流程

・关键点

•产品高阶评审通过之后，产品经理应立即组织产品、开发、测试、UED、数据部门产品

经理、业务负责人、具体执行人员来宣讲产品的高阶设计；

•产品经理可以协调技术总监共同分析数据概念模型并定义出产品的非功能需求

•产品高阶宣讲

•关键任务

•产品经骸寸产品进行方案设计并组织宣讲

•关键点

•产品高阶评审通过之后，产品经理应立即组织产品、开发、测试、UED、数据部门产品

经理、业务负责人、具体执行人员来宣讲产品的高阶设计

•产品详细设计及评审#PRD评审

•输入

•评审通过的产品高阶设计

•参与人员

•产品经理

•一级中心负责人、二级中心负责人

•产品总监、技大总监、敏捷组长/梯队leader.架构师、测试负责人、UED、数据部门

产品经理、数据部门技术经理、业务负责人

•关键内容#包括但不限于

•原型图

•交互流程

•取值逻辑

•业务规则

•各类状态

•提示信息

•产品运营寸旨标的算法及监控手段

•埋点定义（包括数据埋点和UOM业务异常埋点）

•关键彳王务

•产品经理对产品进行详细设计，输出PRD及用户故事（敏捷模式）

•PRD

•用户故事（敏捷模式）

•输出

•产品PRD（根据产品特征，可以是Word或axure文档格式）

•埋点文档（PC和APP）

•用户故事列表（敏捷模式）

•关键点

•产品详细设计0需考虑新老版本的功能和数据兼容,及对周边产品产生的影响；

•产品PRD需要组织产品总监、技术总监、测试经理、UED、数据部门产品经理、数据

部门技术经理进行评审,并执行线下签字流程；

•产品界面、逻辑在过程中倘若必须执行大的变更，需要组织产品总监、技术总监评审，

评审通过方可执行变更，并发送变更邮件告知相关干系人；

•产品需要在PRD文档中明确后台菜单权限及角色逻辑（若涉及后台权限）；

•UOM基本原贝J:

•异常提示语的地方都要需要UOM业务埋点

•异常不给提示语使用默认方式处理都需要UOM业务埋点

•涉及到用户故寻相关内容都为敏捷模式

•产品PRD宣讲

•输入

•产品PRD文档

•用户故事列表［敏捷模式）

•参与人员

•产品经理

•敏捷组长/梯队leader

•参与开发人员、测试人员、UED人员、周报相关系统的产品和开发、产品总监（可选）

和技术总监（可选）、业务负责人（可选）

•关键任务

•产品经理将产品需求文档、用户故事与项目组成员、各个专家进行宣讲

•输出

•产品PRD及用户故事得到参与人的确认，项目组各个角色成员都无疑问，以邮件形式

发出产品宣讲的PRD文档、用户故事列表，并归档于SVN/wiki文档库

•关键点

•涉及到用户故事相关内容都为敏捷模式

•产品数据分析

•输入

•产品交付使用

•关键彳壬务

•产品经理对已交付的产品进行数据分析，作为结项的依据

•输出标准

•《数据分析报告》经过一级中心负责人评审通过，并归档于SVN/wiki文档库

•关键点

•产品数据分析二作是一个持续的过程，项目结项后，产品经理仍需定期输出《数据分析

报告》，并由产品部门负责人在二级中心'数据例会上进行数据汇报

•UED设计阶段

•交互设计及评审

•视觉设计及评审

•开发阶段

•概要设计及评审

•概要宣讲

•开发详细设计及评审

•编码及代码评审

•开发冒烟测试及结果输出

•冒烟测试

•起源

•最初源于硬件行业，在对一个硬件或者硬件组件进行更改或修复后，先不进行直接

测试，而是直接给硬件加电，观察设备是否冒烟。

•软件应用

•对每一

则可以交付给测试人员进行正式测试，如若不通过则打回交予开发人员进行重新修

改

•关键点

•强调要对程序的主要功能进行验证,只有通过了主要功能的测试，才能后续更细化

的测试流程

•测试阶段

•测试方案及评审

•编写测试案例及评审

•执行测试

•上线发布阶段

•发布准备

•日常准备发布文档，包括服务器准备、数据库结构更改、数据初始化、系统切换、灰度方

案、配置更改、外部服务对接申请、外部配合验证等；

•技术经理完成封板前代码评审，并严格执行研发上线checklist检查单，测试经理于17点

之前完成封板，产品经理于当天18:00前完成发布单审批流程,并组织发布流程评审会；

•发布单逾期未完成审批流程或者审批不通过的版本当晚不准上线，血情况必须中心'技术

总监找一级中心负责人报备；

•发布文档评审

•发布前按照日常准备的文档梳理出《发布操作手册》，并经过架构师、产品总监、技术总

监共同评审，且评审通过

•关键点

•技术经理制定《发布操作手册》，明确发布内容、发布步骤和注意事项（写明系统之间

的发布顺序）、回滚方案、发布风险分析（影响的系统和影响内容）等

•回滚方案需要明确系统发布的逆向流程的每个步骤，且6点之前必须完成系统回滚

•产品经理需要组织发布流程评审会，会议内容包括但不限于《发布操作手册》、技术评

审检查点、大数据采集的一致性、产品、测试、业务验证注意事项以及协调外部配合验

证、降级和容错方案、重试机制、应急预案等，并发送评审确认邮件知会相关干系人

•如果此次发布牵涉新老系统迁移，需要明确兼容执行方案和步骤

•发布通知

•发布前至少一天，产品经理通过邮件、豆芽等形式通知相关业务方、外部系统干系人、内

部产品、开发、测试人员，体现上线的版本内容和发布注意事项

•发布执行

•输入

•《项目过程确认单》/《代码评审确认单》

•研发上线checklist检查单签字确认，发布流程评审会确认邮件

•关键任务

•测试人员执行生产发布

•关键点：

•ITP发布单由项目中的技术经理角色提交

•ITP发布单选择评审专家时，要求将涉及到的产品经理、技术负责人、测试负责人、架

构师、SQA负责人等加入评审专家组

•代码评审报告、测试报告、性能测试报告等上传至ITP单

•发布后，开发当晚需完成修改页面的后台菜单及权限匹配（若涉及后台权限配置）

•发布过程中出现异常，不容许当晚技术支持人私自修改发布方案，需要重新修订发布方

案并组织中心技术总监重新评审，评审不通过或无法组织评审必须立即回滚，停止发布

•针对后台新增/变更的页面，上线后由开发输入新增/变更的页面清单给运维，运维在上

线1个工作日内完成对应菜单的操作权限配置（不影响业务操作），若权限不清晰，报

各功能对应产品经理进行确认（若涉及后台权限）

•发布验证

•关键任务

•测试、产品经理和业务执行生产验证，验证范围要覆盖系统的主流程、新增功能

•关键点：

•一级系统以及核心链路上的系统要求开发人员发布后一周内持续查看云迹日志量以及响

应时间，观察是否异常，并输出一周内的《技术验证报告》，提交技术总监评审，其它

系统由中心技大总监视情况而定；

•根据发布评审的要求，进行降级和容错方案、重试机制、应急预案的生产演练；

•测试、产品经理生产验证完毕之后12小时内发送验证邮件，告知相关干系人验证结果；

•产品经理的验证邮件中要体现上线的功能清单，以明确当前版本具体的上线功能内容，

并在12小时内完成ITP单验证流程；

•产品经理至少在发布睑证后24小时内输出《产品指导手册》，方便业务及时展开推广；

•若验证失败，须及时联系产品总监和技术总监，评估解决方案，6点之前完成回滚或者

紧急修复；

•产品验证时，需对照埋点文档验证埋点数据，殓证埋点数据正确性。

•业务推广#业务验证与试用

•准入标准

•生产环境验证成功

•关键彳王务

•产品经理要第一时间告知业务方该版本所上线的功能点，并输出《产品指导手册》

・关键点：

•产品经理至少在发布验证后24小时内输出《产品指导手册》，方便业务及时展开推广

工作

•业务试用期内，产品经理协助业务方在产品上线后到结项前安排业务角色和真实用户试

用产品，收集试用反馈，与业务负责人做好充