大众和地平线的亲儿子，需要什么研发管理工具链

01.

大众和地平线的合作，是非常典型的智能网联汽车团队的软件开发模式

第一，由两家完全不同的公司合资而成，双方都携带核心技术

大概率，大众会通过CARIAD在中国的子公司，和地平线成立一家合资公司。地平线在芯片和自动驾驶算法领域非常资深，旗下的征程类芯片，已经在多家主机厂商大规模落地。CARIAD对于大众而言，就好像零束对于上汽而言，都是全球软件转型战略的亲儿子。CARIAD的总部在德国，它的目标就是作为大众在软件定义汽车转型过程中的重要支撑，包括操作系统、新一代电子电器架构、自动驾驶 、OTA 等。

虽然CARIAD在中国的子公司是今年4月份成立，但是CARIAD总部在2020年初即成立，可以想象德国CARIAD拥有成立以来的经验积累，而中国的CARIAD是在这一基础上继续开发。他们打出的口号是“在中国研发，为中国创新；在中国研发，为世界创新”。

总体来说，无论是大众CARIAD，还是地平线，都拥有自己的核心技术，而且是对方所不具备的。

第二，合资公司的产品主要被其中一家公司可用，但合资公司的项目管理经验和产品开发经验，有非常大的价值被应用于其他公司

很明显，大众和地平线成立的这家公司，未来不管是开发操作系统，还是更适配于L4级别的自动驾驶芯片，或者自动驾驶相关的算法，它的主要客户将会是大众全球的一些车型，是不太可能把这样一个产品或解决方案拿出来继续卖给其他公司的。但对于合作方地平线而言，与大众进行产品开发合作，这样一款产品具有非常高的可复用价值，可以用于其他品牌的车型和产品。基于这样一个跨国际团队的项目管理经验和产品开发经验，对于地平线后续开发其他的厂商，比如美国的福特、通用或其他日本的公司，都具有非常大的借鉴作用。

基于这样的考量，这样的合作对双方而言，有不同的目标。大众希望最先进的产品最先被自己使用，希望这些先进技术，永远不会被其他厂商学习和运用。但地平线的目的则不一定相同，这种分歧也是合资类公司最难做的地方之一。而当前的智能网联汽车团队的软件开发，大部分也面临着这样的困境，比如上汽和阿里成立的斑马、华为和北汽的合作，虽然后者没有成立合资公司，但合作逻辑和面临的问题是一样的。

第三，一方拥有根深蒂固的主机厂思维，而另一方是新兴的软件供应商

什么叫主机厂思维呢？对于具备主机厂思维的一方而言，他只需要定义一个需求，而且有时需求非常粗放，将这个需求给到供应商，最后由供应商来交钥匙即可。在交钥匙的过程中，为了保证产品的质量，除了最后要进行产品验收之外，依据德国人的质量管控思维，质量管控一定要到上游去，也就是也会管控这其中的软件开发流程。传统的主机厂思维，ASPICE是一个最好的体现。主机厂需要深度地去检查合资公司的研发过程，包括需求分析过程，需求是否经历过评审、是否有对应的架构设计、有对应的测试用例、这些测试用例是否有被评审、代码的每一个函数是否有被单元测试覆盖，是否具备质量管理的过程等。所有的东西都需要可追溯，需要留下纸质的记录。

这种主机厂思维，所要求的根本逻辑是什么呢？甲方不是亲自来执行整个流程的完整过程，无法接受黑盒交付，所以需要清晰地知道整个执行过程，以便进行过程质量管控。乙方需要随时提供一些过程文档或者产物文档。这就要求整个流程需要非常高的文档化。但是对于新兴的软件供应商而言，他们的思维和目标都是，更高效的开发出有质量保证的产品。以往他们是在自己的团队里面进行开发，所以整个团队对于开发过程及开发产物都是非常清晰的，它并不需要对所有的内容都进行文档的记录。但是现在面对合资公司，大众在执行方面的参与度肯定是低于地平线，因此它天然会有去查看历史文档的需求，这个也是两家公司的冲突。如何解决冲突，是合资公司能否产生出最大效益，能否满足大众快速软件转型战略的关键。

第四，跨时区、国际性研发团队

这种类型的团队在国内的智能网联汽车的软件研发项目里也是非常常见的，如蔚来汽车是中德美三个国家的软件研发团队，吉利、小鹏等等。面对一个国际性的研发团队，有一个需要直面的问题是，距离和时差。常有合资公司通过无限挤压中国团队的时间，通过中国团队加班到凌晨来满足国际团队的时间，让美国团队更好地工作。这种情况会导致两个问题：一、单方面的付出是不持久的，长此以往，会造成中国团队心里失衡，影响士气。二、跨时区会议的存在是否必要？如果会议的内容、素材都能通过线上来沟通、解决，则跨时区会议的频率会大大降低。虽然此类会议不可完全避免，因为确实存在需要在线讨论的场景，但是可以合理的将这种跨时区会议减少到最低。

第五，多个车型项目并行

可以预见，此类合资公司，他们开发的产品一定是基于某个具体的车型项目进行开发，比如车载操作系统，但是当它开发到一定阶段后，会发现大众的车型项目越来越多。此时，需要将这套解决方案运用到不同车型项目上，有一些团队的做法是把第一次做的车型项目完全 copy一份，再在此基础上修改。如果有更多车型，copy更多备份。

大众的车型是很多的，这样的方法意味着每增加一个车型，就需要增加额外的团队进行支持，效率较低。且随着车型项目的增加，系统的资料会越来越多，资料文档就会愈加冗余，每份资料之间不一致性就会越高。而车型项目中可能60%或以上的文件是极其相似的，相似但又不可以被删除，所以如果合资公司的多车型并行项目采取如上的模式，随着项目的增多，效率会逐渐降低。且每一个车型项目的经验和产品改进，都很难有效的运用到其他的车型项目。

02.

需要什么样的研发管理工具链？

第一，合资公司拥有信息的最大权限，大众CARIAD和地平线都只能接入和获得部分信息

首先这家合资公司会进行新人招聘，不会全部是大众或地平线的人，这些新人属于合资公司的最主要的工程师。早期，大众和地平线都会提供一些项目经理和开发团队，来和新的团队进行沟通。之前我们提到两家公司都拥有自己的核心技术，在联合开发的过程中，双方都无法接受向对方公开自己的全部技术信息。因为大众希望产品仅为自己所用，而地平线会希望项目经验能够运用到其他合作中。所以一定是双方成立的这家合资公司拥有最大的信息权限，而大众和地平线都只能接入和获得部分的信息。

所以常常出现这样的情况，合资公司接受到大众 CARIAD提供的系统需求或软件需求，地平线提供一些技术需求，架构设计等，进而在合资公司进行开发，但大众和地平线都只能接入。所以，这就要求这套研发管理系统，能够实时地接受大众输入的信息以及地平线输入的信息，而不是通过中间某个人转达。基于这个需求所做的后续开发，双方可能完全无法了解代码层面的细节，但是双方协商可以共享的部分，比如基于这条需求相关的bug，双方可以在系统中实时查看，甚至如果是产品层面的bug，大众或地平线可以在系统中直接澄清或解决。所以这样一套研发管理系统，需要提供各方自由录入的界面，各方也能在这套系统里，实时获得反馈，同时又能够精确地对各方进行权限限制，无需其看到的信息，则无法看到。

如果我们拿精益管理的分析方法来看，在这样一个团队，写代码、解bug可能不是最花时间的，最浪费时间的，是各方对于某一个问题的对接和澄清上。所以研发管理系统首先要解决这个问题。

第二，大众CARIAD应逐渐放弃主机厂思维，成为软件开发中和Key Player

这并不代表大众要完全成为一家软件开发公司。具体是什么概念呢？对于合资公司而言，涉及到多个合作方的利益，因此会基于多方的一些要求，最大可能的公开一些信息。所以大众不应该继续死板的按着ASPICE的要求，需要合资公司提供整个开发过程的交付物和文档。如果合资公司可以向大众证明，针对软件模块都进行了自动化单元测试。大众是否还需要，这些模块里面的100个函数，分别是和哪些测试代码、测试脚本相关联呢？或者如果大众已经参与了最初的需求设计和需求评审，是否还要求这个团队在后续审查的过程中，出具详细的每一次的评审记录呢？

软件研发过程中的流程是比较固定的，流程的保密性并不需要太高，大众、地平线及合资公司对其都是非常清楚的。那么大众是否还需要合资公司，出具每份流程的详细解读呢？

以上的要求，都是传统主机厂的思维，因为无法获得供应商的日常工作，却又需要对过程进行管控。但是如果大众CARIAD将自己视为软件开发过程中的Key player，那么他就会全程参与到需求分析、架构设计、测试用例的评审等。此时他对于整个流程非常清楚。如单元测试是否对模块进行了测试，后续是否进行了集成测试、功能测试等，到最后的产品验收也没有问题，在这种情况下，我们是否还需要合资公司去准备冗长的文档来证明它的流程合规性呢？

因此，如果CARIAD把自己视为软件开发中的重要一环，并且全程参与时，他对整个过程是已知的，整个过程的质量也是有保证的，他可以选择放弃，那些传统主机厂居高临下的、需要供应商提供各种文档，来证明其研发过程的流程。做过ASPICE评审的人都清楚，同样一个项目，是否需要通过ASPICE，付出时间是有非常大差距的。通过ASPICE往往需要多付出额外两到三倍时间成本。但质量却不会因此，有着质的提高。

第三，工具应实时在线协同，而不是牺牲一方的时间，去配合另一方的时间

这就是上文提到的，此类开发团队必定是跨时区国际性的研发团队。尽管中国的团队主要以中国的 CARIAD子公司为主，但是我们可以预见到，中国的CARIAD子公司会和德国的CARIAD有非常紧密的联系，而德国CARIAD又和德国大众有非常紧密的联系，所以一定会存在某些项目是有德国这一方来参与的。假如我们的研发工具链是通过邮件来传递信息。很可能出现中国的上午9点发邮件到德国，告知其问题进展，德国查阅邮件时，已经是中国下午 15 点。这时很难保证德国方收到的信息是否为最新版，处理情况有两种：一是默认是最新的，德国人基于他获得的信息来做出决策，进行开发。如果信息在这个过程中有了更新，则可能导致他做出错误决策，重复再来会导致整个团队效率变低；二是与中国团队进行沟通，确认信息是否为最新。德国人收到这封信息后，联系中国团队进行会议邀约，而中国团队可能已经超过18 点，中国团队需要牺牲自己的时间去跟德国人开会做解释。

无论哪种情况，都是由某个人主观判断来决定的，而每个人的处理方式不同，会导致不同项目中出现不同的情况。因此会导致两个问题，要么质量管控不严格，易出纰漏，要么一味牺牲中国团队的时间，导致中国团队效率降低，影响中国团队士气。所以，研发管理工具链需要支持双方的团队能够在一个平台上去更新自己的信息，并且双方都可以及时看到。使更多的信息通过线上传递，剩余的少部分信息无法避免，再进行线下会议沟通。

第四，平台项目和车型项目并行，做好平台项目的需求池管理

上文提过相关场景，随着合资公司业务扩大，车型增多，在最开始时就要做好车型项目的管理计划，筛选可以复用的需求、架构文档等，做好平台项目的需求池。针对这些需求池，有对应的架构设计、测试用例、bug经验，这些都是可复用的。日后的新项目，就可以在需求池里最大程度地复用上一个项目的经验。复用后，可以在此基础上进行修改，修改好后，对产生的新文件进行复查，思考其是否可以被下一个项目复用或是否有可能让平台壮大，将有效的信息继续投入需求池。

Git天然支持这样这种模式，通过主线和分支的策略，主线是平台项目，从平台项目上拉出一些分支项目去修改它的代码。修改成功后，分支项目里面对平台项目有帮助的部分就可以进行合并。

但是除代码外，我们有非常多的内容也可以复用。需求分析文档、架构设计文档、测试用例、bug 经验等，这些复用的文件在我们的研发管理平台里，需要以类似的方式进行支持。

作者介绍：

罗宇超，云体科技创始人，软件质量工程师，工具链工程师。