1

 

一、关于本次插件命令

本次涉及的应该是“XX预置插件”，应该主要针对的未量产的产品吧。个参命令集每个产品至少一个，如果需要修改，需要先梳理受影响的产品清单我们评估工作量再排期。

参考之前杭研插件（重大问题防护）的处理经验，部门是按一天修改一个产品的节奏推进的。如果本次插件也要处理，处理量不超过这个节奏。 

 

二、关于会议组织

工具基本没自己组织会议，也没云笔记本，现在冯工刚离职，我要及时响应产线时间碎片，不适合组织。讨论东西应该不多，建议合并到其他会议里，到时候把相关角色叫上。如果要专门组织，还是建议由BA来牵头，流程和角色更清楚，也应该经常组会

三、设备侧疑问，我先同步下我了解的：

这个关注的应该还是项目和源头侧。产线对插件检查基本处于半开放状态，项目上需要排查或核实时才向产线要日志，脚本不报错应该就没管。

将 check_all_plugin 纳入版本发布管控对质量就有提升。另外如果发现某产品存在检查遗漏，项目上也可以通知到我这边，用命令集临时做防护，对单个产品的修改还是比较快的

 

 

 -----------------

移动新增的插件命令 应该需要尽快部署到产线吧？

按照新流程还要再讨论，还要改版本，来得及吗？

 

 时间点有要求吗？

 

我建议本次移动新增的插件命令就直接部署了，新流程请XX再组织大家线下讨论呢？

 

 

邮件里面新的是是”检查集团三大预置插件“，如果这次要改的话应该针对的是没有量产过的吧。
个参命令集每个产品至少一个命令集。如果需要修改，要修改哪些产品，我们需要评估下。
之前杭研插件是重大问题防护，部门按照一天修改一个产品的节奏规划。如果这个插件急，梳理下产品，也按照这个节奏。

工具基本没自己组织会议，我也没云笔记本，现在工离职，我频繁要处理产线问题，时间碎片化，不适合组织。这个讨论的东西应该不多，建议合并在其它会议里，
专门组织的话还是ba组织吧，对流程和角色更清楚。