软件定义汽车下的合作开发

1

起

随着“软件定义汽车”的浪潮，整车软件功能和复杂度在不断提升，主机厂为了把握主动权，开始逐渐参与甚至主导整个软件开发过程，使当前整车软件开发呈现出多方交互、参与和协作的特点。

此外合作模式也更加灵活和多样，例如有的供应商只供硬件，而底层和应用层则由主机厂完成；有的则是供应商主导主机厂只参与其中很小一个功能包的开发，比如四驱功能。在Autosar还未大规模普及之前，合作双方都有各自一套约定俗成的方式来进行接口交互和沟通，这个交互过程可能一次涉及很多类型文件，例如.C .H或者.O等等，后面则可通过Arxml来进行接口交互等。

2

承

总体来说当一个开发活动中，参与元素越来越多，由于个体主观叠加之客观条件的差异（如组织流程差异、合作方式选择、接口交互方式等）就会使整个合作开发任务变得复杂和具有挑战性。

3

转

影响软件合作开发的因素有很多，我只选择几点来谈谈个人看法，也欢迎跟大家交流。

3.1 主动性和约束

攻城狮向来讨厌流程和约束，创造性活动与约束是相悖的，合作开发过程中除了开发工作还充斥着流程、文档等活动。这些流程和文档类工作我认为分为两大类：1、有必要且有助于保证产品质量和项目进度 2、无必要徒增工作量的。

当约束变多，攻城狮逐渐开始应付并消极待之，那么也会让有价值的约束失去作用。既然两者都没错，如何调和？只能精简约束且约束制定者必须具有项目实践经验，一个脱离项目实践的人制定流程就好比“纸上谈兵”。只有真正了解痛点才能有措施针对性铲除并让攻城狮发挥主动性再把主要时间放在功能设计和开发上，例如不要再动不动整个功能就要拿着所谓的Aspice说事，首先是不是有必要？如资质审查需要，如果没必要还要强加显然不合理，因为除了它还有很多有效措施保证开发质量，这就好比石器时代结束后，大家推崇青铜。但是现在有些时候还是石头好用。地球上石头也没有消失，只是多了青铜这个选择，流程花样再多只是一种选择，合适自己的才是最好的。

3.2 一夫当关：需求管理

一个功能的实现从简来说主要有三部分：输入、内部逻辑和输出，输入和输出可以统一概括为接口，内部逻辑则是依据输入经过某些运算得到输出达到控制目标。从这个角度讲在合作开发过程中，分配的功能模块要想顺畅完成，那么我们谈好接口明确功能即可，但实际操作起来我们发现并不容易，要么需求接口到了开发都还没完全确认清楚而是开发过程中不断更改甚至持续到整个项目末期；要么就是合作双方未理解，造成传递错误等等。

需求交互、分解和传递作为开发活动的起点，对整个项目起着我认为是80%的作用，首先需要一位相匹配的系统或架构攻城狮。他们是一栋大楼骨架的设计者，大楼建设顺不顺利且建后稳不稳固全靠它。例如对于未确定和持续变化的接口要有效跟踪和管理，对于明确的功能要做好分解、传递和测试验收，这就考验系统和架构师的功底了。

3.3 组织和人

当某业务兴起，很多公司都会为了新业务调整组织架构，例如德尔福在智驾单独成立安波福；上汽在新能源单独成立智己等等。有在现有基础上整合的，也有直接干脆新拉一个团队的。《浪潮之巅》中也写了很多鲜明的例子，有固守体制而失败的也有改变但偏离而失败的（如雅虎）还有改变非常成功的（如重回苹果掌权的乔布斯进行的改革），这是一个探索道路的过程。当改变后若组织间存在着太多的条条框框限制或价值差异那么协作起来谈何顺畅，例如组织臃肿，大家会发现部门间协作扯皮的事越来越多严重影响效率。当然一个组织经过这么多年的发展已自成体制，改变原有价值认同也不容易，我们有句古话：不破不立，不破除旧东西何以更好重生？此时我们需要一个真正的引领者。

人是一个公司最宝贵的财富，组织是一个有约束边界的平台，在公司战略方向对的前提下，人在此基础上创造出价值。那么检验组织首先就是输入：员工的真实反馈，就好比诊断通讯需要经常问答反馈，得到系统运行的实时状态再制定措施修复完善，当真实反馈普遍不好时就需要警惕和思考，因为这会使一个团队活力逐渐消退，影响最终的价值输出。在一段《遗失的访谈》纪录片中，乔布斯关于团队合作曾说过这么个例子：一位老人让他捡一些普通的石头，然后放进一个磨石机里，开动后让他明天再去看，他第二天后打开罐子看到了打磨的异常圆润美丽的石头。这些普通石头通过相互摩擦最后变成了光滑美丽的石头。而这正是团队合作过程中通过大家之间相互碰撞：辩论、对抗、争吵、协作和完善修正等来磨砺ideas最终圆满完成项目。

4、不可能三角

持续快节奏交付与质量的相悖，这也是一个老问题了。

软件合作开发模式下，软件要求的交付节奏越来越快，但有些功能涉及的开发量巨大很难满足交付质量这也是事实，现在的敏捷和持续集成测试有一定作用，但无法完全解决上述痛点，对于有标准的可以做到一次做好终身受益，例如某功能主机厂在每个控制器上要求一致且万年不变，那么做好测试case后不管换什么产品，功能开发完后都进行持续检验就可以了，前期的费劲主要在于这些测试库的建立。而当某个功能在同一主机厂都在持续更改更别谈在不同主机厂是咋样时，这种问题对于使用持续集成和测试也显得力不从心。这其中可能存在着这么几个问题：首先开发人员理解需求且知道测试什么和测试目标，但负责搭建持续测试的人不理解要测试什么，而当把这个任务交给开发人时又对开发的人提出了额外的工作内容和技能要求：编写测试case甚至再转化为测试脚本，这项工作是持续的；其二，整车配置非常多样，项目软件对应的测试模型难以覆盖各种配置等等。

持续集成测试好的一面就是规避人的错误，保证有测试case的功能验收的一致性。那么推动合作方对功能做好标准化并一以贯之是合作双方利好的事，但这个推进过程会很遥远甚至根本不现实，国内主机厂的功能向来说变就变。

5、高效合作新模式探索

探索新的方式，这个在一个固有模式的行业要想翻出新的水花会比较困难，马斯克自传中也曾说过一句话：颠覆者从来都不是在原有行业诞生的。新能源和智驾兴起时，当时传统汽车开发人员是众矢之的，他们保守、他们拉胯，招聘都不受待见，但随着传统汽车人员在新势力和智驾公司的迁移，我们发现这些曾经要改变现有模式的新势力反而又回归到原有的模式，因为这些迁移的人把原有行业的开发方式带过去并影响了他们，这我更愿意称之为同化进程-跟《人类简史》中有些片段描述非常相似。不论是传统主机厂的人，还是互联网的人当面临的客观环境超过专业知识能解决的范围后都会从传统文化中寻找解决方法。马斯克是一个狂人，但这种狂人毕竟少。

4

合

软件合作开发是后面的主旋律，合作方式、参与内容都很灵活和多样。但探讨一种高效的合作手段需要时间不断打磨。