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