芯片/半导体/制造研发型企业，大都知道华为使用过的IPD管理体系，但大家用到什么程度，那就是参差不齐了。
因为IPD管理体系它只是一个管理理念，是一个方法论。它需要有相应的组织架构来承载，它有很复杂的流程需要有IT系统来支撑。如果没有组织架构来支持，那IPD就是空中楼阁，无法执行落地。如果没有IT 系统支撑，因为过于复杂，很难执行，也很难在公司的发展过程中不断去迭代。所以，组织架构和IT系统是IPD的前提。
组织架构是公司领导/高层的理念，这个多说无益。
说到IT系统，有很多传统的项目管理工具，如：JiRA，Ones，Teambition。新兴的互联网工具：PingCode，Tower等……但是，他们并不能很支撑IPD（技术能力上和理念上的差距）。最近看了一下飞书最新推出的项目管理方案，感觉很有一些体会，可以结合飞书的实现方案，来谈谈IPD，给合芯片企业的实际情况，看看IPD应该在芯片企业如何落地。当然，肯定不完整，也不一定专业，只是做为探索的一个开始。
一：什么是IPD管理体系？
Integrated Product Development，集成产品开发。
IPD不是新词，最早是由美国PRTM在1986年提出的PACE方法论，由IBM实践后被冠名为IPD，在国内又被华为应用后被奉为良药。这是一种集成了众多管理模型和理论、众多企业最佳管理实践的产品开发模式、理念与方法。简单来说，就是一种把项目上下游人员和优秀方案“集大成”的开发模式。
按照当下市面上最流行的说法，IPD想解决的问题，是与其让产品经理、设计师、程序员、销售各自埋头苦干，不如让他们协同起来，在资源和信息共享的状态下，展开标准化的流程。
通常情况下，相比更加注重快速迭代和灵活性的软件行业，IPD更适合需要各种硬件加工和供应链长等待周期的硬件开发，或软硬一体的复杂系统，主要是因为其强调的跨部门协作、明确的阶段划分和决策评审以及风险管理等特点，与这些领域的开发需求高度契合。
我们再拆解一下IPD：
I：Integrated——集成
这里的集成，首先指的是 工具，方法和流程的集成。其次是将企业各部门资源和团队集成到一起，共同完成规划和开发，满足客户需求。最最重要的一条是：IPD集成了很多重要的思想，这些思想是IPD的核心。拿芯片企业为例，它为包含了 市场架构（定义产品），销售，硬件研发，软件研发，测试质量，应用研发，客户技持，测产测试等多个部门的协同和集成。
P：Product——产品
对了，IPD是面向产品，而不是面向管理。因为产品是终极目标，包括了客户的所有需求，包括有形和无形。如果把IPD仅当作研发部门的工具来使用，那就是完全没理解了。我们可以理解FPGA芯片的某个系列是一个产品，需要关注从定义，规划，设计，研发，上线，支持，维护，退役的整个生命周期过程。
D：Development——研发
当然，研发仍然是企业的重中之重。它是整个环节中最重要的一环，因为公司最核心的资产是在研发环节。
下面是 IPD的一些基本概念，可以列出来看看。
1.1：IPD的特点：
- 以市场和客户需求为导向——关注需求和客户价值，驱动后面的环节。
- 强调跨部门协作——共同参与，减少部门摩擦。
- 关注产品全生命周期——全生命周期管理，关注后期维护，提高产品在整个生命周期的满意度
- 规范化、阶段化管理——每个阶段有明确的输入、输出和评审点（Milestone）
- 精益管理与资源优化——资源合理配置和优化，并行开发
1.2：关键流程
- 概念阶段
- 计划阶段
- 开发阶段
- 验证阶段
- 发布阶段
1.3：核心价值观
- 研发是投资行为——再次强调，这是原则
- 基于需求的研发
- 平台化开发
- 跨部门协作
- 结构化流程
- 业务和能力均衡
- 灵活发展，与时俱进
1.4：组织架构支撑
是否需要有相应的组织架构来支撑IPD，答案是肯定的，如果公司并没有相应的组织架构，那一切都是白搭。文章一开始，我们也说过。
公司如果在创建初期就有这个意识，那应该要有这方面的专家尽早介入。如果一开始并没有，那也应该在合适的时间引入。
IPD分为四大组织，一个是集成产品管理团队（IPMT），属于高层管理（决策层）。
一个是产品开发团队（PDT），属于项目的执行层。执行层又分为市场管理团队（PMT），技术开发团队（TDT）
各自的工作职责，大致如下：
1.5：技术评审详解
对于IPD的每个阶段都需要严格评审，按评审人员和内容不同，分为决策评审和技术评审。
TR 主要是对产品技术成熟度评估，检查技术点上的准备情况，用以发现遗留问题，评估存在的产品风险，并形成对策和操作建议。
决策评审点如下：
Chater DCP —— 任务书的评审
CDCP（Concept Decision Check Point）—— 概念初步决策 检查点
PDCP（Plan Decision Check Point）—— 计划决策 检查点
ADCP（Advanced Decision Check Point）—— 发布前决策 检查点
LDCP（LifeCycle Decision Check Point）——生命周期的决策 检查点
详细的技术评审 TR 如下：（不同行业可能内容的描述是不一致的）
| 阶段 | 名称 | 主要目标 | 关键输出 | 备注 |
| TR1 | 产品需求 概念评审 | 产品需求的完整性、技术可行性。 对于需求的完整性，要特别关注是否已包含了产品的外部需求和内部需求，内部需求是否已完整考虑了可测试性需求、可制造性需求、可服务性需求等等。对于需求的技术可行性，要关注实现需求所需技术的成熟度，以及相应的产品部件的可重用性等等 | MRD（市场需求文档） | 概念 |
| TR2 | 产品设计规格评审 | 产品规格和总体方案的完整性和合理性。 产品需求和概念是否完整、合理地转化到了产品规格中？产品规格和总体方案是否具有完整、合理的对应关系？有何技术风险？是否充分考虑了产品部件的重用性等。 | PRD 需求规格表（Requirement Specification) | 计划 |
| TR3 | 概要设计评审 | 概要设计方案的业务合理性和风险。 是否符合总体方案并能完成产品规格？技术的成熟度与技术风险如何？ 在测试、采购、制造、售后服务等各个业务方面是否合理，有何风险？ 是否充分考虑了产品部件的重用性？ 这些概要设计方案的详细程度是否足以支撑下一步的详细设计工作等等。 | 概念设计方案，技术原型报告，模块化设计文档 | 设计 |
| TR4 | 详细设计 评审 | 对详细设计、构建模块功能验证测试结果。可分子系统/模块分别进行。 评审内容是产品/子系统是否已经满足进行子系统级别的集成和测试的条件，包括：这些详细设计方案和实现是否符合概要设计方案并能完成产品规格？从BBFV结果来看各模块的技术成熟度如何？有何潜在风险？是否充分考虑了产品部件的重用性？在测试、采购、制造、售后服务等各个业务方面是否可行，有何风险？ 检查building block 满足SDV进入的标准，确保SRS分解到该building block所包含的所有模块的相关规格在模块详设中体现。1、检查BB模块的详设审查结果，单元测试结果、IT、ST、BBIT结果。2、判断BB能否进入SDV | 模块设计验证报告，系统集成测试报告，设计变更或优化方案 | 开发/设计 |
| TR4A | 原型样机评审 | 评估原型机的质量和初始产品的准备情况。 模块和系统完成集成/联调工作，模块级测试SDV测试。评估技术成熟度是否可以开始全面的整机测试SIT，评估制造成熟 度是否可以开始工程样机的生产和测试。 1、功能和性能需求得到满足。2、软件功能和性能质量达到不影响SIT开展。3、SDV所测特性的用例累计执行覆盖率达到100%。4、完成SIT测试准备（测试设计、测试环境、人员）5、对采购和制造能力基线化，保证足以支撑初始产品生产（从而保证SIT的启动）。 | 量产验证报告、市场反馈报告 | 开发/设计 |
| TR5 | 工程样机评审 | 样机评审，验证产品可生产性，准备小批量试产。 评估工程样机技术成熟度和制造系统准备成熟度，能否进入批量试生产和SVT。工程样机技术成熟度评估主要包括是否满足产品需求规格，已知的技术问题的解决情况，以及有何技术风险？制造系统成熟度评估工艺流程、工艺文件、工夹具等方面的准备情况和风险情况。 | 量产准备报告、生产流程文档 | 验证 |
| TR6 | 小批量评审 | 评估产品生产级的技术成熟度，确定产品是否可以转入批量生产和启动市场发布。相关评估依据SVT测试结果、批量试生产的过程记录和总结、β测试结果（如果有的话）、市场准入测试结果等。 | 上市报告、用户支持文档 | 发布 |
为了保证TR的结论的严肃性，所有已经通过TR评审的阶段性成果，如果要进行更改，就必须通过一个变更流程进行审批，或者说变更开始受控。例如，在TR1之后，产品需求规格的更改就必须进行记录和审批，必须受控。
通常情况下，TR的结论有以下几种情况：
1．继续：没有遗留问题，或者遗留问题的改进计划的执行没有任何风险，并且在短时间内可以完成。
2．带风险继续：遗留问题的解决有一定风险，但不影响下一步活动的启动。
3．修正：遗留问题影响到下一步活动的启动，必须首先解决。
1.6：哪些企业适合IPD？
如下企业应该是适合的：
- 产品线复杂、生命周期较长的行业（如通信设备、汽车、电子产品）。
- 企业希望通过流程改进提升开发效率和市场竞争力。
- 研发团队规模较大，部门协作需求强的企业。
- 需要提高市场敏感度和客户满意度的企业。
对ROI的绝对重视，对跨部门的协同需求，对市场的敏感度把控，这些在行业里具备共通性，制造业的需求更加紧迫。
个人理解，芯片研发企业是一定适合的，而且基本上是量身定制的管理体系。
二：IPD & 研发的关系
作为一个研发人员，一开始对IPD是有误解的（因为自身也没有在华为工作过，所呆公司也有上过IPD，但更多的是形式上的），以为IPD对研发内部做了很多流程上的改造，但实际看下来，并不是，内部的研发过程仍然是瀑布或敏捷之类的老方法。但也不是没有影响，实际上在理念上的不同，导致的实操的细节上，工具使用上，有很大的差别。在全面讨论IPD之前，我们先看看，作为研发人员，在IPD的管理体系下，需要注意一些什么？
2.1：IPD对研发过程的影响
- 需求定义的规则和管理发生变化
- 客户为中心，强调需求分解，从MRD开始分解需求，需要和市场人员对齐。
- 需求变更需要严格管理，受控，但可以接受变更。（传统研发一般是完全冻节需求，但基于IPD的研发，可能随时更改需求，因为要响应客户）
- 跨部门来定义，评审需求。建立需求跟踪距阵（RTM），追踪需求到实现的全过程。不再是串行的工作，需要和其它部门协同，不断沟通。
- 研发设计原则的变化
- 强调接口和模块化设计，避免依赖，并行开发，提升效率。这有点像之前软件行业的平台化战略的做法，但目的不同，原因是为了保证并行，必须要接口更清楚。不可能是只关注单体的质量和性能。
- 硬件，软件，测试，工艺设计同步进行。避免串行延迟问题。
- 模块化设计，强调复用性和灵活性，定义接口规范，减少模块间的依赖。
- 更严格的设计评审（PDR，CDE）
- 有明确的输入（需求文档）和输出（设计方案）。引入DFx，DFM，DFA。
- 注意设计也要多部门协同，同步推进，避免设计脱节。
- 测试需要提前介入和全覆盖验证
- 测试团队从需求和设计阶段就开始参与，提前定义测试用例。
- 功能测试，性能测试，可靠性测试，生产可行性测试。原型到小批量生产全过程。
- 测试与设计同步进行，设计的更新得到验证。
- 提供自动化测试平台，可回归和高效测试。引入FMEA方法，评估高驻地中的风险。
- 更多的评审节点。
- PDR（初步设计预审，包括市场需求，生产可行性）
- CDR（详细设计评审，包括量产问题）
- TRR（测试准备评审）
- 发布需要跨部门准备和全生命周期支持
- 发布涉及了生产，市场，销售和服务团队，确保产品可顺利推向市场。要包括量产准备，市场推广和用户培训等。
- 发布前需要有严格的TRR，ORR，一个强调测试的准备，一个强调运营的准备。
- 发布要包括后续持续跟进，用户反馈收集，产品维护和升级计划。
- 建立PLM，强调发布后续的维护和优化。
- 全局规划分配资源。
- 这个并不好处理，但是研发资源一定是要可以全局分配的，否则，无法支撑庞大的产品研发。
- 可以使用一些IPD的工具和方法。
- 如：DFM工具 等……
2.2：需要重点关注的阶段
也因此，研发人员需要参与的阶段有：
- 概念阶段——根据市场和客户需求分析，参与技术可行性分析。
- 规划阶段——按MRD拆分PRD，计划与市场，生产计划同步，根据优先级优化资源配置。
- 验证阶段——原型验证（技术可行性，用户体验），生产可行性验证（小批量试生产，产品实际在生产条件下的表现），客户验证（目标客户使用情况反馈）。DVT，PVT。验证会在研发全过程。
- 产品生命周期管理
- 产品上市后，需要关注维护，优化和最终退役。
- 持续改进，根据数据分析，不断优化产品性能和功能。
- 确保产品在整个生命周期中的成本最小化。
- 需要收集用户反馈，持续的技术支持和定期更新，确定产品退役的资源回收和用户迁移方案。
总的来说，IPD管理体系下的研发团队，需要更多关注客户需求，更多关注与其它部门的协同，参与更多的评审，提供更好的设计支持并行开发……
三：IPD 系统基础模块
从上面的介绍，我们可以看到 IPD 涉及到的内容很多，很复杂，那它有一些什么样的基础模块呢？哪些模块是必须具备的，哪些是可以阶段性提供的的呢？
下面，我们以飞书的项目管理系统为例，来介绍一些基础的模块。当然，在介绍模块前，我们需要先简单介绍一下飞书项目管理这个系统。
注意：下面的内容有点象给飞书项目管理打的广告。但我的本意并非如此，只是因为看了它的产品介绍，确实可以通过它批露的资料，比较好的讲解IPD的实施模块和原则。而且，飞书的项目管理是需要大量实施工作的（甚至咨询），加上使用费，其实非常昂贵，也不是普通公司可以承受的。
3.1：飞书解决方案
飞书在2024年发布了基于IPD项目管理的工具平台，我们可以看看。
3.1.1：产品架构
从上图可看出，飞书的项目管理基本达成中型IPD规模。
小IPD：只处理集成产品开发
中IPD：添加市场，客户部分，战略管理。
大型IPD：整个组织，人力，绩效，团队全部含入。需要一些绩效工具，技术件。这个飞书暂时是做不到的。
3.1.2：飞书希望解决的问题
可能的做法：流程在文档里，计划在excel里，执行靠各种各样的会议来监督完成。
三者不统一，就是上面说的三层皮，无法很好的将IPD得以执行。
说白了，就是将IPD进行信息化，数字化。而飞书能做好这一点，有一些先天优势，因为飞书有协同平台，有很强的技术开放平台的能力。
3.1.3：飞书的解决方案核心
流程可视化：可以理解为可以象建立飞书审批流一样，将IPD过程中的流程全部可视化。这样，使用起来简单，而且可以卡住关键的时间点（也可记录），从而可以催办，通知，报表。
流程标准化：说是标准化，我理解就是定制化，因为每个企业的流程是有不同的，飞书提供流程的定制能车。
流程高可配：可随时配置，修改。
所谓 IPD + ，就是达到 端 到端 解决问题。
因为提供的是全配置平台，所以，初期梳理业务流程，实施工作量巨大，当然，好处在于，可以持续通过小的实施修改，使得企业的变化在系统中体现和沉淀下来。
这里可以和 Jira，Ones做一个小比较：
1：有计划和执行，但没有复杂的流程。缺少流程卡点。
2：系统比较割裂，评审，计划，反馈。只能单独完成。大多数企业只能覆盖一小块，多个工具管理。如果要二开，工作量大。飞书的特点可以做到端到端。
3：IPD的建设时间非常的长，流程过程迭代中，流程可能随时需要变化，增加，有一个好的可配置平台，可以让工具不过时，工具可以陪伴企业成长。
说白了，飞书提供一个适合于IPD管理体系搭建的配置平台，没有提供任何具体的流程。
当然，飞书提供了一些标准实践，模板，但业务流程没有做任何的工具化。
3.1.4：飞书的亮点功能
计划管理——通过泳道图来查看全景
对 IPD（Integrated Product Development） 管理理念的直观化实现。主要目的是通过清晰的时间线和泳道划分，展示产品生命周期中不同阶段的关键任务、角色分工和时间安排。
纵轴是不同的角色：
横轴是不同的阶段：
做项目进度的跟踪，任务可以下钻。
协同计划——排期
基线管理——可对比历史
集成评审——这个非常重要，评审要素可管理
评审要素库，可以发给相关人员，会上做讨论和结论。
自动化通知——如果协同平台使用的是飞书，那确实非常方便
度量报表——因为同一系统，报表会更容易
非标准化的流程资源库
3.2：客户的痛点
再重复一下可能客户需要解决的问题：
3.2.1：评审流于形式
评审流于形式，经验很难沉淀，跨部门协作困难，流程不统一。这些都是新/老企业非常共性的问题。
3.2.2：跨部门协作困难
计划与管理脱节，经验无法沉淀，事项无法有效收集管理。
多个系统处理 流程，计划，执行跟踪三面皮。
3.2.3：流程，计划，执行三面皮
3.2.4：经验无法很好沉淀
这其实是一个通病，工作好的经验其实最关键的就是流程（知识库也需要有流程来串联）。所以，有一个好的流程定义工具，可以很好的将公司的经验留存下来。
3.3：IPD重要场景
对于芯片研发/制造业，如果要上线IPD，应该上线哪些场景，下面简单列举一下。
3.3.1：战略管控场景-DSTE
从战略规则到目标，项目集，到项目，到任务。
这个非常重要，领导认为IPD是否有必要，主要看这个场景是否满足领导的需求，领导认为这个场景是否解决问题。
3.3.2：客户需求管理场景-OR
需求一定要管理，但要管到全生命周期，是有一定难度的。
3.3.3：产研场景-IPD 集成开发
这个自然是必需的，不用多说。
3.3.4：市场运营场景——IPMS
3.3.5：市场运营场景——LTC
3.3.6：客户服务场景——ITR
3.4：IPD 基础模块
我们先不考虑模块间的关联，一些复杂的问题，我们今天只列出一些重要的管理模块。做为一个概览。
3.4.1：全景视图
整个产品需要有一个全景视图，一般的做法，就是搭建DSTE战略管理视图。将整体IPD系统中的所有内容自顶向下，以树形方式串起来，呈现给领导把控风险和项目完成情况。
类似上面提到的战略管控场景，一般是通过全景视图来完成。
全景视图的能力非常强，提供了多种呈现方式，基本能满足复杂视图的需求。
3.4.2：需求管理
需求管理有很多种，我们这里重点谈的是产品的总体需求管理，全生命周期的。
它会包括复杂的流程：
客户需求收集——需求分析——需求分发——需求变更——版本/项目负责人审批——开发——测试——需求验证——结束
流程中可以根据填入表单的值不同，做不同的流程跳转。
比如：在收集客户需求时，我们认为是生死需求，就触发一个领导评审会来进行决策。
3.4.3：集成产品开发（项目管理）
这是最重要的模块，不同的开发方法会有不同流程模板（可以有不同的版本），这大都会成为公司重要资产，约束公司的研发过程。
提供一些关键功能：如：计划排期，风险管理，质量分析
这和其它管理软件做法一致，不再多说。
3.4.4：问题管理
需求，项目，问题（缺陷）差不多是必不可缺的三大件。问题可以是研发中的程序bug，也可能是评审的缺陷，或者是客户反馈的一个问题。所以，问题单可能会有多种，用在不同的流程中。
它也可以和代码研发，测试用例，客户反馈紧密关联。
3.4.5：评审管理/评审要素
评审是IPD里非常重要的模块。
3.4.6：交付物管理
3.4.7：基线管理
3.4.8：计划排期
3.4.9：流程资源库
3.4.10：任务管理
3.4.11：度量（报表）
这个需要自行定制，但还是非常重要的，按需定制。还包括人力甘特图，可以查看人力使用情况。
3.4.12：变更管理
变更非常重要，一般是关联审批流来完成。
3.4.13：工时登记
3.4.14：里程碑管理
3.4.15：其它
可能还是一些其它功能是需要的，这要看具体的需求。比如：客户管理，采购管理，订单管理……
3.5：飞书提供的角色功能
除了标准模块，还提供一些个性化的功能，是必须的。
比如：角色维护，个人工作台，通知中心，
3.6：飞书的集成能力
飞书按空间来定义公司的一个事业部。
一个空间中的数据是共享的，由上述的这些模块来组成。
它背后提供强大的表单，流程，报表，三方平台的集成能力（Devops工具）。
非常重要是它的模块间的粘合能力，它提供任意的关联功能，可以将不同模块，以及飞书审批，三方工具集成在一个流程中。
提供很强的视图输出能力。
提供功能，字段，数据的权限管控。
提供消息通道。
四：IPD的实施
非常抱歉，这可能是最重要的一个章节，但我现在还给不出好的建议。一来这有信息安全问题，再者每个公司的情况是不同的，如何将上面讲的模块联合起来，形成公司各个场景的工具，会根据公司的实际情况不同，有不同的方案。
据我和飞书实施的沟通，良性的企业（流程完整，思路清楚），可以在2-3个月完成实施上线工作，传统老旧企业（流程不清楚的）花上半年，也不能上线，当然，副产品是梳理清楚了公司的很多业务。
最后，研发和制造有项目管理的银弹，一切工具都是人来使用的。IPD只是一个概念，它并不是产品成功的最关键的要素，但它确实是一个企业能良性发展的好工具。它也不是什么高深的理论，实际上就是按商业投资逻辑来重新定义一些过程，使用IT工具来进行管理的手段。
就写在这里了。
五：其它方案
5.1：Ones解决方案
这是ones提供的一个解决方案Demo，可供参考：
覆盖从需求管理，项目立项，计划制定，资源分配，设计开发，验证测试，产品发布到上线交付的端到端研发管理过程。
附1：IPD术语
BB：building block，组件
BG：business group，业务群
BLM：business leadership model，业务领先模型
BMT：business management team，业务管理团队
BP：business planning，业务计划
CB：capability baseline，能力基线
CBB：common building block，通用构建模块
CDP：charter development process，项目任务书开发流程
Charter：项目任务书
Review Checklist：评审要素表
CDT：charter development team，项目任务书开发团队
CRM：customer relationship management，客户关系管理
CP：check point，检查点
C-PMT：corporate portfolio management team，公司组合管理团队
C-RMT：corporate requirement management team，公司需求管理团队
C-TMT：corporate technology management team，公司技术管理团队
DCP：decision check point，决策评审点
DRR：deployment readiness review，推行准备度评审点
E2E：end to end，端到端
EOL：end of life，生命周期结束
ESP：early support plan，早期客户支持计划
GA：general available，通用可获得性
IFS：integrated financial service，集成财务转型
IPD：integrated product development，集成产品开发
IPMT：integrated portfolio management team，高层决策团队
IRB：investment review board，投资评审委员会
ISC：integrated supply chain，集成供应链
ISOP：integrated strategy & operation process，集成战略与运营流
ITMT：integrated technology management team，集成技术管理团队
ITR：issue to resolution，从问题到解决
JIT：just in time，准时制
LMT：life-cycle management team，生命周期管理团队
LPDT：leader of PDT，产品开发团队经理
LPMT：leader of PMT，组合管理团队经理
LTC：lead to cash，从销售线索到回款
MM：market management，市场管理
MOT：moment of truth，关键时刻
MP：marketing planning，市场规划
ODM：original design manufacture，原始设计制造商
OEM：original equipment manufacture，原始设备生产商
O/S：offerings/solutions，交付物/解决方案
OR：offerings requirement，产品包需求
PACE：product and cycle-time excellent，产品及周期优化法
PBC：personal business commitment，个人绩效承诺
PDM：product data management，产品数据管理
PDT：product development team，产品开发团队
PLM：product life-cycle management，产品生命周期管理
PL-lPMT：product line integrated portfolio management team，产品线集成组合管理团队
PL-LMT：product line life-cycle management team，产品线生命周期管理团队
PL-PMT：product line portfolio management team，产品线组合管理团队
PL-RAT：product line requirement analysis team，产品线需求分析团队
PL-RMT：product line requirement management team，产品线需求管理团队
PL-TMT：product line technology management team，产品线技术管理团队
PMBOK：project management body of knowledge，项目管理知识体系
PMI：Project Management Institute，美国项目管理协会
PMOP：program management operation process，变革项目管理运作流程
PMT：portfolio management team，组合管理团队
Product roadmap，产品路标
PROPS：the project for project steering，指导项目运作的项目
PRR：Pilot readiness review，试点准备度评审点
PRT：product research team，产品预研团队
PSST：products and solutions staff team，产品和解决方案体系
PTIM：product & technology innovation management，产品技术创新管理
QMS：quality management system，质量管理体系
RAT：requirement analysis team，需求分析团队
RDPM：R&D project management，研发项目管理
RM：requirement management，需求管理
RMT：requirement management team，需求管理团队
RP：roadmap planning，产品路标规划
SDCP：selection decision check point，决策选择评审点
SDT：solution development team，解决方案开发团队
SE：system engineer，系统工程师
SP：strategy planning，战略规划
SPDT：super product development team，超级产品开发团队
S-PMT：super portfolio management team，解决方案组合管理团队
system requirement，系统需求
TDCP：Temporary decision check point，临时决策评审
TDT：technology development team，技术开发团队
TMG：technology management group，技术管理组
TMS：technology management system，技术管理体系
TMT：technology management team，技术管理团队
TPD：technology & platform development，技术开发团队
TPM：transformation progress metrics，变革进展评估
TPP：technology &platform planning，技术和平台规划
TR：technology review，技术评审
TRT：technology research team，技术研究团队
WWPMM：world wide project management methodology，全球项目管理方法论
X-TMG：跨产品线技术管理组
