虽然任正非从来不认为华为已经成功了（他认为华为只是暂时没有失败）。
管理体系是否有效，要和企业所处行业、历史、规模、人员结构、外部环境等相吻合，
黑格尔说，人类最大的教训就是人类从来没有从历史上吸取教训。
IPD（integrated product development，集成产品开发）
我们学的方法是IBM的。IBM教会了我们怎么爬树，我们爬到树上就摘到了苹果。我们的老师主要是IBM。”
说：“创造力就是连接……连接生命中的各种体验，然后把把它们组合成一种新的东西。”
向榜样和标杆学习，采用业界成熟的管理体系，是企业提高创新和研发管理水平的重要方法，但在如何学习上不少企业走了弯路，其中的一个原因就是引入过多的管理体系让管理者和员工无所适从。华为过去10多年的实践为我们指明了一条如何学习榜样的有效路径。这条路就是持之以恒地模仿、跟随、固化、优化一套经过验证的管理体系，结合企业特点不断向深度发展，然后超越，最终形成自己的管理体系。
这家企业出身卑微，没有显赫背景，在老套的价值观（以客户为中心+艰苦奋斗+自我批判）的带领下从2万元起家，在竞争异常激烈的通信市场用20年时间进入世界500强。
在歌功颂德的同时，也以寻找华为公司和任正非的破绽为己任，当任正非说要追求利润的时候，他们说这个和互联网精神不符合，互联网精神要的是烧钱买流量，小米、京东、BAT一开始都不追求利润，最终才有利润；当华为任正非说要科学管理，管理要规范化，化，向“蓝血十杰”和西方管理持续学习的时候，他们说任正非老了，跟不上时代的发展，华为因为管理太僵化已经遭遇“创新者的窘境”，快要步诺基亚、摩托罗拉、北电网络等的后尘了;当任正非说要艰苦奋斗、加班加点奉献（尤其是管理层）的时候，他们说这不符合80、90后的需求；当任正非说要坚持自我批判的时候，他们说这是什么年代了，现在年轻人要的是个性、自我，这样才能创新；当任正非说要以客户需求为中心、围绕客户需求创新的时候，他们说客户不知道客户需求是什么，乔布斯从来不做市场调研……
任正非曾多次强调，华为没有什么秘密，取得一些成绩在于20多年持续坚守一些常识，那就是：以客户为中心，坚持自我批判和艰苦奋斗，长期坚持压强原则，只做一件事（通信设备）。轮值CEO徐直军强调，华为的成功，一是利益分享机制，通过股权稀释让大部分员工成为华为股东，分享经营利润；二是持续坚持自我批判和艰苦奋斗的企业文化。最高层强调的这些要素，华为在2009年以核心价值观的形式进行了固化，在6大核心价值观中，成就客户、艰苦奋斗、自我批判位列前三。
总结下来，除了上面提到的“官方”认可的全员持股、以客户为中心、艰苦奋斗、自我批判以外，主要集中在几个方面：（1）压强原则。（2）创新与研发。（3）市场营销能力。（4）低成本优势，尤其是研发低成本。（5）管理体系和IT。另外，还有作者总结为外部市场环境，比如中国通信市场高速发展、固定汇率带来的海外市场低成本优势等。
华为CEO用这个比喻来强调跨部门流程的重要性。
华为有多少个跨部门流程？从满足客户需求角度，华为只有3个流程
（1）IPD流程（Leads To Cash）：各层级和各领域战略规划、需求管理、产品规划、项目任务书开发、产品开发、上市、生命周期管理。
（3）ITR（issue to resolution，从问题到解决）流程：包括从客户问题产生到最终得到解决的流程。
LTC即L2C,Leads To Cash,从线索到现金的企业运营管理思想，华为的LTC流[4]程也深入的应用了这一思想[5]，L2Cplat是这一思想的践行者。是以企业的营销和研发两大运营核心为主线，贯穿企业运营全部流程，深度融合了移动互联、SaaS技术、大数据与企业运营智慧，旨在打造一个从市场、线索、销售、研发、项目、交付、现金到服务的闭环平台型生态运营系统.
（3）ITR（issue to resolution，从问题到解决）流程：包括从客户问题产生到最终得到解决的流程。
华为在流程建设方面，首先从方法论上确定了规则，即“流程的核心是要反映业务的本质，还原以后，该是谁的就是谁的。”
然后，针对三大业务流，建立对应的三个系统，即IPD（产品集成开发）、LTC（机会至收款）、ITR（售后），同时用流程IT的方式进行固化。这样就可以避免“前面一段说日语，中间说德语，后面说汉语”、“各段都是李云龙”的问题。大部分企业都可以参照梳理成这三大业务流。
最后，在“以客户为中心”的理论指导下，进行组织配置，包括责任人、考核方式等。保证瞎子能共同拼出一头真正的大象。
一个公司就三件大事：
●第一件把产品开发出来，产品从有概念开始，到面市；
●第二件是把产品变现，要有客户买，形成订单，发货、安装、验收、回款；
●只有上帝做的东西才没问题，当时没问题，时间长了也有问题：客户有这样那样的需求，产品要不断地改进升级。因此，有了第三件事情，网上有问题，发生了，就要解决，然后关闭。某代表处的问题解决了叫“解决”，全球此类问题都根治了才叫“关闭”！
这三件事情对应三大业务流，这三大业务流有起始终止，对应三个系统（IPD/LTC/ITR），还要有相应的组织去适配（不仅是流程IT），也要和客户去匹配，很多订单要和客户去对接。
日复一日，年复一年，简单、海量、重复的工作怎么去做更好？就是先要把它流程化，模板化，固化下来，最后采用IT支撑。公司三大业务流，日复一日，一年运行下来，就形成了公司的业绩：财务三张表。
业务就上面的三件大事，流程要匹配业务流，不长也不短，够用就行。其核心是：流程要反映业务的本质，尤其是完整系统地反映业务的本质。业务中的各关键要素及其管理不要在流程体系外循环。基于流程建设的管理体系（IPD/LTC/ITR），是一个运营系统，是一个业务操作系统（BusinessOperationSystem），其中最重要的是落实到组织中，就是流程化的组织建设和运作。
产品是满足需求的交付物的总和，包括有形部分和无形部分。为了强化这点，IPD体系用offerings来替代产品这个概念，中文翻译为“产品包”，是对客户和下游环节所有交付的统称。
产品包需求（offerings requirement，OR）就是对原始需求进行分析、判断和加工后，最终向客户（包括外部客户和内部客户）交付的需求，是对产品包的正式描述，完整且准确，是对产品包进行开发、验证、销售、交付的依据。
（1） 开发（development）：开发是创新性活动，目的是在企业有盈余的前提下满足市场和客户需求。
（2） 产品（product）：产品是满足客户所有需求（$APPEALS）的提供物的总和，也就是前面定义的产品包（offerings），包括有形部分和无形部分。
（3） 集成（integrated）：IPD的威力体现在“集成”上。首先，IPD集成了若干中有效的工具、方法和流程。其次，IPD把企业内各资源部门通过跨部门团队的方式集成在一起，共同完成规划和研发工作，满足客户需求。最后，也是最重要的一点是：IPD集成了若干重要的思想，这些思想是IPD的核心。
所以，IPD是基于市场和客户需求驱动的规划和开发管理体系。其核心是由来自市场、研发、制造、服务、采购等方面的人员组成的跨部门团队共同管理整个规划和开发过程，即从客户需求、产品规划、任务书开发、概念形成、产品开发、上市，直到生命周期的完整过程。通过IPD管理体系，使产品开发更加关注客户需求，加快市场响应速度，缩短产品开发周期，减少报废项目，降低开发成本，提高产品的稳定性、可生产性、可服务性等。
可以从3个不同视角来定义IPD：
（1） 狭义IPD：也叫“小IPD”，指的就是新产品开发。
（2） 中观IPD：包括产品开发（狭义IPD）、市场管理及产品规划（market management，MM）和需求管理（requirement management，RM），3大流程共同构成产品创新管理体系。
（3） 宏观IPD：也叫“大IPD”。这种概念下的IPD指的是端到端产品管理体系，甚至可以延伸到公司管理体系（当我们拓展产品的定义，谁还认为公司经营不是产品经营呢？）。除中观IPD范围外，宏观IPD还包括技术和平台规划（technology＆platform planning，TPP）、技术开发（technology＆platform development，TPD）、产品生生命周期管理（product life-cycle management，PLM），以及支撑它们的组织体系和绩效激励体系。
IPD是关键！我们必须更加规范地开发产品；在开始便考虑市场情报和客户需求；在开始阶段就确定所需资源；根据里程碑管理；只在里程碑变更需求和项目方向，因此我们不会不断地修补项目。整个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已经有非常大的不同。
PTIM（product&technology innovation management，产品技术创新管理）体系，就来源于华为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（project management body of knowledge，项目管理知识体系）和业界最佳实践的基础上，制定了RDPM（R&D project management，研发项目管理）框架。RDPM创新性地把各种管理方法和工具集成在一起，为研发项目保驾护航，
组成6绩效与激励：绝不让雷锋吃亏
组织和流程让大家在同一平台上工作，解决了谁来做事、如何做事的问题，但要让员工充满工作激情，需要做的工作还有很多。首先，需要对绩效进行有效的测量。犹如行驶中的飞机和汽车需要仪表盘，IPD体系也需要一个“管理仪表盘”，对需求、规划、研发、项目管理、组织和流程运作状况等进行测量，让组织和个人随时知晓所处的状态。其次，要把公司、各产品线和各部门的目标转化为个人目标，使组织目标和个人目标“对齐”。上级主管要帮助下级达成个人目标，在整个过程中要和员工保持持续沟通，对员工进行物质和非物质激励，满足员工多方面的需求，而不仅仅是对员工实施“考核”。
组成7管理变革与优化
把思想融入管理体系：七七四十九
IPD体系的7大核心思想是：研发是投资行为；基于需求的研发；平台化开发；跨部门协作；结构化流程；业务和能力的均衡；灵活发展，与时俱进。企业可围绕7大核心思想，不拘泥于任何形式构建产品和技术创新管理体系。
IPD体系的7大组成部分：基于MM的规划，基于IPD的创新，以客户需求为中心，矩阵组织，研发项目管理，绩效与激励，管理变革与优化。
从逻辑顺序看，企业经营应当是“战略—产品规划—产品开发—生产—销售—服务”，也就是图3-1中的从左到右，但大部分中国企业的关注重点和能力构建是从右到左进行的。
制造和销售关注的是今天如何生存，研发关注的是明天如何生存，但是企业需要研发什么技术和产品，是规划需要解决的问题，我们称之为后天的生存。
制造可以用OEM方式式外包，销售可以交给批发商和零售商，或者通过电商渠道销售，产品研发可以委托给设计公司或者用ODM+OEM①的方式外包。企业究竟应当进入什么市场？提供什么产品？这些产品如何进行定义？企业内部应当构建什么能力？这些问题无法外包。虽然咨询领域有大量提供战略咨询的公司，但这些咨询服务还是以单个项目的方式开展的，不会深入到产品路标规划和具体产品定义。所以，企业必须具备市场管理、产品规划和产品定义等方面的能力。
OEM（original equipment manufacture，原始设备生产商），ODM（original design manufacture，原始设计制造商）。
大部分企业没有把各层级战略、策略和行动计划的制订（也就规划过程）作为一个体系来管理，缺乏一致的规划方法论和流程，没有组织和人力资源保障。最终即便有各层级书面计划（plan），却没有规划过程（planning），导致难以做到公司行动一致，也就是不能做到“四个对齐”：
（1） 上下对齐：高层、中层和基层的对齐。
（2） 左右对齐：不同产品线和部门之间的对齐。
（3） 长中短期对齐：长期规划（3年以上）、中期规划（1～3年）和短期规划（年度计划）的对齐。
（4） 外部对齐：整个公司的计划要能满足客户和市场需求，适应外部环境变化。
大部分企业没有把各层级战略、策略和行动计划的制订（也就规划过程）作为一个体系来管理，缺乏一致的规划方法论和流程，没有组织和人力资源保障。最终即便有各层级书面计划（plan），却没有规划过程（planning），导致难以做到公司行动一致，也就是不能做到“四个对齐”：（1）上下对齐：高层、中层和基层的对齐。（2）左右对齐：不同产品线和部门之间的对齐。（3）长中短期对齐：长期规划（3年以上）、中期规划（1～3年）和短期规划（年度计划）的对齐。（4）外部对齐：整个公司的计划要能满足客户和市场需求，适应外部环境变化。
规划的输入不明确
没有基于市场需求进行产品规划
产品路标从哪里来？这个看起来简单的问题，在实际操作过程中，往往被企业忽视。很多企业在进行产品规划时并没有从市场分析、客户需求出发，而是直接进行产品规划，更多地是从目前现有的产品出发进行规划，过度考虑自身的现状。这样的做法忽视了外部宏观环境、行业竞争格局、技术发展趋势、市场状况、客户需求等因素，导致产品规划没有以市场和客户需求为根基。结果是：要么创新过少，要么创新无法满足客户需求。
规划在无谓的试错中形成
这种现象在国内企业普遍存在。企业在发展过程中，针对现有客户需求和竞争压力开发了很多产品，但成功率在逐逐步降低。这些企业的现有产品格局是在被动响应和试错中形成的，而不是经过自觉的、规范的规划过程产生。结果是，虽然有一些产品成功了（如果企业还没有倒闭），但也为此付出了惨痛的代价，表现出来就是在“成功”的同时也有大量产品不成功。当企业发展到一定阶段，这种运作方式将大大增加经营风险。
各领域规划割裂，未转化为组织的一致行动
公司到达一定规模后，“部门墙”就会产生，如果不在管理体系和文化上刻意去克服和避免，必然会成为公司发展的障碍。部门墙产生的原因之一就是各部门的目标和行动不一致，我们称之为“左右”没有对齐。
没有考虑平台和技术规划
规划中的问题还表现在产品规划和平台规划、技术规划相割裂，没有充分考虑各个产品之间、产品线之间的技术共同点，没有形成产品平台和技术平台，难以形成技术壁垒。结果是企业开发了很多产品，但这些产品没有形成系列。产品做了很多，但是技术积累很少，每次开发新产品都要从头做起，研发成本高，产品上市速度慢，质量也得不到保证。证。同时，因为产品之间差异性很大，导致供应链成本、销售成本和后期维护成本升高。
孙子曰：“上下同欲者胜。”
企业要在竞争中取胜，上下级之间目标要一致，部门之间目标要一致，长期、中期、短期目标要一致，这些目标要和外部环境的变化保持一致，华为称之为“上下对齐，左右对齐”。
MM方法论通过一系列流程来运作，把相关工具融入其中。它运用严格、规范的方法分析市场走势、业务要求及需求，创建合理的市场细分规则，对要投资和取得领先地位的细分市场进行选择和优先级排序，从而制订可执行的业务计划，驱动新产品的开发和各领域活动，并闭环管理业务计划。严格执行MM流程可使各项举措成功付诸实施。完整的方法论包括6个步骤：理解市场，细分市场，组合分析，制订业务计划，融合和优化业务计划，管理和评估业务计划（
MM方法论围绕这些关键问题展开：
（1）价值观、使命、愿景、目标分别是什么？
（2）为谁服务，也就是选择哪些细分市场？
（3）战略路径（业务设计）和业务计划是什么？
（4）要满足细分市场客户的哪些需求？
（5）为目标客户提供什么产品、服务或解决方案？
（6）需要构建哪些能力？如何构建？
（7）各领域策略和行动计划是什么？
（8）如何实现业务计划的闭环管理？
（1）在明确使命、愿景和目标的基础上，确定要服务的对象及其需求。
（2）确定用什么交付（产品/服务/解决方案）来满足这些需求。
（3）确定在采取哪些行动/构建哪些能力来提供这些交付。
（4）对规划过程进行闭环管理和评估。
战略就是定位、取舍和匹配，MM方法论和这个观点是非常一致的。
（1）定位：确定企业为哪些客户提供哪些区别于竞争对手的独特产品和服务。
（2）取舍：明确哪些事情是要做的和不做的，尤其明确哪些是不做的。
（3）匹配：各个领域的活动支撑战略定位，并且相互匹配和加强。
ISOP（integrated strategy&operation process，集成战略与运营流）就是以MM方法论为基础，统一管理企业的战略规划和各种运营活动及其管理体系的流程框架。
战略和运营同等重要。华为经过多年的实践摸索，提出基于MM方法论的“集成战略与运营流”概念，把公司各种管理体系集成在一起。狭义的IPD流程实现了企业各部门在产品开发上的集成和协同，“集成战略与运营流”可以称为管理的“IPD”流程，把企业各功能部门的管理有机集成起来，包括战略、市场、研发、销售、服务、人力资源、财务、供应链、质量管理等体系，这个流程同时也是组织的绩效管理流程。
①决策评审（decision check point，DCP）
项目任务书（charter）是研发项目的启动文档，是用于向干系人，尤其是投资方汇报项目概况、承诺目标，并获取资源承诺的关键性文档。对产品开发项目而言，把初始产品包业务计划书的核心内容提取出来，便形成项目目任务书，Charter必须回答6个关键问题：
（1）Why：为什么要开发这个产品？
（2）What：产品是什么？要满足客什么需求？
（3）Who：谁来开发产品？
（4）How：如何开发这个产品？
（5）When：开发计划是什么，何时上市？
（6）How much：需要多少投资，收益是多少？
（1）越是不确定性的业务，越要进行规划，尤其是长期规划，但要随随时进行调整。否则产品开发只能是机会主义的。比如手机，看起来产品生命周期短，但如果自身没有核心技术，就很难保持长期竞争优势。
（2）产品和技术研发周期越长的业务，越要进行长期规划。比如飞机、乘用车、商用车、药品。
（3）投资越大的业务，越需要进行长期规划。比如乘用车产品。
（4）如果要取得长期竞争优势，必须进行长期规划，在此基础上进行基于产品和技术平台的开发，取得质量、成本和时间进度在高层次上的平衡。比如通信设备、软件产品。
华为把中长期规划称之为战略规划（SP），规划周期为5年，每年进行滚动。长期规划周期根据行业和企业的不同，可以自己定义，建议在3～10年间。业务计划（BP）周期为12个月，也要定期进行滚动。
（1） 公司指最高层级的规划对象，可以是总公司、集团等。
（2）业务单元指隶属于公司的各项业务（从市场和客户角度看，主要是产品、服务、解决方案），可以是产品系列、产品线、事业部、子公司、分公司等。
（3）功能部门指按专业进行划分的公司和业务单元下属机构，包括但不限于：财务、质量、研发、售后服务、采购、制造、物流、市场、销售等部门。
从另一个角度来理解，在现代分工体系中，原本属于企业“内部事务”的工作绝大多数都可以外包，包括生产制造、销售、售后服务、行政事务、人力资源、IT、企业变革等，研发、采购、质量控制等也可外包给更为专业的机构。也就是说，以上这些工作都是“产品或服务”，都遵循同样的商业逻辑，都需要进行规划、开发、上市和生命周期管理，在企业内部构成一个“内部市场链”。但是，如若外部机构做得更好，从财务角度讲，应外包这些工作，但从外部采购这些服务需要的沟通和交易成本可能更高，根据诺贝尔奖获得者罗纳德·H.科斯的说法，这些交易成本是企业产生的理由，也决定了企业的规模。外包的基础是要做好前期规划。
在产品和技术规划过程中，识别各种技术非常重要，尤其在外包策略的选择上。核心技术和部分关键技术只有掌握在自己手上，才能构建核心竞争力（见图3-10）。（1）产品中的技术选择，尤其是核心技术和关键技术选择非常关键。诺基亚手机终端业务的迅速溃败和其软件技术平台的选择有直接关系。（2）技术选择决定产品的主要差异。（3）高科技企业必须掌握平台中的核心技术，才能构建核心竞争力。华为不断加大对海思半导体的投资，开发核心芯片，就是为了构建手机业务的核心竞争力。（4）核心技术和关键技术最好不要外包，这些往往是价值链中利润最高的环节。IBM因为没有抓住价值链中的CPU、操作系统等高利润环节，最终退出了自己亲自参与创建的PC行业。（5）服务于同一细分市场的产品平台数量必须严格受控。
技术最终体现在交付给客户的产品中，产品由不同的组件（BB，building block）构成，而部分组件可以在企业内或企业间不同产品之间共用，称之为CBB（common building block，通用构建模块）。不同产品间的共用部分构成产品平台，产品平台和所采纳的核心技术、关键技术相关，这些技术决定了产品平台及其相关产品的主要功能和性能。
如果说有哪种策略可以让研发项目的质量、成本和时间进度（QCT）三个方面都同时得到提高，那就是平台化开发。平台化开发的核心是要在不同产品中尽可能做到零部件、组件、子系统和技术的共享。被共享的部分称之为CBB。平台化开发为产品和技术规划提出了更高要求。要在不同产品之间共享CBB，必须提前进行规划。
根据客户需求开发产品，还是根据自己储备的核心技术开发产品，实质上就是我们常常说的产品研发是靠“需求拉动”还是靠“技术推动”。无论哪一种方式，最终都是客户需求拉动的。任何先进的技术，都必须解决客户问题，
即便今天的客户暂时还没有意识到。作为某一方面的专家，就应当比客户更成功地预测未来的需求，这些需求从时间维度上讲是长期需求。所以，我们认为所谓技术推动是“伪命题”，如果技术脱离了客户需求，必然无法推动产品的发展。所以，无论技术预研、技术开发还是平台开发，都必须以客户需求为导向。
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的流程（Apple new product process，苹果新产品开发流程）。乔布斯1997年重返苹果后，大力推行这套流程体系。
据《乔纳森传》这本书的描述，ANPP由一张张巨大的工作检查表组成，它们详细地规定了不同部门和角色的员工在产品开发过程中应当承担的工作，以及完成这些工作后应当输出的文档。参与产品开发过程的部门和角色包括软件、硬件、制造、采购、财务、营销、售后、质量等等诸多环节。在ANPP流程中，从产品开发的最初阶段，就将顾客需求和市场竞争的需求考虑在内。对于苹果的产品而言，市场营销与设计工作一样，是同样重要的一环。
ANPP最大的特点是非常系统，除考虑到各个方面外，还把产品开发过程中的一切都详细无误地记录下来，这些记录下来的内容被苹果提炼为指南或指导手册，它们为新的开发团队和新员工提供帮助，避免走弯路。
乔布斯是受并行工程（concurrent engineering）的启发而设计苹果的ANPP流程的。并行工程首先由美国国家防御分析所提出：“并行工程的目标为提高质量、降低成本、缩短产品开发周期和产品上市时间。并行工程的具体做法是：在产品开发初期，组织多种职能协同工作的项目组，使有关人员从一开始就获得对新产品需求的要求和信息，积极研究涉及本部门的工作业务，并将需求提供给设计人员，使许多问题在开发早期就得到解决，从而保证了设计的质量，避免了大量的返工浪费。”
方面1没有把研发作为项目进行管理
方面2开发流程结构化不足或过度结构化
上文提到化学品公司的案例中，该企业存在的另一个问题就是没有结构化的产品开发流程，具体表现在没有明确哪些角色和部门应当参与产品开发过程，什么时候参与，在其中做什么，输入和输出是什么。开发过程也没有进行阶段划分，过程中没有设置评审点（里程碑点），高层和技术专家只在开发结束的时候才介入进行评审，问题无法被及时发现。
方面3研发部门唱独角戏
产品是满足客户各方面需求（$APPEALS）的交付物/解决方案（O/S，offings/solutions），而不仅仅是提供功能、性能的实体，还包括产品的无形部分，比如品牌、易用性、服务等。并且，在满足客户需求的同时，还必须实现利润目标或其他战略目标。如果认同这个理念，产品开发就必然是跨部门的。
方面4决策层介入不当
产品开发是一种投资行为，而高层（决策层）作为投资方的代理人需要对结果负责，必须介入产品开发过程。但问题又来了：高层在哪个时间点介入？如何介入？是像苹果公司前任CEO乔布斯那样深入到每个细节，还是像现任CEO库克那样授权给研发和营销团队？
国内很多企业高层对产品开发过程要么介入太多，要么介入太少，根源就在于产品开发流程中并没有明确他们应当在什么时候介入，以什么样的方式介入，介入做什么。而这些应当在流程设计中事先明确规定。
方面5部门经理和专家介入不当
方面6在产品开发过程中进行技术攻关
平台化开发是IPD的核心思想之一，体现在产品开发过程中就是要提前把开发过程中的技术难题识别出来。如果他们在关键路径上，就应当提前单独立项进行技术开发，否则产品开发过程就会不受控，供应链和市场营销就无法按计划正常开展工作，整个过程就自然成了研发部门的独角戏，最终使产品无法在预定时间上市。
方面7创新过程缺乏一致的方法论
对企业而言，只要从事以前没有做过的业务都是一种创新，比如产品开发、技术开发、产品和技术的研究、新生产设备的开发等，公司引入一种新的管理方式也是创新。如果完成这些工作的流程制度没有一致的方法论作为指导，犹如规划工作缺乏统一方法论指导，会增加企业的管理和沟通成本。IPD作为一种创新方法论，可以为这些创新工作提供一致的方法论。
要解决前面提到的各种问题，需要把参与研发过程的各种角色，包括项目组成员、项目经理、部门经理、相关专家及决策层清晰识别出来，对研发过程进行合理的阶段划分，设置“不多也不少”的评审点。同时，需要对流程中的活动和交付件模板进行定义，厘清主流程和支撑流程之间的相互关系；需要一种对各种研发活动均适用的创新方法论，并有针对性地应用。
创新和研发很长时间内都被认为是一些天才和技术人员的专属活动，这些活动不能被管理，难以结构化。随着产品越来越复杂，涉及的领域越来越多，参与研发的企业内外部人员也相应增加。如果结构化程度不够，进度、质量和成本就无法得到保障，无法实现客户价值。
启动产品开发项目的前提是要清楚产品针对的目标客户群，知道应满足他们哪些核心需求，本公司是否已具备成功开发这个产品的各种条件，尤其是技术准备是否充分，或是否可以外包并进行有效的管理。
在大IPD体系中，产品开发流程的前导流程是产品规划（MM）和项目任务书开发流程（CDP），它们的输出就是IPD流程的输入。当项目任务书经过决策层评审后，启动产品开发过程，这个过程的终点就是产品成功上市，称之为GA（general available，通用可获得性）点。
产品开发的输出与生产制造不同，后者最终输出的是产品本身，而前者输出的是产品方案、产品数据和制造产品的能力，以及相关的过程记录，它们的载体是文档。
很多企业会问：产品开发过程中需要多少个文档？我们的观点是，视情况而定，和产品复杂程度和企业管理水平相关。除机械/结构图、电子线路图、软件代码等产品数据和制造体系文档外，其他都是过程文档。但从结果看，是否有过程文档，并不影响产品的生产甚至上市，但这些文档体现了开发之前和开发过程中是否“想清楚了再做”，过程是否规范，是否做好记录，决定了有问题是否可以进行有效回溯。产品最终质量是由过程决定的，过程中要做好好记录，形成文档。
成功的产品有两个重要特点：满足客户需求和公司有利可图，两者缺一不可，且要同时考虑。第一点不满足，客户不会埋单；第二点不满足，公司不能长久经营。对于第二点，目标有多种，可能是获取利润，也可能是某种战略需要，比如：积累客户、建立客户黏性、树立品牌、阻击对手等。即便是“免费”的互联网产品，也有这两个重要特征。
华为IPD流程纷繁复杂，但在顶层设计上，两条主线清晰地表达了整个开发过程的逻辑（见图4-2）：从产品包需求到产品包交付这条线实现客户需求；产品包业务计划把各领域计划整合起来实现产品商业目标。
“在IPD全流程环节都要紧紧抓住两条主线，即IPMT（integrated portfolio management team，高层决策团队）、BMT（business management team，业务管理团队）、SPDT（super product development team，超级产品开发团队）、LMT（life-cycle management team，生命周期管理团队）和PDT（product development team，产品开发团队）一定要在每个决策点和全流程紧紧盯住产品包和O/SBP。每个评审点都要评审这两个方面的交付，生命周期管理也是继续围绕这两条主线开展工作。”
流程是有输入和输出的若干活动的集合，活动的颗粒度有大小，阶段是颗粒度最大的活动。阶段划分与产品的复杂度相关。产品越复杂，过程中需要把控的点越多，流程就可以分成更多的阶段，
●概念（concept）阶段：蓝色，代表创造、自由、大海。概念阶段要充分发挥想象力，围绕客户需求构思尽可能多的创新方案，并确定最优方案。产品层面的创新主要发生在这个阶段，在这个阶段结束时，需求和产品概念就基线化了。
●计划（plan）阶段：绿色，代表精密、完美。计划阶段针对选定的方案开展系统设计和子系统设计工作，把需求分解，然后分配到系统设计中。这个阶段需要充分考虑方案的完整性。
●开发（development）阶段：橙色，代表努力、汗水、成果。开发阶段要把各个专业领域的计划付诸实施，完成各个子系统的开发和验证工作，并做完整的产品内外部测试，确保满足客户需求。
●量产（product）阶段：红色，代表热情、奔放。产品上市后进入量产阶段。这个阶段的特点是充分发挥运营体系的能力，尽可能多地生产和销售产品，为公司创造利润。
概念和计划阶段是IPD流程的核心
概念和计划阶段的工作质量决定了产品开发过程的质量和最终产品质量。概念阶段决定了产品能给客户提供哪些特性和功能，也就是满足客户哪些需求，以及总体方案是否具有创新性；计划阶段的工作决定了系统设计和子系统设计的水平，是否能完美实现概念阶段确定的系统方案。通过这两个阶段工作形成的产品包业务计划书决定了商业目标的实现方式。面对同一细分市场，产品只做简单优化调整的项目，这两个阶段的工作可以合并进行，但它们的工作性质截然不同。
加强概念和计划阶段工作表面上会增加局部投入，但磨刀不误砍柴工，华为公司正是通过加大这两个阶段的投入，大大缩短了开发、验证和发布阶段的时间，从而在整体上压缩了整个开发周期。不仅如此，加强概念和计划阶段的工作后，还会因为减少返工而提高产品质量，降低产品开发费用。
（1） 概念阶段投入不足，导致在没有明确客户需求之前就开始设计方案，并很快启动系统设计和概要设计工作。
（2） 计划阶段投入不足，导致在没有明确系统设计和规格之前就启动具体开发工作，最终结果就是在开发过程中不断被需求和设计变更打断。
（3） 到了验证和发布阶段，产品和技术问题纷纷暴露出来，不断进行修改，甚至导致产品在没有经过严格测试验证的情况下发给客户，客户现场成了实验室。
（4）研发以外的其他角色，如市场、销售、采购、制造等角色在概念和计划阶段基本没有参与，他们的需求没有纳入总体方案加以整体考虑。
（5）前期没有深入分析需求、技术难点和模块重复利用等问题，导致在产品开发过程中解决技术难题，由此也加长了研发周期。
采用IPD流程后，对产品开发最大的改变是在前期各领域组成跨部门团队，项目启动后同步充分介入，各司其职开展本领域工作，把各种问题在早期就识别出来并扼杀在摇篮中，共同为产品成功上市负责。虽然增加了前期的时间和投入，但“想好了再做”缩短了开发、验证和发布阶段的时间，从而从整体上降低了产品开发周期。
华为在IPD引入前后产品开发过程的各阶段时间分步对比，是对两句古语最好的阐释:欲速则不达，磨刀不误砍柴工！
一般把IPD流程中的角色或领域分为9类，分别是高层决策、项目管理、财务、质量、研发、采购、制造、市场、售后。对于复杂产品的开发，参与产品开发的角色会更加丰富，但还是纳入这9大角色中，只是进行分层，下一个层次叫作扩展组。除高层决策和项目管理以外的7大角色构成产品开发项目的核心组。角色划分不等同于组织结构设计。角色划分为产品开发流程确定一个框架，这个框架能够涵盖所有行业的情形。流程中的角色犹如电影中的角色，与角色的扮演者在“现实生活”中所担任的岗位无关。产品开发过程就是这些角色轮番或者同时上场的表演过程。这9类角色的划分是基于大量行业实践和经验的总结。不同行业、不同企业在应用时可以进行适当调整。
为了确保产品开发商业目标的实现，高层在产品开发过程中的介入不能太少，也不能太多，必须设置合理的决策评审点（decision check point，DCP）。在产品开发过程的两条主线中，高层主要在产品包业务计划这条线上开展工作，此时可以把产品作为“黑盒子”，只有产品满足了客户需求，也就是通过了产品级的技术评审（technical review，TR），高层才介入进行决策评审。高层决策评审关注的重点是产品包业务计划书。
（1）概念决策评审（CDCP）：在概念阶段结束前进行，关注已经满足需求的产品概念是否具有竞争力，产品包业务计划中各领域策略是否有效，承诺资源，判断项目是否继续。
（2）计划决策评审（PDCP）：在计划阶段结束前进行，关注最终的产品包业务计划是否可以达成商业目标，各领域计划是否考虑完整，具有可行性。评审赢利计划，与产品开发团队明确绩效考核指标，承诺资源，判断项目是否继续。
（3）可获得性/上市决策评审（ADCP）：在验证阶段结束前进行，关注产品包是否已经满足客户需求，产品包业务计划是否根据环境变化进行优化调整，是否具备上市条件，最终决定产品是否上市销售或提交给委托方。
产品开发过程中，当环境发生变化对产品包业务计划带来重大影响，或必须提前发货时，需要进行临时决策评审（temporary decision check point，TDCP）。
决策评审点的设置不是固化的，对于全新产品开发，不建议裁剪或合并；对于改进型产品开发，概念和计划阶段可合并。相应的，CDCP和PDCP也合并在一起进行，不过需要同时关注这两个点的评审要素。
决策评审必须做出明确的结论，且只有三个结论：
（1）继续（Go）：同意，可以继续开展项目，承诺提供下一阶段资源。
（2）重视项目（No Go）：不同意，项目终止，释放资源。
（3）重新定向（Redirect）：重新定向，要求项目组根据高层评审意见对业务计划进行调整优化，重新进行决策评审。
需要特别指出的是，产品开发流程的“6个阶段，9个角色，5个DCP，7个TR”只是华为公司的实践，虽然15年来变化很小，但并不一定适合其他行业和企业。在构建企业自身产品开发流程时，可以参考，但未必照搬。
为确保产品包需求的完整性，以及产品概念、总体方案、系统设计和各子系统设计、部件和组件、最终的产品包能满足客户需求，在产品开发过程中，必须设置正式的评审点，通过这些评审点判断技术方案是否可行，识别潜在问题和风险。在业务计划书提交DCP决策前，需要各个领域和PDT内部预先进行评审，在进行TR前，各个技术领域也要预先进行技术评审，这些除DCP以外的评审我们统称为技术评审。技术评审是分层的，分为PDT级评审（PDTR，PDT review）、领域级评审（X-department review，XR）、产品级技术评审（technical review，TR）和技术领域级（sub-TR）。对应到功能和项目组结构中，就是先先通过下个层级的评审，再提交上一层级评审，它们之间的逻辑结构如图4-7所示。
与决策评审点的设置相比，产品层面的技术评审点设置具有更大的行业和产品特征，以下是一些供参考的原则：
（1）在决策评审点前必须设置技术评审点，只有通过技术评审才能提交高层决策评审。
（2）产品开发周期越长，TR应越多。两个评审点之间如果超过3个月，通常应增加TR。
（3）复杂和技术含量高的产品，应设置更多的TR。尤其是系列产品的第一个产品。
（4）涉及领域越多的产品，应设置更多的TR。比如汽车产品几乎涉及所有专业技术领域，需要在产品开发过程中设置比其他产品更多的TR。
DCP和TR也有诸多相似的地方，主要在评审流程上，尤其是评审会议必须精心设计，要点如下：
（1）会议质量决定了评审质量，有华为高层曾说，IPD的最大价值是教会了华为如何开会。
（2） 评审会参与者会前必须仔细阅读相关材料，和项目组沟通，发现问题及时解决。
（3）评审会的目的主要是达成共识和识别潜在问题，尤其是跨部门问题，而不是在会上解决问题。
（4）会议一开始首先解决上次会议的遗留问题。
（5）无论是DCP还是TR，都必须使用评审要素表，以免遗漏检查项。
（6）主持人要注意控制时间，避免漫谈和跑题，会议必须有结论。
（7）会后贯彻会议结论，明确责任人，跟踪问题的解决。高层是否可以同时参加DCP和TR？答案是肯定的，同一岗位在IPD流程中承担多个角色色非常普遍，犹如一部戏中一人同时扮演两个甚至多个角色。需要注意的是，高层必须做到“在什么山上唱什么歌”，角色不能错位。在技术评审中，高层扮演的是技术专家角色，除高层需要具备相应专业技能外，还必须注意，作为专家提供的建议仅供项目组参考，否则就可能带走项目组的责任。
苹果公司的前任CEO乔布斯和现任CEO库克在产品开发过程中扮演了非常不同的角色。乔布斯作为公司最高决策者，同时深度介入每款产品的研发过程，甚至提出非常具体的基于个人洞察的需求和设计建议。而库克则表示，乔布斯不可替代，自己不会试图成为乔布斯，那也不是自己的人生目标。相比乔布斯，库克称自己在设计和营销方面花的时间较少。从结果来看，乔布斯去世后的苹果公司在库克带领下，过去3年多的时间里市值增加一倍多，成为全球价值最高的公司，是第二名的1.7倍。
包括苹果在内的大量案例表明，高层是否介入技术评审甚至亲自上阵参与开发并不重要，关键在于高层是否在他所承担的角色上有相应的能力，为产品做出贡献。乔布斯作为苹果公司董事长兼CEO，虽身处高位，但他同时具备超越普通人的产品规划和定义能力，如果不充分利用他的这个长处是一种浪费。同时，库克深知他的优势在于公司运营，而不是产品设计，如果还像乔布斯那样，花费大量精力在产品细节上，不但做不好CEO，还会影响产品表现，对苹果公司反倒是一种灾难。
（1） 高层决策：决策评审，资源管理，组合管理。
（2） 项目管理：业务计划书，项目计划和管理。
（3） 财务：目标成本管理，研发费用管理，项目赢利分析。
（4）质量：产品质量策划与控制，过程质量策划与控制。
（5）研发：研发领域的子流程最多，且不同行业和不同产品差别很大。比如通信/IT行业一般包括技术评审、SE（系统工程）、UCD（以客户为中心的设计）、软件、硬件、结构、工艺、测试、资料、包装等领域的子流程。
（6）采购：新物料认证，新供应商认证。
（7）制造：制造策略和计划，订单履行策略和计划，新产品试制和导入。
（8）售后：售后服务策略和计划，售后服务成本预测。
（9）市场营销：需求探索和管理，市场分析，市场营销策略和计划，早期发货管理，上市管理，生命周期管理。
解决方案是满足特定细分市场客户需求的一种交付形式，本身也是一种产品。如果说解决方案和部件产品有什么“本质区别”，那就是解决方案一般由多个部分构成，这些组成部分可以自己开发，也可以来自合作方，包括有形的实体产品和无形的服务，其中有些部分可以独立销售，叫作构成解决方案的部件产品。
（1） 要求不仅需要单个部件产品的架构和设计，还要有一个整体方案的系统架构和网络设计。
（2） 要求不仅对单个部件提供产品、服务、全球培训、客户支持，还要对整个网络设计提供产品、服务、全球培训、客户支持。
（3） 要求在解决方案网络环境中充分测试所有的部件和业务。
（4） 要求不仅提供针对单个部件的文档，还要提供针对整体网络的文档。
从华为对解决方案的定义可以看出，解决方案本身是一个极其复杂的开发对象，既要进行整个方案系统层次的开发工作，也要进行部件产品层次的开发工作，两个层面都包括架构设计和系统设计、培训、客户支持、测试、文档等。这就需要有一个整合的解决方案开发流程把这些工作纳入一个整体进行考虑。而本章讨论的IPD流程天然具备这个潜质。解决方案中的部件产品，在逻辑上就是产品中的子系统，除了称谓之外“本质上”没有太多不同。把握住这点，就很容易把IPD流程应用在解决方案的开发上。
IPD方法论可应用在不同的创新领域，包括产品开发、解决方案开发、定制项目开发、技术开发、产品/技术研究、变革项目实施等。
结构化的研发流程是过程质量和结果质量的保障。
IPD产品开发流程起始于项目任务书（charter）获得批准，终止于产品生命周期结束（end of life，EOL）或经过评审的项目终止。产品开发项目在GA点结束。
一般说来，共有9个角色（含团队）参与产品开发过程，分别是高层决策团队（IPMT）、产品开发团队经理（leader of PDT，LPDT）、财务代表、质量代表、市场代表、研发代表、采购代表、制造代表、技术服务代表等。其他参与角色可纳入这些角色的外围组。
产品开发流程有两条主线，一条是商业计划线，关注各领域业务计划，并综合为产品包业务计划。另一条是需求实现线，关注产品包如何满足目标细分市场客户需求，也就是产品开发的技术线。乔布斯认为产品是商业、科学和艺术的结合，“艺术”可纳入“需求实现线”。
IPD流程可分为6个阶段，分别是概念、计划、开发、验证、发布、生命周期管理。每个阶段都有明确的目标、输入和输出。
业务评审和技术评审相分离。IPD流程在商业计划线设有决策评审点（DCP），高层在这这些决策点判断是否继续投资该项目，项目的商业风险在这条线得到收敛和控制。
IPD流程在“产品需求实现线”设有技术评审点（TR），各领域代表和专家在TR点评审需求是否完整、产品是否满足需求、是否能够大批量供货等，技术风险在这条线得到收敛和控制。只有通过TR才能进行DCP。
无论产品规划还是产品开发，乃至企业的全部经营活动，都要以客户需求为中心，这已成为企业共识。但如何对需求进行有效管理却没有引起足够重视：有的企业缺乏有效方法探索和收集客户需求，有的企业不知道如何判断需求的真伪，有的企业面对众多需求难以取舍……
与此同时，大量企业问题就出在过度“以客户需求为中心”。为了满足同一细分市场不同客户的需求，有针对性地开发了大量产品，但每一款产品的销量却很少。这些产品看似相似，却又有所不同，为了开发和管理这些数量众多的产品，企业付出了高昂的研发和运营费用。
缺乏完整的需求定义和描述框架
错误地认为需求是创造出来的
持有这种观点的人一般同时会认同：需求是由技术推动的。没有互联网技术，人们就不不会有上网的需求；LED、液晶、等离子技术没有成熟前，大个头的CRT电视足够了，人们没有看平板电视的需求；没有数码成像技术前，我们小心翼翼地用胶卷拍照，不也自得其乐？胶片和传统照相机没有发明前，我们的先辈哪有照相的需求？不过，在没有这些技术前，人类真的就没有沟通、娱乐和拍照的需求吗？只是在不同的时代，满足需求的方式和方法不同。相反，胶片时代的王者柯达公司发明了数码照相技术，却反被数码技术打败。在需求满足上，技术推动不是万能的，关键是如何利用技术。
不能“无节制、无底线”地满足客户需求
在需求管理上对企业的要求就是要针对细分市场的共同需求，而不是特定需求进行研发，在客户订单到来时，最好是现有产品就能满足，或者做尽可能小的改动就能够满足，这样就会节省大量研发费用和供应链成本，这是一个从“行商”到“坐商”的转变，从“小公司”到“大公司”的转变。
长中短期需求分布不合理
不能以产品为中心而非以需求为中心经营企业
需求的分层描述：需求＝问题＋解决方案
需求是产品的约束条件，包括功能需求、非功能需求、DFX（design for X，X代表procurement、manufacture、assembly、environment、……）等，也就是“需求=问题+解决方案”。要分层描述需求，包括客户问题、系统特性、系统需求和各层之间的跟踪关系。如第1章所述，针对产品的完整需求描述，也叫产品包需求，有时也称为“包需求”。完整的产品包需求其实就是对产品本身的详细描述。
用一致的框架完整描述客户需求
构建完整的客户需求框架是市场与需求调研、需求管理、产品规划和产品开发的基础工作。每个维度的需求还需要进一步细化，最终构建客户需求描述的分层结构，
（1） 华为的商业模式是什么？
（2）华为成功的秘诀是什么？
（3）华为的价值观是什么？任正非对这三个问题的回答是统一的：
（1）满足客户需求是我们生存的唯一理由。
（2）我们的商业模式是以客户需求为导向。
为了在公司范围内统一管理需求，最佳的做法是通过一致的渠道提交需求。为提高效率和减少出错，可构建公司统一的需求管理IT平台。
为了让需求信息完整全面，各种渠道得到和提交的需求应当按照统一的格式进行描述，通常包括以下要素：
（1）需求名称，需求编号和关键字，便于检索。
（2）需求类别，根据$APPEALS进行分类。
（3）需求的详细描述，重点包括：背景和场景，需求原因，带来的好处。
（4）竞争对手情况，即：对手是否实现了需求？实现得如何？
（5）需求重要程度，可用KANO模型①进行分析。
（6）客户反馈。
（7）需求如何验收？……
以上针对特定细分市场的客户需求信息形成细分市场的原始需求。
需求分析：对原始需求进行加工提炼
需求分配：产品规划的核心工作
华为B2B业务（运营商业务）的大量需求来源于一线市场部门——地区部Marketing，为了确保产品开发团队（PDT）最终交付的产品满足客户需求，在需求验证上采取了4项措施。
需求早期确认：对于重要的产品和解决方案，要求产品开发团队（PDT）的关键成员在概念和计划阶段与客户面对面沟通，以确保正确理解客户需求。
需求团队参与技术评审：需求分析团队（requirement analysis team，RAT）参与产品开发过程中的技术评审（TR），跟踪需求实现过程，确保客户最初的“所需所想”最终在产品中得以实现。
例行的需求确认：需求团队和地区部的营销部门定期（比如每月）与产品开发团队确认大量处于开发状态的需求的执行情况，而不仅仅是在TR或产品交付时集中确认。
需求的常规确认：产品开发团队通过实验局（Beta测试）等活动，收集客户意见，完善产品，确保产品满足客户需求。
需求管理需要团队作战
为了让需求管理流程真正运作起来，华为设立了公司级和产品线级的跨部门团队支持流程运作，并把相关工作纳入相关职能部门，成为部门工作的一部分。
公司需求管理团队（corporate requirement management team，C-RMT）负责公司层面的需求管理推动工作，管理公司级重大项目及跨产品线的需求，向C-PMT的产品组合路标提交需求，以及进行跨产品线需求的协调、重大需求争议的仲裁。同时，公司级需求管理团队为公司级的MM流程提供相关输入材料，负责制订主动需求收集计划，通过地区部市场管理组织（MTKG）等渠道开展收集活动，并定期审视收集进展。
产品线需求管理团队（product line requirement management team，PL-RMT）是产品线需求管理业务的驱动者和日常管理的执行者，负责产品线需求管理流程、方法和工具的推行，产品线需求的分发和管理监控，以及需求管理人员的技能提升。PL-RMT代表本产品线负责跨产品线需求的协调。
产品线需求分析团队（product line requirement analysis team，PL-RAT）分别支撑对应领域的PL-RMT成员工作，可分领域或子产品线/产品族成立多个，在PL-RMT的组织下，负责本产品线需求的分析和评估，支持决策。大量的需求分析工作在PL-RAT进行：对需求进行批量专业分析，包括解释、过滤、分类、排序和证实；必要时进行市场调研，最终给出评估意见，包括收益程度、风险程度、工作量、是否采纳等；进行优先级排序，形成市场需求包或待定的需求列表，将市场需求包传递到PDT/TDT（technology development team，技术开发团队）等相关组织进行后续处理，将待定的需求列表提交RMT（requirement management team，需求管理团队）考虑;进行需求实现的任务跟踪监控:在PDT的TR1对产品包需求进行内容验证，证，并作为技术专家参与TR2、TR3评审，以及在TR4A、TR5、TR6进行最终结果确认；负责监控客户需求早期确认工作。
公司级和产品线级的跨部门团队成员由各相关功能部门代表构成，为确保相互“上下对齐”，相互之间有交叉，团队定期举行例会。
满足客户需求是企业存在的理由，从这个意义上讲企业就是“需求加工机”，但大量企业并没有把需求作为一个管理对象，并建立需求管理体系。
企业在需求管理上的问题主要表现在缺乏需求定义和描述框架、错误地认为需求是创造出来的、过度满足客户特定需求而无法平台化开发产品、长中短期需求分布不合理、以产品和技术为中心而不是以需求为中心经营企业。
构建需求的分层定义（问题+特性+系统需求+跟踪关系）和完整的客户需求描述框架（$APPEALS）是需求管理的基础工作。
建立需求管理体系要从4个方面入手：建立需求管理流程、需求变更控制流程、需求管理组织和需求质量管理体系。
需求管理流程分为需求收集、需求分析、需求分配、需求实现和需求验证5个阶段。其中，需求收集和分析阶段是关键，需求分配是产品规划的核心工作，需求实现和验证通常在研发过程中实现。
为了确保最终交付的产品和解决方案满足需求，必须对需求进行端到端的跟踪；当需求发生变化，或设计变更和工程变更影响需求时，必须启动需求变更流程。
鉴于需求来源的广泛性、需求实现涉及各部门，企业有必要构建需求收集、管理和分析析的跨部门组织（RMT/RAT），为需求管理提供组织保障。
质量从本质上讲是需求的实现程度，质量管理首先要确保需求本身的高质量，需求质量管理应当成为公司质量管理体系建设的核心内容之一。
“加快从以功能部门为中心向以项目为中心的运作机制的转变。项目是公司经营管理的基础和细胞，只有高质量的项目经营，才有整个公司高质量的运营。我们要通过2～3年的时间，把公司从功能部门为中心的运作转向以项目为中心的运作。这是一个巨大的转变，意味着将激活千万作战团队，意味着功能部门未来就是能力中心、资源中心，而不再是权力中心。在2014年，要进一步推动将预算权、核算权和激励权转移到项目，切切实实激活项目这个最基本的经营单元。”
几乎所有创新和研发工作都是以项目方式开展的，如果说在创新上做得好的企业有什么共同点或“独门绝技”，那就是：相对其他企业，项目开展得更好。本书前面提到的所有理念、方法和工具，只有融入具体项目，达成项目目标，才能为企业创造价值。从这个意义上讲，项目管理是创新和研发管理的“临门一脚”。单个项目的成功有偶然性，但要持续打造成功的项目，需要构建一套适合企业的研发项目管理方法。
研发项目管理是一个管理体系
产品生命周期起始于产品规划和产品开发项目任务书（charter），通过评审（charter DCP）后启动产品开发项目，项目终止于GA，然后进入生命周期管理阶段，其中很多工作以项目的方式开展。从时间维度来看，有产品路标规划项目（roadmap planning，RP）、项目任务书开发流程（CDP）、产品开发项目（狭义的IPD）、补丁版本研发项目、器件替代项目、生命周期终止项目（EOX）；从项目所属领域来看，产品开发项目由每个领域的子项目构成，其中研发领域子项目还包括很多“子子项目”
虽然这些项目的目标和研发内容不同，但是它们有很多共同点：
（1）每个子项目都在开发一个需要移交给客户或其他领域的交付物（含服务）。
（2）需要跨部门合作，组成跨部门团队完成任务。
（3）均需要和最终的商业目标对齐。
（4）产品开发过程中需要考虑客户需求、质量、成本等。
根据公司产品规划，启动B产品的项目任务书（charter）开发工作。在成立项目任务书开发团队（charter development team，CDT）时，研发部门指派后续可能承担该项目研发领域项目经理的小王参与该项工作。
小王了解到B产品是在A产品的基础上面向全球发布的产品，主要增大系统容量，大幅提高系统可靠性和可维护性，预计未来三年全球销售额10亿美元左右，希望在6个月后上市，同时了解了B产品的若干初始需求。会后，小张立即根据所掌握的信息做了相关策划，组织研发部各个相关领导讨论，确认需求和开发周期的可实现性，依据客户需求和项目周期要求提供了系统设计、软硬件、结构、测试等研发人力预算，以及物料预算和其他配套项目的进度依赖，并完成了项目任务书相关章节的撰写，比如关键里程碑、产品架构、关键技术实现路径、产品和技术的依赖关系、人力需求、研发预算、风险评估等内容。
B产品项目任务书通过高层决策团队（IPMT）评审后，研发部门召开项目启动会议，成立B产品研发项目，小张担任项目经理。由于小张在前期的深度参与，充分理解了客户需求、商业目标和整体商业计划，使研发域项目目标和产品开发项目目标非常一致，对研发资源的需求预算非常准确，研发项目开展非常顺利，并最终取得成功。
华为产品开发团队（PDT）是一个虚拟组织，其成员来自7个领域：市场、研发、财务、采购、制造、售后、质量。在一个PDT内部，有多个项目同时开展，称之为版本，针对每个版本设置版本经理。
要把研发项目管理好，需要掌握若干知识和工具，2012年版PMBOK将其总结为10个知识域，包括整体管理、范围管理、质量管理、时间管理、成本管理、干系人管理、沟通管理、人力资源管理、采购管理、风险管理，其中后面9个知识域要作为一个整体服务于项目的整体管理。
“以客户为中心，长期坚持艰苦奋斗和自我批判”被包括任正非在内的华为高层认为是华为成功的最核心要素。这些价值观不仅仅体现在管理层的宣誓、民主生活会、绩效考核上，还渗入了每个研发项目中。
很多项目经理在出现问题后首先找员工的问题，这在华为是被明令禁止的。华为的自我批判是一个从上到下的过程，首先管理者应当从管理上做自我批判，再要求员工做自我批判。
研发项目管理案例
●背景●
作为职业化的项目经理，杰克有过硬的技术背景和十年项目管理经验，被总公司委派到子公司，掌管一项投资额超过8000万元的重大项目A，公司希望通过此项目培养一批项目管理人才。
刘强是子公司自己培养的项目经理，从硬件经理转岗项目经理2年，表现不错，刚被晋升为中级项目经理。刘强对公司的组织结构和A项目非常了解，本次作为杰克的助理共同承接A项目。
●项目立项阶段●
干系人沟通
在项目立项准备阶段，刘强按照惯例，等产品规划部门给他下发项目任务书。而杰克刚一进入项目，就主动安排一系列的会议和沟通，刘强看着这个外来和尚的日程，每天都被会晤占满，不是被叫去开会，就是叫别人开会。没过多久，杰克和产品规划部门的人混得很熟，对产品的市场情况和商业目标非常了解。同时，对研发资源情况，尤其是研发人力资源状况及其他相关项目的情况也了如指掌。在项目任务书评审会上，杰克的发言，无论从质量上还是数量上都已盖过刘强，让刘强内心有些不爽。
识别关键路径
按着初步计划，只能保证产品在第二年2月上市，营销一线对此提出强烈抗议，认为错过了12月的销售机会窗。杰克立即与市场代表沟通，看看是否能把一些不太紧急的需求放到后面的产品版本中实现，同时让刘强再看看项目的时间瓶颈在哪里。刘强分析下来，了解到Y平台是A项目的关键技术和关键路径，如果Y平台可以提前，整体计划就有可能满足12月上市的要求。事不宜迟，刘强找来Y平台的项目经理小张进行沟通，与小张强调了A项目及时上市的重要性，软磨硬泡让小张将Y平台提前。小张晃着脑袋苦笑说，最多可以提前1个月，提前2个月无论如何都做不到。这个消息传到项目任务书开发团队（CDT）后，大家都很泄气。
深度介入周边项目
杰克重新找到小张，把Y项目的项目计划、项目风险清单从头到尾和他沟通了一整天，最后小张面带悦色地从杰克办公室出来，明确表示Y平台项目进度可以压缩2个月，支持A项目的市场进度。刘强狠踹了小张一脚，抱怨说前几天怎么死活不答应，是不是得到杰克什么好处。小张只是笑笑，闭口不谈。
杰克看着刘强疑惑的眼神，离开办公室前给刘强留下一句话：“立项准备阶段，一定要关注项目技术准备度。对于关键平台和技术项目，要与相关项目经理仔细沟通，再细也不为过。”
小张后来和刘强说，杰克把Y项目计划的关键路径从活动时间和顺序、资源安排、技术风险都问了一遍，最后提出一个大量活动并行的方案，将关键路径缩短了1个月。小张再根据关键路径，重新调整了资源安排，又压缩了1个月，就这样轻松地达成了将工期压缩2个月的目标。
刘强这下明白了，作为项目经理，不仅要关注本项目的计划，还要密切关注周边项目，必要时深度介入这些项目的计划。
●项目概念阶段●
专家坐镇，防患于未然
在杰克的影响下，刘强也开始重视以前忽略的细节工作。根据双方的特长，杰克在需求、关键技术、平台配合等方面投入较多，刘强则重点关注项目资源的可获得性和在各职能部门间的协调，两人逐步建立起了默契。杰克非常认可刘强在对项目资源进行安排时，能考虑员工任职资格等级的做法，尤其对刘强能邀请到一位架构设计专家参与项目的概念阶段大加赞赏。这位专家对项目概念阶段的工作发挥了重要作用，能请到这位专家，与刘强之前和系统架构部建立的良好人际关系密不可分。
有了架构专家坐镇，具体设计工作的重担便放在了系统设计师身上。在概念阶段，杰克把握项目整体管理，刘强则把精力放在项目概要计划和项目团队资源的获取方面。刘强费了九牛二虎之力，从各个职能部门经理那里协调到所需项目成员，由于项目预算的限制，并不是每个成员的专业程度都符合项目要求。概念阶段开工会后，杰克拍拍刘强的肩膀，交给他一份方案评审会的名单，上面有技术服务专家、制造专家、采购专家、测试专家、维护专家，让刘强按名单组织会议。评审会上，杰克引导大家，对架构专家提出的方案从技术可行性、可服务要求、可制造要求、以往测试易重犯的问题、器件采购资源等因素多方面考虑，提出风险与预防建议。会上，各个领域专家获得空前的尊重，大家讨论非常激烈，针对产品需求包，对不同的方案进行了分析比较。项目团队成员在这个会上受益良多，刘强也感觉到以前项目中常出现的问题在这个会上基本都提到了，一下子明白杰克如此安排会议的意义。在概念阶段发挥专家的集体智慧，防患于未然，是弥补团队能力不足的最有效方法。
计划不是用于汇报的，而是用来指导工作
概念阶段评审前，刘强把精心制订的项目整体计划和概念阶段详细计划交给杰克，第二天却收到一封来自杰克的批评邮件，说计划中没有全部体现专家们提出的建议。刘强很委委屈，打电话给杰克，强调这份计划是他自己凭着多年的项目管理经验做出来的，绝对能够通过评审。杰克严肃地说：“计划不是用来给领导汇报的，而是为了指导项目的具体工作。前期专家的建议如果没有转化为计划，所有的准备都是浪费。你的计划虽然能忽悠别人，但不可能通过我的评审，赶紧修改，修改后我请你吃饭。”
刘强针对前期研讨会的会议纪要，一面回顾，一面修订计划。2天后，杰克拿着刘强修订的计划，露出了笑容。按照新的计划，各项工作有序地开展，概念阶段以针对实现设计方案相匹配的各类问题讨论为主，整个过程中，跨部门会议、沟通成了主题曲。刘强充分认识到，概念阶段对方案讨论的充分性和完整性是管理控制的关键。
●项目计划阶段●
计划要抓住重点，分层分级
项目通过概念阶段评审后进入计划阶段，这个阶段会议非常多，会议主题从方案的讨论转变为系统设计、概要设计及各种计划的讨论，经历了概念阶段计划不到位的教训，刘强对计划的工作投入了十二分的精力。
杰克在刘强计划的基础上，更关注项目涉及的端到端（end to end，E2E）环节配合问题。看着杰克对计划的专注，刘强对自己之前做项目经理时对待计划的态度非常感慨，也领会到计划管理是项目经理的首要职责。
经过充分的讨论和策划，项目的整体计划大功告成，准备提交评审团队进行计划阶段评审。就在这时，市场部客户经理提交了一个客户要求，针对这个要求，有必要在方案中调整部分规格。客户是上帝，何况还是非常重要的价值客户！事不宜迟，杰克安排相关专家针对变更进行研讨。会后，杰克让刘强根据新的情况尽快调整计划，不要影响原定于2天后的计划评审。刘强看着400多条任务的任务书，一下傻眼了。
杰克拿过刘强的计划，笑着说：“费了不少工夫啊！但研发项目有个最大的特点——计划没有变化快，你之前也领教过吧。把计划调整到150个任务以内，确保前期讨论的方案和建议能在计划中体现就可以了。你这400条任务，不要说改，就是按着执行和跟踪，别说我俩，再多几个项目经理也搞不定！”刘强点点头准备离开办公室，杰克回头强调了一句：“涉及相关部门的计划，一定要和他们沟通清楚！”刘强立即调整计划，把整体计划和阶段计划分开，开发阶段的计划相对详细，其他相对概括。三天过去了，刘强终于确保在计划阶段评审前将计划调整和沟通完毕。评审顺利通过，刘强松了口气。
在此之前，刘强还认为自己是做项目管理，尤其是做项目计划的高手，但和杰克比起来，还是有很大差距，他做了反思和总结：
（1）计划要经过充分讨论和沟通。做计划时，要充分考虑每项工作涉及的项目组成员和部门，一定要让这些人一起参与，才能减少变化和反复。
（2）计划要分层分级。虽说每个阶段都要做计划，但计划的颗粒度（详细程度）和侧重点在各个阶段是不同的。
（3）计划要基线化。刘强发现，杰克每次做完计划，一定要发给相关人员，要求严格遵照执行。在项目会议上，计划涉及的人员必须按照计划详细汇报进展状态，计划会根据讨论情况修订后再发布。在项目进展过程中，实施跟踪的总是同一份计划。
（4）拥抱变化。计划和变化是双重奏，变化源于外部环境的不可控、企业自身技术能力、资源管控能力等各种因素。每次遇到市场需求变动，杰克都不会抱怨，而是重新理解客户真正的要求，再和系统设计师、相关采购、技术服务人员、制造人员等利益相干人沟通变更的事项，将变更融入到新的计划中。对他而言，变化似乎是一种乐趣。
（5）计划要方便管理。做计划的目的是为了指导具体工作，要便于使用。杰克的计划，无论用于查询还是用于资源分配，都一目了然，计划中还会对风险较大的任务用特殊的颜色标出来，便于后期重点关注。最主要的，杰克的计划粗细有致，任务间关系明确，调整起来来非常方便。
●项目开发阶段●
做好风险和问题管理
进入开发阶段后，项目团队成员逐步增加，在阶段开工会上，刘强给大家介绍了项目的核心价值、明确了项目目标，团队成员积极讨论了项目过程中可能遇到的困难及解决方案。团队成员士气高昂，刘强感到不再只是主管和骨干，而是一个团队在共同努力。
在刘强的经验中，这个阶段是可以歇歇的，因为具体事情由开发和测试人员去做，自己的任务就是管控进度。
而杰克却丝毫没有放松，在项目例会上，采用项目管理软件跟踪项目进度，时刻关注风险和问题。一开始大家觉得东西都还没做出来，有什么风险？杰克于是召开了一个会议，会上他分享了自己以前收集的成功、失败的案例，通过讨论，他让大家感受到如果风险不在前期提出来，到了最后就是问题，而风险可以主动管理，问题就只有被动接受；风险管理有助于项目成功，问题总是把项目往失败上引。通过真实的案例，大家意识到，风险不仅存在于开发环节，在制造导入、采购、结构等环节中也存在风险，而这些风险也必须被纳入管理范围。从这些角度出发，风险跟踪表很快就被填满了。为提升大家对风险和问题管理的意识，杰克强调，今后每次例会，每人至少提出3条风险和问题。
在每周一的例会上，主要就围绕进度和风险两个议题进行分析和讨论。例会后相关人收到的就是更新后的项目计划和风险、问题跟踪表，其中有明确的工作安排和责任人，大家也逐步习惯了没有会议纪要的模式。一开始，大家还不习惯经常看计划和跟踪表，后来发生了一件事，大家才认识到计划和跟踪表的重要性。
做好自我管理
有块印制电路板（PCB）下周就要返回，杰克要求大家核查单板PCB返回后立即贴片有什么风险。硬件经理突然提出，供应商无法提供样片，采购翻查了关键器件采购清单，发现是之前疏漏了。通过与供应商交涉，厂家最快3周以后才能提供5块芯片，这意味着项目整体进度将延迟3周。杰克让刘强、硬件经理、采购经理留下，其他人先散会。散会前，他再次强调：“项目团队的每一个成员，都应对照计划，检查自己工作的准备和完成情况，要做好自我管理，这是对一个职业人士的基本要求。这个问题由会后留下来的人处理，其他成员回去后再次确认计划和风险。”在散会后的小会上，杰克严厉批评了硬件经理和采购经理，要求他们针对公司核心价值观进行深刻的自我反省，并拿出解决方案。
这个项目因为无谓的等待要拖延3周，12月上市的目标难以达成，大家都有些失落，回去后对照计划分别检查各自负责的部分。从此，团队成员对计划和风险、问题等异常警觉，逐渐形成了每天对照计划和跟踪表的习惯。
不拘一格，特事特办
为了挽回3周的延误，杰克亲自跑了趟香港，想办法将5片芯片带了回来，节省了物流时间，算是省回一周。在大家的共同努力下，整个项目还是有1周的延误。
在进度压力下，刘强也跟着大家每周都为风险规避、问题解决、计划变更而协调奔波。在开发阶段的后半段，杰克又协调了售后维护团队的2个成员参与到产品开发过程中，以便维护人员早期熟悉产品，顺利进行后期的移交。
●项目验证阶段●
早期充分策划，后期“坐享其成”
在刘强的经验中，验证阶段将会出现大量问题。这时大部分人力资源已被释放，协调人人力解决问题会将占用大量时间和精力。
A项目以延迟1周的偏差通过开发阶段评审，项目计划同步刷新，大部分人员被释放出来，只留下几位开发工程师和测试认证人员一起工作。另外，杰克还特地把售后维护团队的两名员工也安排到测试验证工作中，在实战中提高他们的业务能力。杰克在项目计划中早已把测试的各项工作罗列得非常仔细，且每周都会监控相关工作的进展，尤其是寻找验证客户的工作，需要不断和营销人员确认。
优势互补，艰苦奋斗是一种幸福
虽然前期和客户已经进行了多次交流，规避了大部分风险，但客户验证是否最终成功，还有赖于很多因素。为此，杰克让一线客户经理和产品经理参加例会。因为是海外客户，语言交流成了大问题。团队一般工程师的英文水平还没有达到顺畅交流的程度，大部分是中国式英语。在很多会议上，杰克除了管理项目，还充当翻译。大家很佩服杰克流利的英语，杰克很谦虚，认为优秀的项目团队就是要优势互补，每个人都有自己的所长。作为项目成员之一，他能在项目中发挥自己的作用，就是一种幸福。
由于时差原因，和客户的会议经常在凌晨召开，没多久，项目团队成员就被大家戏称为“功夫熊猫”。其他项目组对熬出黑眼圈的A项目成员纷纷表示敬佩。
策划在先，风险不再可怕
虽然大家都很努力，但刘强最担心的意外还是出现了。客户经理突然反馈，客户运营策略有所调整，取消了对T特性的验证。T特性虽然重要，但使用概率不高，很难在短期内找到其他测试客户。刘强在风险预测中已经考虑到这个问题，当时的风险规避措施是在某单板上预留验证接口，以便转为内部验证。得知客户运营政策调整后，杰克和刘强立即召集市场人员、系统工程师（SE）、软/硬件经理、测试经理、售后、工程代表，按照预定的风险响应规规避措施，调整了验证计划。
T特性在售后、维护人员的参与下，完成了所有的内部验证工作，整个验证阶段没有任何延误。外局验证也顺利拿下了客户出具的《验证通过证书》，项目团队成员看着通过的验证报告，心情都非常激动。
按照转维护计划，转维护工作也有条不紊地进行着，杰克定期与维护团队成员沟通，一起检查转维护标准的达成情况，针对问题，及时采取措施解决，到验证阶段结束时，大部分转维护标准都已达成，只剩下几个遗留问题，准备在发布阶段彻底解决。
●项目发布/移交阶段●
关怀项目组成员
验证阶段结束后，大部分项目成员将回到职能部门，承接新的任务。在这离别之际，大家都有些依依不舍，离开前大家纷纷表示希望有机会再与杰克和刘强合作，这种心情，刘强很能理解，他的确感受到包括自己在内的项目成员在杰克的带领下成长了不少。在杰克指导下，大家对项目管理也有了更深的认识。
剩下的项目成员主要负责解决遗留问题和移交资料，以及总结经验教训等工作，同时也开始考虑自己下一步的去向。杰克特别强调了后续移交阶段的重要性，并让刘强和大家再次确认具体计划，明确具体工作内容。杰克认为，移交工作就是把接口部门的兄弟们扶上马、送一程，只要有一项工作没有做好移交，团队就不能解散。
杰克非常关心团队解散后成员的去向。针对每一个团队成员，杰克都会亲自和他们的职能部门主管沟通，反馈其在团队的绩效表现，商讨下一步工作安排。随后，他将这些信息和团队成员沟通，让大家吃定心丸。
每一步安排都是有远见的
在发布阶段，工作重心从工程技术转向了移交，具体就是与供应链、制造、采购、售后等的顺利交接。在移交过程中，交付给客户的产品出现了一个软件问题，维护人员无法解决，而与此相关的软件工程师已被释放，目前在国外出差。杰克立即想起在研发阶段就参与进来的那位维护工程师，立即将问题现象和数据传递给他。维护工程师仔细查看了数据和软件程序，发现是接口参数不适配，随后修改代码并升级软件，问题得到圆满解决。刘强想，幸好在开发阶段有维护人员的参与，否则此问题不可能在1天之内解决。看来，杰克的每一步安排都是有远见的。
●项目关闭阶段●
不断总结，持续改进
在项目结项评审会上，评委们全面审视了整个项目：目标是否上下对齐，执行的偏差，在多项目组合中的价值，资源的承诺和到位情况。委员们对A项目的交付和项目管理过程非常认可，项目绩效评分为4.5分（满分为5分）。评审团队就项目管理中的一些问题（主要是项目延期1周）给杰克提出了改进建议：改变项目管理模式时，要考虑团队的转变需要一个过程，不要操之过急。对于项目中出现的临时困难和问题，要学会及时求助，善于利用组织的平台力量，包括相关领域专家资源、项目群中其他项目的资源等。
刘强作为项目助理，也将与杰克合作8个月的项目管理经验进行了总结：
（1）项目经理最核心的工作就是计划，计划的好坏，直接影响执行力，这也是项目经理管理能力的体现。
（2）沟通应贯穿整个项目过程。沟通方式有多种：面对面、邮件、电话，每种方式有不同的特点，要善于在不同场合使用不同的沟通方式，比如批评，可以先通过邮件，给被批评者一些情绪调整的空间。
（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会议（决策评审会议）来进行，这些会议的会前准备、开会过程和会后跟踪质量决定了决策评审的质量。
会前的充分准备是为了让会议在规定的时间内做出明确的决策，而不是在会议上讨论细节问题。决策会议的结论有三种：继续（Go）、终止（No Go）或者调整方向（Redirect），以及相应的整改措施。
●打造跨部门规划团队PMT●
战略规划和产品规划谁来做？一般有四种情况：
（1）最高层亲自做规划：由最高层亲自确定公司方向、战略、市场和产品规划，甚至亲自做各职能领域规划，各部门和员工执行。
（2）高层团队做规划：老板和高层团队一起制定战略，确定方向，进行产品规划。部门规划主要由各分管领导完成，高层之间相互协调各种规划。
（3）规划部门做规划：公司成立企划部、战略规划部、产品规划部等负责制定规划，由专人做调研和分析工作，规划成为一种职能。各部门也可能成立专职规划部门从事规划工作，比如技术规划、人力资源规划、生产规划等。规划报高层审批后执行。
（4）跨部门团队做规划：规划部门牵头成立正式的跨部门规划团队（PMT），以团队方式运作规划流程，各部门同时完成部门规划，确保各部门规划之间的相互支撑和匹配。规划报高层审批后执行。
PMT是负责规划和产品定义的跨部门团队，一般由规划部门负责人/骨干员工担任团队经理，各个相关功能领域派代表参加，形成跨部门团队完成规划工作。
PMT是分层的，可分为公司级、分/子公司级、业务单元或产品线级等。PMT团队成员组成和规划的覆盖面相关，完整的规划需要所有功能部门规划的支撑和匹配，所以，理论上所有功能部门都应有代表参加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个环节忽略了，尤其是前面两个环节。
研究结果表明，决定员工是否加入公司的因素是薪酬和福利；决定员工留在公司不离职的因素除薪酬外，还有公司提供的发展机会和工作环境；但决定员工是否在岗位上敬业的因因素却没有一个与薪酬和福利相关，这些因素是成长空间、工作本身、责任、成就感等。也就是研发主管们看重的工资和奖金并不是激励因素，这些因素对吸引员工加入公司，让员工留在工作岗位上是有效的，但不能有效激发工作积极性。这其实就是美国著名人力资源专家、心理学家赫茨伯格在20世纪50年代提出的激励保健理论，也叫双因素理论，它深深影响了全球管理实践，在中国也影响巨大。
也许在很多主管心目中，中国社会的物质发展水平不如西方，研发人员的主导需求还处于马斯洛需求层次中的低层次阶段，也就是生理需求和安全需求，所以物质激励是主要的，这个观点难以被证实，同时也难以被证伪。可以肯定的是，在实践中我们要针对员工的不同需求采取不同的激励措施。
●指标过多导致抓不住重点●
所以，设置哪些指标，需要结合企业和员工个人的情况。
华为轮值CEO徐直军认为：绩效管理整体上要促进生产力的发展，而不是制约生产力的发展，且不是要高成本。站在管理者角度来讲，绩效管理就是要让你的下属都愿意跟你一起干。
通用电气董事长杰克·韦尔奇认为：绩效管理的最终目标并非仅使员工达到期望的绩效，而是使他们愿意付出超越职责的努力。
IBM公司认为：绩效管理的根本目的是为了引导并激励员工贡献于组织的战略目标，同时实现组织和个人的共同成长，它不是绩效考核，而是一个管理过程。
（1） 绩效管理是将公司的使命、愿景、目标、战略、业务、资源有机地结合起来所构成的一个完整的管理体系。
（2）绩效管理是管理者和员工双方就目标及如何达到目标形成共识，并促成员工成功达成目标的管理方法。
绩效可以应用在奖金、工资、股权激励等物质激励中，也可应用在培训、晋升（承担更多机会）、任职资格等非物质激励中。但是这些应用对象一般是由很多因素综合决定的，绩效可能并不是最重要的因素（
绩效管理是一个包括目标制定、执行与辅导、绩效评价、绩效沟通四个部分的完整过程，绩效评价只是其中最不增值的一个环节。沟通贯穿于整个绩效管理过程。
研发工作和人员的特点决定了研发绩效管理有其特殊性，正确理解研发绩效、研发绩效管理和员工激励的概念是基础，不能照搬供应链和营销体系的绩效管理方法。
在绩效管理的各个环节都可以激励员工，赫茨伯格双因素理论中的激励因子主要在绩效管理过程中起作用，而不是等到绩效考核结果出来后。
没有基于结构化流程的量化衡量体系做支撑的量化考核不但不能提高研发人员的积极性，还会带来副作用。
绩效衡量、员工考核结果和报酬之间的强挂钩会改变工作的原动力，甚至会引导员工提出较低的绩效目标。
绩效目标分解为指标的过程中要注意是否“失真”，实现目标的不同方法对应不同的指标。
绩效目标和指标要聚焦，重点改进薄弱环节，一个绩效周期的目标不应超过5项（与绩效周期长短相关）。绩效辅导和执行阶段是真正产生绩效，但却被绝大多数企业忽略的阶段，在这个阶段主要帮助员工实现组织目标和个人目标。
绩效评价结果的当面沟通非常重要，上下级双方均需要充分准备，贯彻“不惊讶”原则。
绩效结果有多方面应用，但要避免绩效主义，绩效不能决定所有的物质和非物质激励要素。
最高层亲自参与、推动并全力支持IPD的实施是成功的关键。最高层特指公司董事长或总经理。华为的IPD如果不是任正非亲自发起并推动，绝对不会成功。
很多企业的IPD变革由研发、市场或质量管理部门发起，最高层往往认为由这些部门牵头就行了。一些企业虽由最高层发起，但项目一旦启动就交给下面执行，自己就不理不问了。
IPD变革涉及各大主要部门，需要改变很多习以为常的工作方式，有赖于各部门的深入参与与全力配合，要做到这些自然会有阻力，这些阻力会伴随变革过程的始终，一旦各部门感觉到最高层对IPD的态度是犹豫不决，在遇到阻力就会退缩，最终回到原来的老路上。
IPD强调产品研发必须跨部门作战，但大量企业在IPD实施中还是以研发、市场为主，其他部门根本不参与或参与极少，导致其他部门不清楚在产品研发过程中应当扮演的角色，为体系实施埋下隐患。
IPD体系涉及战略、流程、组织、绩效、薪酬、领导和沟通等，把这些要素都实施起来至至少需要3年以上的时间，企业规模越大，业务越复杂，需要的时间越长。华为把IPD整个大体系中的主要内容实施完毕花了近8年时间。为什么不一次把这些模块都上齐呢？这是不少企业在体系变革中的疑问。并且，在流程和制度设计过程中，这些企业还一个角色和一个活动都舍不得落下，凡是IBM、华为、三星、苹果现在正在做的，都需要做。
IPD体系的实施需要在整体规划下分步进行。IPD体系中的每个变革项目都需要员工大量投入，而他们同时还有业务工作要做，计划在短时间内完成过多变革项目会造成严重的资源拥堵，势必影响变革质量。这种方针指导下的流程和体系看起来的确很美，但却非常难以操作。
中国改革开放的成功经验之一就是先在特区进行试点，成功后再逐步推广。这点在管理变革中也极其重要，尤其对那些产品种类繁多、规模很大的企业。试点可以验证体系是否适合本企业，同时培养员工能力。
试点犹如产品开发过程中的测试，不经过测试就把产品投放市场，最终返修率一定很高，客户满意度也会下降。但很多企业在变革过程中急于把成果用起来产生效益，认为在体系设计过程中已经考虑得很周全了，不用再浪费宝贵时间，这就导致在推行过程中流程、制制度和模板不符合企业实际情况，员工对体系的熟练程度也不够。
成功的IPD变革将缩短产品开发周期、提高研发效率、提升产品质量，但是这些产出需要足够的投入支撑。很多企业在对变革的产出寄予厚望的同时，大大低估了需要的投入，这也是造成变革失败的原因。
变革投入一般包括三个部分：外部顾问的咨询费用；内部员工的投入；短时间内的业绩下降。根据我们的经验，支付给外部咨询顾问的咨询费仅仅是变革成本中很小一部分，更多是企业内部高层、中层和基层骨干在变革上的时间和精力投入。另外一项变革成本往往被忽略，就是变革过程中业绩的暂时下降。原因有两个，一个是骨干团队参与变革会减少其投入到业务的时间，另一个是试点实施过程中因为对新工作方法熟悉程度不够会影响业务，犹如换用新的输入法，会影响打字速度。没有足够的投入，自然就不能享受变革带来的收益。
最高层无条件全力支持
公司最高层可能没有时间深度参与细节，但是一定要让高层、中层和基层员工深切感知到最高层支持变革的明确态度，当变革遇到困难，或者暂时还没有取得成绩时，最高层无条件支持变革的声音尤其重要。
我们坚持认为，要发挥IPD的威力，除了研发，更多是非研发部门的深度参与。这些领域在IPD项目中和研发领域同等重要，不分伯仲，犹如在PDT项目组中一样。他们不能仅仅在项目启动和结束时象征性参与，而是全程都要深度参与。IPD中的“I”（integrated）中文含义是“集成”，在这里体现得淋漓尽致，只要有一个领域被落下，效果就会大打折扣。
和其他领域变革不同，IPD变革是企业涉及面最广的变革，需要各领域深度卷入，这对变变革引导者提出非常高的要求，除掌握IPD知识和IPD实施经验，还要具备一定的各领域专业知识，否则难以和功能部门进行有效沟通。
如何选择咨询公司？与其说选公司，还不如说选人。一些大咨询公司顾问很多，但对IPD有足够理解的顾问极少。在选择咨询公司时，一定要明确是哪些顾问参与项目，对顾问进行背景调查，面试通过后要在条款中明确要求顾问公司不能“调包”。
如果由内部顾问来引导变革，要求也一样。内部顾问必须具有管理体系实施经验，还要掌握足够的IPD知识，这点可以通过参加相关培训进行“恶补”。
无论由外部顾问还是内部顾问来引导变革，一经选定，管理层就必须给予顾问充分信任，对顾问不应有任何置疑，至少绝对不能在公开场合置疑顾问，一旦员工对顾问的信任度下降，对顾问传递的知识也将产生怀疑，最终影响变革质量。
IPD变革，也就是体系在企业的导入，也是产品、服务或者叫作解决方案。对咨询公司而言很好理解，咨询公司的服务不是引入IPD知识，而是帮助企业按IPD的模式改进和优化管理流程，提高管理效率。
无论是全面实施IPD体系，还是实施其中一部分，都需要多个角色参与，映射到企业组织中，就是各个部门的参与。具体需要哪些角色参与，和企业现状和变革实施内容相关。公司高层不能置身于这个团队之外，必须亲自担任跨部门团队的负责人，深度参与其中。
我们把中小型企业定义为营业额在10亿元人民币以下，或者研发体系人员（指参与产品研发的人员，不等于研发部门员工）不超过200人的企业。这类企业大量存在于各行各业，往往是细分领域的领头羊。它们有自主品牌和产品，有产品研发的成功经验，但往往没有把规划和需求作为一项职能来建设，不一定有专职的市场和需求管理人员。
中型企业大致指营业规模在10亿～100亿元，或者研发体系人员在200～1000人的企业。这类企业在需求管理、产品规划和产品研发等方面的各项职能相对完整。它们在其所在领域有相当的话语权，管理体系也相对完善。
大型企业指营业规模在100亿元以上，或者研发体系员工在1000人以上的企业。大型企业管理已步入正规化，在全球开展业务，相当部分营业额来源于海外。这类企业的员工可能分散于全球各地，要解决异地沟通和文化融合问题。大型企业的IPD实施总体上可以按照IBM、华为等公司所树立的“最佳实践”和“标杆”进行。
●通信和IT设备●
这些所谓高科技产品非常复杂，大多数属于B2B（企业对企业）业务，客户采购这些产品的目的要么用于运营（运营商），要么用于提高生产效率（行业和企业客户），或者是两者的结合（用于内部运营）。这些产品往往以解决方案的方式提供给客户，所以还包括大量的服务。这要求供应商要深入理解客户及客户的客户的需求，并把全球各地的需求进行提炼，以平台化的方式开发产品和服务，否则研发成本会很高。在这个行业的公司要尽可能影响行业标准和客户需求。企业也必须这么做，否则在激烈的竞争中就会处于被动局面。
IPD体系思想和方法论适合各行各业不同规模的企业。但IPD是否能真正发挥作用，关键在体系导入的过程，也就是变革管理过程，导入过程中要考虑企业的行业和规模等特征。
国内企业在IPD实施中的3大典型问题是：最高层领导重视程度和投入不够、信心不足，整个企业缺乏足够的变革紧迫感，只有研发、市场等个别角色参与变革过程。
IPD实施中的其他问题还表现在：没有经过试点就进行全面推广实施，盲目学习标杆，过度追求完美，试图一次完成过多的变革，变革的投入不足。
要成功实施IPD变革，必须把变革过程作为一个项目来管理。
无论是否有外部顾问参与，体系导入本身都可以作为一个服务产品开发过程来对待，用IPD方法论来导入IPD。这分为六个阶段：变革规划和项目任务书，概念阶段，计划阶段，开发阶段，验证阶段，推广阶段。
要成功实施IPD，高层领导必须无条件支持变革过程，营造变革紧迫感，与创新相关的各个领域必须深度参与，IPD带来的最佳效果是创新成为公司全体员工的共同行为。
IPD的实施必须考虑公司的规模，不同规模的公司拥有的资源不同，中小型企业不能照搬华为、IBM等的做法。
IPD适用于所有行业，但在实施过程中需要考虑不同行业的特点。
研发是投资行为
在IPD的7大核心思想中，“研发是投资行为”和“基于需求的研发”又最为核心。这两大核心对应了管理体系中所有流程的两条主线：实现组织的商业目标和满足客户需求，两者缺一不可。要实现公司商业目标，在需求管理、规划、研发、项目管理、组织能力建设、绩效管理和管理变革过程中都必须考虑投资收益。
基于需求的开发
华为总裁任正非多次强调，华为的商业模式就是以客户需求为中心。对商业组织而言，获取投资收益的方法归根结底只有一个，就是满足客户需求。从这个意义上讲，企业是一部“需求加工机”。在IPD管理体系的7大组件中，必须贯彻“以客户需求为中心”的思想。
平台化开发
如果有哪一种方法可以使企业在QCT（质量、进度、成本）3个相互矛盾的维度上都能得到提升，那就是平台化开发。德国大众汽车公司、美国苹果公司和华为公司的成功都与深度实施平台化开发策略有关。要做到平台化开发，企业需要在产品和技术战略规划阶段就关注客户未来的共同需求，形成平台。是否基于平台和核心技术进行产品开发是公司研发实力的最终体现。同时，在IPD管理体系的各个组成部分中，都要有平台化思想。
结构化流程
产品和技术创新过程有规律可循，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使能器/工具、技能、衡量标准。
IPD是基于市场和客户需求驱动的产品规划和开发管理体系。其核心是由来自市场、开发、制造、服务、采购等方面人员组成的跨部门团队共同管理整个产品规划和开发过程，即从产品规划、客户需求、概念形成、产品开发、上市，直到生命周期的完整过程。通过IPD管理体系，使产品开发更加关注客户需求，加快市场响应速度，缩短产品开发周期，减少报废项目，减少开发成本，提高产品的稳定性、可生产性、可服务性等。
华为从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，简称charter DCP。
（2）概念（concept）DCP，简称CDCP。
（3）计划（plan）DCP，简称PDCP。
（4）可获得性（available）DCP，简称ADCP。
（5）生命周期终止（life end）DCP，简称LDCP。DCP是基于投资的决策，DCP的评审材料准备由PDT准备，IPMT做决策。
为了确保产品交付质量符合客户需求，华为设置了7个TR，TR是由PDT内部组织的针对产品包成熟度的评审。
IPMT和PDT两个团队是产品开发流程的“主角”，IPMT负责对产品投资进行决策，PDTPDT负责具体的产品开发。
在华为IPD体系推行过程中，已把IPD抽象提炼为一种创新方法论，不仅应用在产品开发过程，还拓展到技术研发、变革管理、项目管理等领域中。
在华为，用IPD管理体系来保障流程的有效运作。IPD管理体系除了包含前面提到的业务流程外，还包括：
（1）组织、角色和职责。它们定义了支撑流程运作的各级组织，主要是跨部门团队，以及相关的成员角色和工作职责。
（2）度量（metrics）与考核。度量指标用于衡量流程运作质量。华为针对所有流程、子流程分别制定了衡量指标。部分流程度量指标用于员工考核，通过绩效管理和激励机制，强化行为规范。
（3）技术管理体系。通过业务的分层分级管理，构建各层级的通用构建模块（CBB），提高产品开发效率。
（4）技能提升。构建支撑IPD体系运作的个人技能，包括管理和领导能力、沟通交流能力等。
（5）IT工具。构建支撑IPD体系运作的各种信息系统。
如果狭义的IPD方法论实现了各个功能部门在产品开发上的集成与协同，战略运营流则是管理的“IPD流程”，把各个功能部门（战略、市场、产品与解决方案体系、销售与服务、供应链、HR、财经、质量等）的管理实现了有机集成与协同。同时，这个流程也是组织的绩效管理流程。
术语表：
BAT，Baidu，Alibaba，Tencent，百度，阿里巴巴，腾讯。
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，项目任务书。
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 system，集成财务转型。
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，产品开发团队经理。
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-IPMT，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 DCP，决策选择评审点。
SDT，solution devolopment team，解决方案开发团队。
SE，system engineer，系统工程师。
SP，strategy planning，战略规划。
SPDT，super product development team，超级产品开发团队。
S- PMT，solution 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 methods，全球项目管理方法。
X-TMG，跨产品线TMG。
联系客服
