最近有不少童鞋、特别是初⼊职场的朋友，向我咨询汽车软件⼯程师的职业发展与选择。刚好我想写⼀篇⽂章谈谈这个问题，顺便写⼀些⾃⼰作为软件⼯程师和项⽬主管这些年来的职场感悟，最后给出⼀个⾮常主观的选择排⾏。
⼊⾏这些年，我阴错阳差地当过通信诊断⼯程师、算法⼯程师、需求⼯程师、测试经理，现在是项⽬负责⼈，带着⼀个美、德、印三地⼗来个⼯程师的软件⼯程团队。也算是有⼀定发⾔权吧。可能有些观点⼤家不⼀定赞同，就算是我抛砖引⽟，还望轻拍。 ⼀、汽车软件⼯程师的职位都有哪些啊？我应该怎么选？
⾸先要澄清⼀个错误的观念，那就是：不是只有写代码的⼯程师才叫软件⼯程师！事实上，车企（零部件企业也好、主机⼚也好）的软件部门⾥，有⼀半以上的⼯程师是不写代码的，但是职位也叫“软件⼯程师”。
这⾥借⽤⼀张我的⽼帖
中的软件部门组织架构图：
软件部门组织架构
⼀个汽车软件部门，⾄少要有以下⼏种职位：
1. 项⽬组长
空气中取水
2. 需求⼯程师
3. 软件架构师
4. 基础软件⼯程师
5. 应⽤层软件⼯程师
6. 系统集成⼯程师
7. 测试⼯程师
那么对新⼈⽽⾔，究竟什么是好的职位呢？我觉得可以从以下⼏个维度来考察：
能常常学到新知识（成长性）：这个不说了，新⼈最重要的是学习
学到的知识在⾏业⾥有通⽤性： 这样才好下⼀份⼯作不是？
职位有灵活性，容易转岗：谁也不会在⼀个职位上⼲⼀辈⼦。
⼯作过得舒⼼，同事能尊重，⾃⼰有成就感免摇启动器
在公司⾥有曝光度，⽼板、同事能看得见你的⼯作：升职快啊。
钱多：简单粗暴。
还有⼀个维度是⼯作的稳定性，但是我个⼈认为这些职位的稳定性都差不太多，⽽且现在企业裁员都xjb裁，谁去谁留真的不好说，跟员⼯个⼈也有很⼤的关系。所以这个维度就不⽐较了。
我们现在⼀个⼀个说。
汽车软件开发流程和职位⽰意
1. 项⽬组长：负责整个项⽬的总体规划、任务分配、资源整合、客户对接，定义任务优先级，在技术路线发⽣争执的时候做出决策，并
监督整个项⽬的进⾏。⽤⼈话讲就是⼀个“对外忽悠客户、对内忽悠组员”的职位。
基本上在软件团队⾥，这个职位是最好的，但是跟职场新⼈也是基本上绝缘的。你不把技术、流程⽤⼏年时间理清楚，咋能出去忽悠⼈呢对吧。 所以这个职位新⼈基本上就不⽤关⼼了。
成长性： 5
知识通⽤性：5
转岗灵活性：5
⼯作成就感：5
曝光度： 5
⼯资： 5
综合评价： 5 -- 少年你还在想什么呢？
2. 需求⼯程师：和客户沟通软件需求，讨论确认所有技术细节，并撰写详尽的需求⽂档。
坦⽩⽽⾔，说需求⼯程师是⼀个项⽬最重要的职位也不为过。⼀份准确、清晰的需求⽂档是⼀个优秀项⽬的基⽯，⽽⼀个优秀的需求⼯程师团队更能够直接⼤幅提升整个项⽬的效率，甚⾄能引导整个项⽬组以最优的路径开发。需求⼯程师本来应该是由经验丰富的⽼⼯程师担任的。
但是呢，需求⼯程师同时也是⼀份⾮常枯燥的⼯作。平时有⼀半以上的时间都在写⽂档。如果你⾜够不幸， 那还得在⼀个叫DOORS的挨千⼑的软件平台⾥写，可以写得你怀疑⼈⽣。
IBM 需求管理软件DOORS
技术⼤⽜们当然是不屑于写⽂档的啦！所以国内外的现状就是“鸠占鹊巢”：技术⼤⽜负责和客户沟通需求，⽽需求⼯程师们退化成了⼀
帮“打字员”，只是记录技术⼤⽜的讨论和设计，把它们被动地变成需求⽂档。
于是需求⼯程师往往就由新⼈来担任，在外企的话，甚⾄整体外包到印度、越南、罗马尼亚等等低⼯资国家去完成。由于新⼈或者外包团队对产品理解有限，往往写出来的需漏洞百出，于是被⼤⽜怼简直是需求⼯程师的常态...总⽽⾔之这简直是软件团队⾥最糟糕的⼀个职位。
由于需求⼯程师不接触代码，也不接触算法细节，很难转岗到别的职位。需求⼯程师的成长路线往往是向系统⼯程师、质量⼯程师、安全⼯程师上靠，最终脱离软件部门。另外，⾮常优秀的需求⼯程师也是有机会成为项⽬主管的，但往往这种优秀⼯程师都不是⼀毕业就做需求出⾝。
成长性： 4
知识通⽤性：3
转岗灵活性：3
⼯作成就感：2
曝光度： 3
⼯资： 3
玻璃纤维膨体纱综合评价： 3 -- 短期做做挺好，别做久了！
3. 软件架构师：负责软件架构设计，明确各个软件模块之间的接⼝，并且负责操作系统的配置和调度。
这⼜是⼀个和新⼈⽆关的岗位。不多说了。能⼲这个都是技术⼤⽜，甚⾄⽐项⽬主管还⽜，因为毕竟不是每个搞技术的⼈都想去做撕逼抢资源的协调⼯作。
软件架构师转项⽬主管是理所当然的事，甚⾄在不少项⽬⾥，架构师本⾝就是项⽬主管的备份。架构师⼏乎可以转软件部门的任何职位。
架构师的常⽤⼯具软件：Enterprise Architect
成长性： 5
知识通⽤性：4
转岗灵活性：5
⼯作成就感：5
曝光度： 4
⼯资： 5
综合评价： 4.7 -- 和项⽬组长不相上下的选择
4. 基础软件⼯程师：其实基础软件⼯程师还可以再细分。包括软件驱动⼯程师、通信/诊断⼯程师等等。驱动⼯程师就包括Hardware/ECU Abstraction Layer的设计和编程啊、Bootloader编写啊、AutoSAR的配置啊、内存Layout的设计啊、操作系统啊等等，范围很⼴。⽽通信诊断⼯程师就是字⾯上的意思：负责总线通信接⼝的配置和诊断的配置。
驱动⼯程师其实蛮吃⾹的，尤其现在AutoSAR是个热门，知识通⽤性很好，因为各个ECU其实驱动部分的开发都差不太多。但是底层软件跟ECU的具体功能离得蛮远，并不容易转成算法⼯程师。驱动的测试和软件应⽤层的测试差别⽐较⼤，所以也⽐较难转成整体软件的测试⼯程师或者测试经理。
另外，虽然知识通⽤性好，但是驱动⼯程师的市场需求总体来说是⽐较⼩的。因为⼀个ECU软硬件平台定型以后，基本上驱动部分未来3到5年都不会进⾏⼤规模开发了，⽽是成为⼀个平台解决⽅案，被各个项⽬借⽤，所以驱动⼯程师团队并不需要很⼤，这意味着⼀旦失业可能还是不如其他职位好⼯作。
成长性： 4
知识通⽤性：5
转岗灵活性：2
⼯作成就感：4
定时药盒曝光度： 3
⼯资： 4
综合评价： 3.7 -- 我觉得还⾏
通信/诊断⼯程师，这也是我进⼊汽车⾏业的第⼀个职位。怎么说呢。。。真的超级枯燥且没有成就感。这也是我在做了两年多以后选择跳槽的主要原因。通信/诊断容易上⼿，适合新⼈。市⾯上绝⼤多数车企都⽤的是CAN通信和UDS诊断协议。如果做德国车企项⽬的话，再看看FlexRay就可以了。
然⽽通信/诊断职位在技术上没有太⼤上升空间，虽然知识通⽤性很好，不愁⼯作，但很难接触ECU的核⼼功能算法，算是对职业发展有⼀定的限制。通信/诊断⼯程师是可以转成测试⼯程师的，但是⼏乎不可能成为总体软件的架构师或者项⽬主管。
⽽且由于上⼿快，⼯资也不是特别有竞争⼒。
成长性： 3
知识通⽤性：5
转岗灵活性：3
⼯作成就感：3
曝光度： 3
⼯资： 3
综合评价： 3.4 -- 有点鸡肋啊，还是尽量转岗吧
5. 应⽤层软件⼯程师，在很多公司也被叫做算法⼯程师或者控制⼯程师。看过我以前帖⼦的童鞋都知道，我做过很长⼀段时间的转向助⼒算法⼯程师和制动系统算法⼯程师。我觉得这段经历是最让我获益匪浅的。
应⽤层软件⼯程师的主要⼯具之⼀：Matlab/SimuLink
应⽤层软件，算是ECU软件核⼼中的核⼼。⽆论是什么控制系统，都可以通过对应⽤层软件的设计获得⾮常深刻的理解，成长性⾃不必说。对于通⽤性⽽⾔，只要是算法⼯程师，招聘时候并不太关⼼你以前是不是做同⼀个ECU的，因为应⽤层软件都有它的相似性。但是有⼀点需要注意，那就是ECU的安全等级。
总体来说，⾼安全等级ECU （⽐如转向、制动、安全⽓囊控制器）的应⽤软件⼯程师，⽐低安全等级
ECU（车载娱乐系统、车⾝控制——⾬刷、车窗等等）的⼯程师，在⼯作的时候有更⼤的优势。这⼀点我们可以后续再谈。
成就感爆棚也是应⽤层软件⼯程师的⼀个特点。应⽤层软件⼯程师基本上都有机会实车测试并调试⾃⼰写的算法。看着⾃⼰的算法从⼀⾏⾏冰冷的代码，变成能够跟驾驶员交流的实际功能，这种成就感是其他⼯作（哪怕是项⽬主管）都很难带来的。
另外，由于应⽤层软件⼯程师需要参与V型流程的全过程，基本上可以转成任何其他的岗位，转型架构师或者项⽬主管也是⽔到渠成的事。
成长性： 5
知识通⽤性：4
转岗灵活性：4
⼯作成就感：5
曝光度： 4
⼯资： 5
综合评价： 4.5 -- 对于职场⼩⽩最好的出道选择！没有之⼀！
6. 系统集成⼯程师，负责将每个⼯程师的软件变更正确地集成在⼀起，形成新的发布软件。系统集成的具体⼯作就涉及到SCM (Software Configuration Management) 的部分了，⽐如有的公司⽤SVN，新潮⼀点的公司⽤git ， 还有的公司⽤⼀些奇奇怪怪的⼯具(ClearCase, ) 等等等等。⼀般⽽⾔，除了巨⽆霸公司有专职的系统集成⼯程师，⼀般这个职位是其他⼯程师兼任的。
ClearCase, 集成⼯程师要给每个模块定义好不同的分⽀和标签，来形成正确的最终软件
系统集成⼯程师⼯作⽐较枯燥，⽽且系统集成总是发⽣在软件发布周期的最后，压⼒超级⼤。由于集成⼯程师往往也负责⼀部分集成测试，所以转做测试⼯程师/测试经理还挺常见的。另外的职业上升途径就像需求⼯程师⼀样，转做质量或者系统⼯程师。除此之外，转岗并不是很容易。
集成⼯程师的具体⼯作很依赖本公司的SCM软件，所以可能在公司A你是ClearCase⼤神，⽽转到⽤PTC Integrity的公司B你就有点蒙圈了（虽然原理都差不多）。知识的通⽤性不是很好。但是集成⼯程师往往对软件发布的流程烂熟于⼼，所以说转去做质量⼯程师的很多。
实验室用振荡器
成长性： 3
知识通⽤性：3
排火
转岗灵活性：3
⼯作成就感：2
曝光度： 2
⼯资： 3
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议