项目研发流程与制度

需求变更流程规范

申请上线

临时性发布试问点(开发答复->运维/测试span style=\

测试&验收

需求详细评审

用例评审

发布上线

提出修改/新增需求

通知所有相关方

代码实现

运维发布规范：一、审核：1、发布前确认发布计划的合理性&完整性2、确认发布工单的有效性二、线上发布范围1、运维类线上操作2、服务发布、重启3、数据修复等三、发布时间要求1、正常可发布时间：周一~周四，下午2:00~4:00，晚上：7:00~9:002、非规定发布时间内，钉钉申请紧急发布，审批通过后才可发布（除紧急修复线上问题，节假日封版期间不开放紧急发布申请入口）3、属于【线上发布范围】内的，都需按照规定的发布时间内操作，并告知测试四、发布监控1、运维在发布期间，先进行小流量的灰度观察，无问题再全量。2、发布期间，开发、运维关注服务监控，有问题第一时间进行回滚。

系统测试

产研测流程

发起：技术参与：产品、业务、BI、大数据产出物：1、技术方案确认2、产品明确埋点需求并同步给项目组成员

灰度数据效果：输出&负责周知方：策略分析部(学超部门)被周知方：产品部、研发部、设计部、市场部、销售部、运营部、客服部、策略分析部、抄送老板周知时间：灰度3天左右(具体灰度量级&时长由策略分析部同学决定)周知内容：1、此次上线的核心需求的数据效果&分析结论2、给出是否可全量的参考建议3、核心关注指标：PV*PV点击率*点击报名量*单价

产品prd终稿(若有流程则需输出业务流程和数据流程图)

需求疑问跟踪列表

需求收集

联调

发布计划：1、PM汇总此次项目的发布计划(acm配置、数据库变更、服务发布顺序，回滚计划等)。

设计产出

是否测试通过

冒烟

项目总结

验收

编写测试用例

开发详设评审/测试用例评审/需求答疑、跟踪

通过

需求变更/紧急需求

发布计划及邮件

组织相关方讨论

前后端联调

测试产出

上线

测试用例初稿

业务方

交互评审

prd(产品)

不通过

需求分析

交互稿验收

1、做好需求变更内容&需求分析2、负责更改测试用例，保证用例与需求同步3、调控测试进度，保证任务的正常完成

交互初稿视觉初稿

排期报告+测试计划(PM)

项目立项

冒烟验收

PM更新排期计划

测试用例内审

交互&视觉产出

测试修改用例

技术详设(开发)

操作手册：周知时间：后端发布上线当天输出&负责周知方：产品周知内容：1、功能中重点逻辑调整方案2、功能设计的基本操作流程周知人员：产品部、研发部、设计部、市场部、销售部、运营部、客服部、策略分析部

交互、视觉验收

PM确认是否变更

全流程规范

发起：业务产出物：目标策略行动分解表

小程序发版规范：端口：B、C端主包发版节奏：1.每周一、四作为小程序的日常提审窗口期，并邮件记录主送产品部、研发部、设计部、市场部、销售部、运营部、客服部、策略分析部2.紧急发版：符合故障定级规范中P2及以上或有资损的故障允许申请版本

拒绝

业务方向讨论会

复盘报告

冒烟用例执行

产品prd初稿+原型

需求设计

结束

研发产出

复盘会

开始

全量

开发详设评审/测试用例评审/交互&视觉答疑、跟踪

测试用例评审

产品修改PRD（原型+文档）

需求要求：1、产品与业务方确认需求的背景、业务价值2、产品与技术同学初步沟通需求是否可实现3、正式评审前，需确保prd的完整性4、产品与设计同学确认交互、UI细节，如prd与UI稿不一致时，以prd为准5、正式评审前半天到一天同步prd到相关同学，提前熟悉需求UI效果图要求：1、交互评审前，需确保交互设计、UI设计的完整性2、正式评审前半天到一天同步UI效果图到相关同学，提前熟悉交互设计

开发阶段（方案评审、开发、测试用例编写、评审）

产品验收

变更需求开发

PM(测试暂代)

测试报告(测试)

需求+交互评审

灰度观察

数据分析（数据结论统一以策略分析部为准）

客户端渠道包回归规范：1、新版本线上回归需完成P0级测试用例库 + 新需求模块的回归才可确认上线成功。提供市场部渠道包要求：1、所有对外提供的渠道包必须经过测试，开发同学不允许单独对接市场部同学2、测试同学完成渠道包的安装、功能回归后，邮件发送给市场部，并在钉钉群内周知

立项报告

内审

开发实现及测试用例产出

发起：业务参与：产品、业务、BI、技术、大数据产出物：目标、策略、成本、可行性、风险（参考立项报告模板）

视觉评审

需求评审

需求提出

交互、视觉终稿

运营优化

反馈不变更

项目启动会

测试用例要求：发起方：测试参与人员：项目组所有成员1、需求覆盖全面2、异常覆盖比较全面3、可读性高4、易维护性

视觉稿验收

开发人员

线上回归

测试

app版本上线通知负责周知方：测试周知时间：灰度完成后周知方式：渠道包邮件周知内容：版本所包含的功能周知人员：产品部、研发部、设计部、市场部、运营部、策略分析部、用户运营operation@qtshe.com、数据部 <dashuju@qtshe.com>、生态服务运营中心

修改bug

冒烟测试报告

交互+UI(设计)

开发联调&自测

项目复盘

测试方案

测试日报

测试人员

群内@相关方（设计、开发、测试等）

font color=\"#b71c1c\

需求评审完1~2天左右，收集排期，发立项报告

开发详设文档(大前端&后端共同交付)

需求答疑

测试：1、测试人员把测试过程中发现的bug提交到禅道。2、钉钉群发项目日报，汇报测试进度、bug情况、风险点。3、完成一轮测试后，让UI、产品进行验收。4、上线前邮件发测试报告。

app渠道包邮件周知规范：负责周知方：测试周知时间：灰度完成后周知方式：渠道包邮件周知内容：版本所包含的功能周知人员：产品部、研发部、设计部、市场部、销售部、运营部、客服部、策略分析部、抄送老板

验收(各端口的业务逻辑/UI/交互)

冒烟测试

功能自测

发起：产品参与：技术产出物：成本（预估工作量）、可行性(1、业务价值，2、技术实现 ROI)

运维部署上线

协作复盘发起：研发Owner参与：业务、产品、技术、BI、大数据、设计产出物：CSS(团队反思)

提测

确认上线

冒烟测试报告(测试)

节假日发布时间要求：1、国庆、春节放假一周前全平台封版2、五一放假3天前全平台封版3、其余节假日1天前全平台封版特别说明：封版期间除修复重大bug外，不开放紧急上线入口

研发：1、积极配合修改bug，尽可能当日bug当日解决。

需求变更截止时间：提测之前切记：勿在需求发布前频繁变更

灰度阶段

交互评审发起：设计参与：产品、技术、业务产出物：交互+视觉方案确认

业务阶段

交互评审设计评审

产品&业方邮件确认数据效果&是否可全量：业务方：市场部、销售部、运营部、客服部、审核，并抄送老板确认内容：1、是否同意策略分析部门的建议2、给出是否可全量的决策

操作手册(产品)

数据&项目复盘:发起人：业务方参与人：项目全体成员1、回顾目标；2、评估结果；3、分析原因；4、总结经验；5、项目复盘过程与结果文档存档到语雀；

功能测试

立项要求：1、立项前与相关利益方充分讨论清楚目标、策略、风险、成本

立项报告邮件周知人员：产品部、研发部、设计部、市场部、销售部、运营部、策略分析部、用户运营operation@qtshe.com、数据部 <dashuju@qtshe.com>、生态服务运营中心

验收(各端口的业务逻辑、UI、交互)

产品经理

发布

需求跟踪列表

测试报告及邮件

灰度

立项标准&要求：1、立项标准：≥8人天2、明确项目背景、现状、目标、起止时间，未明确的不予立项3、明确需求范围，明确需求内容、视觉、交互的完整性，未明确的不予立项4、确认完整prd的交付时间5、确定需求的优先级6、确定后端技术方案评审时间项目故障处理：1、项目接口文档(后端提供)未按时提供，按故障处理(P3)， font color=\"#f44336\

立项报告(业务方)

测试用例(测试)

产品产出

编码开发

发布计划(开发)

测试方案(附在立项测试计划内)

产出&负责周知方：产品周知时间：后端发布上线当天周知内容：1、功能中重点逻辑调整方案2、功能设计的基本操作流程周知人员：产品部、研发部、设计部、市场部、销售部、运营部、客服部、策略分析部、用户运营operation@qtshe.com、数据部 <dashuju@qtshe.com>、生态服务运营中心

测试用例终稿

渠道包

操作手册

发起人：产品验收人员：产品、UI、业务方业务方：市场部、销售部、运营部、客服部、审核，并抄送老板确认方式：演示会/邮件确认/钉钉群沟通确认内容：1、功能验收2、优化意见反馈

业务侧流程

产出物：1、发布计划 @开发2、测试报告@测试3、钉钉申请发布工单 @开发

需求阶段

交互、视觉终稿确认

交互、视觉初稿

方案设计

输出文档

编码

需求变更各角色职责

数据复盘发起：业务参与：产品、技术、BI、大数据、设计产出物：业务目标(好、坏、策略手段)

流程说明图

需求评估

开发阶段

1、把控需求变更提出的时间点&需求紧急程度&优先级2、负责协调变更的需求并对变更的需求有拒绝的权利3、确认项目进度是否需要进行变更

通过邮件/钉钉群内发起

需求池筛选需求

技术方案评审要求：发起方：服务端参与人员：项目组所有成员1、服务端组织设计方案讨论会，评估并明确需求落地是否有难点2、在项目正式立项前，提供设计方案文档并组织评审3、设计方案应包含：系统交互逻辑，本次逻辑的调整及相关影响，接口设计，表设计，三方插件的使用，及方案设计的优缺点4、设计方案要经过业务、产品、测试、架构的认可，若有一方不认可，上线后出现问题，开发全责

需求评审发起：产品参与：技术、业务、BI、大数据、设计目标(结果)：成本、可行性

客户端主包发版规范：1、按照月度迭代，月末最后一个周的周一到周三提审版本

发起变更申请

产品&UI：1、完成UI、产品逻辑的验收，并钉钉群周知验收结果。

BUG修复

开发详设评审

接口设计

PM

测试用例编写

规范&要求

测试用例设计

编码设计详设评审

测试用例执行&测试报告

冒烟测试用例执行&冒烟测试报告

开发详设文档评审

发起验收(UI、产品、业务方)

冒烟测试通过标准说明：1、对应模块P0级回归冒烟case 全部执行 通过率：100%2、新功能的冒烟case 全部执行 通过率：100%3、冒烟发现的bug，提测时修复率：95%

技术详设评审会

测试阶段

1、负责产品需求的提交以及解答项目开发过程中遇到的需求问题2、负责与客户的沟通确认，并及时反馈客户最新需求3、负责与PM的沟通4、负责与客户协调沟通需求变更中需求部分存在的差异

项目中的会议

产出&负责周知方：策略分析部周知时间：灰度3天内周知内容：1、版本相关功能的数据效果2、该版本是否可全量的结论3、灰度量级&时长周知人员：产品部、研发部、设计部、市场部、销售部、运营部、策略分析部、用户运营operation@qtshe.com、数据部 <dashuju@qtshe.com>、生态服务运营中心