之前写过一篇文章是《一名汽车软件项目经理的34个能力点和对应的5个级别》，算是比较零散的能力点，但这不能告诉我们如何展开日常具体工作，本文会对此总结提炼一些关键要点，以辅助初级项目经理快速上手。
不妨仍然使用PMBOK的经典框架展开：启动、规划、执行、监控、收尾。但对于项目经理而言，工作主要集中在启动、规划和监控上，因为执行是由具体的职能团队负责，而收尾这个过程往往比较形式化一些。
1启动
所谓，兵出无名，事故不成。
对于要组织团队干活儿的项目经理，也是同理，要讲究个师出有名。
建立这个“名头”的过程就是启动，而启动的方式也很简单，就是开一个软件项目启动会。
启动会可以关注两部分内容：
邀请谁参加：系统架构、系统需求、软件需求、软件架构、软件开发、软件集成、软件测试、质量保证等干活儿最多和提要求最多的人。
讲什么：立项背景、项目等级、主要变更、关键挑战、已识别风险、团队架构、首次发版计划等框架性信息。
实际上，启动会要达到的核心目的是让大家都知道也同意干活儿了，有时形式意义大于现实意义。
2规划
现在的汽车软件项目基本不会是单一的，多项目在平台化开发策略下有着复杂的分支管理需要，这就会衍生出很多依赖关系。
所以，我们需要分层规划，以便及早发现资源或技术冲突。
通常，从项目管理的角度，我们可以分为三层：
多个不同类型的项目层
面向不同需求的feature层
分配给不同个人的任务层
这三层从下到上逐级支撑上一层的实现，三层的规划也是相互依赖的。
2.1 第一层：多个不同类型的项目层
第一层的规划主要关注两大部分：
时间点：不同项目的不同里程碑下的不同成熟度软件交付的时间点。
资源分布：资源又会区分人力和钱（工时和材料费），前者关注的是要有真实的人干活，后者关注的是财务预算上的钱够用。
2.2 第二层：面向不同需求的feature层
当第一层的大目标和大约束确定下来后，我们可以通过feature来进入软件工程。
具体步骤如下：
利用ALM工具建立诸如CR（Change Request）这样的在线工作项，其会作为feature的承载。
将这些承载feature的多个CR工作项分配到第一层规划中不同项目不同节点软件交付的基线。
对CR的技术可行性、技术依赖性以及所需的资源与周期进行评估，并完成批准，即CCB批准。
2.3 第三层：分配给不同个人的任务层
到这里，上层规划已完成，需要进入到个体执行层面的规划，具体方式是将CR拆解为可分配给个人的任务，比如，分解为软件需求开发、软件架构设计、软件模块开发、软件集成（包括集成测试）以及软件测试等。
在这里，有几个注意点提示一下：
基于产品或项目的复杂性，可以增加拆解层级，比如，细分为Epic、Story、平台CR、项目CR、系统CR、软件CR、Use Case、Workpackage、Task等。
任务层级的具体协调、更新、验收应由职能团队管理者负责。
只要feature可以按时交付，就不需要软件项目经理的参与。
当CR下的任务都交付后，feature owner也就是前面讲的CR的owner可将对应CR标记为交付。
当针对CR的feature测试及更低层级的测试仍然遗留defect时，一个可行的做法是：基于defect的数量和严重程度，为CR也就是feature标记成熟度（百分比或红黄绿），而非简单的关闭或打开。
3监控
规划99%是无法按预期达成的，监控与调整必不可少。提供几个参考经验。
必须安排定期项目会议（如周会），最好是面对面的，讨论内容可以涉及软件交付进度的展示与协调、CR/任务/defect的状态、一定要分配单个负责人与完成时间的开口项清单（这几乎是项目经理最有效的管理工具）等。
花比较大的精力在交付策略澄清、overview展现（如利用清晰直观且实时更新的看板）和配置管理上。
有非常多的因素会导致计划的更新，比如，客户要求改变、开发返工、任务延期、重大缺陷或意外事件等。项目经理要及时更新软件项目计划，要让团队随时获取最新目标且保持紧迫感和节奏感。
要有高度的风险管理意识，风险管理的方法论不复杂，甚至显得很流于形式，但风险管理是种预防的逻辑，很重要。当然，要做好，需要mindset，也需要经验。
4全文小结
本文从启动、规划、监控这三个阶段概要地介绍了一个软件项目经理该如何展开日常工作。
启动会议既是一个信息告知会，更是一个获得“师出有名”的手段。
汽车软件通常很复杂，多层级规划与拆解是必要的，本文给出了一种思路，即利用ALM工具从项目、feature和task这三个层级拆分。因为计划永远赶不上变化，监控及发现变差后的调整不可避免，定期开会是个笨办法，但是必需的。另一个同样重要的工具是有人有时间要求的开口项清单。
5写在最后
启动、规划、监控是项目经理的三大步骤，而开会、ALM工具、开口项清单是三大抓手。
