中文翻译《ASPICE in practice》之“MAN.3 项目管理”

2.19 MAN.3 项目管理

2.19.1 目的

项目管理过程的目的是根据项目的要求和约束，识别、建立、规划、协调和监控项目生产产品和/或服务所需的活动、任务和资源。

项目是临时的、复杂的工作，通常要面临具有挑战性的最后期限。汽车行业还存在一个额外的困难，即由于旷日持久的采购谈判，项目的“正式”启动有时为时已晚，例如，在第一批原型车已经可用时。然而，项目完成日期（通常是新车的生产开始 (SOP)）是确定的。此外，项目开始时不明确的合同情况可能会给双方带来问题：客户的项目经理不确定他现在是否可以向开发组织（供应商）提交要求、最后期限等。为了满足最后期限，开发组织通常必须在没有明确定义的需求规范文件和具有法律约束力的合同的情况下开始前期工作。通常，项目在开始时失去的时间无法在其生命周期内重新获得，因此它从一开始就处于关键路径上。因此，具有足够详细规划的系统项目管理以及适当的项目进度跟踪机制是确保关键项目实现其目标的基本先决条件之一。

2.19.2 汽车行业特有的特征

在汽车行业，开发项目通常包括硬件、软件和机械部件的开发。可用的硬件、机械和软件平台通常会针对特定客户进行调整。在较大的开发组织中，这些项目通常由具有不同职责的不同客户团队/领域部门开发。在复杂的项目中，还有额外的团队负责测试和试验、集成、原型设计和平台开发（另请参阅我们在工程流程中的审议）。

这也反映在项目组织上，项目通常由几个子项目组成。在大多数项目中，软件是由一个或几个子项目开发的。

评估员须知

许多评估选择仅评估项目的软件开发部分。然而，项目管理过程的评估还应考虑软件子项目与整个项目的相互作用。

2.19.3 基本实践

BP1：定义工作范围。定义项目要承担的工作，并确认项目目标在现有资源和约束条件下是可行的。

在建立项目之前，应定义项目范围。根据 [PMBOK 2004]，确定项目范围需要以下内容：

1. 项目基本原理/业务需求
2. 项目目标，包括衡量目标实现的量化标准
3. 将要开发的产品和/或服务的描述
4. 将要创建的所有可交付成果的概述

项目范围通常以范围说明和项目工作分解结构 (WBS) 的形式记录。

评估员注意

在内部开发项目中（例如开发工具的开发），项目范围的定义通常不够充分。项目定义通常缺失，并且项目的确切范围没有得到适当定义（例如，对于开发工具：用户手册是否属于范围的一部分？初始支持是否属于项目的一部分？）。关于内部项目的项目规划和跟踪，应应用与客户项目相同的规则和标准。

在项目过程中，BP1 周期会执行多次。在项目开始时，会创建一个粗略的项目工作分解结构。每次进入新的项目阶段（参见 BP2）时，都会进一步细化该结构，直至工作包和活动级别（参见 BP4）。在汽车行业，项目范围可能会在其生命周期内频繁变化。原因如下：

1. 项目开始时并不总是明确定义需求。由于项目进展方式以及技术概念的修改（例如，车辆中的功能分布），因此会产生变化和新需求。
2. 由于当前市场需求（例如，竞争对手推出新功能，从而获得竞争优势）和当前创新，必须集成项目开始时未知的新需求和功能。
3. 遵守生产日期（开始生产等）和相关里程碑（如产品预系列、样品交付日期等）具有最高优先级。因此，如果商定的里程碑（例如，样品版本）受到威胁，功能就会降低。

因此，一个运行良好的变更管理系统尤为重要（见 SUP.10）。

项目目标必须在商定的成本、时间和质量参数范围内

1. 这些参数特定于项目，
2. 可衡量或可量化，
3. 切合实际，
4. 以书面形式提供。

还应列出非目标（什么不在项目范围内？）。还应记录实现目标所需的条件。

在汽车行业，项目目标通常由合同明确规定。对于非技术范围，目标是样品版本的截止日期或要交付的物品数量。技术范围，例如功能要求，通常在技术规范中描述（另见 ENG.1）。主要目标是让具有计划功能的车辆部件为 SOP 做好准备。

在汽车行业，产品范围通常以要通过功能列表实现的功能的形式进行规划。此列表用于规划各个示例版本和软件版本的内容，将功能（可能还有错误修复）分配给不同的软件版本和里程碑，并跟踪其实施情况。此外，基于此列表，客户和供应商可以在早期阶段就功能范围达成一致。客户知道计划在哪个交付中使用哪些功能，以及何时可以对其进行测试。图 2-19 是无线电导航系统 (RNS) 功能列表的摘录。

图 2-19 RNS 功能列表摘录

理想情况下，项目目标的可实现性应在项目开始前进行检查。在涉及新技术的复杂项目中，通常会进行可行性研究。这通常以单独的（试点）项目的形式进行。可行性研究通常侧重于与成本和收益考虑相关的技术方面（另见 [Kerzner 2001]）。通常会考虑几种替代方案，因此应回答以下问题：

1. 将选择哪种替代方案，项目在技术上是否可行？
2. 需要哪些资源，预计会产生哪些成本，所需资源是否真的有望获得？
3. 需要什么时间框架，目标截止日期是否完全可行？
4. 有哪些机会和风险？

BP2：定义项目生命周期。定义适合项目范围、背景、规模和复杂性的项目生命周期。

注意：应验证项目生命周期与汽车开发过程之间的一致性。

对于每个项目，都会为项目管理指定一个合适且适当的项目生命周期。在顶层，它通常由几个项目阶段组成。图 2-20 显示了 ECU 开发项目生命周期的示例。

图 2-20 ECU 开发项目中的项目生命周期示例（供应商视图）

项目阶段应通过里程碑分隔。许多组织已在定义的里程碑处定义了阶段过渡。有定义的标准可用于检查是否已达到里程碑以及是否可以认为该阶段已完成。实施阶段的典型里程碑是样品交付日期。在交付前，这意味着审查所需文档并进行验证，以查看计划的质量检查是否已完整且成功地执行。

项目阶段将项目分解为更大的部分。在复杂产品的开发中，实际实施阶段通常持续一到几年。因此，必须进一步细化这些阶段。在较低级别，使用定义流程步骤、方法和工作产品的流程模型来细化项目阶段。在汽车行业，开发周期通常经过 V 模型的几次迭代（有关更多详细信息，请参阅 [V 模型 XT]）。

在一定程度上，流程和里程碑通常由客户自己的产品开发方法决定。例如，汽车制造商的开发流程（包括所谓的样品阶段和由此产生的开发原型）可以设定非常严格的里程碑时间框架，从而对其开发合作伙伴的开发流程产生深远影响。

在这一基础实践过程中，需要定义要执行流程模型的哪些项目阶段、里程碑、开发周期和流程步骤。这包括指定在 B 样本开发期间是否要执行 2 个或 3 个开发周期，以及每个增量是否将完全循环“小 V”（根据 V 模型）。

此外，还应检查供应商的项目开发生命周期和 OEM 的车辆开发流程相互关联和相互契合的程度。图 2-21 说明了典型的里程碑和相关的开发阶段。

图 2-21 里程碑网格和相关的开发阶段

BP3：确定并维护项目属性的估计值。定义并维护项目属性的基线。

注意：项目属性可能包括 1) 项目的业务和质量目标、2) 项目资源和 3) 项目工作量、进度和预算。

注意：应使用适当的估计方法。

注意：确定开发策略并估计开发生命周期中满足要求的资源。

注意：资源可能包括所需的基础设施和通信机制。

注意：在估计项目属性时，可以考虑项目风险和质量标准。

估计主要项目参数（工作量、成本、截止日期和质量）（另见 [Hindel 等 2006]）。这些可能包括以下内容：

1. 工作量估计：根据项目的工作分解结构估计创建或实施工作包或模块所需的工作量（例如，以人天为单位）。工作量通常自下而上估计（“微观估计”），将要完成的工作分解为小的工作包。在最低级别，它按每个工作包进行估算，然后逐步加起来以计算总的估计项目工作量。
2. 进度估算：根据估计的工作量和可用资源，估算目标日期（参见 BP6）。在汽车行业，样品交付日期和 SOP 通常是固定的，因此规划重点是中间截止日期和预计在各个里程碑准备就绪的功能范围。
3. 成本估算：资源成本是通过将估计的工作量乘以相关的人员成本率来确定的。还必须添加所需资源（如开发环境和材料）的额外成本。这一点不要与项目报价的计算混淆。
4. 质量规划：必须规划中间产品和最终产品的质量（例如，特定开发版本允许的最大缺陷率、测试覆盖程度）。这通常在质量规划期间或与质量规划协调进行（参见 SUP.1 BP1 和 BP3）。

组织通常只进行工作量、成本和进度估算，很难定义可衡量的质量目标。

上述注释之一涉及估算方法的使用。在实践中，经常使用 Delphi 和 3 点估算等专家估算技术，而功能点或 COCOMO 等高级方法在汽车行业几乎不使用。非正式专家估算在项目中相当常见。通常，结果是未记录的估算，其推导不清楚。估算模板已被证明可用于项目，因为它们允许以相对较少的努力进行结构化估算。有关估算方法的进一步讨论，请参阅 [Hindel et al. 2006]。

记录实际值的方式是有利的（但不是必需的），以便允许创建例如基于收集的经验的具有典型、预定义工作包工作量的标准估算模板。然后，这些经验值用于新项目（所谓的历史数据）。在大多数情况下，估算的准确性因此大大提高。它假定可以定义适用于所有项目的标准工作包。

另一种收集经验和改进估算的方法就是进行项目完成评审或“经验教训”。这样可以收集宝贵的经验，用于未来的项目。特别是在持续时间较长的项目中，在项目过程中（例如，在重要项目阶段结束时）进行几次完成评审是有意义的。在这种情况下，目标不再只是为未来项目学习，而是直接将学到的经验教训应用于同一项目的下一阶段。例如，确定的改进涉及流程和项目描述、模板和清单的调整，以及改进团队合作的措施。关于估算，可以收集以下经验：

1. 准备用于未来项目的实际工作包工作（例如，以历史数据库的形式）
2. 根据实际工作改进估算模型
3. 项目风险的跟进：在未来估算中的考虑

估算是在项目过程中的不同时间进行的。粗略估算是在项目开始时进行的，或者例如包括在报价过程中。在项目规划阶段，这些粗略估算会进行调整和具体化。最后，估算是在工作包级别进行的。在实施阶段，例如，在进入新项目或样品阶段时，或在重新规划时，会进行进一步的详细说明和调整。Automotive SPICE 要求以基线的形式编制这些估算（以及相关的估算文档）。这些基线可以作为整个项目基线的一部分（参见 SUP.8）。

维护估算意味着要考虑项目过程中的变化，结果是需要重复估算或在需要时调整估算文档。估算还可以考虑风险，例如，可以考虑风险津贴。

评估员注意

非正式专家估算很普遍。在那里，估算是由在相应领域具有专业知识的员工非正式地进行的。在这种情况下，非正式估算的结果应有可追溯的记录。只要有可能，估算应由至少两名专家进行，如果只有一名专家进行估算，则由第二名专家进行审查。

BP4：定义项目活动。根据定义的项目生命周期和估算来规划项目活动，定义和监控活动之间的依赖关系。

注意：活动和相关工作包应具有可管理的规模，以确保可以进行充分的进度监控。

项目工作分解结构（WBS，参见 BP1）的定义更为详细。活动源自 WBS 的最低级别。此外，还添加了源自项目生命周期（参见 BP2）的活动。注释中提到，项目的计划工作包需要具有可管理的规模，以确保可以进行进度监控。这取决于项目的持续时间、规模、复杂性、报告周期等。对于完成时间超过一年且每月进行项目跟踪的项目，一个参考值可能最多为 4 周或 160 人时。经验法则是，工作包应详细到可以在一个报告周期内监控其进度的程度。

根据生命周期模型（例如，迭代模型），创建不同的迭代活动实例，例如，设计第一个原型、设计第二个原型等等。

定义活动之间的依赖关系。例如，必须先创建特定组件的设计，然后才能实施。具体的时间顺序在 BP6 中确定。

BP5：定义技能需求。确定项目所需的技能，并将其分配给个人和团队。

根据要完成的任务确定所有必要的资格，并与候选员工的资格进行比较。在此基础上，规划项目团队的最佳人员配置结构。这通常由项目或直线经理完成。如果指定员工不具备必要的资格，则必须采取适当措施对其进行培训。

BP6：定义和维护项目进度表。为活动分配资源，并确定每项活动和整个项目的进度表。

注意：这包括适当的重新规划。

注意：项目时间表必须在项目生命周期内不断更新

为项目计划的活动分配给团队中合格的个人成员。必须知道哪些不同资格的工作人员在何时到何时以及在多大程度上可用，以及活动之间的依赖关系。每项活动所需的工作量也可以从工作量估算中得知。此信息用于分配资源、确定活动的实际持续时间以及确定开始和结束日期。因此，创建了记录的时间表。

维护时间表意味着要考虑项目过程中的变化，并且将时间表置于配置控制之下，并在每次更改后重新发布和重新分配。每当更改对后续里程碑或截止日期产生影响时（例如，如果需要调整重要活动或里程碑的截止日期），就会调整时间表。项目应确定与进度调整相关的变更类型。

此外，必须定期审查和更新进度表。更新频率取决于实际项目情况和进度表的详细程度。通常每周更新一次；至少每月更新一次。

评估员注意

进度表在项目过程中逐渐完善。在长期项目开始时，不可能详细规划所有任务。然而，在迭代开发中，至少应该详细规划当前周期。对于后续周期，粗略规划就足够了。但是，必须在不迟于新周期开始时规划细节（有关可管理活动规模的参考，另请参阅 BP4），并且必须更新后续周期的粗略计划。

如果需要调整截止日期，必须注意考虑计划中的依赖关系，更新后续日期，并识别相关风险。

由于开发项目通常面临巨大的时间压力（问题是上市时间），因此进度表总是带有相应的风险。这些风险可以在 MAN.5（风险管理）背景下识别，通过措施将其最小化，并定期重新评估和跟踪。

BP7：识别和监控项目接口。识别并同意项目与其他（子）项目、组织单位和其他利益相关者的接口，并监控商定的承诺。

注意：项目规划和监控可能包括所有相关方，如质量保证、生产、汽车集成、测试和原型制造

必须与利益相关者就接口的处理达成一致。利益相关者包括负责的直线管理、客户、内部团队（如 QA 和生产、测试​​和集成部门）、原型设计、采购部门、销售、营销、产品管理等。需要解决以下问题：交换哪些信息、如何交换以及何时交换、如何报告和跟踪工作状态、是否有联合会议、如何将这些人员和团体纳入沟通流程等。必须在项目管理过程中积极监控对这些协议的遵守情况。

BP8：制定项目计划。收集并维护项目总体规划和其他相关计划，以记录项目范围和目标、资源、基础设施、接口和沟通机制。

项目计划由一份或多份规划文件组成，这些文件定义了项目范围和项目的相关特征，例如项目目标、工作范围、活动和任务、资源和接口等。Automotive SPICE 区分了总体项目计划和附加计划。附加计划可以是在子项目中或在其他流程的背景下创建的计划。例如质量计划和配置管理计划。在这种情况下，总体项目计划结合了各个子计划并使用共同里程碑来同步它们。在较小的项目中，通常只有一个项目计划。

评估员注意

如果一个项目由多个子项目组成，这些子项目通常会维护单独的计划。这是完全可以接受的。但是，在评估期间需要确定各个子项目计划是否与总体项目计划兼容（例如，通过共同里程碑），并且定期进行调整。

随着项目的进展，必须更新和调整整体项目计划。应定义有关如何更新计划的规则；例如，定期更新或在重大变更后更新。在后一种情况下，需要说明什么构成重大变更。

Automotive SPICE 1 级建议但不要求的一点是，管理层应审查并随后发布规划基准。

BP9：实施项目计划。实施项目的规划活动。

实施项目计划包括将计划提供给所有项目团队成员（例如，通过电子邮件分发），并确保他们熟悉计划并了解他们应该在什么时候做什么。这可以通过启动活动或其他类型的会议来完成。如果项目团队成员没有及时独立地启动活动，则可能需要由项目经理触发，例如在项目会议上。否则，活动将按计划进行。有关进度监控的主题，请参阅 BP11。

BP10：监控项目属性。监控项目范围、预算、成本、资源和其他必要属性，并记录它们与项目计划的重大偏差。

识别并记录项目参数（质量、实际工作量、成本、进度遵守情况等）的进度。记录计划偏差。有关进度监控的主题，请参阅 BP11；有关频率的主题，请参阅 BP7。

在大多数开发项目中，许多技术问题和难题需要在项目过程中澄清和解决。这些问题的解决必须得到系统控制和跟踪，例如，通过开放问题列表（OIL，见图 2-3）。进度监控还可能包括风险跟踪和重新评估（见 MAN.5 BP6）。

BP11：审查和报告项目进度。定期向所有相关方报告和审查项目进度，以符合项目计划。这包括向汽车制造商的报告。定期评估项目的绩效。

注意：管理层可以定期进行项目审查。

实际工作状态与计划进行比较。记录与当前计划基线的偏差。这可以在项目状态报告中完成。定期报告进度（参见工作产品 15-06—项目状态报告）。在实践中，进度监控通常在两个级别进行：

1. 活动级别的进度监控：以短间隔（例如每周）监控活动进度。在最低级别，开发人员将进度报告给下一个级别。在较小的项目中，这是项目经理，在较大的项目中有一些中间级别（例如，团队经理或子项目经理）。使用的方法包括，例如，团队会议、分别确定实际工作量和完成程度，或实际工作量和剩余工作量。这是项目级进度监控所需的原始数据。
2. 项目级进度监控：在这里，进度数据从层次结构的较低级别连续汇总到较高级别，以帮助项目经理清楚了解整个项目级别的进度。然后，他可以将此传达给外部各方（管理层、客户）。结果（例如每月）记录在项目状态报告中。应用的方法包括项目评审、项目进度跟踪指标、里程碑趋势分析和挣值法（参见 [Hindel 等人，2006]）。注释指出，项目级别的定期进度监控也可以由（直线）管理层进行。在关键、复杂或大型项目中，可能存在一个由客户和供应商的管理代表组成的共同指导委员会。

除了进度报告之外，项目会议是项目控制的最重要手段。图 2-22 列出了一些经常发生的项目会议类型。

图 2-22 项目会议类型

BP12：采取行动纠正偏差。在项目目标未实现时采取行动，纠正与计划的偏差并防止项目中发现的问题再次发生。相应地更新项目计划。

如果在项目执行和监控其进度期间发现与计划的偏差，导致无法实现项目目标，则必须采取适当措施。有几种不同的替代方案：

1. 同时执行关键路径上的顺序活动
2. 更换员工/更多员工/更多经验丰富的员工
3. 外包工作，让项目成员有时间完成其他任务
4. 更改或缩小工作/功能范围
5. 延迟计划，与客户展开对话

这些替代方案可能带来相当大的风险和额外成本，并且在某些情况下可能产生完全相反的效果。不幸的是，另一种经常采用的替代方案是偷工减料并损害质量（例如，减少评审、不进行测试或缩短测试时间）。强烈建议不要这样做。

通常，纠正措施会导致计划的改变；这就是为什么必须相应地调整项目计划的原因。如果计划发生较大变化，可能需要进行另一次规划审查。

除了采取措施纠正偏离计划的情况外，Automotive SPICE 还需要采取措施消除或避免原因。

评估员注意

根本不可能针对每个问题制定即时措施以防止其再次发生；有时，消除项目中的原因已经太晚了，因为导致问题的条件已无法消除（例如，如果存在资源问题，短期外包不可能，或者无法进行新的招聘）。在这些情况下，重要的是进行根本原因分析并充分考虑情况（例如，在项目会议上，或作为“经验教训”评估的一部分）。

2.19.4 指定工作产品

08-12 项目计划

项目计划由一份或多份规划文件组成，这些文件定义了项目范围和项目的主要特征。项目计划是项目控制的基础。如果项目计划由多份规划文件组成，则必须注意确保各个文件总体上形成一个连贯且有凝聚力的整体。但是，项目计划不一定需要是连贯的文档。它通常以具有不同文件的目录结构的形式实现。下表提供了项目计划的示例结构。

大型项目的项目计划示例结构

1. 项目目标和项目范围的简要说明

1.1 项目简要说明

1.2 背景

1.3 目标

1.4 项目范围

1.5 项目预算

1.6 项目运行时间

1.7 先决条件和承诺

1.8 基本规划假设

1.9 基本决策

1.10 接口

2. 需求规范和系统规范

3. 项目工作分解结构和项目进度表

3.1 工作包概述

3.2 项目工作分解结构（概述）

3.3 进度表（概述）

3.4 工作包描述

WP 1 ...

WP 2 ...

WP n 项目管理

3.5 工作量估算摘要

4. 角色和职责

5. 风险

6. 使用的流程和工具

7. 报告

8. 项目团队的基本规则

9. 项目团队

10. 项目规定

11.附加信息

11.1 变更流程

11.2 文档

11.3 联合文件

12. 定义、术语、缩写

13. 附录：所需人员工作量估算

14. 附录：人力资源规划

15. 附录：更详细的项目工作分解结构

16. 附录：更详细的时间表

13-16 变更请求

参见 SUP.10

14-06 进度表

进度表应包含（另见 BP6）：

1. 所有要执行的活动、顺序以及它们之间的依赖关系
2. 里程碑
3. 活动的持续时间和估计工作量、开始和完成日期
4. 活动资源分配

此外，进度表中应确定关键路径。进度跟踪的结果通常记录在计划中（例如，完成程度、已完成的活动）。通常，使用 Microsoft Project、R-Plan 等工具来维护进度表。但是，对于简单的进度表，Microsoft Excel 可能就足够了。

14-09 工作分解结构

项目工作分解结构 (WBS) 安排和定义项目的整体内容和范围。WBS 是将项目范围分解为“可管理”项目的工具。每个较低级别都包含对上一级项目项目的更详细描述。工作包构成 WBS 的最低级别。未包含在 WBS 中的可交付成果不在项目范围内。在顶层，WBS 应根据项目阶段或主要可交付成果进行构建。可以使用其他形式的描述：通常选择结构图，但使用编号和缩进的列表描述以及思维导图也很常见。

除了要开发的产品和产品组件外，项目的其他可交付成果还包括用户手册、测试文档、项目状态报告、培训等，以及来自项目生命周期的可交付成果（例如，未传递给客户的文档；例如设计文档）。

评估员注意

特别是较小的项目通常不会为项目工作分解结构创建单独的文档。然后 WBS 隐式包含在项目进度表中。

15-06 项目状态报告

项目状态报告应包括以下信息：

1. 成本情况（当前开发成本或每项生产成本、预期成本发展等）
2. 进度情况（预计完成日期、趋势；例如，关于实现下一个里程碑等）
3. 工作范围/功能
4. 质量情况（缺陷情况、客户相关问题等）
5. 资源状态（例如，人力资源瓶颈）
6. 风险（风险摘要）
7. 指定（通常是技术）问题
8. 启动的措施。谁需要采取行动？

在需要监控大量项目的组织中，项目状态报告是高度汇总的，并以标准化形式呈现，例如，作为基于“交通灯”的绩效指标。（见图 2-23）。

图 2-23 面向更高管理层的高度汇总项目状态报告示例

2.19.5  2 级的特征

项目管理过程的项目管理

在 2 级（参见 PA 2.1，过程绩效控制）中，也需要基本的项目管理原则，但现在这些原则应用于相应的过程（而不是项目）。

需要根据目标规划过程，并监控计划的执行情况。对于 MAN.3，这意味着必须规划和跟踪项目管理活动，例如制定项目计划。这也适用于活动，例如项目会议、详细项目规划和规划更新、进度监控、创建进度报告等。

例如，规划项目计划的初始完成日期以及在新阶段开始时需要进行的更新是有意义的。此外，还必须制定项目管理活动的资源计划，将重复活动考虑在内。如果项目经理必须在管理任务之外执行技术任务，这一点尤其重要。这通常发生在较小的项目中。结果是，在压力情况下，项目管理工作经常被忽视。

关于工作产品管理

规划文档的变更相对频繁，前提是文档“实时”（即它们被积极用作规划和控制工具）。这就是为什么规划文档不能在每次微小变更后都进行审查的原因。但是，至少在完成规划基线时应审查项目计划和时间表。