规范流程图
2021-08-10 15:24:44 48 举报项目流程规范&各角色职责
作者其他创作
大纲/内容
冒烟测试报告
系统测试
修改bug
开始
线上回归
输出&负责周知方：产品周知时间：后端发布上线当天周知内容：1、功能中重点逻辑调整方案2、功能设计的基本操作流程周知人员：产品部、研发部、设计部、市场部、销售部、运营部、客服部、策略分析部
PM
完成对数据信息项的全面梳理
测试用例评审
冒烟验收
需提供：1、发布计划 @开发2、测试报告@测试3、钉钉申请发布工单 @开发
数据复盘发起：业务参与：产品、技术、BI、大数据、设计目标(结果)：业务目标(好、坏、策略手段)
测试日报
业务1
交互&视觉产出
需求阶段
灰度
测试
交互、视觉终稿确认
加工后数据2
交互、视觉初稿
技术方案设计文档
确认上线
提测
通知所有相关方
需求答疑
需求评估
冒烟测试
需求变更各角色职责
概要设计
测试报告
需求提出
需求评审
开发阶段（开发、测试用例编写、评审）
测试用例内审
设计产出
允许自测
测试产出
验收(各端口的业务逻辑/UI/交互)
1、做好需求变更内容&需求分析2、负责更改测试用例，保证用例与需求同步3、调控测试进度，保证任务的正常完成
测试人员
测试阶段
跟进试运行
迭代更新部署
验收(各端口的业务逻辑、UI、交互)
原型设计
代码实现
开发自测
上线
开发人员
运维团队
验收测试
交互评审发起：设计参与：产品、技术、业务目标(结果)：交互+视觉方案确认
1、概要设计说明2、数据库设计说明3、详细设计说明
发起：产品邀请业务方参与验收确认方式：演示会/邮件确认/钉钉沟通)确认内容：1、确认此次产品功能是否满足需求2、有无优化建议
QTS项目流程规范(含业务方)
产品经理输出文档
数据模型
复盘会
组织项目会议
PM输出文档
测试输出文档
立项(立项报告、测试计划)
渠道包
跟踪项目进展
开发提发布工单
需求分析
数据分析（数据结论统一以策略分析部为准）
开发实现及测试用例产出
立项阶段
通过邮件/钉钉群内发起
测试排期
修改PRD（原型+文档）
技术详设评审会
测试用例初稿
开发详设评审
是否通过
内审
发布计划
测试方案(附在立项测试计划内)
需求变更流程规范
产品验收
开发阶段
数据质量
发布(需提供：测试报告、发布计划、发布工单)
收集整理新需求
迭代更新修复
增加：上线后数据效果同步
主数据
发起变更申请
技术方案评审
需求：产品bug：开发/新测试需告知：提测时间及影响点
数据库设计
大数据对内协作
通过
立项报告
跟进项目验收
收集项目计划
开发联调&自测
交互初稿视觉初稿
开发详设文档(大前端&后端共同交付)
大数据对外协作
提出修改/新增需求
需求+交互评审
统一正确的数据观
需求初评
需求详细评审
标准：1、多少时间节点内的项目营收2、不属于日常事项，属于长期策略的就需要考虑XX人日3、分类：不需要产研支持，需要产研支持->立项项目
需求变更截止时间：提测之前切记：勿在需求发布前频繁变更
收集整理需求
加工后数据1
Kick off meeting
详细设计
禅道提需求/bug
集成测试
产品prd初稿+原型
不通过
开发详设评审/测试用例评审/交互&视觉答疑、跟踪
需求池筛选需求
感性思维和理性思维结合运用
发布(需提供：测试报告、发布工单)
编码实现
交互评审
需求跟踪列表
运维阶段
更新排期计划
1、关注项目进度2、解决风险问题/推动解决风险问题3、协调资源4、会议纪要5、需求变更控制&同步
联调阶段
项目过程中及上线后
需求疑问跟踪列表
相关方(运营、市场等)
数据源3
产品经理/PM
设计稿评审
研发团队
需求变更控制
测试方案
前后端联调
冒烟用例执行
视觉评审
验收阶段
验收
测试用例执行&测试报告
结束
发布上线
测试Owner评估
回归测试
发起：产品参与：技术目标(结果)：成本、可行性(1、业务价值，2、技术实现 ROI)
线上回归测试
需求收集
接口设计
变更需求开发
组织培训
系统培训
方案设计
预估项目周期
是
试运行记录
测试冒烟测试
产品团队
业务2
交互、视觉验收
参照数据
测试用例设计
产品产出
产品prd终稿(若有流程则需输出业务流程和数据流程图)
测试通过
互相学习，补足对方的知识
业务方
开发详设评审/测试用例评审/需求答疑、跟踪
不允许
研发产出
测试计划
数据源1
申请上线
数据标准化
反馈不变更
PM(测试暂代)
1、把控需求变更提出的时间点&需求紧急程度&优先级2、负责协调变更的需求并对变更的需求有拒绝的权利3、确认项目进度是否需要进行变更
需求变更（在此阶段前可发起需求变更，具体流程见需求变更流程）
输出&负责周知方：策略分析部周知时间：灰度3天内周知内容：1、版本相关功能的数据效果2、该版本是否可全量的结论3、灰度量级&时长周知人员：产品部、研发部、设计部、市场部、销售部、运营部、策略分析部
需求评审发起：产品参与：技术、业务、BI、大数据、设计目标(结果)：成本、可行性
测试用例终稿
1、负责产品需求的提交以及解答项目开发过程中遇到的需求问题2、负责与客户的沟通确认，并及时反馈客户最新需求3、负责与PM的沟通4、负责与客户协调沟通需求变更中需求部分存在的差异
拒绝
视觉稿验收
测试团队
发起：技术参与：产品、业务、BI、大数据目标(结果)：1、技术方案确认2、产品明确埋点需求并同步给项目组成员3、详设评审后发立项报告
1、需求文档2、需求变更记录3、用户操作手册
交互稿验收
服务端输出文档
需求设计
系统联调
发起：业务方参与：产品、技术目标(结果)：调研、可行性
发布计划及邮件
app上线版本周知负责周知方：测试周知时间：灰度完成后周知方式：渠道包邮件周知内容：版本所包含的功能周知人员：产品部、研发部、设计部、市场部、销售部、运营部、客服部、策略分析部
操作手册(产品)
发起：业务方/产研(产研共创项目则是产品或技术发起)参与：产品、技术、BI、大数据、设计目标(结果)：调研、可行性、目标、关键策略、利益相关方、粗时间节点
监控项目进度
确认是否变更
发起验收(UI、产品、业务方)
各角色职责
数据资产
形成数据工作的标准流程与规范
开发详设文档评审
交互、视觉终稿
上线部署
组织相关方讨论
协作复盘发起：研发Owner参与：业务、产品、技术、BI、大数据、设计目标(结果)：CSS(团队反思)
授权数据部门对指标进行统一定义
发布阶段
编写测试用例
群内@相关方（业务方、开发、测试等）
正式发布前
修改用例
用例评审
测试用例
测试报告及邮件
冒烟测试用例执行&冒烟测试报告
BUG修复
业务方向讨论会
部署及试运行阶段
项目流程
需求终评
运维记录
业务3
验收(业务、产品、UI)
验收(产品、UI)
加工后数据3
数据源2
0 条评论
下一页
