管理体系是否有效，要和企业所处行业、历史、规模、人员结构、外部环境等相吻合，
黑格尔说，人类最大的教训就是人类从来没有从历史上吸取教训。
IPD（integratedproductdevelopment，集成产品开发）
我们学的方法是IBM的。IBM教会了我们怎么爬树，我们爬到树上就摘到了苹果。我们的老师主要是IBM。”
说：“创造力就是连接……连接生命中的各种体验，然后把把它们组合成一种新的东西。”
向榜样和标杆学习，采用业界成熟的管理体系，是企业提高创新和研发管理水平的重要方法，但在如何学习上不少企业走了弯路，其中的一个原因就是引入过多的管理体系让管理者和员工无所适从。华为过去10多年的实践为我们指明了一条如何学习榜样的有效路径。这条路就是持之以恒地模仿、跟随、固化、优化一套经过验证的管理体系，结合企业特点不断向深度发展，然后超越，最终形成自己的管理体系。
在歌功颂德的同时，也以寻找华为公司和任正非的破绽为己任，当任正非说要追求利润的时候，他们说这个和互联网精神不符合，互联网精神要的是烧钱买流量，小米、京东、BAT一开始都不追求利润，最终才有利润；当华为任正非说要科学管理，管理要规范化，化，向“蓝血十杰”和西方管理持续学习的时候，他们说任正非老了，跟不上时代的发展，华为因为管理太僵化已经遭遇“创新者的窘境”，快要步诺基亚、摩托罗拉、北电网络等的后尘了;当任正非说要艰苦奋斗、加班加点奉献（尤其是管理层）的时候，他们说这不符合80、90后的需求；当任正非说要坚持自我批判的时候，他们说这是什么年代了，现在年轻人要的是个性、自我，这样才能创新；当任正非说要以客户需求为中心、围绕客户需求创新的时候，他们说客户不知道客户需求是什么，乔布斯从来不做市场调研……
总结下来，除了上面提到的“官方”认可的全员持股、以客户为中心、艰苦奋斗、自我批判以外，主要集中在几个方面：（1）压强原则。（2）创新与研发。（3）市场营销能力。（4）低成本优势，尤其是研发低成本。（5）管理体系和IT。另外，还有作者总结为外部市场环境，比如中国通信市场高速发展、固定汇率带来的海外市场低成本优势等。
华为CEO用这个比喻来强调跨部门流程的重要性。
华为有多少个跨部门流程？从满足客户需求角度，华为只有3个流程
（1）IPD流程（LeadsToCash）：各层级和各领域战略规划、需求管理、产品规划、项目任务书开发、产品开发、上市、生命周期管理。
（2）LTC即L2C,LeadsToCash,从线索到现金的企业运营管理思想，华为的LTC流[4]程也深入的应用了这一思想[5]，L2Cplat是这一思想的践行者。是以企业的营销和研发两大运营核心为主线，贯穿企业运营全部流程，深度融合了移动互联、SaaS技术、大数据与企业运营智慧，旨在打造一个从市场、线索、销售、研发、项目、交付、现金到服务的闭环平台型生态运营系统.
（3）ITR（issuetoresolution，从问题到解决）流程：包括从客户问题产生到最终得到解决的流程。
华为在流程建设方面，首先从方法论上确定了规则，即“流程的核心是要反映业务的本质，还原以后，该是谁的就是谁的。”
然后，针对三大业务流，建立对应的三个系统，即IPD（产品集成开发）、LTC（机会至收款）、ITR（售后），同时用流程IT的方式进行固化。这样就可以避免“前面一段说日语，中间说德语，后面说汉语”、“各段都是李云龙”的问题。大部分企业都可以参照梳理成这三大业务流。
最后，在“以客户为中心”的理论指导下，进行组织配置，包括责任人、考核方式等。保证瞎子能共同拼出一头真正的大象。
一个公司就三件大事：
●第一件把产品开发出来，产品从有概念开始，到面市；
●第二件是把产品变现，要有客户买，形成订单，发货、安装、验收、回款；
这三件事情对应三大业务流，这三大业务流有起始终止，对应三个系统（IPD/LTC/ITR），还要有相应的组织去适配（不仅是流程IT），也要和客户去匹配，很多订单要和客户去对接。
日复一日，年复一年，简单、海量、重复的工作怎么去做更好？就是先要把它流程化，模板化，固化下来，最后采用IT支撑。公司三大业务流，日复一日，一年运行下来，就形成了公司的业绩：财务三张表。
业务就上面的三件大事，流程要匹配业务流，不长也不短，够用就行。其核心是：流程要反映业务的本质，尤其是完整系统地反映业务的本质。业务中的各关键要素及其管理不要在流程体系外循环。基于流程建设的管理体系（IPD/LTC/ITR），是一个运营系统，是一个业务操作系统（BusinessOperationSystem），其中最重要的是落实到组织中，就是流程化的组织建设和运作。
产品是满足需求的交付物的总和，包括有形部分和无形部分。为了强化这点，IPD体系用offerings来替代产品这个概念，中文翻译为“产品包”，是对客户和下游环节所有交付的统称。
产品包需求（offeringsrequirement，OR）就是对原始需求进行分析、判断和加工后，最终向客户（包括外部客户和内部客户）交付的需求，是对产品包的正式描述，完整且准确，是对产品包进行开发、验证、销售、交付的依据。
（1）开发（development）：开发是创新性活动，目的是在企业有盈余的前提下满足市场和客户需求。
（2）产品（product）：产品是满足客户所有需求（$APPEALS）的提供物的总和，也就是前面定义的产品包（offerings），包括有形部分和无形部分。
（3）集成（integrated）：IPD的威力体现在“集成”上。首先，IPD集成了若干中有效的工具、方法和流程。其次，IPD把企业内各资源部门通过跨部门团队的方式集成在一起，共同完成规划和研发工作，满足客户需求。最后，也是最重要的一点是：IPD集成了若干重要的思想，这些思想是IPD的核心。
可以从3个不同视角来定义IPD：
（1）狭义IPD：也叫“小IPD”，指的就是新产品开发。
（2）中观IPD：包括产品开发（狭义IPD）、市场管理及产品规划（marketmanagement，MM）和需求管理（requirementmanagement，RM），3大流程共同构成产品创新管理体系。
（3）宏观IPD：也叫“大IPD”。这种概念下的IPD指的是端到端产品管理体系，甚至可以延伸到公司管理体系（当我们拓展产品的定义，谁还认为公司经营不是产品经营呢？）。除中观IPD范围外，宏观IPD还包括技术和平台规划（technology＆platformplanning，TPP）、技术开发（technology＆platformdevelopment，TPD）、产品生生命周期管理（productlife-cyclemanagement，PLM），以及支撑它们的组织体系和绩效激励体系。
IPD是关键！我们必须更加规范地开发产品；在开始便考虑市场情报和客户需求；在开始阶段就确定所需资源；根据里程碑管理；只在里程碑变更需求和项目方向，因此我们不会不断地修补项目。整个IPD重整至关重要，如果你不知道它是什么，你就真正地需要回去学习。我的意思是说，这个公司的每个人都需要熟悉IPD。我们准备根据这个流程来经营公司。
检验管理是否有效的唯一标准就是成果。
此外，持之以恒还表现在遇到困难的时候，不要轻易怀怀疑管理体系有问题，要多从自身找问题，绝大多数情况下是自己还没有吃透管理体系的精髓，没有做好变革的准备，导致变革的过程出现问题，而不是体系和方法论的问题。
标杆学习的重点不是具体的做法和模板，而是这些最佳实践背后的原理。只有吃透其中的原理，并转化为适合本公司的管理体系，才会成功。
那本书是什么？一言以蔽之：以华为作为案例之一，说明公司的产品管理、创新管理和研发管理必须遵循的一些普遍规律和思想原则，如果坚持不懈地贯彻和应用它们，在公司内部各个领域/部门之间达成共识，并形成管理制度和流程，就可以显著提高企业的产品管理和研发管理水平，实现从中国制造走向中国创造的梦想。
理论是对若干现象、实践、经验及教训的总结和提炼，反过来用于指导实践。
将成功企业普遍遵循的规律提炼为IPD的核心思想。只要在日常管理活动中有效贯彻了这些思想，我们认为你的企业就是按IPD来运作了，并不局限于是否采用了某种固化的流程、组织结构或绩效管理方式。
IPD体系在全球经过20多年的发展，其核心思想有7个。
思想1研发是投资行为
以，业务经营有两条主线：实现公司商业目标和满足客户需求，两者缺一不可。因此，要把所有研发项目作为投资对象进行管理，包括产品开发、平台和技术开发，以及研究类项目，从一开始就要考虑产品、服务、解决方案和技术的投资回报率。针对B2B（businesstobusiness，企业对企业）业务，尤其是解决方案类的产品和服务，还需要站在客户角度进一步考虑客户的投资回报率，只有客户成功了，企业才有存在的价值。
思想2基于需求的研发
思想3平台化开发
为了提高产品、服务、解决方案的开发效率，需要通过需求管理、产品和技术规划提前识别公共技术和关键技术，单独立项开发，这样才能在产品开发过程中调取这些资源，从而在快速响应客户需求、提高质量、降低成本上同时取得领先优势。为了做到这一点，抽取现有产品共同使用的模块和技术形成平台只是最基础的工作，更为重要的是要探索和研究目标客户未来的共同需求，在此基础上形成产品和技术平台，对产品研发提供有力支撑。是否基于平台和核心技术进行系列产品开发是公司研发实力的最终体现。
思想4跨部门协作
创新和研发是全公司的行为，接力棒式的产品开发流程程难以保证产品质量。在IPD体系中，无论是需求管理、产品和技术规划、项目任务书开发、产品和技术研发、产品上市，还是上市后的生命周期管理，都广泛采用跨部门团队，汇集各个领域的专业智慧，形成合力，共同满足客户需求，为产品的商业成功负责。为此，各个职能部门应“退到幕后”，为这些跨部门团队提供资源和支撑。同时，公司的企业文化、绩效管理和激励机制也要支撑跨部门团队的运作。
思想5结构化流程
把复杂的产品创新过程进行解构是管理的基础。IPD体系中的各种流程被划分为若干个阶段，在每个阶段设置了评审点，按角色归集流程中的活动，以便与组织结构相互匹配。评审点分为决策评审点和技术评审点，在MM流程和IPD流程中，通过决策评审实现高层决策团队（投资方）和规划团队、研发团队（承诺方）等的互动，资源分批受控投入，既满足项目进展需要，又避免投资失控。通过流程中的技术评审，实现专家和项目团队的充分互动，各领域专家充分利用其专业经验为研发团队提供指导，确保产品最终满足客户需求。
思想6业务和能力均衡
法国社会心理学家托利得说：“测验一个人的智力是否属于上乘，只看脑子里能否同时容纳两种相反的思想而无碍其处世行事。”企业也是如此。业务发展和内部能力建设是一对相互支撑的矛盾，业务发展可以促进能力提升，但独立进行能力构建也是必需的，“磨刀不误砍柴工”。所以，快速响应市场需求的同时不能忽略内部能力构建，两者都很重要。无论产品多有竞争力，终有生命周期结束之时，但企业通过各种方式构建的能力可以使其源源不断地推出新产品。在企业发展的不同阶段，可以有策略、有选择地把重心放在业务发展或内部能力的构建上。
思想7灵活发展，与时俱进
IPD不是一套固化的思想、流程、子流程、组织架构、激励机制，更不是各种纷繁复杂的工具、模板、表单和考核核指标。IPD是灵活发展的，必须在不断吸取业界最佳实践和解决业务问题的过程中与时俱进，因此华为目前运行的IPD与1999—2003年在IBM咨询顾问的指导下引入的IPD已经有非常大的不同。
要让IPD的7大核心思想发挥作用，一定要有管理体系作为载体，包括方法论、流程、组织结构、绩效管理和激励制度等。
通过多年对华为研发管理的亲身经历和深入研究，以及10年来把IPD体系应用于各行各业的实践，我们把IPD体系划分为7大模块，它们相对独立又相互耦合，共同构成IPD大厦，推动华为10多年的高速发展。简单讲，IPD解决了华为“做什么产品，以及如何把产品做出来成功上市”的问题。第11章将尽量“原汁原味”地系统介绍华为的IPD体系。
组成1基于MM的规划：应当做什么
对于公司、事业部、产品线、单个产品、区域市场、各个部门等组织内的不同层级，都需要进行规划，让这些规划相互匹配是规划体系有效运作的基础。华为用MM方法论解决了这个难题，MM为公司所有层级的规划提供了一致的方法论。MM方法论分为六个步骤：理解市场，细分市场，组场，组合分析，制订业务计划，融合和优化业务计划，管理和评估业务计划。MM是工作方法，也是思想方法，实际运作中绝非简单地按部就班就能完成规划工作的，而需要在各步骤之间创造性地不断迭代循环，最终制订出可执行的业务计划。
组成2基于IPD的研发：如何进行创新
言。IPD方法论也分为6个步骤：概念、计划、开发、验证、发布和生命周期。
组成3以客户需求为中心：华为的商业模式
需求管理（RM）是MM和IPD的支撑流程，为它们提供输入。RM包括五个过程：需求探索和收集，需求分析，需求分配，需求实现，需求验证。
组成4矩阵组织：职能部门支撑团队运作
组成5研发项目管理：管理的“临门一脚”
在参考PMBOK（projectmanagementbodyofknowledge，项目管理知识体系）和业界最佳实践的基础上，制定了RDPM（R&Dprojectmanagement，研发项目管理）框架。RDPM创新性地把各种管理方法和工具集成在一起，为研发项目保驾护航，
组成6绩效与激励：绝不让雷锋吃亏
组织和流程让大家在同一平台上工作，解决了谁来做事、如何做事的问题，但要让员工充满工作激情，需要做的工作还有很多。首先，需要对绩效进行有效的测量。犹如行驶中的飞机和汽车需要仪表盘，IPD体系也需要一个“管理仪表盘”，对需求、规划、研发、项目管理、组织和流程运作状况等进行测量，让组织和个人随时知晓所处的状态。其次，要把公司、各产品线和各部门的目标转化为个人目标，使组织目标和个人目标“对齐”。上级主管要帮助下级达成个人目标，在整个过程中要和员工保持持续沟通，对员工进行物质和非物质激励，满足员工多方面的需求，而不仅仅是对员工实施“考核”。
组成7管理变革与优化
把思想融入管理体系：七七四十九
IPD体系的7大核心思想是：研发是投资行为；基于需求的研发；平台化开发；跨部门协作；结构化流程；业务和能力的均衡；灵活发展，与时俱进。企业可围绕7大核心思想，不拘泥于任何形式构建产品和技术创新管理体系。
IPD体系的7大组成部分：基于MM的规划，基于IPD的创新，以客户需求为中心，矩阵组织，研发项目管理，绩效与激励，管理变革与优化。
制造可以用OEM方式式外包，销售可以交给批发商和零售商，或者通过电商渠道销售，产品研发可以委托给设计公司或者用ODM+OEM①的方式外包。企业究竟应当进入什么市场？提供什么产品？这些产品如何进行定义？企业内部应当构建什么能力？这些问题无法外包。虽然咨询领域有大量提供战略咨询的公司，但这些咨询服务还是以单个项目的方式开展的，不会深入到产品路标规划和具体产品定义。所以，企业必须具备市场管理、产品规划和产品定义等方面的能力。
OEM（originalequipmentmanufacture，原始设备生产商），ODM（originaldesignmanufacture，原始设计制造商）。
大部分企业没有把各层级战略、策略和行动计划的制订（也就规划过程）作为一个体系来管理，缺乏一致的规划方法论和流程，没有组织和人力资源保障。最终即便有各层级书面计划（plan），却没有规划过程（planning），导致难以做到公司行动一致，也就是不能做到“四个对齐”：
（1）上下对齐：高层、中层和基层的对齐。
（2）左右对齐：不同产品线和部门之间的对齐。
（3）长中短期对齐：长期规划（3年以上）、中期规划（1～3年）和短期规划（年度计划）的对齐。
（4）外部对齐：整个公司的计划要能满足客户和市场需求，适应外部环境变化。
大部分企业没有把各层级战略、策略和行动计划的制订（也就规划过程）作为一个体系来管理，缺乏一致的规划方法论和流程，没有组织和人力资源保障。最终即便有各层级书面计划（plan），却没有规划过程（planning），导致难以做到公司行动一致，也就是不能做到“四个对齐”：（1）上下对齐：高层、中层和基层的对齐。（2）左右对齐：不同产品线和部门之间的对齐。（3）长中短期对齐：长期规划（3年以上）、中期规划（1～3年）和短期规划（年度计划）的对齐。（4）外部对齐：整个公司的计划要能满足客户和市场需求，适应外部环境变化。
规划的输入不明确
没有基于市场需求进行产品规划
产品路标从哪里来？这个看起来简单的问题，在实际操作过程中，往往被企业忽视。很多企业在进行产品规划时并没有从市场分析、客户需求出发，而是直接进行产品规划，更多地是从目前现有的产品出发进行规划，过度考虑自身的现状。这样的做法忽视了外部宏观环境、行业竞争格局、技术发展趋势、市场状况、客户需求等因素，导致产品规划没有以市场和客户需求为根基。结果是：要么创新过少，要么创新无法满足客户需求。
规划在无谓的试错中形成
这种现象在国内企业普遍存在。企业在发展过程中，针对现有客户需求和竞争压力开发了很多产品，但成功率在逐逐步降低。这些企业的现有产品格局是在被动响应和试错中形成的，而不是经过自觉的、规范的规划过程产生。结果是，虽然有一些产品成功了（如果企业还没有倒闭），但也为此付出了惨痛的代价，表现出来就是在“成功”的同时也有大量产品不成功。当企业发展到一定阶段，这种运作方式将大大增加经营风险。
各领域规划割裂，未转化为组织的一致行动
公司到达一定规模后，“部门墙”就会产生，如果不在管理体系和文化上刻意去克服和避免，必然会成为公司发展的障碍。部门墙产生的原因之一就是各部门的目标和行动不一致，我们称之为“左右”没有对齐。
没有考虑平台和技术规划
规划中的问题还表现在产品规划和平台规划、技术规划相割裂，没有充分考虑各个产品之间、产品线之间的技术共同点，没有形成产品平台和技术平台，难以形成技术壁垒。结果是企业开发了很多产品，但这些产品没有形成系列。产品做了很多，但是技术积累很少，每次开发新产品都要从头做起，研发成本高，产品上市速度慢，质量也得不到保证。证。同时，因为产品之间差异性很大，导致供应链成本、销售成本和后期维护成本升高。
孙子曰：“上下同欲者胜。”
企业要在竞争中取胜，上下级之间目标要一致，部门之间目标要一致，长期、中期、短期目标要一致，这些目标要和外部环境的变化保持一致，华为称之为“上下对齐，左右对齐”。
MM方法论围绕这些关键问题展开：
（1）价值观、使命、愿景、目标分别是什么？
（2）为谁服务，也就是选择哪些细分市场？
（3）战略路径（业务设计）和业务计划是什么？
（4）要满足细分市场客户的哪些需求？
（5）为目标客户提供什么产品、服务或解决方案？
（6）需要构建哪些能力？如何构建？
（7）各领域策略和行动计划是什么？
（8）如何实现业务计划的闭环管理？
（1）在明确使命、愿景和目标的基础上，确定要服务的对象及其需求。
（2）确定用什么交付（产品/服务/解决方案）来满足这些需求。
（3）确定在采取哪些行动/构建哪些能力来提供这些交付。
（4）对规划过程进行闭环管理和评估。
战略就是定位、取舍和匹配，MM方法论和这个观点是非常一致的。
（1）定位：确定企业为哪些客户提供哪些区别于竞争对手的独特产品和服务。
（2）取舍：明确哪些事情是要做的和不做的，尤其明确哪些是不做的。
（3）匹配：各个领域的活动支撑战略定位，并且相互匹配和加强。
ISOP（integratedstrategy&operationprocess，集成战略与运营流）就是以MM方法论为基础，统一管理企业的战略规划和各种运营活动及其管理体系的流程框架。
战略和运营同等重要。华为经过多年的实践摸索，提出基于MM方法论的“集成战略与运营流”概念，把公司各种管理体系集成在一起。狭义的IPD流程实现了企业各部门在产品开发上的集成和协同，“集成战略与运营流”可以称为管理的“IPD”流程，把企业各功能部门的管理有机集成起来，包括战略、市场、研发、销售、服务、人力资源、财务、供应链、质量管理等体系，这个流程同时也是组织的绩效管理流程。
①决策评审（decisioncheckpoint，DCP）
项目任务书（charter）是研发项目的启动文档，是用于向干系人，尤其是投资方汇报项目概况、承诺目标，并获取资源承诺的关键性文档。对产品开发项目而言，把初始产品包业务计划书的核心内容提取出来，便形成项目目任务书，Charter必须回答6个关键问题：
（1）Why：为什么要开发这个产品？
（2）What：产品是什么？要满足客什么需求？
（3）Who：谁来开发产品？
（4）How：如何开发这个产品？
（5）When：开发计划是什么，何时上市？
（6）Howmuch：需要多少投资，收益是多少？
（1）越是不确定性的业务，越要进行规划，尤其是长期规划，但要随随时进行调整。否则产品开发只能是机会主义的。比如手机，看起来产品生命周期短，但如果自身没有核心技术，就很难保持长期竞争优势。
（2）产品和技术研发周期越长的业务，越要进行长期规划。比如飞机、乘用车、商用车、药品。
（3）投资越大的业务，越需要进行长期规划。比如乘用车产品。
华为把中长期规划称之为战略规划（SP），规划周期为5年，每年进行滚动。长期规划周期根据行业和企业的不同，可以自己定义，建议在3～10年间。业务计划（BP）周期为12个月，也要定期进行滚动。
（1）公司指最高层级的规划对象，可以是总公司、集团等。
（2）业务单元指隶属于公司的各项业务（从市场和客户角度看，主要是产品、服务、解决方案），可以是产品系列、产品线、事业部、子公司、分公司等。
（3）功能部门指按专业进行划分的公司和业务单元下属机构，包括但不限于：财务、质量、研发、售后服务、采购、制造、物流、市场、销售等部门。
从另一个角度来理解，在现代分工体系中，原本属于企业“内部事务”的工作绝大多数都可以外包，包括生产制造、销售、售后服务、行政事务、人力资源、IT、企业变革等，研发、采购、质量控制等也可外包给更为专业的机构。也就是说，以上这些工作都是“产品或服务”，都遵循同样的商业逻辑，都需要进行规划、开发、上市和生命周期管理，在企业内部构成一个“内部市场链”。但是，如若外部机构做得更好，从财务角度讲，应外包这些工作，但从外部采购这些服务需要的沟通和交易成本可能更高，根据诺贝尔奖获得者罗纳德·H.科斯的说法，这些交易成本是企业产生的理由，也决定了企业的规模。外包的基础是要做好前期规划。
在产品和技术规划过程中，识别各种技术非常重要，尤其在外包策略的选择上。核心技术和部分关键技术只有掌握在自己手上，才能构建核心竞争力（见图3-10）。（1）产品中的技术选择，尤其是核心技术和关键技术选择非常关键。诺基亚手机终端业务的迅速溃败和其软件技术平台的选择有直接关系。（2）技术选择决定产品的主要差异。（3）高科技企业必须掌握平台中的核心技术，才能构建核心竞争力。华为不断加大对海思半导体的投资，开发核心芯片，就是为了构建手机业务的核心竞争力。（4）核心技术和关键技术最好不要外包，这些往往是价值链中利润最高的环节。IBM因为没有抓住价值链中的CPU、操作系统等高利润环节，最终退出了自己亲自参与创建的PC行业。（5）服务于同一细分市场的产品平台数量必须严格受控。
根据客户需求开发产品，还是根据自己储备的核心技术开发产品，实质上就是我们常常说的产品研发是靠“需求拉动”还是靠“技术推动”。无论哪一种方式，最终都是客户需求拉动的。任何先进的技术，都必须解决客户问题，
IPD的核心思想之一“平台化开发”，强调在进行产品开发前把核心技术、关键技术和共用部分进行识别并突破，以确保产品开发周期和产品质量，同时尽量做到在同一产品线和不同产品线之间做到共享，也就是模块化或平台化开发。
“在我们未进入的一个全新领域进行产品开发，对公司已拥有的成熟技术以及可以向社会采购的技术利用率低于70%，新开发量高于30%，不仅不叫创新，反而是浪费，它只会提高开发成本，增加产品的不稳定性。凡是说‘我的项目全部都是我做的，未利用别人的成就’，这种人一定不能加薪。”
任正非强调，如果华为所有员工、上上下下都讲创新，就是华为的葬歌。华为的创新是70%的继承+30%的创造，创新不是推倒重来。在华为，坚决反对新官上任三把火，反对推倒重来，反对激烈的改革，华为提倡的是改良、改进、改善。
构建产品和技术平台有两种策略（见表3-4）：（1）分析现有产品，抽取其共用部分形成平台。这是面向过去的产品平台策略。（2）分析客户需求，尤其是中长期客户需求，在产品和技术规划过程中形成平台。这是面向未来的产品平台策略。
无论哪个行业，现在的顶尖公司都是昔日的创新者，无论产品创新还是
是商业模式创新，都或多或少采用了若干核心和关键技术，形成超越于其他竞争对手的平台，包括产品平台和运营平台。这些平台往往又会限制自己的进一步发展，尤其在行业快速变化期间。如不能从旧平台及时转换到新平台，就会面临灭顶之灾。日本整个电子行业以及柯达、摩托罗拉、诺基亚等莫不如此。
任正非早期的货架式开发思想主要强调如何利用以前的成果（Y模型的右侧）。IBM在与华为合作的IPD咨询项目中明确提出平台化是基于客户细分市场的共同需求，不同细分市场的共同需求可以用相同的产品特性、功能、模块、组件、技术来实现，这些形成了平台（Y模型的左侧）。经过10多年的发展，华为形成了自己独特的平台和技术管理架构（
结构化不能太多，也不能太少
通常认为，生产制造必须有严格的流程制度保障，对谁做什么、产出标准是什么等要事先进行严格规定，而战略和创新工作不需要有太多约束，否则会限制思路和创新。其实，这些过程都需要结构化，只是结构化的程度有所不同。
事实上，流程是对重复发生的业务的一种规律性总结，用以指导未来的活动。流程应结构化到什么程度，本身也有规律可循，
华为这样来评价MM给华为带来的转变：“MM是制定战略规划（SP）、业务计划（BP）、初始产品包项目任务书（charter）的方法论和流程，MM带来了市场领域规划思维和文化的转变。”不仅如此，MM方法论还应用于地区部（营销）和功能部门的SP和BP。
各层级规划的目的是要做到上下级目标对齐，不同部门目标对齐，且同时长中短期的目标要相互协调，所有这些活动都要以客户需求为中心。
大多数企业在规划上缺乏统一的方法论指导，导致不同产品线、不同细分市场、不同部门的规划难以整合，增加了沟通成本，难以保证规划的高质量。
MM为制订各层级业务计划提供了统一的方法论，包括公司战略规划（SP）、公司业务计划（BP）、产品线业务计划、细分市场业务计划、功能部门规划等。
MM方法论的核心逻辑是在充分了解客户需求和市场状况的前提下选定细分市场，在此基础上规划产品和解决方案，且同时要做好能力规划，确保可实施。\
基于MM方法论的ISOP（集成战略和运营流）集成了全公司的活动和管管理。
在进行产品规划的同时要进行平台和技术规划，为平台化开发和支撑中长期战略奠定基础。规划需要跨部门团队作战。
在跨部门团队作战过程中，公司、业务单元和职能部门的规划同时完成，且相互匹配。
与产品开发一样，战略与规划同样需要结构化流程支撑。结构化程度根据业务的不同而有所不同。
乔布斯在20世纪80年代中期离开苹果后，创立了NeXT。在这家公司，乔布斯酝酿了后来被称之为ANPP的流程（Applenewproductprocess，苹果新产品开发流程）。乔布斯1997年重返苹果后，大力推行这套流程体系。
据《乔纳森传》这本书的描述，ANPP由一张张巨大的工作检查表组成，它们详细地规定了不同部门和角色的员工在产品开发过程中应当承担的工作，以及完成这些工作后应当输出的文档。参与产品开发过程的部门和角色包括软件、硬件、制造、采购、财务、营销、售后、质量等等诸多环节。在ANPP流程中，从产品开发的最初阶段，就将顾客需求和市场竞争的需求考虑在内。对于苹果的产品而言，市场营销与设计工作一样，是同样重要的一环。
ANPP最大的特点是非常系统，除考虑到各个方面外，还把产品开发过程中的一切都详细无误地记录下来，这些记录下来的内容被苹果提炼为指南或指导手册，它们为新的开发团队和新员工提供帮助，避免走弯路。
方面1没有把研发作为项目进行管理
方面2开发流程结构化不足或过度结构化
上文提到化学品公司的案例中，该企业存在的另一个问题就是没有结构化的产品开发流程，具体表现在没有明确哪些角色和部门应当参与产品开发过程，什么时候参与，在其中做什么，输入和输出是什么。开发过程也没有进行阶段划分，过程中没有设置评审点（里程碑点），高层和技术专家只在开发结束的时候才介入进行评审，问题无法被及时发现。
方面3研发部门唱独角戏
产品是满足客户各方面需求（$APPEALS）的交付物/解决方案（O/S，offings/solutions），而不仅仅是提供功能、性能的实体，还包括产品的无形部分，比如品牌、易用性、服务等。并且，在满足客户需求的同时，还必须实现利润目标或其他战略目标。如果认同这个理念，产品开发就必然是跨部门的。
方面4决策层介入不当
国内很多企业高层对产品开发过程要么介入太多，要么介入太少，根源就在于产品开发流程中并没有明确他们应当在什么时候介入，以什么样的方式介入，介入做什么。而这些应当在流程设计中事先明确规定。
方面5部门经理和专家介入不当
方面6在产品开发过程中进行技术攻关
方面7创新过程缺乏一致的方法论
对企业而言，只要从事以前没有做过的业务都是一种创新，比如产品开发、技术开发、产品和技术的研究、新生产设备的开发等，公司引入一种新的管理方式也是创新。如果完成这些工作的流程制度没有一致的方法论作为指导，犹如规划工作缺乏统一方法论指导，会增加企业的管理和沟通成本。IPD作为一种创新方法论，可以为这些创新工作提供一致的方法论。
启动产品开发项目的前提是要清楚产品针对的目标客户群，知道应满足他们哪些核心需求，本公司是否已具备成功开发这个产品的各种条件，尤其是技术准备是否充分，或是否可以外包并进行有效的管理。
在大IPD体系中，产品开发流程的前导流程是产品规划（MM）和项目任务书开发流程（CDP），它们的输出就是IPD流程的输入。当项目任务书经过决策层评审后，启动产品开发过程，这个过程的终点就是产品成功上市，称之为GA（generalavailable，通用可获得性）点。
成功的产品有两个重要特点：满足客户需求和公司有利可图，两者缺一不可，且要同时考虑。第一点不满足，客户不会埋单；第二点不满足，公司不能长久经营。对于第二点，目标有多种，可能是获取利润，也可能是某种战略需要，比如：积累客户、建立客户黏性、树立品牌、阻击对手等。即便是“免费”的互联网产品，也有这两个重要特征。
华为IPD流程纷繁复杂，但在顶层设计上，两条主线清晰地表达了整个开发过程的逻辑（见图4-2）：从产品包需求到产品包交付这条线实现客户需求；产品包业务计划把各领域计划整合起来实现产品商业目标。
“在IPD全流程环节都要紧紧抓住两条主线，即IPMT（integratedportfoliomanagementteam，高层决策团队）、BMT（businessmanagementteam，业务管理团队）、SPDT（superproductdevelopmentteam，超级产品开发团队）、LMT（life-cyclemanagementteam，生命周期管理团队）和PDT（productdevelopmentteam，产品开发团队）一定要在每个决策点和全流程紧紧盯住产品包和O/SBP。每个评审点都要评审这两个方面的交付，生命周期管理也是继续围绕这两条主线开展工作。”
●概念（concept）阶段：蓝色，代表创造、自由、大海。概念阶段要充分发挥想象力，围绕客户需求构思尽可能多的创新方案，并确定最优方案。产品层面的创新主要发生在这个阶段，在这个阶段结束时，需求和产品概念就基线化了。
●计划（plan）阶段：绿色，代表精密、完美。计划阶段针对选定的方案开展系统设计和子系统设计工作，把需求分解，然后分配到系统设计中。这个阶段需要充分考虑方案的完整性。
●开发（development）阶段：橙色，代表努力、汗水、成果。开发阶段要把各个专业领域的计划付诸实施，完成各个子系统的开发和验证工作，并做完整的产品内外部测试，确保满足客户需求。
●量产（product）阶段：红色，代表热情、奔放。产品上市后进入量产阶段。这个阶段的特点是充分发挥运营体系的能力，尽可能多地生产和销售产品，为公司创造利润。
概念和计划阶段是IPD流程的核心
概念和计划阶段的工作质量决定了产品开发过程的质量和最终产品质量。概念阶段决定了产品能给客户提供哪些特性和功能，也就是满足客户哪些需求，以及总体方案是否具有创新性；计划阶段的工作决定了系统设计和子系统设计的水平，是否能完美实现概念阶段确定的系统方案。通过这两个阶段工作形成的产品包业务计划书决定了商业目标的实现方式。面对同一细分市场，产品只做简单优化调整的项目，这两个阶段的工作可以合并进行，但它们的工作性质截然不同。
（1）概念阶段投入不足，导致在没有明确客户需求之前就开始设计方案，并很快启动系统设计和概要设计工作。
（2）计划阶段投入不足，导致在没有明确系统设计和规格之前就启动具体开发工作，最终结果就是在开发过程中不断被需求和设计变更打断。
（3）到了验证和发布阶段，产品和技术问题纷纷暴露出来，不断进行修改，甚至导致产品在没有经过严格测试验证的情况下发给客户，客户现场成了实验室。
（4）研发以外的其他角色，如市场、销售、采购、制造等角色在概念和计划阶段基本没有参与，他们的需求没有纳入总体方案加以整体考虑。
（5）前期没有深入分析需求、技术难点和模块重复利用等问题，导致在产品开发过程中解决技术难题，由此也加长了研发周期。
一般把IPD流程中的角色或领域分为9类，分别是高层决策、项目管理、财务、质量、研发、采购、制造、市场、售后。对于复杂产品的开发，参与产品开发的角色会更加丰富，但还是纳入这9大角色中，只是进行分层，下一个层次叫作扩展组。除高层决策和项目管理以外的7大角色构成产品开发项目的核心组。角色划分不等同于组织结构设计。角色划分为产品开发流程确定一个框架，这个框架能够涵盖所有行业的情形。流程中的角色犹如电影中的角色，与角色的扮演者在“现实生活”中所担任的岗位无关。产品开发过程就是这些角色轮番或者同时上场的表演过程。这9类角色的划分是基于大量行业实践和经验的总结。不同行业、不同企业在应用时可以进行适当调整。
产品开发过程中，当环境发生变化对产品包业务计划带来重大影响，或必须提前发货时，需要进行临时决策评审（temporarydecisioncheckpoint，TDCP）。
决策评审必须做出明确的结论，且只有三个结论：
（1）继续（Go）：同意，可以继续开展项目，承诺提供下一阶段资源。
（2）重视项目（NoGo）：不同意，项目终止，释放资源。
（3）重新定向（Redirect）：重新定向，要求项目组根据高层评审意见对业务计划进行调整优化，重新进行决策评审。
需要特别指出的是，产品开发流程的“6个阶段，9个角色，5个DCP，7个TR”只是华为公司的实践，虽然15年来变化很小，但并不一定适合其他行业和企业。在构建企业自身产品开发流程时，可以参考，但未必照搬。
为确保产品包需求的完整性，以及产品概念、总体方案、系统设计和各子系统设计、部件和组件、最终的产品包能满足客户需求，在产品开发过程中，必须设置正式的评审点，通过这些评审点判断技术方案是否可行，识别潜在问题和风险。在业务计划书提交DCP决策前，需要各个领域和PDT内部预先进行评审，在进行TR前，各个技术领域也要预先进行技术评审，这些除DCP以外的评审我们统称为技术评审。技术评审是分层的，分为PDT级评审（PDTR，PDTreview）、领域级评审（X-departmentreview，XR）、产品级技术评审（technicalreview，TR）和技术领域级（sub-TR）。对应到功能和项目组结构中，就是先先通过下个层级的评审，再提交上一层级评审，它们之间的逻辑结构如图4-7所示。
与决策评审点的设置相比，产品层面的技术评审点设置具有更大的行业和产品特征，以下是一些供参考的原则：
（1）在决策评审点前必须设置技术评审点，只有通过技术评审才能提交高层决策评审。
（2）产品开发周期越长，TR应越多。两个评审点之间如果超过3个月，通常应增加TR。
（3）复杂和技术含量高的产品，应设置更多的TR。尤其是系列产品的第一个产品。
（4）涉及领域越多的产品，应设置更多的TR。比如汽车产品几乎涉及所有专业技术领域，需要在产品开发过程中设置比其他产品更多的TR。
DCP和TR也有诸多相似的地方，主要在评审流程上，尤其是评审会议必须精心设计，要点如下：
（1）会议质量决定了评审质量，有华为高层曾说，IPD的最大价值是教会了华为如何开会。
（3）评审会的目的主要是达成共识和识别潜在问题，尤其是跨部门问题，而不是在会上解决问题。
（4）会议一开始首先解决上次会议的遗留问题。
（5）无论是DCP还是TR，都必须使用评审要素表，以免遗漏检查项。
（7）会后贯彻会议结论，明确责任人，跟踪问题的解决。高层是否可以同时参加DCP和TR？答案是肯定的，同一岗位在IPD流程中承担多个角色色非常普遍，犹如一部戏中一人同时扮演两个甚至多个角色。需要注意的是，高层必须做到“在什么山上唱什么歌”，角色不能错位。在技术评审中，高层扮演的是技术专家角色，除高层需要具备相应专业技能外，还必须注意，作为专家提供的建议仅供项目组参考，否则就可能带走项目组的责任。
包括苹果在内的大量案例表明，高层是否介入技术评审甚至亲自上阵参与开发并不重要，关键在于高层是否在他所承担的角色上有相应的能力，为产品做出贡献。乔布斯作为苹果公司董事长兼CEO，虽身处高位，但他同时具备超越普通人的产品规划和定义能力，如果不充分利用他的这个长处是一种浪费。同时，库克深知他的优势在于公司运营，而不是产品设计，如果还像乔布斯那样，花费大量精力在产品细节上，不但做不好CEO，还会影响产品表现，对苹果公司反倒是一种灾难。
（1）高层决策：决策评审，资源管理，组合管理。
（2）项目管理：业务计划书，项目计划和管理。
（3）财务：目标成本管理，研发费用管理，项目赢利分析。
（4）质量：产品质量策划与控制，过程质量策划与控制。
（5）研发：研发领域的子流程最多，且不同行业和不同产品差别很大。比如通信/IT行业一般包括技术评审、SE（系统工程）、UCD（以客户为中心的设计）、软件、硬件、结构、工艺、测试、资料、包装等领域的子流程。
（6）采购：新物料认证，新供应商认证。
（7）制造：制造策略和计划，订单履行策略和计划，新产品试制和导入。
（8）售后：售后服务策略和计划，售后服务成本预测。
（9）市场营销：需求探索和管理，市场分析，市场营销策略和计划，早期发货管理，上市管理，生命周期管理。
解决方案是满足特定细分市场客户需求的一种交付形式，本身也是一种产品。如果说解决方案和部件产品有什么“本质区别”，那就是解决方案一般由多个部分构成，这些组成部分可以自己开发，也可以来自合作方，包括有形的实体产品和无形的服务，其中有些部分可以独立销售，叫作构成解决方案的部件产品。
（1）要求不仅需要单个部件产品的架构和设计，还要有一个整体方案的系统架构和网络设计。
（2）要求不仅对单个部件提供产品、服务、全球培训、客户支持，还要对整个网络设计提供产品、服务、全球培训、客户支持。
（3）要求在解决方案网络环境中充分测试所有的部件和业务。
（4）要求不仅提供针对单个部件的文档，还要提供针对整体网络的文档。
从华为对解决方案的定义可以看出，解决方案本身是一个极其复杂的开发对象，既要进行整个方案系统层次的开发工作，也要进行部件产品层次的开发工作，两个层面都包括架构设计和系统设计、培训、客户支持、测试、文档等。这就需要有一个整合的解决方案开发流程把这些工作纳入一个整体进行考虑。而本章讨论的IPD流程天然具备这个潜质。解决方案中的部件产品，在逻辑上就是产品中的子系统，除了称谓之外“本质上”没有太多不同。把握住这点，就很容易把IPD流程应用在解决方案的开发上。
IPD方法论可应用在不同的创新领域，包括产品开发、解决方案开发、定制项目开发、技术开发、产品/技术研究、变革项目实施等。
结构化的研发流程是过程质量和结果质量的保障。
IPD产品开发流程起始于项目任务书（charter）获得批准，终止于产品生命周期结束（endoflife，EOL）或经过评审的项目终止。产品开发项目在GA点结束。
一般说来，共有9个角色（含团队）参与产品开发过程，分别是高层决策团队（IPMT）、产品开发团队经理（leaderofPDT，LPDT）、财务代表、质量代表、市场代表、研发代表、采购代表、制造代表、技术服务代表等。其他参与角色可纳入这些角色的外围组。
IPD流程可分为6个阶段，分别是概念、计划、开发、验证、发布、生命周期管理。每个阶段都有明确的目标、输入和输出。
业务评审和技术评审相分离。IPD流程在商业计划线设有决策评审点（DCP），高层在这这些决策点判断是否继续投资该项目，项目的商业风险在这条线得到收敛和控制。
IPD流程在“产品需求实现线”设有技术评审点（TR），各领域代表和专家在TR点评审需求是否完整、产品是否满足需求、是否能够大批量供货等，技术风险在这条线得到收敛和控制。只有通过TR才能进行DCP。
无论产品规划还是产品开发，乃至企业的全部经营活动，都要以客户需求为中心，这已成为企业共识。但如何对需求进行有效管理却没有引起足够重视：有的企业缺乏有效方法探索和收集客户需求，有的企业不知道如何判断需求的真伪，有的企业面对众多需求难以取舍……
与此同时，大量企业问题就出在过度“以客户需求为中心”。为了满足同一细分市场不同客户的需求，有针对性地开发了大量产品，但每一款产品的销量却很少。这些产品看似相似，却又有所不同，为了开发和管理这些数量众多的产品，企业付出了高昂的研发和运营费用。
缺乏完整的需求定义和描述框架
错误地认为需求是创造出来的
持有这种观点的人一般同时会认同：需求是由技术推动的。没有互联网技术，人们就不不会有上网的需求；LED、液晶、等离子技术没有成熟前，大个头的CRT电视足够了，人们没有看平板电视的需求；没有数码成像技术前，我们小心翼翼地用胶卷拍照，不也自得其乐？胶片和传统照相机没有发明前，我们的先辈哪有照相的需求？不过，在没有这些技术前，人类真的就没有沟通、娱乐和拍照的需求吗？只是在不同的时代，满足需求的方式和方法不同。相反，胶片时代的王者柯达公司发明了数码照相技术，却反被数码技术打败。在需求满足上，技术推动不是万能的，关键是如何利用技术。
不能“无节制、无底线”地满足客户需求
在需求管理上对企业的要求就是要针对细分市场的共同需求，而不是特定需求进行研发，在客户订单到来时，最好是现有产品就能满足，或者做尽可能小的改动就能够满足，这样就会节省大量研发费用和供应链成本，这是一个从“行商”到“坐商”的转变，从“小公司”到“大公司”的转变。
长中短期需求分布不合理
不能以产品为中心而非以需求为中心经营企业
需求的分层描述：需求＝问题＋解决方案
需求是产品的约束条件，包括功能需求、非功能需求、DFX（designforX，X代表procurement、manufacture、assembly、environment、……）等，也就是“需求=问题+解决方案”。要分层描述需求，包括客户问题、系统特性、系统需求和各层之间的跟踪关系。如第1章所述，针对产品的完整需求描述，也叫产品包需求，有时也称为“包需求”。完整的产品包需求其实就是对产品本身的详细描述。
用一致的框架完整描述客户需求
构建完整的客户需求框架是市场与需求调研、需求管理、产品规划和产品开发的基础工作。每个维度的需求还需要进一步细化，最终构建客户需求描述的分层结构，
（1）华为的商业模式是什么？
（2）华为成功的秘诀是什么？
（3）华为的价值观是什么？任正非对这三个问题的回答是统一的：
（1）满足客户需求是我们生存的唯一理由。
（2）我们的商业模式是以客户需求为导向。
为了在公司范围内统一管理需求，最佳的做法是通过一致的渠道提交需求。为提高效率和减少出错，可构建公司统一的需求管理IT平台。
为了让需求信息完整全面，各种渠道得到和提交的需求应当按照统一的格式进行描述，通常包括以下要素：
（1）需求名称，需求编号和关键字，便于检索。
（2）需求类别，根据$APPEALS进行分类。
（3）需求的详细描述，重点包括：背景和场景，需求原因，带来的好处。
（4）竞争对手情况，即：对手是否实现了需求？实现得如何？
（5）需求重要程度，可用KANO模型①进行分析。
（6）客户反馈。
（7）需求如何验收？……
以上针对特定细分市场的客户需求信息形成细分市场的原始需求。
需求分析：对原始需求进行加工提炼
需求分配：产品规划的核心工作
需求早期确认：对于重要的产品和解决方案，要求产品开发团队（PDT）的关键成员在概念和计划阶段与客户面对面沟通，以确保正确理解客户需求。
需求团队参与技术评审：需求分析团队（requirementanalysisteam，RAT）参与产品开发过程中的技术评审（TR），跟踪需求实现过程，确保客户最初的“所需所想”最终在产品中得以实现。
例行的需求确认：需求团队和地区部的营销部门定期（比如每月）与产品开发团队确认大量处于开发状态的需求的执行情况，而不仅仅是在TR或产品交付时集中确认。
需求的常规确认：产品开发团队通过实验局（Beta测试）等活动，收集客户意见，完善产品，确保产品满足客户需求。
需求管理需要团队作战
产品线需求管理团队（productlinerequirementmanagementteam，PL-RMT）是产品线需求管理业务的驱动者和日常管理的执行者，负责产品线需求管理流程、方法和工具的推行，产品线需求的分发和管理监控，以及需求管理人员的技能提升。PL-RMT代表本产品线负责跨产品线需求的协调。
满足客户需求是企业存在的理由，从这个意义上讲企业就是“需求加工机”，但大量企业并没有把需求作为一个管理对象，并建立需求管理体系。
企业在需求管理上的问题主要表现在缺乏需求定义和描述框架、错误地认为需求是创造出来的、过度满足客户特定需求而无法平台化开发产品、长中短期需求分布不合理、以产品和技术为中心而不是以需求为中心经营企业。
构建需求的分层定义（问题+特性+系统需求+跟踪关系）和完整的客户需求描述框架（$APPEALS）是需求管理的基础工作。
建立需求管理体系要从4个方面入手：建立需求管理流程、需求变更控制流程、需求管理组织和需求质量管理体系。
需求管理流程分为需求收集、需求分析、需求分配、需求实现和需求验证5个阶段。其中，需求收集和分析阶段是关键，需求分配是产品规划的核心工作，需求实现和验证通常在研发过程中实现。
为了确保最终交付的产品和解决方案满足需求，必须对需求进行端到端的跟踪；当需求发生变化，或设计变更和工程变更影响需求时，必须启动需求变更流程。
质量从本质上讲是需求的实现程度，质量管理首先要确保需求本身的高质量，需求质量管理应当成为公司质量管理体系建设的核心内容之一。
几乎所有创新和研发工作都是以项目方式开展的，如果说在创新上做得好的企业有什么共同点或“独门绝技”，那就是：相对其他企业，项目开展得更好。本书前面提到的所有理念、方法和工具，只有融入具体项目，达成项目目标，才能为企业创造价值。从这个意义上讲，项目管理是创新和研发管理的“临门一脚”。单个项目的成功有偶然性，但要持续打造成功的项目，需要构建一套适合企业的研发项目管理方法。
研发项目管理是一个管理体系
虽然这些项目的目标和研发内容不同，但是它们有很多共同点：
（1）每个子项目都在开发一个需要移交给客户或其他领域的交付物（含服务）。
（2）需要跨部门合作，组成跨部门团队完成任务。
（3）均需要和最终的商业目标对齐。
（4）产品开发过程中需要考虑客户需求、质量、成本等。
根据公司产品规划，启动B产品的项目任务书（charter）开发工作。在成立项目任务书开发团队（charterdevelopmentteam，CDT）时，研发部门指派后续可能承担该项目研发领域项目经理的小王参与该项工作。
B产品项目任务书通过高层决策团队（IPMT）评审后，研发部门召开项目启动会议，成立B产品研发项目，小张担任项目经理。由于小张在前期的深度参与，充分理解了客户需求、商业目标和整体商业计划，使研发域项目目标和产品开发项目目标非常一致，对研发资源的需求预算非常准确，研发项目开展非常顺利，并最终取得成功。
华为产品开发团队（PDT）是一个虚拟组织，其成员来自7个领域：市场、研发、财务、采购、制造、售后、质量。在一个PDT内部，有多个项目同时开展，称之为版本，针对每个版本设置版本经理。
“以客户为中心，长期坚持艰苦奋斗和自我批判”被包括任正非在内的华为高层认为是华为成功的最核心要素。这些价值观不仅仅体现在管理层的宣誓、民主生活会、绩效考核上，还渗入了每个研发项目中。
很多项目经理在出现问题后首先找员工的问题，这在华为是被明令禁止的。华为的自我批判是一个从上到下的过程，首先管理者应当从管理上做自我批判，再要求员工做自我批判。
研发项目管理案例
●背景●
作为职业化的项目经理，杰克有过硬的技术背景和十年项目管理经验，被总公司委派到子公司，掌管一项投资额超过8000万元的重大项目A，公司希望通过此项目培养一批项目管理人才。
刘强是子公司自己培养的项目经理，从硬件经理转岗项目经理2年，表现不错，刚被晋升为中级项目经理。刘强对公司的组织结构和A项目非常了解，本次作为杰克的助理共同承接A项目。
●项目立项阶段●
干系人沟通
识别关键路径
深度介入周边项目
杰克重新找到小张，把Y项目的项目计划、项目风险清单从头到尾和他沟通了一整天，最后小张面带悦色地从杰克办公室出来，明确表示Y平台项目进度可以压缩2个月，支持A项目的市场进度。刘强狠踹了小张一脚，抱怨说前几天怎么死活不答应，是不是得到杰克什么好处。小张只是笑笑，闭口不谈。
●项目概念阶段●
专家坐镇，防患于未然
有了架构专家坐镇，具体设计工作的重担便放在了系统设计师身上。在概念阶段，杰克把握项目整体管理，刘强则把精力放在项目概要计划和项目团队资源的获取方面。刘强费了九牛二虎之力，从各个职能部门经理那里协调到所需项目成员，由于项目预算的限制，并不是每个成员的专业程度都符合项目要求。概念阶段开工会后，杰克拍拍刘强的肩膀，交给他一份方案评审会的名单，上面有技术服务专家、制造专家、采购专家、测试专家、维护专家，让刘强按名单组织会议。评审会上，杰克引导大家，对架构专家提出的方案从技术可行性、可服务要求、可制造要求、以往测试易重犯的问题、器件采购资源等因素多方面考虑，提出风险与预防建议。会上，各个领域专家获得空前的尊重，大家讨论非常激烈，针对产品需求包，对不同的方案进行了分析比较。项目团队成员在这个会上受益良多，刘强也感觉到以前项目中常出现的问题在这个会上基本都提到了，一下子明白杰克如此安排会议的意义。在概念阶段发挥专家的集体智慧，防患于未然，是弥补团队能力不足的最有效方法。
计划不是用于汇报的，而是用来指导工作
刘强针对前期研讨会的会议纪要，一面回顾，一面修订计划。2天后，杰克拿着刘强修订的计划，露出了笑容。按照新的计划，各项工作有序地开展，概念阶段以针对实现设计方案相匹配的各类问题讨论为主，整个过程中，跨部门会议、沟通成了主题曲。刘强充分认识到，概念阶段对方案讨论的充分性和完整性是管理控制的关键。
●项目计划阶段●
计划要抓住重点，分层分级
项目通过概念阶段评审后进入计划阶段，这个阶段会议非常多，会议主题从方案的讨论转变为系统设计、概要设计及各种计划的讨论，经历了概念阶段计划不到位的教训，刘强对计划的工作投入了十二分的精力。
在此之前，刘强还认为自己是做项目管理，尤其是做项目计划的高手，但和杰克比起来，还是有很大差距，他做了反思和总结：
（1）计划要经过充分讨论和沟通。做计划时，要充分考虑每项工作涉及的项目组成员和部门，一定要让这些人一起参与，才能减少变化和反复。
（2）计划要分层分级。虽说每个阶段都要做计划，但计划的颗粒度（详细程度）和侧重点在各个阶段是不同的。
●项目开发阶段●
做好风险和问题管理
进入开发阶段后，项目团队成员逐步增加，在阶段开工会上，刘强给大家介绍了项目的核心价值、明确了项目目标，团队成员积极讨论了项目过程中可能遇到的困难及解决方案。团队成员士气高昂，刘强感到不再只是主管和骨干，而是一个团队在共同努力。
在刘强的经验中，这个阶段是可以歇歇的，因为具体事情由开发和测试人员去做，自己的任务就是管控进度。
做好自我管理
有块印制电路板（PCB）下周就要返回，杰克要求大家核查单板PCB返回后立即贴片有什么风险。硬件经理突然提出，供应商无法提供样片，采购翻查了关键器件采购清单，发现是之前疏漏了。通过与供应商交涉，厂家最快3周以后才能提供5块芯片，这意味着项目整体进度将延迟3周。杰克让刘强、硬件经理、采购经理留下，其他人先散会。散会前，他再次强调：“项目团队的每一个成员，都应对照计划，检查自己工作的准备和完成情况，要做好自我管理，这是对一个职业人士的基本要求。这个问题由会后留下来的人处理，其他成员回去后再次确认计划和风险。”在散会后的小会上，杰克严厉批评了硬件经理和采购经理，要求他们针对公司核心价值观进行深刻的自我反省，并拿出解决方案。
这个项目因为无谓的等待要拖延3周，12月上市的目标难以达成，大家都有些失落，回去后对照计划分别检查各自负责的部分。从此，团队成员对计划和风险、问题等异常警觉，逐渐形成了每天对照计划和跟踪表的习惯。
不拘一格，特事特办
在进度压力下，刘强也跟着大家每周都为风险规避、问题解决、计划变更而协调奔波。在开发阶段的后半段，杰克又协调了售后维护团队的2个成员参与到产品开发过程中，以便维护人员早期熟悉产品，顺利进行后期的移交。
●项目验证阶段●
早期充分策划，后期“坐享其成”
优势互补，艰苦奋斗是一种幸福
虽然前期和客户已经进行了多次交流，规避了大部分风险，但客户验证是否最终成功，还有赖于很多因素。为此，杰克让一线客户经理和产品经理参加例会。因为是海外客户，语言交流成了大问题。团队一般工程师的英文水平还没有达到顺畅交流的程度，大部分是中国式英语。在很多会议上，杰克除了管理项目，还充当翻译。大家很佩服杰克流利的英语，杰克很谦虚，认为优秀的项目团队就是要优势互补，每个人都有自己的所长。作为项目成员之一，他能在项目中发挥自己的作用，就是一种幸福。
由于时差原因，和客户的会议经常在凌晨召开，没多久，项目团队成员就被大家戏称为“功夫熊猫”。其他项目组对熬出黑眼圈的A项目成员纷纷表示敬佩。
策划在先，风险不再可怕
虽然大家都很努力，但刘强最担心的意外还是出现了。客户经理突然反馈，客户运营策略有所调整，取消了对T特性的验证。T特性虽然重要，但使用概率不高，很难在短期内找到其他测试客户。刘强在风险预测中已经考虑到这个问题，当时的风险规避措施是在某单板上预留验证接口，以便转为内部验证。得知客户运营政策调整后，杰克和刘强立即召集市场人员、系统工程师（SE）、软/硬件经理、测试经理、售后、工程代表，按照预定的风险响应规规避措施，调整了验证计划。
T特性在售后、维护人员的参与下，完成了所有的内部验证工作，整个验证阶段没有任何延误。外局验证也顺利拿下了客户出具的《验证通过证书》，项目团队成员看着通过的验证报告，心情都非常激动。
按照转维护计划，转维护工作也有条不紊地进行着，杰克定期与维护团队成员沟通，一起检查转维护标准的达成情况，针对问题，及时采取措施解决，到验证阶段结束时，大部分转维护标准都已达成，只剩下几个遗留问题，准备在发布阶段彻底解决。
●项目发布/移交阶段●
关怀项目组成员
验证阶段结束后，大部分项目成员将回到职能部门，承接新的任务。在这离别之际，大家都有些依依不舍，离开前大家纷纷表示希望有机会再与杰克和刘强合作，这种心情，刘强很能理解，他的确感受到包括自己在内的项目成员在杰克的带领下成长了不少。在杰克指导下，大家对项目管理也有了更深的认识。
剩下的项目成员主要负责解决遗留问题和移交资料，以及总结经验教训等工作，同时也开始考虑自己下一步的去向。杰克特别强调了后续移交阶段的重要性，并让刘强和大家再次确认具体计划，明确具体工作内容。杰克认为，移交工作就是把接口部门的兄弟们扶上马、送一程，只要有一项工作没有做好移交，团队就不能解散。
杰克非常关心团队解散后成员的去向。针对每一个团队成员，杰克都会亲自和他们的职能部门主管沟通，反馈其在团队的绩效表现，商讨下一步工作安排。随后，他将这些信息和团队成员沟通，让大家吃定心丸。
每一步安排都是有远见的
●项目关闭阶段●
不断总结，持续改进
刘强作为项目助理，也将与杰克合作8个月的项目管理经验进行了总结：
（1）项目经理最核心的工作就是计划，计划的好坏，直接影响执行力，这也是项目经理管理能力的体现。
（3）在项目最危急关头，项目经理要挺身而出，为项目力挽狂澜。比如，杰克为了了让芯片及时到位，动用老关系，并“铤而走险”。
（4）对依赖关系采取更加积极主动的策略。对于关键依赖，可以直接介入具体项目计划的管理，而不是被动等待。比如，杰克主动介入小张负责的Y平台项目，使该项目工期压缩2个月，对两个项目来说都是双赢。
（5）风险和问题管理，一定要激发群体智慧。任何个人都不是圣人，总有疏漏之处，缺陷要靠大家一起弥补。
（6）不要害怕项目中的变化。提前预防、及早部署是根本的解决办法。
（7）巧用项目各阶段开工会，抓住成员的心，确保每一个项目成员都完全领会项目目标及要求，确保项目的所有细节工作都能完全到位，保证项目成功。
这些都是刘强的心里话，评委认为总结得很实在，某委员说，刘强这半年多成长非常快！评审会在欢笑声中结束。
结项评审通过后，项目的评审纪要、决议以及被认可的项目经验教训总结都提交到公司IT平台。此后，A项目的管理经验成为点击率最高的经验总结文档之一。在随后的三年里，A项目交付的产品是公司最具竞争力的产品之一。但最具竞争力的，还是逐步成长起来的一个个能打硬仗的项目经理。
企业在研发项目管理中的典型问题包括：没有把项目管理方法引入研发领域，用流程管理代替项目管理，没有用一致的方法管理各种类型的研发项目，重视对事的管理而忽略对人的管理，没有项目群和项目组合管理概念，没有围绕商业目标和客户关键需求开展项目，没有把项目作为一个整体进行管理。
从广义上讲，任何研发项目产出的成果都是为客户或下游环节服务，都是一种“产品”，项目生命周期都可以遵循IPD方法论和流程。这样做的好处还在于，在组织内部可以让不同的研发项目之间便于沟通交流，提高运作效率。项目生命周期中包括3大流程：项目指导流程、项项目管理流程和项目执行流程。
公司价值观和文化只有转化为项目组共同认可的文化，才能在产品管理和研发领域落地。为此，RDPM框架特别增加了项目文化部分。
规模优势：全世界所有商学院都教学生说，一个巨大的规模优势是成本会沿着所谓的经验曲线下降。那些受到资本主义的激励和想要改善生产的人们只要加大产量，就能够让复杂的生产变得更有效率。规模优势理论的本质是，你生产的商品越多，你就能更好地生产这种商品。那是个巨大的优势。它跟商业的成败有很大的关系。
大多数小公司都希望发展壮大，以发挥规模优势。但是，规模大了又难以像小公司那样灵活应对客户需求和市场竞争。是不是有一种有效的组织方式，既能发挥大公司的规模优势，又能像小公司那样灵活、高效运作呢？
答案是肯定的，精心设计的矩阵组织就是唯一的解决方案（不是“之一”！）。但是，很多企业在不充分了解这种组织方式的情况下开展变革工作，导致阻力重重，不能取得预期效果，过早宣告“矩阵组织不适合本公司”，再次回到职能制，或者事业部制、项目制的组织方式。
业务流程告诉我们应当如何做事，流程中的角色要和组织中的部门和岗位对应起来，并明确这些角色之间的关系，流程才能良好运作。这些工作统称为组织和人力资源工作。
这样的抱怨司空见惯：产品表现不好，研发部会认为营销部没卖好；而营销部会抱怨产品设计得太差，生产成本高根本没法卖；供应链会认为质量和成本的80%以上都是在研发阶段决定的，供应链的职责是负责采购、制造、发货……
IPD体系对技术评审和业务决策评审进行严格区分，清晰定义了各层级管理者和员工在创新中的角色，尤其是管理者。高层可以根据自身的背景和职责定位，按照体系要求在产品和技术创新过程中承担相应角色。
管理大师德鲁克说，管理是否有效最终要靠结果来检验。
义：“矩阵结构，采用这种结构，组织就像不用再从若干分组方式中单选一样，而是可以同时选择多种。”说白了，矩阵结构就是让“鱼与熊掌可以兼得”。但是这样一来，组织中就形成了双重权力结构。所以矩阵结构牺牲了统一指挥原则。
程，在肯定成绩的同时，也指出了变革的方向：进一步开展跨部门流程建设，提高流程的集成度，让公司所有部门都围绕端到端流程来运作，为客户创造价值。
跨部门团队作为专业部门和跨部门流程之间的纽带，是IPD体系成功运作的关键。跨部门团队与职能部门的设置和建设一样，都属于能力建设，并最终服务于业务。在IPD体系中，最重要和最基础的跨部门团队是决策团队、规划团队和开发团队，其他团队都可以认为是在这3个团队基础上的延展，本节将重点介绍这3个团队。这3个团队在组织中的位置如图7-4所示。
（1）高层决策团队（IPMT），集成组合管理团队。
（2）规划团队（PMT），组合管理团队。
（3）产品开发团队，IPD体系中称之为PDT。
IPD体系建议高层在产品开发中承担的角色是商业决策，并且是集体决策。如果高层同时在技术方面具备相应的评审能力，则可以在技术评审过程中发挥作用，把两者进行清晰划分，这样有助于不同的角色各司其职。
IPD体系中的高层决策团队（IPMT）是一个集成组合管理团队，它是一个由各领域高层组成的正式的跨部门团队，根据其决策层级的不同，可分为公司级、产品线级、子产品线级等。IPMT主任由该业务层级的第一责任人承担，成员由各个职能领域高层组成，必须涵盖7大功能领域：财务、质量、研发、售后、采购、制造、营销，并可根据决策会议的需要增加成员。
无论哪个层级的IPMT，这些职责是共同的：
●确定价值观、使命、愿景、目标和战略路径。
●审批中长期战略规划、年度业务计划、预算和产品路标规划等。
●确保各领域规划与整体业务计划保持一致。
●确定市场、产品和资源的投资优先级。
●MM、CDP和IPD中的决策评审和重大变更审批。
●通过各领域资源建设，为跨部门团队提供合格资源。
●对跨部门团队的绩效表现进行管理。
IPMT的打造是IPD体系成功运作的最重要因素。IPMT成员即是资源建设的责任人，同时又是业务成果的责任人，在PMT和PDT运作中的大部分问题都可以在IPMT中找到缩影，某种种程度上可以说规划团队和执行团队中的问题是IPMT团队问题的映射。比如，PDT的成功运作特别强调跨职能领域的合作，PDT成员在IPMT中都有其对应的直接或间接上级，如果IPMT团队成员不能在跨部门合作上做出表率，而是像很多企业那样，高层之间“相互拆台”，PDT团队内部的合作就大打折扣。跨部门流程从表面上是解决了产品开发中部门工作的衔接问题，但是研发工作的跨领域和必须频繁沟通等特点决定了团队建设和流程建设同等重要。
IPMT在行使决策权的同时，必须深知其权力基础在于已在规划和研发过程中解决了本领域问题，必须在各个方面对PMT和PDT提供支持（见图7-6）。同时，IPMT作为一个跨部门高层团队，其成员在进行产品方面的决策时，必须超越本领域，从业务和公司角度审视产品线和产品包业务计划。
IPMT的业务决策主要通过规划和研发过程中的DCP会议（决策评审会议）来进行，这些会议的会前准备、开会过程和会后跟踪质量决定了决策评审的质量。
●打造跨部门规划团队PMT●
战略规划和产品规划谁来做？一般有四种情况：
（1）最高层亲自做规划：由最高层亲自确定公司方向、战略、市场和产品规划，甚至亲自做各职能领域规划，各部门和员工执行。
（2）高层团队做规划：老板和高层团队一起制定战略，确定方向，进行产品规划。部门规划主要由各分管领导完成，高层之间相互协调各种规划。
（3）规划部门做规划：公司成立企划部、战略规划部、产品规划部等负责制定规划，由专人做调研和分析工作，规划成为一种职能。各部门也可能成立专职规划部门从事规划工作，比如技术规划、人力资源规划、生产规划等。规划报高层审批后执行。
（4）跨部门团队做规划：规划部门牵头成立正式的跨部门规划团队（PMT），以团队方式运作规划流程，各部门同时完成部门规划，确保各部门规划之间的相互支撑和匹配。规划报高层审批后执行。
PMT做好产品规划和产品定义，经过IPMT审核通过后，就由PDT团队来执行产品开发工工作。PDT是一个对产品的市场和财务成功负责的跨部门团队，其工作起始于项目任务书（charter），终止于GA。
在IPD体系中，特别强调PDT必须是一个完整的跨部门团队，一般说来，这个团队包括LPDT（产品开发团队经理）和7大领域（产品质量、财务、市场、研发、采购、制造、售后），这8个角色构成PDT的核心组。对于小型和初创型公司，PDT核心组一人承担多个角色是常见的，但对于中大型公司，最好把这些必要的角色单独配置和专职化，并由相应的职能部门来承担。
很多公司的IPD变革之所以失败或远远没有达到预期，主要原因在于组织能力和业务流程要求之间的不匹配。
以专业分工为基础的职能制容易导致各部门“各自为政”，缺乏端到端的责任人为产品研发的最终结果负责。同时，按产品和项目分工的组织方式容易导致“各自为战”，不能共享资源，不能充分发挥公司规模优势。
组织结构设计必须在面对市场的灵活性和强调资源共享带来的僵化之间取得平衡，由此，矩阵结构是大多数企业可以采取的组织方式，但它是不稳定的。
跨部门流程需要跨部门团队的支撑，跨部门团队需要资源部门的支撑。创新型组织要有效运作，必须处理好专业分工与跨部门合作之间的关系。
跨部门团队和资源部门各司其职是IPD体系运作的组织基础。跨部门团队为业务成果负责，资源部门为跨部门团队提供足够的合格资源。
跨部门决策团队（比如IPMT）、跨部门规划团队（比如PMT）和跨部门执行团队（比如PDT）是IPD体系中最典型的三类跨部门团队。
IPMT是公司或产品线的业务决策机构，IPD变革要取得成功，IPMT成员必须起到表率作用。
PMT是公司或产品线的参谋机构，必须按规范的流程方法开展战略规划和产品规划与定义工作，提交IPMT评审。
PDT是跨部门产品开发团队，对产品的市场和财务成功负责，资源部门支撑PDT运作。
绩效是指组织、团队或个人，在一定的资源、条件和环境下，完成任务的出色程度，是对目标实现程度及达成效率的衡量与反馈。
绩就是业绩，体现企业的利润目标
效就是效率。
很多企业的解决方案是建立一套科学、量化的考核机制对研发工作进行精确衡量，据此考核研发人员，考核结果与薪酬直接挂钩，以确保结果的客观公正。
很多企业想通过绩效考核调动研发人员的积极性，却往往事与愿违，反而降低了员工的积极性，为什么会出现如此南辕北辙的结果呢？
这是管理者需要深入考虑的问题，作为管理者决不能粗暴地用自私、没有大局观来解释员工的行为。只有把组织目标和个人目标有机结合起来，才能真正调动员工工作积极性。
研发人员的主导需求是什么？调查结果表明：个人成长、物质报酬、尊重与自我实现是最重要的3大需求。
完整的绩效管理过程包括绩效目标和计划、绩效执行和辅导、绩效沟通和评价以及考核结果应用4个阶段。过度而片面地强调绩效考核带来的结果就是把其他3个环节忽略了，尤其是前面两个环节。
也许在很多主管心目中，中国社会的物质发展水平不如西方，研发人员的主导需求还处于马斯洛需求层次中的低层次阶段，也就是生理需求和安全需求，所以物质激励是主要的，这个观点难以被证实，同时也难以被证伪。可以肯定的是，在实践中我们要针对员工的不同需求采取不同的激励措施。
●指标过多导致抓不住重点●
所以，设置哪些指标，需要结合企业和员工个人的情况。
华为轮值CEO徐直军认为：绩效管理整体上要促进生产力的发展，而不是制约生产力的发展，且不是要高成本。站在管理者角度来讲，绩效管理就是要让你的下属都愿意跟你一起干。
通用电气董事长杰克·韦尔奇认为：绩效管理的最终目标并非仅使员工达到期望的绩效，而是使他们愿意付出超越职责的努力。
IBM公司认为：绩效管理的根本目的是为了引导并激励员工贡献于组织的战略目标，同时实现组织和个人的共同成长，它不是绩效考核，而是一个管理过程。
（1）绩效管理是将公司的使命、愿景、目标、战略、业务、资源有机地结合起来所构成的一个完整的管理体系。
（2）绩效管理是管理者和员工双方就目标及如何达到目标形成共识，并促成员工成功达成目标的管理方法。
绩效可以应用在奖金、工资、股权激励等物质激励中，也可应用在培训、晋升（承担更多机会）、任职资格等非物质激励中。但是这些应用对象一般是由很多因素综合决定的，绩效可能并不是最重要的因素（
绩效管理是一个包括目标制定、执行与辅导、绩效评价、绩效沟通四个部分的完整过程，绩效评价只是其中最不增值的一个环节。沟通贯穿于整个绩效管理过程。
研发工作和人员的特点决定了研发绩效管理有其特殊性，正确理解研发绩效、研发绩效管理和员工激励的概念是基础，不能照搬供应链和营销体系的绩效管理方法。
在绩效管理的各个环节都可以激励员工，赫茨伯格双因素理论中的激励因子主要在绩效管理过程中起作用，而不是等到绩效考核结果出来后。
没有基于结构化流程的量化衡量体系做支撑的量化考核不但不能提高研发人员的积极性，还会带来副作用。
绩效衡量、员工考核结果和报酬之间的强挂钩会改变工作的原动力，甚至会引导员工提出较低的绩效目标。
绩效目标分解为指标的过程中要注意是否“失真”，实现目标的不同方法对应不同的指标。
绩效评价结果的当面沟通非常重要，上下级双方均需要充分准备，贯彻“不惊讶”原则。
绩效结果有多方面应用，但要避免绩效主义，绩效不能决定所有的物质和非物质激励要素。
最高层亲自参与、推动并全力支持IPD的实施是成功的关键。最高层特指公司董事长或总经理。华为的IPD如果不是任正非亲自发起并推动，绝对不会成功。
很多企业的IPD变革由研发、市场或质量管理部门发起，最高层往往认为由这些部门牵头就行了。一些企业虽由最高层发起，但项目一旦启动就交给下面执行，自己就不理不问了。
IPD变革涉及各大主要部门，需要改变很多习以为常的工作方式，有赖于各部门的深入参与与全力配合，要做到这些自然会有阻力，这些阻力会伴随变革过程的始终，一旦各部门感觉到最高层对IPD的态度是犹豫不决，在遇到阻力就会退缩，最终回到原来的老路上。
IPD强调产品研发必须跨部门作战，但大量企业在IPD实施中还是以研发、市场为主，其他部门根本不参与或参与极少，导致其他部门不清楚在产品研发过程中应当扮演的角色，为体系实施埋下隐患。
中国改革开放的成功经验之一就是先在特区进行试点，成功后再逐步推广。这点在管理变革中也极其重要，尤其对那些产品种类繁多、规模很大的企业。试点可以验证体系是否适合本企业，同时培养员工能力。
成功的IPD变革将缩短产品开发周期、提高研发效率、提升产品质量，但是这些产出需要足够的投入支撑。很多企业在对变革的产出寄予厚望的同时，大大低估了需要的投入，这也是造成变革失败的原因。
最高层无条件全力支持
我们坚持认为，要发挥IPD的威力，除了研发，更多是非研发部门的深度参与。这些领域在IPD项目中和研发领域同等重要，不分伯仲，犹如在PDT项目组中一样。他们不能仅仅在项目启动和结束时象征性参与，而是全程都要深度参与。IPD中的“I”（integrated）中文含义是“集成”，在这里体现得淋漓尽致，只要有一个领域被落下，效果就会大打折扣。
和其他领域变革不同，IPD变革是企业涉及面最广的变革，需要各领域深度卷入，这对变变革引导者提出非常高的要求，除掌握IPD知识和IPD实施经验，还要具备一定的各领域专业知识，否则难以和功能部门进行有效沟通。
如何选择咨询公司？与其说选公司，还不如说选人。一些大咨询公司顾问很多，但对IPD有足够理解的顾问极少。在选择咨询公司时，一定要明确是哪些顾问参与项目，对顾问进行背景调查，面试通过后要在条款中明确要求顾问公司不能“调包”。
无论由外部顾问还是内部顾问来引导变革，一经选定，管理层就必须给予顾问充分信任，对顾问不应有任何置疑，至少绝对不能在公开场合置疑顾问，一旦员工对顾问的信任度下降，对顾问传递的知识也将产生怀疑，最终影响变革质量。
IPD变革，也就是体系在企业的导入，也是产品、服务或者叫作解决方案。对咨询公司而言很好理解，咨询公司的服务不是引入IPD知识，而是帮助企业按IPD的模式改进和优化管理流程，提高管理效率。
我们把中小型企业定义为营业额在10亿元人民币以下，或者研发体系人员（指参与产品研发的人员，不等于研发部门员工）不超过200人的企业。这类企业大量存在于各行各业，往往是细分领域的领头羊。它们有自主品牌和产品，有产品研发的成功经验，但往往没有把规划和需求作为一项职能来建设，不一定有专职的市场和需求管理人员。
中型企业大致指营业规模在10亿～100亿元，或者研发体系人员在200～1000人的企业。这类企业在需求管理、产品规划和产品研发等方面的各项职能相对完整。它们在其所在领域有相当的话语权，管理体系也相对完善。
●通信和IT设备●
这些所谓高科技产品非常复杂，大多数属于B2B（企业对企业）业务，客户采购这些产品的目的要么用于运营（运营商），要么用于提高生产效率（行业和企业客户），或者是两者的结合（用于内部运营）。这些产品往往以解决方案的方式提供给客户，所以还包括大量的服务。这要求供应商要深入理解客户及客户的客户的需求，并把全球各地的需求进行提炼，以平台化的方式开发产品和服务，否则研发成本会很高。在这个行业的公司要尽可能影响行业标准和客户需求。企业也必须这么做，否则在激烈的竞争中就会处于被动局面。
IPD体系思想和方法论适合各行各业不同规模的企业。但IPD是否能真正发挥作用，关键在体系导入的过程，也就是变革管理过程，导入过程中要考虑企业的行业和规模等特征。
国内企业在IPD实施中的3大典型问题是：最高层领导重视程度和投入不够、信心不足，整个企业缺乏足够的变革紧迫感，只有研发、市场等个别角色参与变革过程。
IPD实施中的其他问题还表现在：没有经过试点就进行全面推广实施，盲目学习标杆，过度追求完美，试图一次完成过多的变革，变革的投入不足。
要成功实施IPD变革，必须把变革过程作为一个项目来管理。
无论是否有外部顾问参与，体系导入本身都可以作为一个服务产品开发过程来对待，用IPD方法论来导入IPD。这分为六个阶段：变革规划和项目任务书，概念阶段，计划阶段，开发阶段，验证阶段，推广阶段。
IPD的实施必须考虑公司的规模，不同规模的公司拥有的资源不同，中小型企业不能照搬华为、IBM等的做法。
IPD适用于所有行业，但在实施过程中需要考虑不同行业的特点。
研发是投资行为
在IPD的7大核心思想中，“研发是投资行为”和“基于需求的研发”又最为核心。这两大核心对应了管理体系中所有流程的两条主线：实现组织的商业目标和满足客户需求，两者缺一不可。要实现公司商业目标，在需求管理、规划、研发、项目管理、组织能力建设、绩效管理和管理变革过程中都必须考虑投资收益。
基于需求的开发
华为总裁任正非多次强调，华为的商业模式就是以客户需求为中心。对商业组织而言，获取投资收益的方法归根结底只有一个，就是满足客户需求。从这个意义上讲，企业是一部“需求加工机”。在IPD管理体系的7大组件中，必须贯彻“以客户需求为中心”的思想。
平台化开发
结构化流程
产品和技术创新过程有规律可循，IPD体系中的各种流程被划分为若干阶段，在每个阶段设置了评审点。同时，每个阶段都需要若干部门和角色参与，这些角色构成跨部门团队。结构化流程就是在吸收提取业界优秀实践的基础上，明确规定创新要经过哪些阶段，在每个阶段每个角色需要完成哪些工作，输入输出及其标准是什么，与周边如何协作。
跨部门协作
战略与业务特征决定组织和人力资源管理方式，不同部门间靠接力棒式的串行工作方式无法高质量满足客户需求，所以，在IPD体系中，无论是需求管理、产品和技术规划、项目任务书开发、产品和技术研发、产品上市，还是产品上市后的生命周期管理，都广泛采用跨部门团队形成“核心小组”，汇集各个领域的专业智慧，形成合力，共同满足客户需求，为项目的商业成功负责。为此，各个功能部门“退到幕后”，为这些跨部门团队提供资源和支撑。同时，公司的企业文化、绩效管理和激励机制也要支撑跨部门团队的运作。
业务和能力均衡
在客户需求多样化，产品生命周期越来越短的时代，无论多有竞争力的产品，终有生命周期结束之时。所以，企业必须在业务发展的同时构建不断推出新产品组织能力。业务发展和内部能力建设是一对相互支撑的矛盾。业务的快速发展可以促进能力提升，但单独进行能力构建也是必需的，“磨刀不误砍柴工”。在企业发展的不同阶段，可以有策略、有选择地把重心放在业务发展或能力构建上。
灵活发展，与时俱进。
IPD不是一套固化的流程、制度、表单和组织模式，它的核心思想和7大组成部分必须根据外界环境的变化不断发展，吸取业界最新的管理理论和最佳实践。这些使得华为目前运行的IPD与当年IBM顾问指导下引入的IPD已经有非常大的不同。
IPD体系的7大核心思想和7大组成部分不是一一对应的关系，而是一种相互渗透的“矩阵关系”。
管理体系是核心思想的载体，每个核心思想只有融入IPD管理体系的7大组成部分，“思想”才能落地。
IPD体系的每个组成部分只有贯彻7大核心思想，管理体系才有“灵魂”。
IPD体系的威力就在于把7大核心思想有机融合在一起，解决了长期困扰企业的产品创新和研发管理难题。
管理体系不是固化的，但核心思想往往是长期不变的。
在引入IPD体系前，华为与绝大多数中国企业一样，业务流程都是基于职能部门的，每个部门都认为自己的流程很重要，所以核心业务流程非常多。从1999年引入IPD产品开发流程（小IPD）开始，华为学会了从客户角度思考公司的主业务流程。
（1）后天的客户：是否提前考虑到未来客户的需求，并为此做好产品和技术方面的准备。这个流程就是IPD。
（2）明天的客户：对于已经有现实需求的客户，需求是否可以迅速得到满足。这个流程是LTC（机会点到回款）。
（3）现有客户：对于已经购买产品的客户，当产品出现问题和故障时，是如何得到服务的？就是ITR。
流程管理部门，运营管理体系。
在变革过程中，华为深刻认识到，必须转变之前“以技术推动产品，客户被动接受产品”的做法，将客户和市场的需求作为产品开发的原动力。在满足需求的同时，华为还要实现作为一个商业机构的投资目标。所以，华为的IPD体系构建在两个最基本的核心思想之上：
（1）市场需求是产品开发的驱动力。
（2）产品开发要作为投资来管理。
华为强调：在射击场上先瞄准，再射击，没有瞄准的射击毫无意义。在开发产品前就要确定需求和产品概念。
在推行过程中，华为通过3个方面“IPD的主要理念”的建设让IPD最基本的两大核心思想落地（
（1）做正确的事：市场管理、业务策略。
（2）正确地做事：需求管理、结构化流程、跨部门团队、技术开发、项目管理、系统工程、管道管理。
（3）支撑基础：IT使能器/工具、技能、衡量标准。
华为从2002年开始在公司全面推行IPD体系中的产品开发流程，同时开始建设其他流程和管理体系。其中市场管理流程（MM，通常也称为产品规划流程）和需求管理流程（RM）是最重要的两个流程，加上IPD产品开发流程，被称为“IPD的3大流程”（见图11-5）。在IPD体系发展过程中，在这“3大流程”基础上，不断衍生出很多其他流程，最重要的是战略规划、技术规划和技术开发流程，加上需求管理、产品规划、产品开发，被称为IPD的“6大模块”。
市场管理（MM）流程是确保华为“做正确的事”的核心方法论和流程，是IPD产品开发流程的上游流程。
MM流程的输入是：市场信息、客户反馈、竞争对手信息、技术趋势、现有产品组合等，通过理解市场、市场细分、组合分析、制定/融合业务战略和计划，形成组合策略和路标规规划。在管理业务计划和评估绩效阶段，通过项目任务书（charter）启动IPD流程
MM为公司战略规划（SP）、业务计划（BP）、产品路标规划、技术和平台规划、项目任务书开发、职能部门规划等提供了一致的方法论。在华为流程体系发展过程中，曾把战略规划、产品规划和技术规划并列作为IPD体系的“6大模块”之三，可见其重要性。
需求管理流程（RM）作为支撑流程为MM和IPD提供输入，让市场管理流程、产品路标规划和产品开发“瞄准靶心”。
需求管理流程分为收集、分析、分配、实现和验证5个阶段，如图11-7所示。其中需求收集、分析、分配主要在产品规划、项目任务书（charter）开发（很多企业也叫产品定义）、IPD流程的概念阶段进行，实现和验证阶段流程主要在IPD产品开发流程中实现，所以，需求管理流程和MM流程、IPD产品开发流程是并行的。
实际上，无论是否有公司层面的独立需求管理流程，MM和IPD流程都需要进行需求的收集、分析等工作，从这个意义上说需求管理流程是MM和IPD的支撑流程。
华为公司的独特之处是在集团公司、3大业务群、各个产品线、子产品线分层分级统一建设端到端的需求管理流程，把来自各方面的需求汇集起来进行统一管理，让它们“无处可逃”，实现以客户为中心。
微观的IPD指的就是IPD产品开发流程，简称“IPD流程”，在华为也叫“小IPD”。IPD流程的起点是项目任务书（charter），终点是产品上市结束（GA）。相对MM流程，IPD流程结构化程度更高。华为的IPD流程分为概念、计划、开发、验证、发布和生命周期管理6个阶段。
IPD流程强调按投资决策标准对产品开发进行分阶段评审。华为的IPD流程共设置了5个决策评审点（DCP）。
（1）项目任务书（charter）DCP，简称charterDCP。
（2）概念（concept）DCP，简称CDCP。
（3）计划（plan）DCP，简称PDCP。
（4）可获得性（available）DCP，简称ADCP。
（5）生命周期终止（lifeend）DCP，简称LDCP。DCP是基于投资的决策，DCP的评审材料准备由PDT准备，IPMT做决策。
为了确保产品交付质量符合客户需求，华为设置了7个TR，TR是由PDT内部组织的针对产品包成熟度的评审。
IPMT和PDT两个团队是产品开发流程的“主角”，IPMT负责对产品投资进行决策，PDTPDT负责具体的产品开发。
在华为IPD体系推行过程中，已把IPD抽象提炼为一种创新方法论，不仅应用在产品开发过程，还拓展到技术研发、变革管理、项目管理等领域中。
在华为，用IPD管理体系来保障流程的有效运作。IPD管理体系除了包含前面提到的业务流程外，还包括：
（2）度量（metrics）与考核。度量指标用于衡量流程运作质量。华为针对所有流程、子流程分别制定了衡量指标。部分流程度量指标用于员工考核，通过绩效管理和激励机制，强化行为规范。
（3）技术管理体系。通过业务的分层分级管理，构建各层级的通用构建模块（CBB），提高产品开发效率。
（4）技能提升。构建支撑IPD体系运作的个人技能，包括管理和领导能力、沟通交流能力等。
（5）IT工具。构建支撑IPD体系运作的各种信息系统。
如果狭义的IPD方法论实现了各个功能部门在产品开发上的集成与协同，战略运营流则是管理的“IPD流程”，把各个功能部门（战略、市场、产品与解决方案体系、销售与服务、供应链、HR、财经、质量等）的管理实现了有机集成与协同。同时，这个流程也是组织的绩效管理流程。
BAT，Baidu，Alibaba，Tencent，百度，阿里巴巴，腾讯。
BB，buildingblock，组件。BG，businessgroup，业务群。
BLM，businessleadershipmodel，业务领先模型。
BMT，businessmanagementteam，业务管理团队。
BP，businessplanning，业务计划。
CB，capabilitybaseline，能力基线。
CBB，commonbuildingblock，通用构建模块。
CDP，charterdevelopmentprocess，项目任务书开发流程。
charter，项目任务书。
checklist，评审要素表。
CDT，charterdevelopmentteam，项目任务书开发团队。
CRM，customerrelationshipmanagement，客户关系管理。
CP，checkpoint，检查点。
C-PMT，corporateportfoliomanagementteam，公司组合管理团队。
C-RMT，corporaterequirementmanagementteam，公司需求管理团队。
C-TMT，corporatetechnologymanagementteam，公司技术管理团队。
DCP，decisioncheckpoint，决策评审点。
DRR，deploymentreadinessreview，推行准备度评审点。
E2E，endtoend，端到端。
EOL，endoflife，生命周期结束。
ESP，earlysupportplan，早期客户支持计划。
GA，generalavailable，通用可获得性。
IFS，integratedfinancialsystem，集成财务转型。
IPD，integratedproductdevelopment，集成产品开发。
IPMT，integratedportfoliomanagementteam，高层决策团队。
IRB，investmentreviewboard，投资评审委员会。
ISC，integratedsupplychain，集成供应链。
ISOP，integratedstrategy&operationprocess，集成战略与运营流。
ITMT，integratedtechnologymanagementteam，集成技术管理团队。
ITR，issuetoresolution，从问题到解决。
JIT，justintime，准时制。
LMT，life-cyclemanagementteam，生命周期管理团队。
LPDT，leaderofPDT，产品开发团队经理。
LTC，leadtocash，从销售线索到回款。
MM，marketmanagement，市场管理。
MOT，momentoftruth，关键时刻。
MP，marketingplanning，市场规划。
ODM，originaldesignmanufacture，原始设计制造商。
OEM，originalequipmentmanufacture，原始设备生产商。
O/S，offerings/solutions，交付物/解决方案。
OR，offeringsrequirement，产品包需求。
PACE，productandcycle-timeexcellent，产品及周期优化法。
PBC，personalbusinesscommitment，个人绩效承诺。
PDM，productdatamanagement，产品数据管理。
PDT，productdevelopmentteam，产品开发团队。
PLM，productlife-cyclemanagement，产品生命周期管理。
PL-IPMT，productlineintegratedportfoliomanagementteam，产品线集成组合管理团队。
PL-LMT，productlinelife-cyclemanagementteam，产品线生命周期管理团队。
PL-PMT，productlineportfoliomanagementteam，产品线组合管理团队。
PL-RAT，productlinerequirementanalysisteam，产品线需求分析团队。
PL-RMT，productlinerequirementmanagementteam，产品线需求管理团队。
PL-TMT，productlinetechnologymanagementteam，产品线技术管理团队。
PMBOK，projectmanagementbodyofknowledge，项目管理知识体系。
PMI，ProjectManagementInstitute，美国项目管理协会。
PMOP，programmanagementoperationprocess，变革项目管理运作流程。
PMT，portfoliomanagementteam，组合管理团队。
productroadmap，产品路标。
PROPS，theprojectforprojectsteering，指导项目运作的项目。
PRR，pilotreadinessreview，试点准备度评审点。
PRT，productresearchteam，产品预研团队。
PSST，productsandsolutionsstaffteam，产品和解决方案体系。
PTIM，product&technologyinnovationmanagement，产品技术创新管理。
QMS，qualitymanagementsystem，质量管理体系。
RAT，requirementanalysisteam，需求分析团队。
RDPM，R&Dprojectmanagement，研发项目管理。
RM，requirementmanagement，需求管理。
RMT，requirementmanagementteam，需求管理团队。
RP，roadmapplanning，产品路标规划。
SDCP，selectionDCP，决策选择评审点。
SDT，solutiondevolopmentteam，解决方案开发团队。
SE，systemengineer，系统工程师。
SP，strategyplanning，战略规划。
SPDT，superproductdevelopmentteam，超级产品开发团队。
S-PMT，solutionportfoliomanagementteam，解决方案组合管理团队。
systemrequirement，系统需求。
TDCP，temporarydecisioncheckpoint，临时决策评审。
TDT，technologydevelopmentteam，技术开发团队。
TMG，technologymanagementgroup，技术管理组。
TMS，technologymanagementsystem，技术管理体系。
TMT，technologymanagementteam，技术管理团队。
TPD，technology&platformdevelopment，技术开发。
TPM，transformationprogressmetrics，变革进展评估。
TPP，technology&platformplanning，技术和平台规划。
TR，technologyreview，技术评审。
TRT，technologyresearchteam，技术研究团队。
WWPMM，worldwideprojectmanagementmethods，全球项目管理方法。