背景:
一般来说项目迭代,每个公司都有自己节奏,但是我去过公司大差不多。
总结起来:及时沟通 + 及时推动解决 +及时同步 + 风险控制。
需求初审会
-
需求初审前提前查看好对应的需求,预估对应的工作量,提前安排好QA资源
-
技术优化需要单独跟研发对一下对应的预计提测时间,影响范围,和风险大小
-
根据研发填写的资源,确认owner
注意事项:
提前一天查看对应的需求详情,对存在疑问的地方标注
当天提醒研发leader查看需求初审和预先评估对应的研发资源
评估每个需求的QA 预估工时
技术需求单独和研发确认影响范围,改动大小,预计提测时间
了解过往每个人负责的主要业务模块,根据当前版本需求量的情况进行分配
技术宣讲会
组织技术宣讲会
-
针对难度系数 大的,单人工时评估>4天的 业务需求考虑组织技术宣讲,记得提前定会议室和通知需要技术宣讲的ower做好准备
-
可以自己先评估,然后在找对应的研发负责人确认一下
-
开技术宣讲会之前需要提前了解需求和阅读技术宣讲文档,对存在疑问的地方进行标
-
检查研发填写表格和工时填写情况
-
Tapd创建对应版本的发布计划,星期五~星期一,提醒产品将对应需求挂在tapd上。
-
星期五开始创建对应的技术宣讲表格,技术宣讲当天点名提醒。
-
技术宣讲评估结果同步
- 同步之前, 需要自己 + QA leader check一下对应的研发填写结果,是否有需要补充和修改的。
- 存在有风险,延期需求,不排资源单独跟owner进行核对确认情况。避免由于信息不一致,导致的延期
- 需要对研发写的延期,有风险, 不排资源的备注中圈圈上对应的产品和研发leader
研发leadercheck 研发工时通知
版本进度同步
提测情况 (跟版+非跟版)
非预期延期需求跟上级领导报备。
注意事项:
-
非预期延期的需求一定要知道具体是什么原因导致的,现有的可行的解决方案有哪些,风险是否可控
-
解决方案:加班/拆分部分需求/客户端先行,H5&服务端后行(风险可控)/需求优先级调整
事故复盘会
-
线上突发问题,第一时间联系对应负责人, 拉群进行紧急排查和止损
-
线上重大问题,具体事故原因和影响点,改进方案,通知直接负责人编写复盘报告,事故数据评估影响可以找数据组来协助完成
-
如果达到了事故定级的标准,需要开对应的事故复盘会。可以提前确定下负责人确定时间。
节假日研发值班表
-
【放假前一周开始填写】春节,五一,十一需要邀请各个部门负责人(发一份给运维部服务台填写运维相关内容)填写值班表格。
-
【放假前2天发送】发送邮件
-
【放假前2天发送】发送到【综合反馈大群】
-
长假期(春节,五一,十一)提前跟产品研发部门 沟通好发版时间和放量