组内技术管理梳理

目的、要解决的问题：

1. 明确 A 版质量标准，保障 A 版完成度、质量，避免重复性问题占用 A 版验收阶段时间；

2. 梳理 A 版验收阶段存在的问题，讨论推进、协作问题；

   利用好 A 版时间，最大限度的保障提测时的质量，避免后续提测阶段工作紧张；

3. 给程序做绩效窗口，研发做的好的地方留记录；

‍

线上问题：

1. 第一责任人：

   高亚闯、王建、赵恒

   如果需要其他程序介入，表示优先级高于当前所有开发任务，请立即介入；

2. 跟进阶段：

   1. 启动：3-5 分钟时间，做问题识别、分类，同步给关联人员（相关程序、策划），必要时通知 QA 复现、确认问题；

      1. 紧急、严重问题我会直接介入；
      2. 普通查询、补单等问题，后端直接处理；

   2. 排查：30 分钟仍未定位到问题、或预估短时间难以解决问题，群里同步进度，通知我介入评估解决方案；

   3. 流转：问题解决后，飞书问题中填写处理意见（包括原因、处理方案、结果评估），流转问题状态；

   4. 反馈：线上反馈群里同步最终处理结果；

3. 记录、复盘：

   1. bug 类、缺陷类问题，起文档保留现场；
   2. 未解决、需后续优化的问题，以飞书缺陷记入技术债；
   3. 参与并且耗费了自己时间的，尤其是可能影响当前研发进度时，在程序排期表里记录，必要时可在排期单元格里添加评论或备注；

‍

技术债：

1. 遗留的 jira、飞书缺陷；

2. 技术瓶颈、待革新的技术层面：

   1. 引擎升级、优化；
   2. 新特性支持；
   3. 代码规范，系统级别优化；

3. 历史遗留问题；

   之后再发现历史问题，都让 QA 提 jira 或飞书缺陷；

4. 通用层和流程积弊：

   1. 缺失、逐渐不适用的自动化脚本、流程；

   2. 亟待重构的代码，如：

      逐渐跟不上需求变化的历史封装、通用模块儿；

5. 偿还：

   1. 必要时以文档形式留档，添加到程序总表-技术文档中；
   2. 添加到程序排期表中记录；

‍

质量、效率控制：

1. A 版验收：

   1. 自测表：

      1. 后续根据需求变化补充、删减，目的是尽可能的保证质量；

      2. 自测表只做记录、提示、预警（后续工作流程是否有延期风险）用，不必影响现行工作节奏，到达 A 版时间节点，直接打板；

         1. 无论自测表中是否都处理完了；
         2. 如果差的很多，比如主体玩儿法都不完整，我们根据情况及时调整排期；

      3. 记录：没有的条目，备注填无，完成的画勾；

         因为上游问题导致未完成的条目，备注里简单记录一下；

   2. 明确 A 版时间节点：

      1. 研发排期的最后一天，不要占用 A 版验收时间；
      2. 保障平均 A 版验收阶段时长，关卡：2-3 天，活动：1-3 天；
      3. 如果研发进度异常或其他特殊情况确实无法保障 A 版节点，及时沟通适当调整预期或排期；

   3. A 版反馈修改进度：

      1. 杜绝一天一个版本，把握好粒度，改完的及时发布出来，不要影响策划验收；

         策划这边会避免跟之前一样，按版本提，从建立 A 版反馈回档时，就可以给出链接，同步更新；

      2. 第一天优先改流程反馈，

         关卡这边要保证第二天龚师傅能顺利介入，避免 A 版反馈最后一天才能让龚师傅介入的情况；

      3. 后端这边及时推动数值产出，避免因为数值问题卡前后端进度；

      4. 涉及需要等待美术、动画、数值修改，影响研发进度的情况，及时同步给策划协调沟通，必要的时候反馈给我介入协调；

      5. 涉及重大需求改动、优化的，同步给我，我去评估、沟通；

      6. 如果其他岗位有明确版本需求，及时响应；

      7. 统一了策划的 A 版反馈文档格式；模板

2. 代码 review：

   1. A 版我这边会做一次粗略的代码 review，主要评估代码量和明显代码设计问题；

   2. 重点代码审查：

      如果出现较大修改、基础代码修改，同步给我，由我或指定其他人讨论审查；

   3. 交叉评审：

      1. 量级较小、review 耗时少的代码，如果有 review 需求，可自由找其他人审查；
      2. 高质量的代码、存在弊病的历史代码，可随时拿出来讨论、review；

3. 提测：

   1. 保证封版节点，通常周三晚上，视情况动态变更；

   2. 杜绝压着版本不发；及时更新 jira；

   3. 如果其他岗位有明确版本需求，及时响应；

   4. 涉及重大需求改动、优化的，同步给我评估、协调；

      1. 具体要不要改，以需求端为主；
      2. 程序端负责评估成本，我去协调人力、排期；

   5. 涉及需要等待美术、动画、数值修改，影响研发进度的情况，及时同步给策划协调沟通，必要的时候反馈给我介入协调；

      如果最终无法协调、确实影响到程序进度，我这边也会做必要的同步；

   6. 如果出现棘手问题、高耗时的技术问题，要及时同步给我共同评估，不要死磕；

4. 发版：

   1. 发版未完成时，相关人员必须在公司；

5. 上线业务反馈：

   1. 研发端在研发、A 版、提测环节无疏漏的情况下，爆款、市场表现较好的业务功能，作为绩效评估因素记录；

‍

绩效评估参考：

1. 绩效评估结果公示，有异议的单聊；

2. 评价指标：

   1. 各任务节点高质量记录、delay 情况；
   2. 技术债偿还记录；
   3. 爆款、市场表现较好的记录；
   4. 线上问题响应；
   5. 日常问题响应速度、状态；
   6. 内部合作：帮带，积极参与交叉 review 等；
   7. 公司绩效评级标准；

‍

补充一下：

1、程序的排期表，功能会如果是自己去的，自己填一下或者结束后通知我更新排期表；

2、QA 一直拒接在研发分支提测关卡；

‍