协作机制

场景1：商务用了天舟云1.9，期间发现某个功能存在缺陷或不满足需求，需要平台协助支持解决

错误流程：业务相关人员直接向平台开发同学子弹提出需求，要求解决，平台同学快速响应（期间解决功能的同时，夹带了局部功能优化），然后指挥商务前端同学协助更新商务的平台底座功能，方老板操作完成。平台同学认为任务已完成，前端同学也不知道为啥要改，业务相关人员更不知道商务的功能里面还有平台的功能没测试，最终，所有功能一起随着商务的版本上线，在正式系统中出现了因为平台底层调整，导致上层业务异常。

错误分析：
1.平台需求交付与验收内外没闭环，相关方验收不及时；
2..平台自身测试不全面，做了局部功能优化后，没做场景测试和影响范围评估，可能引发的风险和范围未知悉产品线相关方；

改进过程：
平台相关的功能需求或缺陷，均需要在系统中 (https://s.cvte.com/h26tde1s) 提出登记，平台开发同学针对工单受理，反馈登记对应处理时长和产品线更新指引，安排对应的产品线开发，产品线开发根据系统中记载的原始需求或缺陷问题，进行对应的更新和功能测试，测试OK后再流程下推给最开始的提出人进行回收和测试验证，产品线创建待发布项，避免线上遗漏

场景2：商务用了天舟云v1.9，准备进行升级2.0，需要平台协助支持解决。

错误流程：平台提供了v2.0的升级指引和内容，商务的后端同学和前端同学，进行部署升级，执行脚本，刷新数据，熟悉平台的成员进行功能验证，根据异常报错，查漏补缺脚本或配置。

错误分析：
1.平台同学没有提供升级后对应的风险指引和重点关注功能验证，2.0相对1.9是一个非常大的版本升级迭代，涉及非常多的功能调整，需要非常详细的升级指引和影响范围，以便产品线同学更好地升级和功能回归
2.查漏补缺脚本或补缺配置，这个本身是平台功能梳理发布项的遗漏，平台本身应该加强对发布交付物的严格管控，针对产品线不同版本升级，需要提供准确的升级指引、增量脚本差异和配置