博思艾伦和汉密尔顿在20世纪60年代中期提出来的。他们提出的流程分为六个基本阶段，为近年来发展起来的大多数流程奠定了基础。探索、筛选、商业评估、开发、测试、商业化。
门径管理流程
- 发现：寻找新的机会和新产品创意
- 筛选：初步评估市场机会、技术需求以及能力的可获得性
- 立项分析（商业论证）：建立在筛选阶段基础之上的一个关键阶段,更为深入的技术、市场以及商业可行性分析
- 开发：产品设计、原型制造、可制造性设计、制造准备和上市计划
- 测试与修正：测试产品及其商业化计划的所有方面，以修正所有假设和结论
- 上市：产品的完整商业化,包括规模制造以及商业化上市
阶段（AID）是整个产品开发流程中的一个确定区域：
- 活动（Activities）：项目负责人和团队成员基于项目计划必须做的工作；
- 综合分析（Integrated Analysis）：通过跨职能部门间的交流，项目负责人和团队成员综合分析所有职能活动的结果；
- 可交付成果（Deliverables）：综合分析结果的呈现，这是团队必须完成并在进入关口时所要提交的内容；
关口（DOC）开发流程中的一个确定节点
- 可交付成果（Deliverables）：关口评审点的输入内容。可交付成果是前一阶段行为的结果,是事先确定的。在每个关口都有一个可交付成果的标准清单。
- 输出（Outputs）：关口评审的结果。关口处必须给出明确的输出,包括:决策(通过/不通过/搁置/重做)和下一阶段的路径(通过审批的项目计划，下一个关口的日期和可交付成果)。
- 标准（Criteria）：评判项目时所采用的标尺,由此决定项目是否通过以及项目的优先级。这些标准通常被设计为一个包括财务标准和定性标准在内的打分表。
门径管理流程的优劣势：
优势
- 为产品开发提供准则和约束
- 强调要有质量地决策
- 对所有参与者而言都是透明的
- 适用于多种类型的组织
局限性 - 有可能变得过度官僚化
- 在没有完全理解的情况下，可能引起过于僵化和成本昂贵的误解
- 遵循准则和约束可能一定程度上会扼杀创造力
集成产品开发 IPD
并行工程的基本前提
- 产品生命周期中的所有要素，从功能性、可制造性、装配、测试、维护、环境影响到最终处置和回收，都应在早期设计阶段被逐一考虑。
- 考虑到并行推动流程能显著提高生产力和产品质量，前述设计活动都应同时进行。
IPD的核心思想 - 新产品开发是一项投资决策。IPD强调要对产品开发进行有效的投资组合分析，并在开发过程设置检查点，通过阶段性评审来决定项目是继续、暂停、终止还是改变方向。
- 基于市场的开发。IPD强调产品创新一定是基于市场需求和竞争分析的创新。为此，IPD把正确定义产品概念、市场需求作为流程的第一步，开始就把事情做正确。
- 跨部门、跨系统的协同。采用跨部门的产品开发团队，通过有效的沟通、协调以及决策，达到尽快将产品推向市场的目的。
- 异步开发模式，也称并行工程。就是通过严密的计划、准确的接口设计，把原来的许多后续活动提前进行，这样可以缩短产品上市时间。
- 重用性。采用公用构建模块提高产品开发的效率。
-
结构化的流程。产品开发项目的相对不确定性，要求开发流程在非结构化与过于结构化之间找到平衡。
基于集成产品开发系统的组织实践层次
IPD的组织实践层次
瀑布流程(广泛应用于软件行业)
- 要求：理解产品所需的功能、用途、用户需求等等
- 设计：基于完成项目所需的软件和硬件，随后将它们转换为物理设计
- 实施：根据项目需求和设计规范写代码
- 验证：确保产品满足客户的期望
-
维护：通过客户确定产品设计中的缺陷或错误，加以改正
瀑布流程
精益产品开发
精益产品开发建立在丰田首创， TPS 基于消除 Muda，日语中的意思是无用—没用的、浪费。
精益开发的主要原则：
- 建立由客户定义价值，去掉无法带来增值的浪费；
- 在产品开发前端投入更多精力， 去探索所有可能的解决方案，最大化设计空间；
- 创建高水准的产品开发流程流；
- 实施严格的标准化流程，以降低变数，创造灵活性，产出可预见的结果；
- 建立首席工程师体系，由他从头到尾负责开发流程的整合；
- 平衡职能专长和跨职能整合；
- 培养每位工程师的能力；
- 充分整合供应商，将其纳入产品开发体系；
- 建立学习与持续改进的理念；
- 营造支持卓越和不断改进的组织文化；
- 采用与人员和流程相匹配的技术；
- 通过简单的可视化沟通，使整个组织协同一致；
-
善用有效的标准化工具和组织学习工具。
精益产品开发过程的核心概念：
精益产品开发的核心概念
敏捷产品开发
敏捷方法是在合作环境下由自组织的团队进行产品迭代开发的过程。通过渐进式的迭代工作步骤，团队可以应对未预期的事项，称为冲刺。敏捷开发在软件行业的应用极为普遍。
敏捷产品开发的关键原则
- 首要任务是通过尽早和持续交付有价值的软件来满足客户；
- 即使在开发后期，我们也欢迎需求变更；同时将这些变更转化为客户的竞争力；
- 频繁地交付可运行的软件，数周或数月交付一次，时间越短越好；
- 项目期间，业务人员与开发者共同工作；
- 招揽积极主动的人员来开发项目，为他们提供所需的环境和支持，相信他们能做好自己的工作；
- 开发团队里最省时有效的信息传递方式是面对面交流；
- 可运行的软件是衡量进展的主要标准；
- 敏捷流程有利于可持续开发。发起人、开发人员和用户应始终保持一个固定的前进步伐；
- 持续关注先进的技术和优秀的设计，提高敏捷性（内部的或外部的）；
- 简洁—令待办工作最少化的艺术是一切的基础；
11）只有自组织团队才能做出最好的架构和设计；
12）团队定期反思如何提高效率并调整工作流程。
敏捷SCRUM3-4-3框架
敏捷新产品开发流程的关键要素
3个角色-敏捷角色
产品主管
- 确定优先级次序是产品主管的独有职责
- 产品主管是代表客户利益、拥有最终决定权的那个人。（定目标和验收交付）
- 团队必须随时可以联系到他，特别是在冲刺的规划会议期间；
- 在冲刺开始后，产品负责人就不应当再管理团队，也不应当再变更任务。
- 产品主管的主要职责是平衡有竞争关系的干系人之间的利益。
敏捷教练
- 消除团队和产品负责人之间的障碍；
- 激发团队的创造力,给团队授权；
- 提升团队生产率；
- 改进工程工具和实践；
- 确保团队取得进展的信息实时更新，让各方成员均可见。
敏捷团队
敏捷团队通常由 5-9个人组成。
4个会议
冲刺计划会议
每日站会
迭代评审会议
迭代回顾会议
3个工件
产品待办列表
一份包含系统所需的一系列事项要求并将它们按优先次序排列的清单，包括功能性和非功能性的客户需求，及技术团队产生的需求。一个产品需求列表项是一个足够小的工作单元,团队能够在一次冲刺迭代周期中完成。
冲刺待办列表
迭代燃尽图
敏捷流程
软件生成得以按规律的步调进行，并由一系列固定长度的迭代过程开发出产品。
冲刺
完成特定任务,使开发阶段得以进入审查环节的一段时期。
