项目研发流程与制度
2021-09-23 17:34:41 4 举报项目研发流程与制度
作者其他创作
大纲/内容
需求变更流程规范
申请上线
临时性发布试问点(开发答复->运维/测试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>、生态服务运营中心
0 条评论
下一页
