集成产品开发（IPD）认识到需要考虑产品生命周期的所有要素，从概念到处置，从生命周期的开始阶段。需要考虑的重要事项包括质量、成本、进度、用户需求、制造和支持。IPD还意味着在整个产品生命周期中，整个产品团队的持续整合，包括工程、制造、验证和支持（国防部，1998年）。
通过远离传统的层级管理结构并组织成集成产品团队（IPTs），可以减少并发产品开发中固有的风险。通过流程的分散化、避免以前的问题以及工程和制造之间的更好整合，可以提高生产率。传统的串行活动开发可能非常漫长，以至于产品在完成之前就变得过时了。通过良好的接口定义和控制，涉及整个团队的IPD可以加快开发过程。
IPPD进一步认识到过程的重要性。以下定义适用于IPPD：
- 集成产品开发团队（IPDT）——一个跨学科的团队，共同负责交付定义的产品或流程。
- IPPD——使用IPDT同时开发产品或系统的设计和制造方法的过程。过程验证可能包括由IPDT审查过程描述，也可能包括向IPDT展示一个过程。
- 并行工程——是一种管理/操作方法，旨在改进产品设计、生产、操作和维护，通过创建一个环境，在这个环境中，来自所有学科的人员（例如，设计、营销、生产工程、工艺规划和支持）在产品生命周期的所有阶段一起工作并共享数据。
集成开发有可能为开发计划引入更多风险，因为下游活动是在假设上游活动将满足其设计和接口要求的情况下启动的。然而，引入一个跨职能IPDT的层次结构，每个团队都开发并交付产品，可以降低风险并更快地提供更好的产品。
IPPD还通过IPDT改善团队沟通，实施积极的风险流程，根据IPDT的及时输入做出决策，并改善客户参与度。
1 IPDT概述
IPDT是一种面向过程的、集成的跨职能团队（即由许多较小的团队组成的整体团队），被赋予适当的资源，并负责定义、开发、生产和支持产品或过程（和/或服务）。每个团队都配备完成分配给他们的流程所需的必要技能，这些流程可能包括全部或部分开发和生产步骤。
总体方法是为所有产品和服务组建跨职能的IPDT。典型的IPDT类型包括系统工程与集成团队（SEIT）、产品集成团队（PIT）和产品开发团队（PDT）。这些团队各自模仿一个小型独立项目，专注于个别元素和/或它们整合到更复杂的系统元素中。SEIT在产品团队之间平衡需求，帮助整合其他IPDT，关注集成系统和系统流程，并解决系统问题，这些问题本质上可能会被其他IPDT降级为较低优先级 1。尽管这些团队是基于流程组织的，但团队的组织结构可能接近产品的层次结构，这取决于产品组装和集成的方式。
这些IPDT团队类型及其一般职责的重点领域总结在表9.1中。这种安排通常适用于大型、多元素、多子系统的项目，但必须根据具体项目进行调整。例如，在较小的项目中，可以减少或取消PIT团队的数量。在服务导向型项目中，团队的系统层次、重点和责任必须适应相应的服务。
团队成员的参与在整个产品周期中会有所不同，不同的成员可能随着项目从需求开发过渡到生命周期的不同阶段，团队成员可能承担主要、次要或辅助角色 2。例如，在早期的产品定义阶段，制造和验证代表可能只担任次要的兼职顾问角色，但在后期的制造和验证过程中，他们将承担主要角色。团队成员从一开始就参与其中，以确保他们的需求和要求反映在整体项目需求和规划中，避免后期昂贵的变更。同时，让一些团队成员在整个产品周期内保持参与，以保留团队的”项目记忆”也是有益的。
IPDTs 必须被赋予对其产品和系统全生命周期的责任，并拥有完成工作的权力。他们不应该向高层管理寻求关键决策。然而，他们应该被要求向其他人，包括接口团队、系统集成团队和项目管理，解释他们的行动和决策。
2 IPDT流程
IPDT的基本原则是在产品开发的初期让所有学科都参与进来，以确保对产品整个生命周期的需求和要求有完全的理解。需求最初在系统层面制定，然后随着需求向下流动，依次在较低的层面制定。由系统工程师领导的团队在每个层面执行前期的SE活动。
IPDT在IPPD环境中进行内部整合。每个产品团队（或多个）都有一名SEIT代表，负责内部和外部团队职责。产品团队与SEIT之间有广泛的迭代，以达成需求和设计概念的共识，尽管在初步设计审查后以及设计确定时，这一努力应该显著减缓。
系统工程师在SEIT和PIT中参与度很高，而在PDT中的参与度则相对较低。尽管如此，本手册中描述的迭代SE流程同样适用于IPPD环境中的所有团队。由于系统工程师每天都在所有团队中存在，因此在整个项目中应用这些流程变得更加容易。
IPDTs有很多角色，它们的集成角色根据团队类型和集成方式而重叠。图9.9给出了程序过程和系统活动的例子。
左边的三个条形图显示了不同系统层级的产品团队类型的角色。例如，SEIT在外部集成和系统集成活动中领导和审计，如阴影条形图所示。对于涉及较低级别元素（例如零件、组件或子组件）的程序过程，相应的PDT是活跃的领导和审计参与者，并由SEIT和PIT支持。
基本系统活动包括系统需求推导、系统功能分析、需求分配和传递、系统权衡分析、系统综合、系统集成、TPM定义和系统验证。图表中系统功能1、2和3的条形图显示，SEIT领导并审计不同系统活动，而元素团队参与其中。如果需要，较低级别的系统元素团队会提供额外的支持。
图9.9右侧的列显示了所有团队都参与的其他集成领域。对于这些活动，各个团队的角色也必须协调一致，但应与示例类似。
2.1 组织和运行高性能IPDT的基本步骤和关键活动如下：
- 为项目定义IPDT团队——开发涵盖所有项目领域的IPDT团队。
- 将责任和权力委托给IPDT领导者——在开发过程的早期选择经验丰富的团队领导者，并在整个生命周期中避免频繁的预算变动。
- 组建IPDT团队——候选人必须在团队环境中表现良好，沟通顺畅，并履行承诺：
- 平衡核心团队的能力、可用性和全职承诺。
- 规划何时需要和不需要能力。
- 确定需要专家的问题。
- 了解团队的运营环境——认识到团队如何直接或间接地影响其他团队和整个项目。
- 计划并召开”启动会议”——建议召开两次启动会议，一次针对整个项目，一次针对各个IPDT。精心策划的启动会议将使项目走上正确的轨道。
- 培训团队——项目培训是一个关键要素。以下推荐的主题应涵盖：
- 为项目量身定制的SE流程
- 项目描述、利益相关者 3、目的、使命、组织、时间表和预算
- 术语和命名法
- 访问项目产品
- 沟通技巧
- 项目IPDT程序、措施和报告应该举行额外的培训课程，并开发自学指南，以帮助新团队成员在人员流动时迅速了解项目。
- 定义团队愿景和目标——在最初的IPDT会议中使用协作头脑风暴 4来制定团队的愿景和目标，使每个成员都有归属感。很可能需要邀请其他IPDT成员、管理层和客户来充实团队的愿景和目标。
- 让每个团队扩展其工作的定义——一旦高级项目计划被审查，每个团队必须确定团队及其每个成员的任务、角色、责任和里程碑。成员需要了解他们的个人任务如何融入到高级项目-程序任务中。
- 建立对常规流程评估和持续改进的期望——每个团队必须记录他们正在使用的流程和需要监控的关键指标。团队必须具备持续改进的思维，监控自己的活动，并在过程中不断进行调整。
- 通过指标和报告监控团队进度——每个团队都将有一套指标和报告来监控自己的进度。这些报告和指标必须由协调其他IPDT的SEIT进行审查。这些指标可能包括挣值报告和技术指标，如缺陷率报告。所选指标取决于团队在项目中的角色。
- 在整个项目中维持和发展团队——随着每个团队的成长、缩小和技能组合的变化，人员分配到团队的情况会有所不同。当问题出现时，技术专家可能需要加入团队以帮助解决这些特定问题。诸如营销、项目控制、采购、财务、法律和人力资源等服务通常以稳定、低水平的努力或按需支持团队。
- 文档团队产品——团队的产品应该被明确界定。由于IPDT的结构，跨组织沟通的开销会有所不同，应予以减少。当需要多个文档时，应指定不同的团队成员作为负责作者，并由其他人提供贡献，同时确定备份人员。IPDT除了任务、愿景、目标、交付物、会议纪要、决策、定制流程、协议、团队项目信息和联系信息外，还应维护活动日志。
- 结束项目并进行后续活动——与第12步相结合，IPDT应保留记录，就好像项目可能在未来某个时间重新设计，并且所有结束产品都必须可访问。所有IPDT日志应尽可能以相同的方式组织，以便它们可以轻松地整合到整个项目报告中。结束工作应包括经验教训 5、建议的更改以及团队措施的总结。
项目经理应审查团队人员配置计划，以确保适当的组成并努力保持任务的连续性。全职贡献者的优势超过了多个兼职团队成员的工作。同样，失去一个知识渊博的关键团队成员可能会使团队陷入困境。重要的是要有能够很好地合作和沟通的人，但如果没有能够带来改变的杰出技术专家和专业人士，团队结果可能会受到影响。
在IPDT中实现高性能的推荐技术如下：
- 精心挑选员工——优秀的人做出色的工作。
- 建立并保持积极的团队互动动态——所有人都应该知道对团队和每个个体的期望，并努力履行承诺。快速预测并提出潜在问题（内部和外部）。互动应该是非正式但高效的，且是一个”无责备”的环境，在这里问题得到解决，团队继续前进。认可并奖励出色的工作。
- 产生团队承诺和认可——团队对愿景、目标、任务和时间表的统一。保持团队领导者的笔记本。
- 将工作分解为可管理的活动——那些可以准确安排、分配和每周跟进的活动。
- 将日常行政任务分配给团队成员——让领导者有更多时间参与技术活动。让每个团队成员都有一些行政/管理经验。
- 安排频繁的团队会议，要求强制出席以快速交换信息——确保每个人都是最新的。分配任务项目，并指定负责人和截止日期。
3 潜在的IPDT陷阱
在团队成员和领导者在IPDT框架中经历几个项目周期并获得合作经验之前，有很多机会会偏离正轨。表9.2描述了一些团队应该注意的IPDT环境中的常见陷阱 6。
本文同步发表在 软件需求探索的https://srs.pub/specification/integrated-product-process-development.html
作者: