1、背景:
由于组织调整,24年1月被调到另一个新的产线。初到一个新的产品研发团队,基本没给缓冲的时间,春节后就立刻投入价值研发。还被指定为版本质量负责人,要连续交付2个月度版本(229版本、330版本)。
2、个人挑战
1)业务维度:百万级代码的产品,业务复杂度非常高。24年已经开始规模化,不是从0开始研发的产品。但自己作为入组不足一月的新人,缺乏对已交付业务的了解,缺乏相关业务特性的质量保障经验
2)组织维度:
团队构成上,组织结构调整前测试与开发分离,测试是独立的团队,但今年测试、开发、产品组成一个业务团队。缺乏研发三角职能间交互设计,基本开发、测试单条作战;
团队人员上,新产线的组织架构也进行了调整,各组的人员有了变化,有该产品以前的人员,也有其他产线过来的新成员。测试人员能力参差不齐,也缺乏一些明确的研发流程和规范要求交底。
3)研发维度:PC端版本由于业务和技术的复杂性,以季度版本为主,较少月度版本发布。即将要交付的2个月度版本中,229版本是hotfix版本,内容少,不具代表性;330版本是新业务价值交付版本,可供研发的时间短、要交付的价值多,测试处于研发下游,质量稳定周期压力较大,尤其是系统测试月度版本要3+5d以上
4)质量维度:没有工作交接,以前怎么搞的只能通过wiki零散资料拼凑。获取到的信息不够系统,也无法窥见以前质量保障体系建设的全貌。
3、思路
1)针对新产品:虽然是一个全新的产品,但与笔者之前所在的产品也有相似之处,都是专业性极强的PC端工具类软件,行业背景也有相似性,质量保障及建设有诸多可参考的地方。
2)针对新组织:作为新组织结构下的第一个版本,处于团队与人员相互磨合的阶段,前2个版本的重点应该放在走通整体交付流程。但也需要记录过程中暴露的问题,及时复盘总结,持续改进并沉淀经验,便与后续做整体建设规划
4、策略:
业务、组织、研发、质量等等维度,如何采取策略?后续更多内容欢迎阅读:项目质量保障实例:加入新团队,我是如何完成版本发布的
个人原创作品,引用请指明来处,未经允许不可商用。