项目质量保障实例：加入新团队，我是如何完成版本发布的

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、策略：

业务、组织、研发、质量等等维度，如何采取策略？后续更多内容欢迎阅读：项目质量保障实例：加入新团队，我是如何完成版本发布的

个人原创作品，引用请指明来处，未经允许不可商用。