一名汽车软件项目经理的34个能力点和对应的5个级别

有些朋友问我，如何评价项目经理这个职能？我通常的看法是，门槛很低，上限很高。

这篇文章会更聚焦些，谈谈汽车软件项目经理如何从“入门”走到“很高的上限”。

人的能力是很多元的，在谈级别之前，我们先看具体的能力点，具体总结为6大领域（项目管理、流程、技术、工具链、领导力、商业与项目组合管理）的34个能力点。

现如今的汽车软件开发，跨组织协作的特点更为突出，而与上下游协作的过程必然涉及询价、报价、定点、合同、订单等一系列采购活动。

作为工程类角色，通常不必掌握专业的采购知识，但因为要处理报价策略、产品平台选择、供应商管理或者客诉等事务，对这些基础知识和应对流程要有理解。

相关方就是“人”，管理人是最难的。

有限的资源下，没有实权的项目经理们，如何协调好不同相关方的立场？这个环节是区分“还不错”和“优秀”项目经理的分水岭，有时是需要点天赋的，具体可掌握如下能力：

识别出所有的内外部相关方，并确定优先级，有时不止看表面上的官职高低。

主动、提前与相关方沟通好，桌下先达成一致。

有效、及时的汇报与升级，这几乎是项目经理的最大权力了。

针对不同个性和不同立场的人，善于调整沟通风格。

对于软件项目经理，范围基本等同于需求，也就是说要能进行需求管理，具体可掌握如下能力：

需求工程方面的知识，知道向谁、如何获取需求并进行分解。

组织需求变更的CCB会议，甚至具备全局视角下的决策能力。

控制需求变化和导入的节奏，而非一味拒绝或全盘接受。

评估缺陷修复对项目的整体影响

使用Doors之类的需求管理工具

保证基线与追溯的完整与更新

进行需求分析任务的分配，有时需要利用JIRA之类的ALM工具

进度不能说是项目管理活动中最重要的，但却是几乎项目经理最关心的，也就是谁在什么时间能完成什么任务。具体可掌握如下能力：

一些基础的进度排布知识，如WBS、甘特图、关键路径法等

资源计划与平衡，即当资源冲突时，对不同任务的开始和完成时间进行重新调配，以保证资源可用

计划、监控开发和测试工作

跟踪、把控各活动及整体进度

使用ALM进行计划、EPIC、Story、Task等的定义与分配

一般来说，软件项目经理侧重于工程交付，成本管理主要集中在项目预算评估、成本定期监控与控制、工时的统计梳理等基础的成本管理工作。

质量不止是QA的活儿，或者更准确地说，QA原本就是来配合项目经理把软件质量规划管理好的，具体可掌握如下能力：

项目过程定义、裁剪与优化

SQA计划的评估与审批

支持软件质量阀评审与偏差关闭

软件度量指标的监控与控制

这里的资源比较狭义，主要指工程师、软件开发环境（工作站、许可证、权限．．．．．．）、硬件资源（ECU样件、线束、台架．．．．．．）。

项目经理要负责解决资源不足的问题，包括但不限于汇报升级、刷脸、自己上。

除了电话、微信、邮件这类非正式沟通外，这里提几点相对正式的沟通：

组织定期会议，定义与会者、频率和议程，如每日站会、项目周会、CCB会、需求澄清会、管理层汇报会等

记录和跟踪开口项清单

定义、管理项目文件的层级与权限

我始终对风险本身的管理活动嗤之以鼻，诸如一些风险定性定量评估、风险规避转化之类的说法，最终都可转化为一条条开口项。但不是说，风险管理不重要。

风险管理中最核心的是对风险的敏锐嗅觉，能够知道哪里可能不牢靠。

我们佩服野路子项目经理，但当企业规模更大、项目更加复杂时，必然要走向流程化。当然，流程远不仅仅是纸面的流程图，更需要的是利用流程解决问题。

软件测试要占到整个开发工作的40％以上，重要性不言而喻。具体可掌握如下能力：

对ASPICE有整体的理解，这是汽车软件的入门

组织内部的测试流程、工具

完整测试、回归测试、冒烟测试等测试策略

测试角色的工作方法，以便于沟通

测试覆盖率之类的指标要求

发布代表着软件将从开发内部转移到下游客户，发布是软件项目经理要重点管控的环节。具体可掌握如下能力：

知道发布什么文件和整体的内外部交付流程

获取软件所交付的客户对质量的要求

发布评审流程及工具

判断遗留缺陷对下游的影响程度

发布后文档基线归档的流程

绝大多数软件（至少是量产那一版本）是通过工厂的零件装配逐级进入整车的，工厂也会有一些读取、写入之类的诊断测试工作。了解工厂流程对管理软件也就有很有必要。具体可掌握如下能力：

样件或量产件发布流程，这主要适用于一二级供应商

正式释放到工厂的软件如何进行OTA或变更

样件生产、量产或OTA所需的代码、配置和文件输入

软件项目经理的基础全局观将通过配置管理来实现，具体可掌握如下能力：

清楚哪些工作产品需要被作为配置项

使用工具进行配置管理

软件产品线和分支规则

文档命名、存储、数据安全的规则

1．2．5缺陷原因分析和解决流程

缺陷处理显然是软件项目经理的工作大头，具体可掌握如下能力：

识别缺陷所属学科

进行根本原因初步定位

制定预防措施并跟踪其有效性

软件项目经理算是半个技术人员了，要打交道的人多数是工程师，技术能力必不可缺。

汽车作为一个大的产品盒子，包含的产品千千万，而软件也都是作为单独的产品或者嵌入到零件中成为产品的。无论如何，对所负责产品本身知识的掌握是技术能力的基础。具体可掌握如下能力：

从概念到量产直到退出的产品全生命周期管理

终端用户视角下的产品要求

产品自身质量特性，如性能、可重用性、可维护性、可靠性等

内外部产品的历史、现状（StateoftheArt）、趋势（Roadmap）

产品的子级单元或上级子系统知识

硬件架构与设计知识

产品终归要在以车型牵引的项目上应用，而项目具有独特性。因此，产品在项目上应用的特定知识是这个环节要关注的。具体可掌握如下能力：

产品在不同地区的法律法规

车辆电子设备电气要求

与车辆其他系统的交互依赖关系

这部分是脱离于产品，也脱离于项目的软件工程技术能力。具体可掌握如下能力：

敏捷原则和实践经验

基于模型的工程MBSE知识

软件分支和配置管理知识

这里用了产品测试，因为尤其对于嵌入式ECU盒子，光有软件测试不足以保证测试的充分性，还有系统测试、硬件测试、EMC测试等。尽管其他学科都有相应的责任人，但软件项目经理仍需要有一定的基础。

软件以上各级系统测试知识

软件以下的静态扫描、单元测试、集成测试知识

测试环境的搭建、调试知识

测试用例的理解、跟踪与评估

硬件、环境与EMC测试知识

编写、阅读、维护代码的能力是最硬核的

技术点，具体是C、C＋＋还是JAVA要看软件类型。

软件的庞杂让我们无法离开工具链的支持，我们至少要会用。工具也有非常多的种类，详见《拆解一下汽车电子软件开发工具链》，这里仅做一个概览。

作为管理者，领导力十分重要，但这是一种软素质，很难去练，很大一部分取决于个性和天赋。

结果导向、解决问题和着眼于未来，这种看起来雷厉风行的风格对于项目经理颇有裨益，或者说这也是领导者的特质。

做技术的人多数都害怕冲突，做项目管理则要直面冲突，也要懂得如何平衡冲突方之间的利益。这仍然属个人情商的范畴。

跨供应链、跨部门、跨职能、跨组织的关系网的建立与维护是应对各种复杂事务的基础，项目经理尤其要学会协作。

善于听、能说、会写的沟通能力一项放之四海而皆有用的基本技能，而这对于大部分工作就是沟通的项目经理而言，意义尤其不同寻常。

汽车行业对跨国交流要求很多，我们要能够理解和欣赏不同的文化，知道如何与欧美、印度、日本等有着不同文化特点的同事、供应商、客户顺畅交流。当然，前提是英语要过关。

项目经理不做具体的执行工作，要将整个项目主动管起来，别人都可以各人自扫门前雪，只有项目经理不能，他们要为最终的项目交付负责。

1．6商业与项目组合管理能力

BusinessSense，这是以前做工程师时，总被领导提点的，无论产品还是项目，都是为了商业和组织战略服务的，说起来可能有点大，但对于致力于向上发展的项目经理们，也不可不察。

这个概念很宽泛，具体一点看，要理解组织的各条产品线定位、主要竞争对手及其独特的卖点、组织对不同客户的策略、最新的行标法规对业务方向的影响、客户的车型组合等，这些High－level的认知有助于你的具体事务决策。

我们通常不会只负责一个车型项目的一个产品，或者是一个客户群下的一个产品，或者是一个产品下的多个客户群，或者是多产品与多客户的组合。总之，同时管理多个项目时，要能统筹兼顾，识别复用机会，优化产品方案组合，最终保证项目的高绩效交付。

每个能力点的5个等级

以上我们梳理了一名汽车软件项目经理通常要涉及的能力点，看起来要求相当高。实际上，并不是每个能力点都要很精深，不同背景的项目经理有不同的擅长点，不同组织也对项目经理有不同的定位。

一般而言，对于常规项目的软件项目经理，技术要求（对应于以上的流程、技术、工具链）会更高些，而对于复杂大项目的软件项目经理，管理要求（对应于以上的项目管理、领导力、商业与项目组合管理）会更高些。

我们无法针对每个能力点要达到什么水平给出标准的答案，这取决于站位。不过，可以看下每个能力点掌握得好与差到底有什么区别，分什么级别，也可以给各位一个方向上的参考。

我们总结为以下5个级别：一无所知、理论派、实践派、直觉派与传道授业。

一无所知的感觉应该比较清楚，尤其是自己，一无所知这个词也比较通俗了。

当然，这是个理论极端。具象点，如果我们对某个“技能点”（或主题或领域）的主要专有名词没听过、不理解、不清楚，以及和负责这项工作的人无法交流超过10句话，可以算是成功达成该等级。

之前和一位非汽车行业背景的朋友交流功能安全，提到ASIL，他说电脑编码吗，我说那是ASCII（AmericanStandardCodeforInformationInterchange，美国信息交换标准代码），哦．．．．．．显然，这位他的领域的资深人员对汽车功能安全这块可算是一无所知。

理论非常有价值，理论高手也依然是高手，但对于侧重于应用价值的企业来说，能否解决问题和实现具体的目标才是主要评价标准，所以我们仅仅将理论派排在了“一无所知”之上。

现实中的理论派一般是通过看书、查资料、听培训、道听途说、观察他人等方式达成的。或者，所谓非本行专业人员将部分知识、经验进行的跨行业迁移，多少也算是理论派，纯理论派往往很难去独立处理具体的业务，需要行业人引路。

比如，理论上，测试人员知道我们应该测试前移、避免bug逃逸，但实际上，我们的人员配备如何、产品成熟度如何、成本范围如何、SOP节点如何、公司策略如何等现实性的具体问题会直接影响这条政治正确的理论的落实方式，甚至直接决定其不必落实。

对应于理论派，就是实践派。尽管我们把实践派放在了理论派之上，但不代表实践派全面超越理论派，很多情况算是并行，或者最多站在实用角度看略微超理论派半个身位。

实践派是指在某个具体的产品线、某个具体的项目上的有过实际的经历与经验，以后面对类似的任务，他可以马上上手工作，而不需要他人的指点与伴随，但并不意味着他的理论体系比较健全，也了解这样做背后的道理。

不过，可能对于初级执行岗位，有执行力的、趁手的实践派比较容易获得青睐。

另外，实践派与理论派有一个显著的区别在于对细节的把握上，所谓一线的炮火声，这些细节相当于血肉，初期的成长阶段极为重要。简单来说，你有没有完整的项目经验以及有几个。实践能力需要靠足够的项目堆出来。

项目有个特点是独特性，所以项目开发工作中基本要面临新的、有困难的、突发的事件，尤其是复杂的大项目，所以历史的实践和从历史的实践总结出的理论都有可能不那么适用，甚至失效。

这时，该怎么办？就是需要靠大量理论基础和实践经验磨练出来的直觉，就是在摸不到头绪的乱麻里轻松理出头绪，在找不到北的困局中快速找到方向。

一个资深的软件工程师面对很异常的、涉及面很广的软件bug，他能够调动以往各种经验和多个背景的理论知识来分析、研判、定位，这其中也需要他或纯天生或辅以后天经验的、对细节串联把控的天赋。

再举个生活中的例子，我上学时有一个没啥用的天赋，就是班级里几十个人的名字怎么写可以非常快地记住，就是对字有一种敏感和直觉。但另外一点，我的方向感极差，开了也有十来万公里的车，一条路距离超过5公里、转弯路口超过3个就记不住了，脑子里完全建构不起来路线图来，也就是没有那种敏感与直觉。

理论派大约属于看得懂，实践派要求做得到，这个阶段还需要讲得出、讲得清、讲得全，所谓传道授业。

此时的你，可以指导别人去解决复杂问题、去找到具体方案，也能够提炼出有效的方法论来，能够教给别人，救火时可能需要亲自出马，最后还能够将那种高手的直觉转化为方法、流程、标准，以便这种效用能够被稳定化和杠杆化，从个体成功走向团队成功。

但并非所有能力点都有很高的要求，不同难度的项目有不同级别的要求。针对能力点的级别，文章也提出了一无所知、理论派、实践派、直觉派与传道授业这5个级别，各位可自我对照。

再回顾下文章开头的那8个字――“门槛很低，上限很高”。

汽车软件项目经理同样，我们大多数初级的项目经理只在流程、技术与工具链上有部分实践，倒也是能做，门槛显然不算高，但如果多方面能力都能达到实践与直觉的地步，发展上限自不会低。

原文标题：一名汽车软件项目经理的34个能力点和对应的5个级别

iOS15.2正式版发布，重磅功能来了！

安卓手机，已经装不下高通的野心了？

iPhone：重回巅峰的感觉真不错！

小米12mini与iPhone13mini有一战之力？

华为之后，谁能冲击智能机高端市场？

EUV光刻机无法卖到中国

新时代未解之谜：手机存储卡是如何被淘汰的？

小米笔记本Pro15增强版评测：3.5KOLED屏

OFweek（第二届）中国人工智能产业大会“AI智能硬件论坛”

长江商学院科创大课堂-品牌思维与精细化营销

长江商学院科创大讲堂--硬件创业密码

OFweek2017智能硬件产业高峰论坛

本文地址：https://www.uel.cc/article/8d292afac61bf6f979bb.html

上一篇：磷酸铁锂电池的特点和优势...
下一篇：皮秒飞秒激光面向AR高折射率玻璃的精密切割...