下载掌阅APP，畅读海量书库
立即打开
由于产品的多样性，各企业采用的开发方法各不相同，其对应的开发流程也五花八门。但这些开发流程几乎都符合门径管理系统的特征，或多或少也都有PACE系统和IPD方法的影子。从这些开发流程中，我们可以提炼出一些共性，作为普遍适用于多数产品开发的配置管理形式。
以实物类产品开发为例，多数企业的产品开发流程被分成了定义、设计、验证、工业化和量产阶段。图4-4显示了典型的产品开发的阶段划分及其主要任务。
图4-4 产品开发的阶段划分及其主要任务
简单来说，图4-4中的五个阶段都有各自非常明确的阶段目标。
· 定义：定义产品需求，以产品需求冻结为阶段目标。
· 设计：设计并实现产品的基本功能，以概念设计冻结为阶段目标。
· 验证：验证产品满足客户需求的程度，以（详细）设计冻结为阶段目标。
· 工业化：验证产品可连续交付的能力，以生产批准许可为阶段目标。
· 量产：持续生产并为企业获取利润，企业根据产品生命周期规划决定停产时间。
实际上，各个企业在规划产品的阶段和任务时会根据产品自身的特点进行差异化定制。这些差异有多个不同的考量维度。
在定义阶段，企业的主要任务是获取客户需求并转化成企业内部可执行的需求。由于需求的来源非常复杂，因此本阶段对应的需求管理过程存在很大差异。对于承接客户需求再进行开发的企业来说，它们需要主动从客户那里获取产品开发需求，并通过需求管理工具将需求翻译成内部可识别的语言。在这个过程中，非常容易出现需求失真的情况（见第6章）。对于自主开发产品的企业，产品需求很可能由企业自行鉴别或提出。企业可以通过第三方的数据或自身主观判断形成产品需求列表，并以此作为后续产品开发的依据（见第7章）。为了避免客户需求被错误解读或在企业内部传递过程中发生偏差，企业可以在定义阶段增加一些评审活动，以控制这个风险。企业希望在定义阶段能冻结产品需求。该冻结并不意味着产品需求不可更新，而是企业在一段时间内应固化当前的产品需求，以便产品开发团队具备充分的时间去设计产品。
在设计阶段，企业有多种更为细化的阶段划分方式。常见的细化阶段分成概念设计阶段和详细设计阶段，或者系统设计阶段和组件设计阶段。这两种划分方式的区分在于，前者按产品设计的层级来划分，后者则根据产品的物理结构来划分。
· 概念设计是产品从理论上满足客户需求的初始设计。它具有一定的前瞻性，并且可能是高度抽象的设计理念。概念设计是指导产品设计开发的重要过程，可以被分为高水平概念设计（见第8章）和低水平概念设计（见第9章）。从高水平概念设计到低水平概念设计的过程就是高度抽象的概念向逐渐细化的概念发展的过程。
· 详细设计（见第10章）从产品的概念设计发展而来。详细设计通常自上而下进行，通常经历架构设计、系统设计、组件设计和模块设计等。因为架构设计与低水平概念设计比较接近，所以有些企业不区分高水平和低水平的概念设计，而在概念设计之后，将架构设计作为详细设计的前置设计过程。详细设计是产品初步实现客户功能的过程，是具体的开发设计过程。
· 系统设计是详细设计的一部分。因为有些产品的复杂度不高或客户有明确的产品需求，所以企业不设概念设计阶段，而直接进行详细设计。此时，系统设计作为产品的整体设计应满足客户的指定要求。系统设计通常不涉及具体组件或模块的设计。
· 组件设计或模块设计是详细设计的底层设计，它们是具体实现产品功能和参数的底层单位。组件设计或模块设计是针对产品实现客户需求的具体实施方法，该设计阶段是实现产品从无到有的具体过程。
在设计阶段，产品开发团队需要对初步实现的产品进行评估。该评估的形式多种多样，多数以制作产品原型并对其评估为主要手段。产品原型可分为非功能型原型和功能型原型（见第11章），它们分别为改进产品性能提供有效的支持。
在验证阶段，企业也存在多种阶段划分方式。验证阶段（见第12章）最常用的验证模型是V模型，但V模型有多种不同形式，而实物类产品开发和软件类产品开发的V模型也不相同，所以不同企业在验证阶段往往会定制符合自身产品特点的验证方式。在验证阶段，产品开发团队根据客户需求，逐一对产品的样品进行测试，并给出指导性意见。验证报告将帮助开发团队优化产品性能，并最终完全满足客户需求。产品优化的过程多种多样，需要考虑各种因素，包括产品参数的稳健性、可靠性、可制造性和可操作性等（见第13～16章）。
在工业化阶段，开发团队需要完成产品从小规模制作到大批量生产的准备工作。在工业化阶段（见第17章），开发团队需要进一步优化产品的性能，尽力完成与工业化相关的匹配工作。例如，开发团队应开发准备量产所需的工装和设备等。在本阶段，开发团队需要将产品设计以受控的形式传递到生产运营团队手中。对于非实物类产品，开发团队需要将已测试完成且具备上市能力的产品交付至客户或运营团队。
量产阶段（见第18章）是企业持续获利的阶段。多数企业对于该阶段的要求是类似的，其阶段任务主要以提升产能、提高产品质量、维护客户关系等为主。量产阶段的时间由产品规划的生命周期和退市计划决定。对于非实物类产品，企业在本阶段的主要任务为客户服务和运营维护。
交付物（Deliverables）是项目活动的典型输出物。通常，阶段交付物分成过程交付物和结果交付物。过程交付物是产品在项目推进过程中产生的交付物，这类交付物是为了保证项目的健康运作而产生的。结果交付物是项目在该阶段需要达成的目标交付物，是体现阶段目标满足程度的标志。从客户角度，客户更关心结果交付物，企业往往也把管控重点放在结果交付物上。但大量实践证明，产品开发是一个复杂的过程，如果开发团队忽视过程交付物，那么很可能最终无法达成开发目标，即无法获得令客户满意的结果交付物。
交付物的要求来自多个方面，通常包括客户（含内部客户与外部客户）指定的交付物、项目的一般要求、产品的独特性要求、体系或法律法规的要求等。
1. 客户指定的交付物
通常，这类交付物与项目目标有关，即与产品要实现的功能或性能有关。此类常见的交付物包括产品代码、外观设计、成本构成、试验报告和完整产品等。有些客户为了确保供应商在开发过程中的稳健性，也会要求供应商提供部分过程交付物。此类交付物通常都属于体系要求的交付物。
2. 项目的一般要求
这类交付物并未由客户直接提出，但对于产品开发来说，开发团队需要满足开发项目的一般要求。这些交付物常常由项目管理的方法决定，比较常见的交付物包括项目章程、人员技能与分工安排、阶段评审报告、经验教训总结和项目计划等。这些交付物是企业用于管理和监控项目进程的重要依据。
3. 产品的独特性要求
每个产品开发都具有独特性，这与产品自身的特点有关。不同产品在开发过程中会产生一些仅与自身产品有关的交付物。例如，电子硬件产品在开发过程中需要提供拓扑图，而在机械结构的产品开发过程中则没有拓扑图。再如，对于露天工作的电子产品往往要求进行密封性测试，而对于屋内使用的电子产品很可能没有此项要求。
4. 体系或法律法觃的要求
体系要求通常指企业的质量体系或行业体系。企业自身可指定产品开发的体系要求，指定开发过程需要提供的交付物列表。不同行业可以拥有自己的行业体系，并在这些体系中指明开发团队需要提供的交付物。例如，汽车行业常用标准IATF 16949要求企业明确成文的信息；ASPICE体系要求软件开发团队提供配置管理文件等。法律法规要求和体系要求一样，都是企业产品开发必须遵守的要求。
交付物的来源众多，这导致在产品开发过程中的交付物数量很多，这些交付物组合在一起就成了交付物清单。如果交付物清单上的内容过多，那么对于产品开发来说也是一种负担。原则上，交付物清单上的交付物都需要一一准备，但在实际产品开发过程中，企业会根据产品的复杂度和项目的规模调整交付物清单。也就是说，在同一家企业内，产品开发的交付物清单并非一成不变，同时可能存在多张交付物清单。
另外，在产品开发过程中可能存在多种开发模式，应用的开发工具更是五花八门，所以企业即便针对同一类产品开发的交付物清单也会进行必要的剪裁。在剪裁过程中，企业又担心过度剪裁可能导致开发过程失控，所以会保留一些模棱两可（重要但不一定会触发）的交付物并将其定义为可选交付物。因此，在多数企业的交付物清单上，交付物被分为了强制交付物和可选交付物。
为了确保所有交付物都及时交付且交付质量被追溯，通常在交付物清单上会注明交付物的相关负责人。有的交付物清单甚至会与RACI矩阵结合使用。
由于产品开发的各阶段有各自明确的使命，因此各阶段的交付物也显著不同。表4-2显示了产品开发各阶段的典型交付物，这就是一份典型的交付物清单。其中，交付物的分类和要求实际上由企业自行确定，此处仅供参考。
表4-2 各阶段的典型交付物
续表
续表
交付物具有较强的时间属性，不少交付物仅在特定的开发节点前完成才具备相应的意义。在项目开发过程的交付物中，有些交付物有前后顺序，也有些交付物可能并行触发，还有些交付物没有相互关联，所以无法用一张统一的图表来表明所有交付物的逻辑关系。开发团队应注重交付物的前置输入与后续输出的对象，在合理的开发节点上制作这些交付物。
交付物是企业或客户对项目（阶段）成果评审的重要依据。如果当前交付物的质量不满足本阶段的交付要求，则代表产品开发不满足本阶段的开发要求。此时，开发团队应继续工作，更新交付物直至达到阶段要求。
产品开发能否进入下一阶段是根据产品开发是否满足当前阶段的要求来决定的，这需要企业对产品开发项目进行评价。最典型的评价方式是项目的阶段评审，执行阶段评审是产品开发阶段划分的主要目的之一。
阶段评审由一系列活动组成且具有一定的规则。阶段评审需要由企业指定的评审委员会来执行。通常，这个评审委员会由企业最高管理团队或其授权代表组成，其职能覆盖范围与前文介绍的产品开发团队类似。
阶段评审是项目最重要的里程碑，也是强制里程碑，所以项目经理在项目计划中应明确制定阶段评审的日期。即便项目计划频繁被更新，阶段评审的要求也应及时传递给评审委员会成员。一般来说，评审委员会的角色较为固定，主要由各职能团队的负责人组成，但根据项目特点，最高管理团队可以指派额外的技术专家或其他关键干系人参与评审。
项目评审多数以会议决策的方式进行。只有当评审委员会全体成员一致同意项目进入下一阶段时（一票否决制），项目才可以被推进到下一阶段。但企业根据项目的实际情况，可以制定一些特殊规则。
在评审会议上，一般由项目经理进行项目汇报。此时，项目经理应尽可能提供必要和准确的信息，以供评审委员会做出判断。而评审委员会为了做出相对准确的决策，通常至少完成三方面的评审：交付物状态的评审、项目风险的评审、项目健康程度的评审。交付物状态的评审往往在会前可以通过其他形式来完成。如果交付物未达到阶段要求，那么项目经理不会召集项目阶段评审。因此，在评审会议上评审委员会通常仅查看交付物清单的更新情况。项目风险的评审是项目管理的基本要求。评审委员会会审查项目的财务、技术、市场和资源的各种潜在风险，并做出相应的应对措施。项目健康程度的评审较为笼统，这是对项目整体实施过程的分析判断，可能包括项目人员的技能匹配度、绩效成果、资金使用合理性、项目发展趋势等诸多方面。以上这些信息的评审需要一定的规则来实现，所以企业一般会制作一张阶段检查表来作为阶段评审的指导方向。该检查表常以问题列表的形式出现。该检查表会覆盖以上各检查项，而且与阶段交付物紧密关联，以帮助评审委员会做出准确判断。表4-3是典型的阶段检查表示例。
表4-3 阶段检查表示例
续表
通过对阶段检查表的评审，评审委员会要做出项目能否进入下一阶段的判断。这个判断通常包括通过、不通过、有条件通过、重审、项目暂停和项目中止等结果。
不管项目被判断为哪种情况，项目团队均应尊重这个决策结果，并相信评审委员会是出于企业的综合利益做出的判断，应严格遵照评审结果执行后续动作。多次未通过项目评审的项目很可能面临项目中止的风险。