目前国内不少车企都已实现了FOTA的0->1的建设，随着后续量产车型拥有FOTA能力，以及不断新增的整车功能迭代需求，FOTA运营已成为常态工作。OTA工程师的KPI也逐渐从系统建设转移至运营。
在系统建设过程中，FOTA后台是以运营需求设计的。例如，运营工程师可以在后台发布FOTA策略和任务，并对每一台升级车辆进行信息监控、发布编排、远程干预等功能，在任务结束后可从各维度统计分析，得出复盘的结论。这些是FOTA运营的基础和核心能力。
然而各车型运营任务如潮水般涌来，除了系统支持外，还需制定完整的运营流程体系，以支撑包括需求收集、研发测试、任务发布、售后关怀等所有相关业务，提升产品全生命周期下的体系化效率。
本系列介绍的是一种多家车企通用的闭环FOTA运营流程模板，细节略有出入但整体大同小异。
整个流程可分为包括版本发布（序号1-7）、任务发布（序号8-12）、任务监控（序号13-14）三大阶段。
Step 1 用户需求收集
需求是版本开发的起点。不同于过去传统车企的工程师们拍脑袋制定功能需求，车企的内卷提高了用户地位，尤其新势力更乐于倾听用户的意见反馈，为整车版本迭代规划提供建议，完善现有的整车功能以满足用户持续不断的需求。需求的收集一般可分如下三种方式：
1. 线下见面会
不少新势力车企举办各类车主活动，目的是得到用户用车过程中的反馈。例如服务周到的某来，定期召开线下的用户见面会，了解新功能的使用体验和吐槽。通过用户沙龙、一对一访谈、线上调研，了解驾驶体验中的痛点并挖掘真实的需求。
2. 数据分析报告
通过数据埋点对功能生成使用频率和触点报告，创建用户画像，帮助产品经理们更好理解用户的行为习惯。
3. 竞品分析
内部或专业咨询机构对标竞品的明星功能，通过友商用户的反馈意见，综合自身车型的硬件能力，作进一步的改进和优化。
Step 2 需求评估
拿到需求后，内部会对需求分析评估、进行拆解和工作分配。需求分析要对需求分类管理，排定价值和优先级。需求拆解包括功能涉及控制器范围、可行性、成本分析。如车企通过基线管理整车版本，则需要根据基线的发布计划制定各控制器的实施计划。
Step 3-6 功能开发&验证
在开发环节，相关的零部件工程师需要按基线发布计划牵头完成控制器的新版本发布，包括方案设计、系统需求、代码开发、测试验证等。值得一提的是，最新OTA法规要求，如涉及智驾、安全、节能、环保、防盗性能，以及公告参数变更的，要向工信部进行申请。最终，由测试工程师对进行零部件单件和整车功能集成测试，完成功能的验收。
除了整车功能验证外，OTA小组要对本次发布基线版本进行FOTA的端到端全链路测试，验收该基线的FOTA成熟度。售后部门亦需验证线下诊断仪的刷写能力，不仅作为基线发布的必要条件，更为FOTA小概率失败的援救行动提供工具支持。
Step 7 基线发布
基线测试完成发布时，OTA运营需要编写本次发布的ReleaseNote，文案需要突出本次版本的新功能和亮点。
Step 8 法规备案
话接上回，在基线发布前，OTA运营方就要开启备案工作，这是由于国内日益严苛的OTA相关法规要求所致。目前备案流程有两部分，要分别向市场监管总局和工信部发起。
市场监管总局于2021年6月发布了《关于汽车远程升级（OTA）技术召回备案的补充通知》，要求汽车生产者在OTA发布前5个工作日内提交汽车远程升级（OTA）安全技术评估信息表和电子版升级包。
工信部则于2022年4月发布《关于开展汽车软件在线升级备案的通知》，明确了备案要求和备案工作流程。通知规定，涉及产品安全、环保、节能、防盗等技术性能变化的相关升级活动，应提交验证材料。涉及《公告》技术参数变更的，应在备案前向工业和信息化部申请产品变更或扩展，按流程完成《公告》产品准入后才能开展升级，保障汽车产品生产一致性。涉及汽车自动驾驶功能（L3级及以上）的相关升级活动，同样应经工信部批准。在各项功能前期审核完成后，车企可通过 “汽车软件在线升级备案系统”线上发起备案流程。
综上，根据市监局和工信部的要求，OTA备案工作务必于任务发布前完成，否则将会影响任务执行节点。
Step 9 宣传预热
备案同时可在手机APP、微博、抖音等渠道进行FOTA新版本的宣传，让用户知晓本次升级任务，通过炫酷的图文和视频介绍新功能，引起用户对于升级的强烈兴趣。
接下来的两张截图为两家新势力在手机APP端的版本宣传页面，推文细述了版本的新特性。值得一提的是，均为智驾和座舱相关的新功能。
Step 10 内部用户测试
在整车功能和FOTA测试通过，且备案完成后，OTA任务可以正式发布了。然而，相对于工程车较为简单的环境，FOTA在实车的复杂情况和状态下的健壮度仍需进一步观察和验证。
此时，升级活跃度高、抱怨概率低的员工车或者忠实用户可作为“小白鼠”率先执行升级操作，一般可放在公司园区执行，一旦出现了升级异常，救援方便，更容易截取日志分析原因。
内部用户测试完成后，进行意见反馈收集，组织相关产品和研发团队进行问题整改和修复。
Step 11 灰度发布
灰度发布是通过小范围、分批次的发布方式，观察升级版本的稳定性，决策是否将任务全量发布至所有车辆，有效规避发布风险和降低版本发布升级的影响范围。灰度发布需要运营在后台对灰度车辆进行监控、运维、远程协助；
相较于内部用户测试，灰度任务还需新增售后话术和售后救援资源；话术提供给一线客服，协助用户安装指导和小概率失败后的操作。救援资源包括但不限于线下刷写工具、拖车、代步车、升级失败备用件。
灰度发布的任务数据形成灰度发布报告，作为正式任务发布的决策依据。
Step 12-13 正式发布&任务跟踪
灰度发布完成后，OTA运营汇总本次FOTA方案、升级车辆、内部用户/灰度报告等，上报相关领导决策，并制定最终的实施方案。在计划实施日期到达后，在FOTA平台触发任务生效。任务的发布可根据用户地域分布和售后救援情况，按地区分批发布。
正式任务除了售后的全力配合外，研发团队也需快速响应问题，识别出问题责任方并排期修复，对于严重失败需和售后共同参与现场救援。
Step 14 任务统计&复盘
执行正式任务的过程中，FOTA运营持续搜集数据，在任务结束后，形成正式任务报告，对升级完成率和成功率进行复盘。分析偶发的失败case，寻找相应对策，进行各零件和FOTA平台优化改进。售后问题和功能缺陷录入JIRA等管理工具，解决的实施方案合并入下一次基线发布中。
总结
至此，一次完整的OTA运营活动顺利完成，OTA运营团队在Lesson&Learn之后，就投入了下次发布流程中。笔者听闻部分车企由于功能修复迫切，零部件工程师对流程不感冒，版本发布无规划，轻视灰度发布的验收，导致OTA运营失控状态，用户体验差，后续运营更难开展。因此，FOTA的运营流程在实施过程中仍需有效管控和遵守。
相关文章
