通信模组程序由供应商发布,对版本的管理是个很头疼的事儿
首先版本发布主要关注2个点,一个是发布质量,包括供应商自测试的结果和覆盖程度、发布给研发内部版本与实际大货版本的一致性等等;一个是发布效率,包括发版次数、响应周期等
目前现状是
- 发布报告:多个供应商说没有自己的对外发布报告,或者只是很官方的releasenotes,只能是我们研发内部自己理出来关注的发布质量要求及测试报告格式;而就算是我们提供了测试项、报告格式,可能等货都出了,还没拿到供应商报告
- 版本发布:内部管理也很随意,直接找供应商烧一个,版本就发布了,然后到时提供个版本号,大货内容也定了
- 发布质量和频率也没有内部评估指标和数据
找了一下供应商管理的书啊网络文章啊,没有提到这么细的。
至少内部解决的方法感觉总是靠人,结果造成了谁急谁重视谁去找供应商,多头的成效不好,供应商不容易沟通,特别浪费资源和精力
先记录问题,后面再补充内部解决方法
内部邮件:“
最近与易工一起在整理对供应商版本验收的具体内容,发现有一些供应商管理的点全部由研发内部完成,推动难度较大。
目前主要有2个大问题点,@易工看看有没有补充的:
问题点 | 现状 | |
1 | 下述文档,供应商不提供,或不按要求时间点 |
|
2 | 模组程序对研发发布随意 |
|
说明一下,此处只是列了版本过程交付物,至于质量效率等内部最近把需求等再细分后,后面再逐步理出要求
另外,解释一下,当前内部从技术层面,对供应商的发布要求大致如下,按项目流程,罗列文档为研发内部每个项目各自提供:
内部要求 | 内部希望的结果 | |
项目选型时 | 《供应商需求发布.docx》 此文档罗列了本项目上的模组需求 | 此为模组产品的软件需求,需要与项目一起进行确认 |
模组发布程序时 | 《供应商需求确认.xlsx》 此文档为上述发布的需求对应测试结果 | 每次发布都需要供应商与程序一起提供 |
至少O-N阶段之前 | 《性能测试报告》 此为内部列出的模组性能测试项, | 至少在稳定版本上供应商需要完成,最晚不能超过O-N |
”