为什么从蔚来出来创业？ | 罗宇超和他的MappingSpace

编者：

《创业者心路》一个专为汽车创业者打造的专栏。他们闪耀的背后是否藏有鲜为人知的坎坷和挣扎？他们的内心世界是否有过无数次的迷茫与叩问？他们的创业初心是什么？他们的产品又有什么不凡之处？

我们将邀请汽车行业的创业者，以第一人称的视角，分享他们创业的心路历程。让读者可以近距离地认识他们的灵魂，聆听他们的心声。

本文的主人公是罗宇超，他本科毕业于吉林大学车辆工程专业，硕士毕业于德国卡尔斯鲁厄理工学院汽车技术专业，曾在蔚来汽车、上汽零束从事研发流程管理和工具链开发。2021年，他创立了云体科技，主导研发了汽车研发管理工具 —— MappingSpace。

以下由罗宇超撰写：

罗宇超近照

目录

• 前言
• 初进蔚来——为什么软件问题还没解决？
• 智能座舱——保交付还是保质量？
• 软件质量——ASPICE是救命稻草？
• 上汽零束——工具试验场
• 离职创业——用工具辅助人类的思维方式
• 后记

前言

这篇文章，将分享我对汽车行业的流程、质量、体系效率、工具的理解，以及如何在蔚来汽车和上汽零束的工作中，获得我的创业灵感，也想尝试说明MappingSpace的诞生过程，设计理念。为什么她不只是一款简单的汽车行业研发管理工具，更是一款能激发人的创造力、善意和效率的工具。

本文尝试大致回答以下几个问题：

1. 为什么我走上汽车软件质量的道路

2. 为什么一些搭建工具链的方法没有成功

3. 工具链如何解决效率问题

另外本文尝试勾勒出MappingSpace的几个愿景：

4. 释放并激发人的创造力和善意

5. 作为人类思维方式的延伸

6. 下一代汽车软件工具箱

初进蔚来——为什么软件问题还没解决？

硕士毕业之后，我进入蔚来汽车做质量管理。2年前我在德国博世做质量管理实习，解决了生产线上的一个重大bug，使得产品的良率提高了2%，每个月节约了数千欧元的材料成本，让我自以为在质量管理方面有一些天赋。

这次的质量管理，是在工厂整装车间的最后一道环节：站在用户角度对车辆质量进行评审。18年上半年，量产冲刺的最后阶段，我们几乎每周都会抽1-2辆车进行完整的用户角度评审。当时的外观、内饰问题已逐渐收敛，但软件还存在较多问题。自动驾驶功能还未完成，智能座舱也有诸多bug。

（来源：https://chejiahao.autohome.com.cn/info/3426920）

我当时负责整车软件功能的评审。刚接触这块儿时非常兴奋，理论上来说，我是第一个“用户”，完整摸到了当时中国第一辆真正量产的高端智能电动汽车，这辆汽车拥有当时中国最为智能、最为前卫、最有科技感的软硬件设计。但1年的质检体验，给我泼了一盆冷水。临近量产，外观、内饰的问题越来越少，而软件的问题还没有彻底解决。长期的质量培训让我有这样一个意识：质量问题，越到后面，解决成本越高，解决周期越长。因此，我希望到开发部门去管控质量问题。

（来源：https://blog.csdn.net/njcit/article/details/5886811）

当时有一次机会，我在工厂给智能座舱的测试总监演示整车功能。因为我们经常给他们报很多问题，打乱他们的开发节奏，他们对我们“怀有敌意”。当他有机会来工厂之后，他想借此机会看一下，这些人是真懂，还是在随意报bug。

他坐在ES8的后座，看我对整车功能，甚至是一些还未开发出来的功能，如数家珍之后，他非常好奇，为什么一个工厂质量端、最后一道产线的同事，能够对整车软件功能如此清楚。

在一个合适的机会下，我转到了智能座舱的测试部门。

智能座舱——保交付还是保质量？

在智能座舱测试团队，我继续做质量相关的工作。

我做的第一件事是规范测试团队的流程。

当时的测试团队，没有成体系地记录完整的测试用例，许多功能测试，都是基于测试工程师的个人能力，这就使得不同的测试工程师，测试结果的差异非常大。测试能力培训，高度依赖口口相传。

因此，我做的第一件事情，就是推动测试用例的书面化和结构化。当时碰到了很多阻力。对于测试来同学来说，最大的一个抱怨是，测试任务非常繁重，软件版本发布频率非常快，他们没有时间去写测试用例。

经过几轮讨论，我们达成了妥协：测试用例的书面文本化分3步走，第1步，列出测试用例的提纲，并逐步与产品、开发团队进行评审；第2步，在测试工作之余，逐步补充完成详细的测试用例步骤；第3步，将手动测试用例逐步转化成自动化测试用例。

同时我还承诺，要想办法帮他们提高效率，这样他们才能有更多时间来完善测试用例，而不是被版本发布牵着鼻子走。

当测试用例开始编写后，我发现一个现象：测试工程师特别喜欢用思维导图来编写测试用例。不仅他自己编写的时候思路清晰，对于评审的人来说，也是如此，能够快速指出测试提纲里面，缺少何种测试场景、缺少哪个逻辑分支等。相比于一个word或者excel文档，编写和评审的效率都大为提高。

相比于并列式的信息，思维导图更加符合人的思维方式：从一个点状信息出发，不断向外联想、延伸，然后在每一条分支上，又继续不断往外联想，直到达到认知的边界，最终，信息被分解成最小的原子化。

这样，人类才更容易理解复杂的信息，思维导图成了人类思维方式的延伸。

而且我还发现，在测试用例评审过程中，由于思维导图中的思路更加清晰，在分支的基础上进行产品推演，往往能激发出产品工程师更多创意，帮助进一步完善产品。

但是，受限于测试用例仍然是线下的思维导图或者excel，需求、开发同学看到的测试提纲或测试用例往往是滞后的，而非实时的。这就造成了需求和测试用例经常不一致，测试报问题的准确率有所下降，干扰开发团队效率，降低了测试同学的权威。

测试提纲评审完之后，测试工程师开始执行测试。我原以为他们会直接看着思维导图来执行，但实际情况并不是这样，他们会把思维导图拆解成一份excel，每一行就对应一条测试用例，一条条手动创建测试用例。但这无疑是重复工作，相当于创建了两遍测试用例。

“为什么要这样做？”

“因为我要出具测试报告”

“不能直接用思维导图出具测试报告吗？”

“不能，思维导图连保存测试用例都不行”

他说的很对，我没法儿反驳，一个普通的思维导图，仅能够保存测试用例标题。

甚至都无法保存测试步骤。

更别谈直接在思维导图上出具测试报告了！

但是，把思维导图拆开，一条条再放入excel中，缺点可不仅是重复工作，更麻烦的是，在excel里面，也失去了思维导图特有的结构化、可视化、逻辑强的优势。

后续需求如果有变动，需要修改这份测试用例，添加或者删除其中某几条，在excel中寻找位置，都会浪费大量时间。

（来源：https://blog.csdn.net/weixin_41948075/article/details/89287926）

那为何不就在思维导图里，保存测试用例的全部信息呢？

为什么不直接用思维导图，出具一份测试执行报告呢？

我这样问自己。

这个问题的答案，就是MappingSpace最初的创意来源。我们将思维导图从一维的数据库，扩展成多维的数据库，不仅能记录测试用例的标题，还包括测试用例的步骤，测试用例的其他各种类型（文本、数字、选项、链接、附件等）字段信息，还能直接用于测试执行，创建bug追踪和出具测试报告。

使用excel出具测试报告之后，我发现了另外一个问题：开发人员几乎不会查看测试报告，测试报告是否真正有效，是否漏掉了一些测试用例，开发几乎不会去确认。这个问题一般什么时候会暴露呢？往往是问题漏到后端才会发现（比如整车测试团队或者工厂质量团队）。项目经理去质问开发，开发再去质问测试，测试说：

“测试报告是完整的，我测了。”

“你怎么测的？测试场景啥样的？可以复现一下吗？”

“时间太久了，复现不出来了，也许这是个偶发bug……”

“但这个bug在客户端必现……”

然后我再去询问开发：

“你为什么不愿意看测试报告？”

“Bug都看不过来，哪有时间看测试报告？”

“看测试报告不就顺便可以看到Bug吗？”

“不对，看Bug只需要去Jira就好了，看测试报告，我还需要去找到excel，然后再打开excel。”

测试过程被割裂了，测试执行报告和Bug在不同工具中追踪，开发不管是有意还是无意，都会漏掉查看测试报告的过程，因为那反人性。

为了让产品和开发同学更加重视测试报告，我们尝试把测试用例迁移到开源测试管理软件testlink上，进行线上化，和Jira打通，使得他们看上去更像是一体化的工具，减少产品、开发查看测试用例和测试报告的成本。但效果不甚理想。由于测试用例没办法和需求、架构建立双向追溯，以及testlink软件页面本身不够友好，学习成本略高，导致仍然没有产品、开发同学来主动评审用例。testlink软件基本局限在测试团队内部使用。这就导致了测试用例本身的质量不高：未经多方的评审和维护。

不过，当时我的能力，还看不懂整个智能座舱研发团队的全部面貌，并未想到可以通过设计一个需求、开发、测试一体化的线上协作平台，来解决这个问题。直到3年之后的2021年，我才真正开始设计MappingSpace这个产品。

软件质量——ASPICE是救命稻草？

蔚来在成立前几年，不计成本的投入来抢时间，来快速发布产品。快速扩张带来了一系列后遗症：一是到2019年，管理层提出要降本增效，某些部门开始裁员，影响团队士气。二是研发流程体系还没稳定的情况下，正向研发一下子开辟了N条战线，研发工具山头林立，工具分散，各个部门内部的工具链尚且无法在短期之内打通，调到最优状态，何况是在全公司内，让部门之间的数据和信息高效流通起来。

太难了！

蔚来没有经验可以遵循，只能摸着石头过河。

当时我并没有意识到，智能座舱团队碰到的这些问题，本质上是敏捷开发和ASPICE的矛盾，是质量三角形中，Cost和Time之间的矛盾。

在一次公司内部的培训中，我才了解到汽车行业有一个专有的软件质量流程标准ASPICE。当我花了一两周的时间深入去了解这个标准后，发现这个标准里面提到的很多理念，都和我之前接受过的质量教育很相似，我仿佛看到了解决质量问题的曙光。我去向leader建议，是否应该采用ASPICE的开发模式，里面的描述不就是我们现在面临的问题吗？测试用例、测试报告不齐全，追溯性没有建立，需求文档一直在变，文档之间缺乏一致性，缺乏质量管理流程等。如果我们能按照这一套标准来做，软件质量问题有可能得到改善。

他当时也提出了一些疑问。因为团队成员基本都是手机行业或者互联网行业出身，对ASPICE都不太懂，如何从现在这样一种开发模式转到另外一种开发模式，这是一个比较大的问题。另外ASPICE里面对于文档的追溯性要求非常高，我们如何才能在现在这样一种保交付的氛围下，建立详细的过程文档？我当时也无法解答这个问题。

后来，我尝试着在Jira这样一个敏捷开发系统中，去建立ASPICE所期望的详细文档和追溯性。不过由于对团队现有的流程改动非常大，这个方案甚至还没说出来，就不得不夭折了。

上汽零束——工具试验场

在上汽零束成立不到半年的时候，我进入基础软件团队做软件质量管理工作。上级零束当时处于急速扩张期，通过大型招聘会一次性招聘大量人才。它最重要的目标就是服务上汽的高端车型，智己和飞凡，提供整体软件架构、底层基础软件、智能座舱、自动驾驶的能力。当时我已经慢慢开始了解ASPICE更加具体的做法，当时我一心以为ASPICE就是解决汽车软件质量问题的关键。我希望能在上汽大展拳脚，真正将ASPICE落地。

当时碰到一个比较大的问题是，想实施ASPICE，但工具难落地。

一方面，我们迅速推进了ASPICE、功能安全的咨询公司定点，进入咨询流程。我们沿用了上汽西门子的Polarion软件。但是Polarion软件出现了一系列问题。当时的场景是，上汽有一套Polarion环境，正在升级，零束并不是直接使用这套环境，而是重新搭建一套环境，同时还需要把两套Polarion软件上的数据做同步。

（来源：https://www.softwareadvice.com.sg/software/152329/polarion-alm）

但是智能座舱团队已经启用了Jira，因此这个问题又变成了，零束自己的Polarion软件和Jira之间，也需要做数据同步。

Polarion升级花了几个月时间，同一时间，我们在设计上汽Polarion、零束Polarion、零束Jira之间同步的规则和机制，最后我们又花了几个月时间去打通这三套系统。这里需要说明一下，这类管理软件之间的同步机制设计起来尤为复杂，因为双方的信息往往都允许随时更改，而同步的信息就涉及到“以谁为准”，即双向同步问题。单向同步要简单许多。

这里增加一个小插曲，当我们在讨论系统打通的时候，我们需要去试用Polarion。我们拿到了几个上汽环境下的Polarion账户去试用，但需要限制同时上线人数，否则会影响该软件的正常使用。这就不得不提到Polarion所采用的的浮动制账户管理方式。不知道这是纯碎商业上的考量还是技术上的考量。如果说站在商业上考量，这个方案并没有给使用者带来优惠，相反Polarion却是汽车领域最贵的一款研发管理软件；如果是站在技术上考量，是否是软件本身存在性能局限，因此无法支持几百甚至上千个用户的并发。总之，这种账户模式，严重牺牲了用户体验和协同能力（本来购买这个软件就是为了研发协同，结果却对在线协同的人数有限制……）。

后来另外一个部门引入另一款研发管理软件——TAPD。

3个部门内部都在建立以各自的研发管理软件为中心的CICD流程。这时候进入了一个更加复杂的命题：3个研发管理软件，各有各自不同的管理逻辑、理论和使用习惯，他们各自都以自己为中心建立CICD，但是各个部门之间，也有项目管理数据流通的需求，那么就需要将这3个研发管理工具之间打通；当零束内部梳理清楚这些流程之后，再与上汽的Polarion打通。这几乎是一个不可能完成的工程了，光是梳理打通场景就极其复杂，实际花费也大大超出了当时购买这3个工具的成本。更重要的是，在打通工具的这段时间内，研发团队只能线下作业，项目的透明度和工作效率都受到比较大的影响。

而且，面临的另外一个问题是：Jira和TAPD天生都是为敏捷开发而设计的，Polarion天生是为ASPICE而设计的，当时的大方向是要融合，但具体如何融合，尚不清楚。比如Polarion能支持基线管理和变更管理，而Jira和TAPD都不支持，是否使用这两款工具的团队，就直接把基线管理和变更管理裁剪掉？这势必会造成同一家公司的不同部门，采用不一样的流程，造成研发人员的疑惑和混乱。另一个解决方案是在Polarion中管理需求和测试用例，而在Jira和TAPD中管理开发任务，需求和测试用例可以做基线管理和变更管理，而开发任务更多被认为是开发人员建立的临时工作任务记录，无需做基线和变更管理。但这3款工具的优势都在于提供一站式的管理服务，即需求、开发、测试用例的一站式管理，分开管理一方面增加了打通成本，另一方面，数据统计受到影响。比如Polarion中的需求可以和Jira中的开发任务建立双向追溯，却无法天生支持统计其需求的覆盖度。更重要的一点，增加了所有人的工具学习成本。使用效率受到很大影响。

这一切都促使我思考另外一个话题：为什么他们不愿意用同一套工具来做整个公司的研发管理？

Jira + Confluence是敏捷开发中公认的领袖级解决方案。有一位同事对它的描述非常到位：我们把Jira比作一间房子，如果只希望这个房子遵循敏捷开发的流程，那么硬装（购买插件）和软装（系统设置）有比较成熟的方案；但如果你想用它来做汽车行业的研发管理，想要满足ASPICE、功能安全和信息安全，那没有现成的装修方案，甚至在某些领域，比如基线管理和变更管理，Jira还有比较大缺陷。TAPD同属此类，不再赘述。

西门子Polarion能够支持ASPICE，但软件界面呈现的交互，以及功能的易用性，都在工程师试用之后，让人望而却步。我们内部培训了不少于3次，但我们还是经常找不到它的功能按键在哪儿。Polarion作为18年前的一款产品，更像是一款站在管理角度、为了满足ASPICE标准角度而设计的软件，而不是站在用户角度。

所以结论变成了：不是不想用一套工具，而是在市面上找不到这样的工具。

离职创业——用工具辅助人类的思维方式

那我能不能做出这样一款工具：

1、她既能支持高效的敏捷开发，又能在不增加工作量的情况下，满足ASPICE？

2、既然ASPICE的基础是V模型，那么是否也能支持功能安全和信息安全？

3、她必须能同时支持需求管理、开发管理、测试管理、项目管理，而不是在不同的工具间反复横跳。

4、她不应该有太高的学习成本，能看到的地方都可方便点击，她的核心逻辑只需要5分钟就能掌握，掌握了核心逻辑，就能快速上手。

5、她既需要适应发动机、底盘、车身这些传统汽车工程师的操作习惯，同时也需要满足像自动驾驶、互联网工程师的使用体验。

6、她必须是固定制账户，而不是浮动制账户，以此来支持最佳的协作开发体验。

这是我给自己的命题。

"思维导图是一种可以激发创造力和促进创新的工具，它可以帮助我们从不同的角度思考问题。" - 托尼·博赞（Tony Buzan）

敏捷开发最最基础的前提条件是条目化，借此才能实施Kanban或者Scrum这样一种精益管理模式。因此，我再次想到了测试工程师用的思维导图。

如果思维导图能够解决多维度的数据存储问题，那么它不仅能支持条目化，还能真正用于编写一篇复杂且详细的工程技术文档。

因此我们创造性地给思维导图增加了浮窗，并且支持各种类型的数据存储。

当思维导图存储了如此多的信息之后，我们又很方便地将其转换成word文档模式，甚至导出word文档。我们也可以将一个已经写好的word、excel文档导入到系统中，这非常符合汽车工程师的使用习惯。

这是MappingSpace的核心逻辑，5分钟学会了思维导图之后，你就可以在其中进行大胆的工作。

当我们解决了这些基本问题之后，我们开始意识到，思维导图可以激发人的创造力和善意。

产品工程师用思维导图来编写需求文档，他的思路像流水一样清晰，他也可以邀请其他人来和他一起头脑风暴，思维导图成为他记录自己idea的最佳工具。此时，我们才真正意识到托尼·博赞所说的那句话，思维导图激发了创造力和创新。有无数次，我通过查看其他同事的思维导图，才有了新的想法，很容易、很自然地就直接在思维导图的合适地方，插入我的idea。我不再需要考虑工具是如何布局的、如何关联的、数据是如何存储的，我需要去何处创建我的idea，别人才能看见。思维导图极大程度地鼓励了这种同行评审和创新，抓住转瞬即逝的创造力。作为需求工程师，我的同事经常挑战、挑错、补充我的需求文档。因为他们每一次打开思维导图，都看见了了产品的全局；

架构工程师用思维导图来编写架构设计文档，所有人都能清晰看懂他的架构设计思路，他可以给整个架构画一张UML架构图，他也可以给思维导图里面，每一个分支，画一个UML架构图。UML架构图成了他架构设计文档的一部分，而不是使用额外工具；

测试工程师用思维导图来编写测试用例，再也不用担心别人看不懂他的测试设计思路，每个人很很乐于给他做测试用例评审，因为可视化的图形，让大家像做游戏一样，把测试用例拖来移去，没有任何迟疑。他们不用在工具上做过多思考，他们只需要按照自己心里的想法，随意地改变测试用例的位置，随意地改变测试用例的场景；

Bug创建也可以用思维导图。原来我们总是理解，Bug是一个个单独存在的，他们之间没有必要、也无法建立一些关联。但是现在，我们可以将同一个模块的Bug都放在一个思维导图下来进行追踪，当这个思维导图中的Bug全部解完了，这个功能模块自然就测试通过了。

这种随时能看清需求、架构设计、Bug全局的行为，大幅减少了信息不对称，降低了误会。人类世界中所有冲突，皆可归于信息不对称，在工程师的世界中同样如此。信息不对称大致可分为两类：一类是信息没有传达，另一类是信息传达了，而对方没有理解。MappingSpace极大地降低了第二种可能性，从而释放出工程师的善意。

MappingSpace高效地解决了大部分研发中的事情。根据我们内部的数据统计：

7. 需求、架构梳理的时间，节省了50%

8. 需求、架构评审的时间，节省了40%

9. 测试活动的效率整体提高了60%

如果MappingSpace仅仅能做到这一步，那她如何能称自己的愿景是，下一代汽车软件工具箱？

第一，MappingSpace可以进一步支持功能安全和信息安全，从而支持汽车软件领域最重要的三个法规。

FTA (fault tree analysis)天然就是一颗从结果到原因的故障树，联想到思维导图理所当然，因此它是最早被我们实现的；

HARA(hazard analysis and risk assessment)是从功能分解开始，逐步探寻每一个功能潜在的故障，每一个故障可能导致的风险，对每一个风险进行评级，从而得到安全目标。这同样是一个金字塔式的、从上到下的思维，也被我们放到了思维导图中；

FMEA是最难的，步骤二结构分析、步骤三功能分析、步骤四失效分析，同样非常遵循思维导图的模式，但最难的地方在于需要建立功能网和失效网，这个花掉了我们一些时间，但最终仍然以非常自然的方式呈现出来了。

第二，随着汽车开发过程越来越复杂，所涉及到的效率工具也越多，因此可预见地，在研发管理这个平台上，会需要链接各个领域内，越来越多更专业的工具。在这一点上，MappingSpace无意于重复造轮子，而是和业内最优秀的软件工具进行链接，从而创建更加高效的汽车软件工具链生态。

第三，MappingSpace已经接入了AI的能力，未来，用户将拥有更大自由度，选择接入自己的，或者其他国内第三方的大模型，实现更高效、更专业的研发过程文档编写。

后记

当你读完这篇文章，再回头看本文开头提到的MappingSpace的3个愿景：

10. 释放并激发人的创造力和善意

11. 作为人类思维方式的延伸

12. 下一代汽车软件工具箱

是否认为，按照这个方向，它们有可能实现呢？欢迎您在留言中和我们互动，也欢迎直接联系我们 support@ytdevops.com

另外由于我是MappingSpace的产品经理，也是云体科技的创始人，因此各位在选择工具时，应该警惕我是利益相关方，各位还需要独立思考，谨慎判断。

如果您有兴趣来注册试用我们的云端SaaS产品，我们愿意将您的终生免费用户数量提高到20位，以便您和您的团队能更深入地了解MappingSpace的功能和优势。

官网：https://www.ytdevops.com/home

注册地址：https://ms.ytdevops.com/login/register

文章转载自公众号：汽车电子与软件