IPD产品集成开发

第10章 流程与研发管理
10.1 IPD在华为为什么能成功？
近些年，随着业务的成功，华为的管理体系也备受推崇，成为各
行各业学习的对象，特别是IPD （Integrated Product Development，
产品集成开发）流程，但凡有产品的公司都想学。其实IPD并不是华
为首创的，也不是华为独创的，只是因为华为的产品获得了较大的成
功，所以IPD也跟着功成名就。
IPD的思想来源于美国PRTM咨询公司出版的《培思的力量》，该
书详细描述了如何通过改善产品项目管理的四个要素：阶段评审流
程、核心小组、结构化开发流程、开发工具和技术提高研发效率，缩
短产品上市的周期，提升产品在市场上的成功概率。
将IPD付诸实践并重新获得成功的公司首先是IBM公司，1992年
IBM在激烈的市场竞争下，遭遇到了严重的财政困难，公司销售收入
停止增长，利润急剧下降。经过分析，IBM发现他们在研发费用、研
发损失费用和产品上市时间等几个方面远远落后于业界最佳。为了重
新获得市场竞争优势，IBM提出了将产品上市时间压缩一半，在不影
响产品开发结果的情况下，将研发费用减少一半的目标。为了达到这
个目标，IBM公司应用了IPD的方法，从流程重整和产品重整两个方面
来达到缩短产品上市时间、提高产品利润、有效地进行产品开发、为
顾客和股东提供更大价值的目标。
IPD在IBM这个巨人身上的实践成果让任正非怦然心动，华为斥巨
资请来了IBM的专家顾问团，并在公司内部结集了优势兵力，用“照葫
芦画瓢”的强硬方式推行IPD。任正非说：“先僵化，再固化、再优
化。”这句话听起来容易，实际执行则非常困难，特别是僵化的初期，
思想、行动都要转变，还需要来自不同的部门的团队共同磨合，所以
对业务还是会产生影响，也难免会有各种反对的声音。这个时间段非
常需要管理层的坚定。有一段时间，任正非说：“不换思想就换人。”
靠着任正非的坚定与坚持，以及一大批种子选手的培养，IPD逐渐在
华为生根了。
僵化的目的是自我认知，优化是自我修正的过程，固化则是夯实
已有成功。任何企业都有自己的基因，必须找到适合自己的道路。没
有什么流程是可以生搬硬套的，也没有流程能够一劳永逸地用一辈
子。之所以IPD现在跟华为紧密相连，跟华为这二十来年持续不断地
优化IPD有非常大的关系。
华为自1999年启动IPD变革，到2005年才逐步走向成熟，一直到
今天，都在持续变革和优化。
（1）华为将IPD与MM（市场管理）、OR（需求管理）对接，实
现了IPD端到端流程的衔接。解决了需求驱动不够、客户需求响应不
够的问题；将客户需求信息直通到产品开发人员手中，实现需求驱动
产品开发。此优化改进，让华为10万人规模开发团队与中小企业开发
团队一样轻盈，快速、低成本地满足客户需求。
（2）研发在产品开发过程中占了很大的比重，而研发又分了很
多领域，系统、硬件、软件、结构、测试等，为了更好地支撑IPD，
系统地梳理了研发领域的各个流程。同时，华为针对软件研发业务工
作量大且相对独立特点，对IPD流程进行软件开发适配，推出集成
IPD-CMMI流程。2007—2010年，华为继续在各产品线试点敏捷开发
方法；吸收敏捷方法在软件开发中优点，考虑电信嵌入式系统庞大而
又复杂的差异；形成适合华为的IPD+敏捷开发流程，将软件从重型过
程管理转向轻量过程管理。
（3）华为针对电信市场整体解决方案特点，创造性全新地提出
“IPD解决方案流程”，提出解决方案IPD开发模型，为客户提供产品、
服务、全球培训、客户支持解决方案。IBM-IPD流程体系解决的是如
何开发一个盈利的产品，而“IPD解决方案流程”提出让华为从卖产品的
公司迈向卖解决方案与服务的公司，推动华为进入一个更大市场范
围，让华为销售稳步迈向2000亿以上台阶。
（4）随着业务范围的拓展，华为又不断推出新的IPD，如适用于
云的、适用于芯片开发的、适用于汽车相关产品的……业务在发展，
流程也在发展。二十多年来，华为并没有一直僵化地使用IBM-IPD，
而是在掌握IPD精髓之后，投入大量的人力物力优化IPD流程，让流程
运行得更具可操作性且有效率，成为华为不断发展的助推器，所以华
为的产品成功了，华为的IPD也成功了。
10.2 流程到底是什么？
引用哈默的话：流程是一套完整的贯彻始终的共同为顾客创造价
值的活动。把这句话延伸下：一系列可重复、有逻辑顺序的活动，将
一个或多个输入转化成明确的、可衡量的、创造客户价值的输出。我
觉得可以理解为有层次的、详细的业务书面化表达，如图10.1所示。

从定义上可以看出，流程是对业务的描述，但这不代表任意业务
的执行方式都能成为流程。更准确地讲，流程是业务最佳实践的描
述。也就是说，我们要从业务的各种操作方法中找到最佳方法，并用
流程描述出来，以便所有的业务人员都能按照同样的方式执行流程，
从而保持业务完成的一致性、稳定性，提高成功概率。
流程和我们常说的制度有什么区别呢？
制度一般指要求大家共同遵守的办事规程或行动准则，也指在一
定历史条件下形成的法令、礼俗等规范或一定的规则。在不同行业不
同部门的不同岗位都有其具体的做事准则，目的都是使各项工作按计
划按要求达到预计目标。
制度和流程都可以理解为规则、规范，要求员工在工作中按照规
则执行，但两者的表达形式、运用却存在一定的差异。我们用表10.1
所示的内容来对比说明。

还有一个更重要的区别：流程有框架，有架构，能够帮助我们理
顺整个公司的价值链，这是流程非常重要的一个作用。所以，我们建
议简单明了的要求用制度，比如考勤规定；复杂的业务用流程，比如
IPD，就是产品开发流程的合集，形成了一个流程体系。实际上，越来
越多的企业都开始采用流程的方式来管理业务。
流程就是我们用的电子流吗？
这个说法不准确。随着信息化的推进，很多企业都用上了各种办
公系统，也会在系统中走各种各样的电子流。但电子流是否就是流程
呢？这还是要回到流程的本质去看，看电子流到底承载了多少内容，
有可能是整体业务流程都实现了信息化，那么走一条电子流就等于走
完了一个业务流程。但现实中更多的情况是，电子流只是整个业务流
程的很小一部分内容，多见于审批、评审、发布等环节，这个时候，
就千万不要把电子流等同于流程了。
表10.2也列出了一些常见的其他指导类文件，需要和流程做区
分。

10.3 流程的价值在哪里？
流程的价值在哪里？其实如果大家认真地看完了前面的几章，并
且仔细思考，就不会再问这个问题。因为在产品开发的每一个环节
里，都少不了流程的影子，更不要说广义的流程文件还包括了指导
书、模版、Checklist，流程对工作的指导意义显而易见，这里再给大
家看几个怎样用流程的办法解决业务问题的案例。
案例一：物料采购
某公司的研发物料申购周期特别长，研发人员无法知晓物料进
展。大家抱怨的焦点是IT系统还不完善，研发物料申购的过程无法信
息化呈现，项目助理需要时时跟采购员沟通，才能知道物料购买的进
展，甚至出现项目助理填写的纸件物料申请单被采购员遗失的情况。
这种情况下，项目助理还不能第一时间发现，造成了整个物料进度的
延迟。确实，IT系统能提高信息的透明度，但没有IT系统，这个问题
是不是就一定没法解决甚至无法优化？答案是否定的，只要把物料申
购的整个流程做一些规范，就可以大大降低申购方和采购方的沟通成
本。
那这个流程要如何优化呢？第一步，采购做一个物料申购单的模
板，Excel就可以搞定，里面包括申购人、物料种类、数量、厂家、申
购日期、采购指令发出日期、交期等相关信息（这个模板的内容可由
申购者和采购共同完成）；第二步，所有申购人都必须按照模板填写
申购信息，通过电子邮件的方式发送给采购（连纸都省了）；第三
步，采购在收到申购人的信息后，必须回复邮件，确保信息已经传递
到位（避免丢单还不能及时发现的情况）；第四步，采购在发出采购
指令得到供应商的回复后，完善物料申购单相关信息（采购指令发出
日期，交期等）。在这个基础上，还可以做第二步和第三步的优化，
设置一个共享文件夹，给相关人员开通权限，物料申购表单就放在共
享文件夹中，供申请人员、采购人员编辑和查阅。
上面是一些粗略的建议，有一些细节还可以在实施的过程中完
善。但是不难看出，我们在流程上去下一些功夫，做一些改善，是可
以提高工作效率，避免失误的。
案例二：知识共享
很多企业都意识到了知识共享、经验传承的重要性，但是有的企
业做得好，有的企业做得差，这是为什么呢？有人说，是因为我们公
司的工程师能力差，没东西可以共享。有人说，我们公司的工程师不
会讲课。有人说，我们太忙了，天天做项目还来不及，哪里有时间共
享。有人说，我们公司是矩阵组织，人都去产品线了，职能部门管不
着，没法共享。
这些听上去好像是原因，其实都是借口。想靠人的自觉性在做共
享，能实现这点的公司寥寥无几吧？那应该怎么去做？我们就几种典
型场景提供一些专题知识共享的思路。
所有发生的质量问题，必须做质量回溯，并且在部门内部做宣
讲，同时回溯报告发送给所有相关的研发工程师学习；质量回溯报告
要归档；技术探讨，首先确定技术探讨的命题、讲解人、讲解日期；
不用太频繁，一个人讲一个课题，一个礼拜讲一次，如果一个部门20
个人的话，转一圈也需要4到5个月了，也留下了20个知识分享的内
容；简单的课题排前面，安排给资历浅的工程师，难的课题排后面，
提供更多的准备时间；设置考核，在职业发展通道中，明确规定一定
级别的工程师需要分享的课程数目；设置激励，提高大家分享的积极
性。上面这几点是讲的几个大方面，但是如果把这些措施都放到相关
的流程中（质量管理流程，任职资格管理流程），甚至建立专门的知
识分享流程，整个公司的知识分享，经验传递的效果会好很多。流程
管理的第一步，先要有流程。执行不力，再去执行上想办法。例如，
用一些激励的手段鼓励大家多分享，但是为了避免大家追求激励随意
分享，可以在分享前加一个内容审核的环节。这些都是可以用流程解
决的问题。
案例三：项目结算
一个做IT系统的公司，采用的是项目结算制度。一个项目有多少
费用、多少工作量，需要多少个实施顾问，基本是明确的。在这种情
况下项目多增加一个人，大家能分到的奖金就少了一份，所以除非是
现有人员实在完不成项目，否则项目经理是不愿意多要人的。但是公
司为了扩展业务，又不能不进行人才储备，所以经常出现项目所需人
数与公司实际顾问数目不匹配的问题。其实这事的本质是如何保证公
司人才有储备但又兼顾项目团队利益的问题，也可以通过流程来解
决。首先是新顾问的费用，公司和项目组如何分摊得明确，比如完全
没有工作经验的毕业生，前3个项目，奖金都由公司承担；其次是项
目经理对顾问要有面试权、考核权，确定顾问是否适合当前项目，如
果岗位能力无法匹配，对项目和新顾问而言都得不到好的效果。
案例四：器件选型
有一个产品开发项目，计划总是延期，项目经理在组织大家复盘
的时候，发现是因为一个新引入的器件到货时间延误，所以耽误了单
板的加工和测试。同时，在复盘的过程中，项目经理对这个器件的成
本也产生了疑问，最终认为该器件的成本和交期均不能满足项目的需
求，所以要对器件重新选型。我问项目经理，当时DCDC（电源芯
片）是怎么选进来的？他告诉我是硬件经理选的，他没有参与，这次
他准备自己主导。当场我就跟他讲，这次他主导没问题，但是技术上
的把关需要硬件经理支持，而且在选型的前期一定要找多家供应商，
让采购前期介入寻源，尽量避免独家供货。这样的事情是不是常发生
在硬件开发的过程中？那新器件选型流程又需要怎么优化呢？首先，
新器件的引入绝对不只和技术有关系，成本、交期、商务上的条款都
需要一并考虑，因此技术部门要通知采购部门尽早介入。器件选型要
在设计方案完成之前完成，等到单板都做出来了再换器件，相当于重
新做设计，时间、资源都是浪费。
其实这样的案例比比皆是，大家可以在工作中留心观察和总结。
我们回到流程的价值这个主题，总结起来，我觉得有以下几点。
（1）统一业务语言，提供操作指导：公司在发展过程中，一定
会不断吸收人才，人才又来自四面八方，有不同企业的不同工作经验
的人，有高校的应届毕业生。大家都有不同的业务语言，看上去是同
样的文字，可实质可能有不同的含义。因此流程的基础作用就是统一
语言，让大家在一致的语言环境中工作，降低沟通成本。同时，能为
还不熟悉的新人提供标准的操作指导。有时候，流程这位师父比真人
师父靠谱。
（2）确定业务规则、划清职责：前面我们提到过流程是业务的
最佳实践，因此在成熟的业务中，哪些活动由谁做，做到什么程度，
岗位职责的边界都是相对清晰的。但对于一些新业务，有可能业务模
式、业务规则都没有搞清楚，流程如何发挥作用？可以根据业务场景
先尝试划界限（明确活动及责任主体）。首先是从责任主体来讲，哪
个活动应该由谁来完成，活动与活动之间的交接条件，问题的处理与
上升机制，这些都可以通过流程来划分的。然后按照流程执行一段时
间，看看是否顺畅，或者出现了什么问题，再次进行梳理。这样就能
避免业务一锅粥。
（3）形成组织能力的基线：流程是业务的最佳实践，最佳实践
获得了普遍执行，那就意味着大家都是按照目前的最佳路径在做事，
这样对业务结果能有保证，同时也会形成能力基线。比如复杂度不同
的项目，需要什么样构成的团队，需要多少时间能完成，都更容易估
计。同时，也更利于在同一个事情上沉淀经验，不断将个人能力转变
为组织能力。比如研发设计上的坑，可能今天张三犯错误，明天李四
犯错误，如果把这些错误的规避方法都写到流程中，慢慢就可以避免
后面的人再犯错误了，组织的能力得到了提升。
10.4 流程的基本要素
既然流程的作用有这么大，那为什么很多公司的流程不起作用？
这个问题问得很好，也是很多企业面临的实际困扰，这要从三方面
看，一方面是流程本身的质量，另一方面是流程落地过程中的各种因
素，最后一方面是管理流程的机制是不是健全。这几方面都属于流程
管理的范畴，这里我们先看看什么是好的流程。
基本要求：流程要基于实际业务，流程完整、顺畅，易于执行。
高一点的要求：流程是最佳实践的提炼和总结，按照流程能够快速
地、低成本地完成业务活动。再高一点的要求：流程架构简单，不同
层级之间容易承接、遵循，流程容易记忆，流程接口容易鉴别，接口
清晰。
除了以上这几个层次的要求外，流程其实有自己的一套表现形式
和规范，以便于统一流程自己的语言。下面就给大家介绍下流程的一
些基本要素。
单个流程常用泳道图来表达，一个合格的流程应该包含以下几方
面的要素：名称、描述、目的、起点、终点、活动、角色、输入、输
出。更严格一点，还应有流程绩效指标和关键控制点等要素。
流程名称：是赋予流程的一个称谓，要求流程名称是明确的、清
晰的、简短的，能体现流程所描述的业务运作主题，例如《单板硬件
开发流程》《瀑布式软件开发流程》《订单履行流程》。
流程描述：是对流程涉及主要内容的概括性说明，基于流程的主
要活动顺序来描述，描述要简洁、明确。例如《单板硬件开发流程》
的流程描述，包括硬件需求分析、方案设计、详细设计、原理图、PCB
设计、单板加工、单板测试全过程。
流程目的：描述流程对所涉及业务的使命、目标有哪些贡献；关
注流程的客户需求；关注流程的输出。主要包括提高准确性、时效性
和降低运作成本等方面的贡献。例如，《单板硬件开发流程》的流程
目的是指导、规范单板硬件开发业务，确保开发过程的规范性，提升
研发效率和质量，控制单板成本，提高单板的直通率。
流程起点（Start Point）：是触发流程第一个活动的开始事件。事
件是描述与相关业务信息的状态，这种状态可能控制或影响业务的运
作。触发流程开始的事件可以是单一事件，也可以是多个事件；任何
流程都至少有一个开始事件。触发流程开始的事件可以是单一事件，
也可以是多个事件；任何流程都至少有一个开始事件。例如，《单板
硬件开发流程》流程起点是“收到单板硬件开发需求”，也有可能是“收
到产品需求”。
流程终点（End Point）：是流程最后一个活动所产生的结束事
件。流程结束的事件可能是单一事件，也可能是多个事件，但要选择
其中对流程目标达成有意义的事件作为流程的终点。任何流程都至少
有一个结束事件。例如，《单板硬件开发流程》的流程终点是“单板硬
件设计归档”。
活动（Activity）：是一组相互联系的、有一致成果的任务或行
动。每个活动都由一个角色来负责执行；每个活动都有明确的输入、
输出；每个活动都可用时间来度量；一般以动宾结构来命名（根据语
言习惯确定）。例如，制定单板硬件开发计划、设计原理图、PCB布
局。
角色（Role）：已定义好的活动的标准执行者，负责流程活动的
执行及输出，有明确的职责及技能要求。例如硬件工程师、系统工程
师、结构工程师。
流程输入/输出（BI-Business Item）：是指流程中各环节业务活动
的输入/输出对象，包括实体及承载数据的信息、数据等；BI是构成流
程间和流程中活动间的信息链，每一个流程活动都会有输入和输出，
每个BI有且只由一个流程活动创建，可在多个流程活动中使用或更
新。具有唯一性，流程文件中多次出现的同一个BI，其名称必须保持
一致。例如硬件需求表、单板设计规格书等。
关键控制点（Key Control Point，KCP）：对实现业务流程目标、
降低风险、保证质量的一项或一系列重要活动。识别所有控制点后，
流程Owner会从中选择最高风险的控制点并给予特别关注，如执行遵
从性测试、测评等。基于审计报告、公司指引等识别出的高风险控制
点称为关键控制点。其主要特点是只有重要的高风险控制点才是关键
控制点；必须清晰定义在流程文件当中；必须正确、有效地执行；必
须定期进行遵从性测试及报告；必须由流程Owner定期回顾。
关键绩效指标（Key Performance Indication，KPI）：衡量流程运
作绩效的量化管理指标。衡量业务流程目标是否达成；有明确的数据
收集、分析渠道和计算公式；流程绩效指标可能有多个，一般选1~3个
作为关键指标。例如单板综合直通率、需求交付周期等。
以上要素都针对单个流程而言。对于流程体系来说，我们还需要
了解流程架构、流程视图、流程接口等概念，这些对于在复杂的业务
中构建流程体系都是非常重要的。如果暂时没有这个需要，大家也可
以跳过后面这一段。
流程架构（Business Process Architecture，BPA）：流程架构是企
业架构的组成部分，反映企业的战略使命及目标，描述了企业的流程
分类、层级关系。流程级模型如图10.2所示。

每个企业的流程层级可能有小的差异，但整体遵循流程分类→流
程组→流程→子流程→活动→任务这种架构模型。Level1、level2用于
流程管理，回答“why to do”的问题；Level3、level4用于落实方针政策
和管控要求，回答“what to do”的问题；Level5、Level6用于将流程要
求落实到人，使之可执行，回答“how to do”的问题。
我们再看一个企业的流程架构示例，帮助下理解，每一个层级的
内容大家可以自行阅读，无须展开，就有两点跟上面的流程层级模型
示例图有所区别，单独说明以免混淆概念：第一点是图10.3中的Level3
还是一个流程组的概念，不是流程，因为研发领域有很多差异非常大
的子领域，都需要单独一个流程去描述业务；第二点是单板硬件开发
流程没有子流程。因此遵循流程→活动→任务的展开顺序，而不是前
面提到的流程→子流程→活动→任务的顺序。大家可以根据实际的业
务情况梳理流程架构，不用拘泥于到底有几个层级。
流程视图（Process View）：表示业务流程信息的一个集合，向某
一特定情形或特定用户群提供一个业务总览图，展示各个流程之间的
逻辑关系。图10.4是某公司项目E2E流程图。


10.5 流程管理怎么管？
流程管理怎么管？其实就是如何保证流程能实现价值。回应上面
一小节提到的三个点，流程管理就是从三方面下手，一方面是提升流
程本身的质量；另一方面是管理好流程落地过程中的各种因素，确保
流程能够执行落地；最后一方面是建立健全的流程管理机制，确保流
程能够持续改善。
提升流程质量，本质上是提升流程设计的质量，按照好的流程标
准设计好出流程。如何设计出好的流程？我认为主要从两方面着手：
深入理解业务；掌握流程设计的方法、工具。流程是业务的表达，核
心是业务逻辑，所以要设计出好的流程，就是要把业务的最佳实践提
炼出来。比如产品开发流程，就是将产品开发的最优路径提取出来，
形成一组有序、可重复的活动，给做同样工作的人提供共同语言，提
供最佳路径，提供指导，降低犯错概率。所以不深入了解业务的人设
计出来的流程一定不是好流程。
这里介绍两个小方法给大家，一个是《流程功能展开表》，如图
10.5所示。在流程设计的时候可以用这个表，让项目组的成员先把流
程按照活动维度梳理一遍，在这个基础上再做研讨和优化，会大大提
升速度。

还有进行一个方法叫项目映射，也就是把目前的业务开展方式用
流程图的方式呈现出来，再通过与业界最佳实践进行对比，找出问
题、差距，进一步找出改善的方向。
除了提升流程设计的质量外，我们也要用一些好的方法和工具来
帮助我们管理流程设计的过程。一个全新的流程设计或预估有比较大
变动的流程优化，我们可以用类似产品开发流程来管理流程开发的过
程，把流程优化当作一个项目来管理。一些小的流程优化可以用CR
（Change Request）的方式做流程优化的评审。这两种管理方式涉及
的治理结构和组织，后面会单独分享，现在先看看这两种方式的管理
过程。
先来看流程优化项目的管理，如图10.6所示。这也是一个结构化
的管理流程，分为Charter开发、方案设计、详细设计、验证/试点、发
布/推行五个大阶段，有4个DCP点。从结构上看和IPD类似，但整个过
程的复杂度远低于产品开发，所以看到这里不要被这个流程给吓住
了。Charter开发阶段的主要任务是分析业务现状，识别关键需求、关
键干系人及确定项目关键人力资源。因此项目任务书的主要内容就是
描述项目的背景（业务现状与问题）、关键的优化需求、可行性分
析、项目范围及所需资源、关键交付件及关键的利益干系人、项目里
程碑。

方案设计阶段，首先是组建项目组并确定项目计划，在这个阶
段，项目组的主要任务是分析并完善项目需求，完成流程优化方案及
验证的策略；详细设计阶段的主要任务是根据流程优化方案进行详细
设计，完成所有交付件（流程图、模板、指导书、检查单、流程培训
材料等），选择试点项目进行试点准备；验证和试点阶段的任务是引
导试点，并解决试点中发现的问题，优化交付件内容，最后要进行试
点总结并做推行准备；发布/推行阶段的主要任务是全面推行，并且解
决推行过程中遇到的问题，如有必要，需要再次优化交付件内容，最
后进行推行总结，进行结项汇报。
这样的管理流程设计过程有两个好处，一个是流程的优化方案得
到充分评审，包括试点阶段，都能查漏补缺；另一个好处是团队作
战，能够弥补个人能力不足，团队成员里有熟悉业务的成员，也有熟
悉流程设计方法的人员，配合得当的话，流程设计的速度会大大提
高。
流程建设的难点并不只是在流程设计上，流程推行的强度和力度
在很大程度上才是决定流程是否能真正运行的重要因素。流程推行的
过程，并不是随意为之，也有一些关键的动作，换句话说，流程推行
也有流程，如图10.7所示。

成立推行小组：无论做什么事，一定要先有人，流程推行也不例
外，所以首先要成立推行小组。推行组组长一般由流程owner指定的代
表担任，小组成员则由涉及的部门领导指定成员担任。在华为，推行
组的成员一般来源于三个方面：流程部门的流程管理工程师，各产品
线质量部质量工程师，各产品线业务部门的业务代表。三者角色不
同，看待流程的角度不同，更能全方位客观地去评价流程及推行过程
中遇到的问题。
制订推行计划：制订推行计划这个过程至关重要，除了要确定推
行的整体时间计划（包括后续跟各级领导的汇报沟通时间）、试点项
目、推行的范围等以外，这个阶段最重要的工作是要为推行准备好所
有的材料。这些材料包括培训材料、汇报材料、FAQ、流程变更清单、
流程适配表等。从流程活动的划分上来说，应该增加一个活动，可称
为推行准备。
培训：无论是试点还是推行以前，都必须对相关人员进行培训。
培训包括整个流程的讲解，流程中重点和难点的说明。培训的时候多
给一些场景化的案例，帮助业务人员理解。
试点：无论是新鲜出炉的新流程，还是优化后的流程，我们都建
议先试点，再推行。试点项目往往会选择有代表性的项目进行，更能
找出问题。试点分为两种方式，走读和试行。走读就是让业务人员通
读一遍流程，假设各种场景，看看流程是否能跑通，会不会有什么问
题。试行则是直接按照流程来跑业务。选择哪种方式，要根据流程的
不同类别、试行项目是否容易选取、试行可能带来的问题等因素综合
考虑。
流程优化：试点的过程中，必然会遇到各种问题，有的是流程设
计上的缺陷，有的是试点项目对流程的理解不到位，这些问题都需要
推行小组组织讨论，该优化流程的地方就要优化流程，该在培训中加
强讲解的地方就要在培训材料中加强。总体来说，这是一个反复讨
论、反复修改、反复试点的过程。
推行发文：公司的正式发文，××流程发布了，要在××范围内推
行。这一步的作用就是昭告天下，同时将流程文件正式纳入流程文件
体系。
适配（这条特别针对研发流程等灵活性较大的流程，标准化流程
不在此列）：对于灵活性比较大的流程，适配是确定流程是否能顺利
推行的关键环节。比如研发流程，一般是基于典型业务场景的标准化
动作，而我们的研发项目确实千差万别。所以在推行流程之前，我们
一定要进行适配，看看项目的特点是什么，流程中哪些活动是必须做
的，哪些活动对于这个项目来说是不需要的，一定要量体裁衣，才能
把流程推得好。
推行：在流程适用的范围内，全面推行，这个不用多讲。
流程执行审核：在制订流程推行计划的时候，就要确定流程执行
检查的时间点。一般会在流程发布后的三个月或半年进行检查（检查
的时间和频次根据流程的不同会有所不同）。检查的方式一般是访谈
结合查看证据同时进行。流程的执行检查，一般是抽查，不会检查所
有的项目（根据公司的规模、流程推行的范围灵活确定），但检查哪
个项目，什么时间检查，不会提前太多公布。审查也是为了改进，所
以一定要公布流程的审查情况，哪些项目做得好，哪些项目做得不
好，什么原因，都会在审查报告里得到体现。至于流程执行情况的奖
惩制度，可以根据公司的具体情况进行设置。
流程推行的理论知识基本上就讲到这里了，我们再看看知识外的
关键因素，有且仅有一个：管理层特别是大领导对流程的重视程度。
同样的推行方法，同样的流程，不同的领导重视程度就会出来不同的
效果。
流程管理三板斧的最后一板斧是管理流程的流程，也就是说，如
果把流程作为一个职能，那这个职能本身该如何管理？职能管理的逻
辑其实都是类似的，简单来讲，首先根据公司战略规划职能战略，做
年度计划，然后按照计划执行，同时做好过程的监控与管理，最后要
进行绩效评估。
最后提一点，流程管理的工作要想做得好，确实需要投入大量的
人力物力来做保障工作，所以流程组织必不可少，要做到以下几点。
●有专门的部门，退一万步讲，有专门的职位做流程管理的工作。
这个部门的职责：（1）看护企业的流程架构；（2）建设流程管理能
力；（3）组织各领域流程的梳理工作。
●把流程管理的职责落实到各业务领域一把手的头上。流程建设只
能是自上而下的工作，自下而上是无法开展的。那如何自上而下？从
领导的职责、重点工作入手。流程推行落地的第一责任人必须是部门
一把手，所以必须把这点强化到部门职责里。要形成公司+领域的多层
推行组织，要有独立的团队对流程的执行做审查。
最后我们看看两个案例，体会流程管理的成败因素。一个是标杆
企业的研发流程管理，一个是流程优化项目以失败告终的案例。
案例一：以版本管理的方式来管理流程
提到流程的版本管理，可能很多人都会讲，我们的流程文件也有
版本，修订记录也记得很详细，流程文件也都是经过了评审才发布
的……但我想跟大家讲的是整个流程体系的版本管理，我们先通过华为
研发流程版本管理的案例，让大家感受下什么是流程的版本管理。研
发流程作为IPD流程的重要组成部分，每年都要发布一个版本，以保证
流程的先进性与实用性。
研发流程版本的生命周期大致分为图10.8的5个部分。

具体讲每个阶段之前，我们先介绍下研发流程管理体系的治理架
构，这里有两个虚拟组织对研发流程负责，一个是研发流程改进委员
会，主要负责研发流程版本及研发流程变革项目的全生命周期的审核
和批准，研发流程改进委员会由各产品线研发部部长、研发流程部部
长、研发流程部5级专家组成。另一个是研发流程CCB（控制变更委员
会），主要负责对研发流程CR进行评审。CCB由研发流程部部长、研
发流程部5级专家、各产品线研发质量部部长组成。
版本规划：一般在每年的11月、12月进行，由研发流程部部长和5
级流程专家主导，研发流程各个领域的负责人参与。规划主要是根据
目前业务的需求、流程的现状来规划研发流程变革项目，还有一些研
发流程领域的探索性业务。举个例子，在某一年做规划的时候，大家
对研发外包管理做了探讨：（1）研发外包是目前普遍的业务现状，特
别是软件外包，频率非常高；（2）公司有了一些外包的管理要求，主
要是对供应商的选择，法律条款方面的内容进行了约束，但是缺少针
对研发外包项目的项目管理的内容。这样一来，方向就有了，成立一
个研发外包管理的流程变革项目，对业务进行梳理，并发布相应的流
程。
另外一个例子，随着开源软件成熟度的提高，以及企业本身降低
研发成本的需求，将会有越来越多的项目用到开源软件，那么企业应
该如何参与到开源社区的建设，如何规范开源软件的使用过程，规避
风险？这些都是需要探讨的内容，所以在某一次的规划会议中，研发
流程部也将开源软件的使用作为了一个研究方向，由流程专家与业务
专家一起，成立项目做相关的研究。
在做流程项目规划的时候，要考虑项目的范围和难易程度，项目
是一期就能完成还是需要分期完成，项目由哪个产品线牵头比较合
适，这些都是做规划的时候需要考虑的内容。
研发流程版本规划需得到研发流程改进委员会的批准。
版本实施与监控：研发流程版本主要由两大部分组成，除了规划
的流程变革项目以外，另一类主要来源是变更申请（Change
Request），以下简称CR，所以研发流程版本的实施与监控，实际上就
是各个研发流程变革项目和CR的实施与监控。
研发流程变革项目的管理方式与前面讲的流程设计过程项目管理
过程类似，不再复述，只强调标杆的几个关键点。
立项：变革项目不仅涉及资源的投入，而且它的项目过程、项目
结果很有可能带来业务规则的变化、组织的调整，影响的范围也特别
广，所以变革项目的立项过程更应谨慎和严谨。
研发流程变革项目成员一般会由流程专家和产品线业务、质量人
员组成。流程专家会把握整个流程项目的进度节点，协调各产品线的
意见，从流程的角度给出建议及流程文件的修改意见。产品线的业务
人员和QA根据业务的现状和趋势，对于流程现状提出更改建议。最终
项目组输出项目材料及流程CR在获得研发流程改进委员会和CCB的同
意后，项目成果会跟随研发流程版本发布。
华为的变革项目也不是一帆风顺的，也有几个困难的地方：不是
所有产品线都重视流程，所以参与项目的人员的能力和责任性参差不
齐；各产品线产品形态各异，要在中间找到平衡点，发布公司级的流
程，是一个权衡和拉锯的过程；寻找合适的试点项目。华为的项目进
度是出名的紧张，在大家都恨不得一天当作两天用的时候，能找到项
目愿意在忙碌中试点新的流程，也不是容易的事。所以也要依托变更
项目的推进，在研发流程改进委员会层面来解决这些问题。
再看CR的管理，CR的来源主要有这几部分：日常CR，研发流程变
革项目CR，其他领域变革项目CR。
日常CR：华为公司的任何员工发现流程文件中有问题的地方，或
与业务不相符的地方，都可以提交CR申请，提交改进建议。
研发流程变革项目CR：流程变革项目可能会发布新的流程，同时
也有可能对现有流程有一些改进的地方，涉及现有流程修改的具体内
容，都需要提交CR申请。
其他流程变革项目CR：非研发领域的流程项目，但涉及研发流程
配套修改的内容，也需要提交CR申请。
每年研发领域的CR数量大概有50条左右，涉及更改的流程文件的
上百份（包括流程图、模板、指导书、Checklist等），所以CR的管理
是非常重要的。在华为，我们通过研发流程CCB的运作对研发流程领域
所有的CR进行管理。 CCB有固定的运作秘书，一般由研发流程部的流
程管理工程师担任。运作秘书一般会在前一年的12月制定会议日历，
将第二年全年的会议日期确定下来（一般是每月一次，一次半天），
然后按照月度会议时间召集会议。
CR的管理过程：CR的发起者通过CR电子流提交材料，材料中说明
CR的原因、涉及的流程文件、与相关人的沟通记录等。运作秘书收到
电子流以后，会对材料进行初审，初审通过后与相关流程的责任人进
行沟通，然后安排议题，组织评审会议。通过CCB会议评审的CR,由运
作秘书记录在CR清单中，在流程版本发布前，集中更改涉及的流程文
件，随版本发布。CR管理流程如图10.9所示。

研发流程版本发布：每年的7月、8月是研发流程版本发布的时
间。在正式发布之前的一个月左右，是集中修改流程文件的时候。文
档需要审批上传，流程图、活动图都要根据CR清单实施修改。等到所
有变更都修改完毕后，研发流程部部长会汇集变更中的要点，到研发
流程改进委员会和研发部部长会议上进行汇报，经过中央研发部部长
同意后，研发流程正式发布。
如果有流程变革项目进度拖延了，没有赶上流程版本发布的节
奏，就只能等到下一年。除非非常紧急的情况下，研发流程才会增发
版本。
研发流程推行：我认为研发流程的推行是非常重要的环节，也是
整个流程管理中比较难的一个环节。流程变革项目在运作的过程中虽
然有试点项目，但试点项目毕竟是少数几个项目，不可能覆盖公司所
有的项目类型，而推行却是在整个公司的推行。在流程版本发布以
后，与产品线接口的流程管理专家会到产品线IPMT，研发管理会议上
汇报流程版本的重要变更点，以取得产品线领导的支持。同时，流程
管理专家和产品线流程负责人会根据CR清单，逐条对变更进行适配。
适配中最重要的两个文件，一个是流程活动，另一个是交付件模板，
这两个是关系到流程是否能够正确执行、产品交付是否合格最重要的
内容。如果某个变更对某个产品来说确实不需要推行或部分推行，都
得在适配的时候提出来，并且给出适配的具体方案。个人认为适配是
推行环节中非常重要的一个前奏环节，适配做得好不好，关系到流程
推行的难易程度，同时，适配也是对流程管理专家和产品线流程负责
人一个非常重大的考验。必须对流程的变更和产品线产品非常熟悉，
才能做出正确的适配。如果流程的推行过程，被认为一定是自上而下
的，或研发人员认为流程的变更对于业务没有帮助还必须推行，那我
认为，这是推行的前期适配工作没有做好。适配也分层级：首先是产
品线一级的适配，然后是SPDT，PDT的适配，最后是产品项目的适
配。在产品项目的质量策划中，就得明确相关的流程活动及交付件，
这也为后续流程的验收打下基础。
流程验收：流程验收是在第二年的5月份左右，验收的过程用图
10.10来进行说明。

研发流程的变更会涉及产品的整个开发过程，所以验收的项目尽
量选择进展时间长的，可以验收到更多的变更点。验收项目的多少也
要根据产品线和验收清单的覆盖点来确定。一般情况下一个产品线差
不多验收4、5个项目。如果整体验收结果出来后，发现有一些变更点
都没有验收到，可以再补抽查。
交付件的审查主要看新模板的使用情况及交付件的归档，密集是
否符合要求。目前对于有特殊市场要求的产品，会审查得更严格一
些。
验收会议主要是对项目成员的访谈，包括项目经理、QA、研发人
员、配置经理等各领域角色。验收会议的目的主要是对项目过程的规
范性和流程遵从性做一个调查和了解，同时对流程变革的内容做一个
了解，变革内容是否合适，产品在执行的过程中有没有遇到什么问题
和困难，对于流程还有哪些建议，这些都是对流程改进的一个很好的
输入。所以，如果你是产品线的研发人员，如果你的项目正在被验
收，不要拒绝也不要应付了事，这是一个很好的机会，让流程能离你
们更近。
验收报告也分几层：单个项目的验收报告，产品线的验收报告，
以及整个研发流程的验收报告。整个研发流程的验收报告需要在研发
流程改进委员会汇报，各个产品线的验收情况会拉通，所以哪个产品
线对流程的执行度是什么情况就一目了然了。
研发流程版本管理的过程大致就介绍到此了，大家是否有领悟到
把一个领域的流程整体进行版本管理的好处？总结如下。
从全局出发进行统筹规划，有利于抓重点，集中优势兵力攻克最
重要的内容；也有利于理清项目之间的关联性，避免为了做项目而做
项目的情况。
版本中的项目管理：对项目质量把关，也对项目进度进行管控，
把握了版本的整体节奏。统一发布，集中推行，集中验收，有利于业
务一线全面了解流程的变更点，更利于流程的推行和验收。
案例二：永远有多远？就像as-is和to-be的距离。
这个案例是我亲身参与的流程优化咨询项目的故事，给正在做流
程建设的朋友们提供一点思考的方向。
这个项目还在商务接洽的时候，老板就跟我们说：“你们不需要和
员工接触，就跟我谈就好了，我是这个公司最懂业务的人。”尽管我们
强调了让员工参与项目的好处及后续落地的可行性，但是老板坚持
说：“他们都不理解我的想法，你们按照我的想法来做，就行了。流程
做好后让他们照着执行，不行的话就全部换人。”流程的验收也是老板
自己看完就行。整个项目周期要短，一个月内要全部做完。于是，一
个奇怪的项目组就诞生了：
项目经理：对方公司副总兼总裁办G小姐，刚到公司1个月，几乎
不懂公司业务。
项目助理：对方公司M小姐，刚到公司2个月，主要负责公司的项
目管理，也不懂公司主业务。
项目成员：对方公司老板，三个顾问（无行业经验）。
也就是说，6人组的项目成员中，真正熟悉业务的有且仅有一个
人。从这里，是不是就可以看到风险了？我们当时有意识到这是一个
风险，但没有完全重视，因为从前期和老板的谈话中，确实可以看出
来他非常懂业务，也看到了他想彻底改变业务的想法，所以对于我们
来说，就是用我们的专业知识，加上他对业务的理解，把流程架构、
核心业务流程梳理出来。
事实上，前期进展得也很迅速，在跟老板谈了两次以后，我们就
梳理出了整个的流程架构及这次要梳理的主要业务流程范围（4个主流
程），也得到了老板的认可。那问题是怎么发生的呢？
流程的要素有哪些，大家还记得吗？责任人、输入、输出、活动
描述，这几个是最基本的要素，而且要理清楚这几个要素其实也不是
太难的事情，那问题出在哪里呢？出现在流程细化的过程中。
也许是老板太久没有跟下属沟通过他对业务的畅想了，所以在讨
论业务流程的时候，老板畅所欲言，跟我们描绘了很多他对未来业务
的想法，包括业务模式的改变、整个业务流的改变，以及整个组织的
调整，同时，也要求这些构想都融入流程中，也就是说，我们根据他
的描述，整理出来一个to-be的业务流程架构。光有流程的架构、流程
的主要活动是不够的，必须细化活动内容，也需要梳理文件模板，就
在这个阶段，问题得到了充分的暴露。首先，老板对于业务的细节，
已经不再了解，毕竟有些业务他已经不需要亲自动手了，在脱离一线
的过程中，也就脱离了业务。其次，对于行业来说，我们是彻底的外
行，判断不出来老板的to-be中，有多少是与as-is差距巨大的，有多少
是可以跳跳就能够得着的，所以只能在老板和一线业务中来回寻找平
衡。来来回回的过程中，老板也意识到了，过于激进的改变可能不是
最好的处理方式，最终同意大逻辑架构以他的构想为准，但具体业务
活动的细节，以业务部门为准，验收也以业务部门的意见为准。这也
算是老板对业务部分的妥协，他还无法真正下定决心，让所有事情重
新开始。
其实到这个点上，就可以判断项目已经离失败不远了，因为项目
的时间已经过半，任务却又回到了起点。只能再次反思，如何做才能
让流程优化成功。
（1）从项目构成来说，项目成员中必须包括一线业务人员，也就
是离实际业务最近的人。只有他们了解业务操作过程中的细节，对各
种业务场景的处理方式最熟悉。项目成员中也必须包含懂流程的人，
能够帮助大家从细节中解脱出来，看到整个业务流程的大架构，看到
流程的层次，看到流程与流程的交界。
（2）从项目的流程来讲，第一步永远是现状分析。不了解现状，
不足以谈未来，至少我是这样认为的。如果真的是一个新公司，全新
的商业模式，另当别论。公司有流程或没有流程，现状分析的方法也
有差异。在有流程的情况下，要看流程的执行度，也就是说要看看现
在业务是不是按照流程在跑，如果没有按照流程跑，现在真实的业务
情况是什么样的？和流程的差异有多大？造成这些差异的原因在哪
里？针对没有流程的公司，就需要根据业务情况，把as-is的流程描述
出来。也就是说，在现状分析的阶段，我们要得到as-is流程，以及流
程和实际业务的差距分析。
（3）描述to-be。to-be不是空想，而是根据一系列的事实依据提
出的优化、改进方向，也就是说， to-be是有论据来支撑的，to-be能
给业务带来的好处，是可以清晰描绘的。对于to-be的构想，要在整个
项目的范围内进行充分讨论，看看对于一些典型的业务场景，是否能
够走得通。在流程建设项目中，我认为“蓝军”的角色很关键，可以对
to-be提出各种假设，进行攻击，看看to-be是否真的比as-is更优。
（4）将as-is和to-be差异明确的地方拉出来，同时考虑to-be落地
的计划。识别to-be在实施过程中可能会受到的阻力以及应对措施，包
括识别干系人、与干系人进行沟通等等，都是为将来to-be的有效落地
做准备。
（5）业务试点。根据to-be的长度和难度，选择试点方式。最好能
在典型业务中进行to-be的试点，直接根据流程来跑业务，看看会遇到
什么样的问题。再来看如何解决问题，或者进行to-be的调整和优化。
套路其实也就这些，只是我们面临不同对象的时候，所需要做的
“技巧性”工作会有各种差别，这需要我们在实际项目中灵活的运用了。
弯路不能完全避免，只希望我们边走边思考，能少走一点弯路，也能
将to-be和as-is的距离缩短一点。
10.6 流程不是万能的
前面讲这么多，是怕大家不重视流程，也希望能够通过有效的流
程管理办法帮助大家提升流程能力。但又担心有的管理者对流程的期
望过高，导致在看到流程验收报告后，会有失望和失落的感觉，觉得
辛辛苦苦做出来的流程辜负了他，甚至对流程、对自己的方向又有产
生了怀疑。我只能说，当出现这种情况的时候，也是正常现象，因为
流程不是万能的。问题来源于方方面面，我们需要去分辨，哪些属于
流程能解决的问题，哪些属于流程解决不了的问题，再去寻找根因，
找到对应的解决办法。这才是管理的终极。
仍然结合案例来讲。一个结构开发流程推行半年后进行了验收，
在验收过程中暴露出来一些问题：
（1）流程活动看起来很完整了，但实际上在进行开发的过程
中，有些活动很难执行落地。
（2）计划和实际的项目进度偏差大。
（3）有的环节等待时间太长。
下面开始抽丝剥茧，对每个问题进行深入访谈、分析。
首先看第一个问题，有些活动难以执行落地。分析以后发现，难
以落地的活动主要有两类，一类是计算分析类的活动，一类是与供应
商有关的活动。在整个开发过程中，涉及很多需要计算、分析的内
容，但是工程师做不出来。模板里定了框架，但没有具体的计算步骤
和案例，所以还是不会做。为什么没有案例？因为公司几乎都没有项
目从头到尾计算过，完全没有积累。所以这个问题实际上是人员结
构、员工能力、公司经验积累、培训力度等几方面的问题。这个结构
开发团队里的新人占比67%，能力不足可以理解。那针对能力不足、
项目没有积累的现状，怎么做？成立专项小组，挑选有经验的工程师
进组，通过师父带徒弟的方式，将这个项目需要分析和计算的内容完
善，同时形成培训材料和案例。实际的业务过程，就跟带兵打仗一
样，光有兵法不够，得一仗一仗地打，打赢，才能真的形成战斗力。
结构件涉及很多和供应商打交道的内容，比如样机制作、开模等，我
们设计的东西能不能做出来，有很大部分依赖于供应商，所以如果供
应商出现了问题，是比较难处理的。这点首先要保证双方对业务形成
共识，同时在关键节点，我们不能局限于我方的流程，必要的时候要
深入了解供应商的加工环节，看看是否能对加工过程进行干预，确保
对供应商的要求传递到位。实际上，对供应商的管理能否有效，取决
于业务量，所以对于初创企业来说，这本身就是一个难点，只能多协
调多沟通，但无法保障流程完全有效。
第二个问题是计划和实际的项目进度偏差大，访谈结果如下。
项目计划是项目经理主导在做，虽然流程中写了结构工程师要参
与结构计划的制订，但组内结构工程师没有经验，不知道在做具体设
计的时候，多久能做好，也没有向部门内的老工程师请教。较长时间
才能完成的任务，中间没有进行阶段检查，所以实际进展不及预期的
时候，也未进行干预。工程师遇到难点后，不主动反馈，自己死磕，
但是最终也没有磕出来。
这几点说明什么问题？首先还是能力问题，无论是项目管理还是
结构工程师，对于项目的难度、需要的时间和资源的估计是不足的，
也就是说连适配的能力都欠缺，对自己的认识也不够充分，无法判断
完成什么任务需要多少时间。其次是工作方式方法问题，没有形成主
动反馈的工作氛围，大家都等着项目管理来催作用，不会提出风险预
警。
第三个问题是有的环节等待时间太长。仔细分析下来，等待时间
较长的环节是审核环节。新员工较多，骨干员工太少，本来审核就变
成了一个瓶颈，再加上前期的设计工作审核工程师参与得少，对工程
师的设计思路不清楚，需要花时间去看整个设计的来龙去脉，时间当
然就长了。另外IT系统的key太少，经常登录不上去，无法处理图纸的
签核流程。这个问题主要是团队人员结构的问题，从结构上来说，新
老搭配是比较好的，一来老人可以带新人，另外也可以对项目产出把
关，就不要额外的外援审核团队了。另一个是IT系统的问题，公司整
体发展了，规模变大了，IT系统还维持老样子，这确实对业务也是一
种制约。
总结前面几个问题其实不难发现，流程真不是万能的，千万不要
认为制订出一套流程后，研发效率马上就提高了，质量问题马上就减
少了，整个工作都顺畅无比。只有当流程、组织、能力、文化、IT工
具都同步发展了，才能支撑企业的快速发展。
最后想强调一下，流程化的东西都是长期积累下来的。比如硬件
开发经常遇到的器件选型，我们需要考虑器件的可靠性、可生产性、
可供应性等因素，那么这些因素的考虑，是把之前产品积累的内容，
在器件选型的阶段就融入过来，而这些融入的因素不是简单一些思考
维度，而是长时间的案例和经验、人员的积累。小公司在没有经验积
累的时候，快速迭代变得尤为重要，一个版本的总结和积累非常重
要。否则，每个版本都没有进步的话，就不断地原地踏步，做多少个
版本，还是一样BUG一堆。
10.7 流程的核心方法论
其实很多公司都对研发流程感兴趣，甚至很多公司花重金找咨询
公司咨询华为的研发流程。但是如果没有以下几个关键点，很难去复
制华为在IPD流程上推广的成功：
（1）从上到下变革的决心。新城容易建设，旧城改造难度大。
（2）有足够多的角色承载在整个流程中。小公司没有那么多人力
和角色分配，很难实现IPD流程执行。
（3）有IT系统去承载一些关键内容。如果没有电子流，很多流程
完全依赖人的自觉，或者依赖人的管理有时是很难执行的。
（4）掌握流程的精髓、核心方法论，不要生搬硬套，不然画虎不
成反类犬。
所以硬十团队根据自身经历，包括在大公司工作的经历，以及自
己创业的经历，总结了适合小公司管理硬件开发流程的核心方法论，
包括以下四个方面。
1.先僵化、后优化、再固化
华为自身没有生搬硬套IPD流程，所以成功了。
除华为外，中国企业最早引入IPD项目咨询的时间是2002年，之后
在国内有很多企业引入IPD。大部分企业IPD流程仍停留在如何“低成
本、高效、高质量地开发产品”，产品开发流程上并无变化，导致以下
问题。
没有建立需求驱动产品开发过程，没有建立需求端到端流程，将
会出现以下两种情况：一是IPD流程成为研发搪塞市场需求和推诿责任
的工具；二是在市场冲击下，由于IPD建设不合理，僵化无法面对市
场，企业无奈地启用以前流程，以前怎么走还是怎么走，IPD成为历
史。
企业建立的IPD流程复杂，流程效率极低，IPD流程与公司运营流
程脱节，加上市场在变，业务在变，IPD流程一直僵化在1.0版本。没
有优化，认为好东西就不用变化。IPD流程实施后并没有带来显著的竞
争力提升，IPD流程成为痛心之点。
高科技企业软件开发工作量占绝大多数，而多数企业仍以IPD流程
模型支撑软件开发，软件开发效率与效果均不理想，软件质量差。企
业没有想到可以使用“IPD+CMM”或“IPD+敏捷开发流程”解决软件管理
问题。
所以，任正非的不败之谜在于“变化”，在于不断地“自我反省与自
我修正”。
2.统筹方法
“关键路径”之所以关键，就是因为这些事务或工作中耦合关系多、
执行难度大、延期风险高，对项目达成目标影响较大的，也因为关
键，所以值得项目经理集中精力管理。在拟定计划的过程中，寻找关
键路径，合理安排和统筹，并固化下来形成“流程”，这就是统筹方法。
3.阶段性评审
IPD流程设置了很多技术评审点，小公司可能不需要这多评审点，
但是每个环节都应该有个检查点，而不是等东西出来了，做个四不
像，最后傻眼了。
但是如果主管水平不够，或者不懂技术，那就麻烦了，因为没法
细致到每个细节去把握。每个开发人员都可以造成一种虚假繁荣的景
象。
例如华为的度量表、单板返还率、直通率的考核指标，其实都是
可以通过人为操作，造成一种虚假繁荣的景象，所以经常不深入细节
的主管很容易被蒙蔽。
下面介绍两种评审机制DCP和TR。
DCP是Decision Check Point（业务决策评审点）的缩写，业务决
策评审是集成产品开发管理团队（Integrated Product Management
Team，IPMT）管理产品投资的重要手段，在决策评审中，IPMT始终
站在投资商的角度来进行评审。整个开发流程包括5个决策评审点，如
图10.11所示。
Charter：立项评审。
CDCP（Concept DCP）：概念决策评审。
PDCP（Plan DCP）：计划决策评审。
ADCP（Availability DCP）：可获得性决策评审。
EDCP（EOL DCP）：生命周期终止决策评审。

TR是Technical Review（技术评审）的缩写。通过技术评审，帮助
产品开发团队尽早发现产品开发中存在的问题和风险，及时采取相应
的解决方案和行动计划，保证产品开发质量，减少浪费。整个开发流
程包括以下6个技术评审点，如图10.12所示。
TR1：产品需求和概念评审。
TR2：需求分解和规格评审。
TR3：总体方案评审。
TR4：模块/系统评审。
TR4A：集成测试评审。
TR5：样机评审。
TR6：小批量评审。

个人认为IPD流程的一些评审点没有涵盖硬件开发的所有关键点，
所以我们不用照搬IPD流程的评审点，而是抓住硬件的关键评审点。可
以借鉴硬十的开发流程框架，如图10.13所示。

在上述框架中，需要抓3个硬件关键评审点：需求、投板、生产导
入。
4.严格把控从上一个环节进入下一个环节的条件
这点我特别有感触，如果华为的某些指标达不成公司设定的要
求，那么是不允许进入下一个环节的。例如，华为的直通率要求在
95%以上，如果达不成这个指标，产品是不让发货的。需要反复地验
证和优化设计、工艺等，直到小批量试制达成指标了，才允许过点，
进入下一个环节。
但是一些小公司，并不在乎这个指标。一旦产品海量发货了，就
是给自己找麻烦。曾经在一个小公司待过，那个公司直通率还不到
50%时，就开始发货。导致整个硬件团队深陷泥潭，中标如中箭。
最后总结一下，我个人理解的华为研发管理的10个模块，大致上
分为“法制”和“人治”两个维度。个人建议，在学习华为方面，先把“人
治”做到，否则也只是邯郸学步，最后弄巧成拙。
20世纪90年代初期，随着迈克尔·哈默接连推出《企业再造》《超
越再造》，管理界掀起了一股流程再造的风潮，流程管理也逐渐被大
家熟知；20世纪90年代末期，华为引入IBM，开始了漫长的产品管理
体系的变革，随着华为在商业上取得巨大的成功，华为的管理体系也
逐渐被业界熟悉，IPD体系成为被科技制造业争相学习的典范，如今更
是辐射到很多其他的行业，甚至金融、互联网都在学。然而，学得好
的企业凤毛麟角，学得不怎么好的企业多如牛毛，于是渐渐又出现了
另外一些声音，“搞IPD就是建流程”“流程无用”“华为是军事化管理，所
以才能执行流程”……在我看来，流程是一种基础管理手段，没有必要
神话，业务没搞清楚，流程做得再好也没有用，但也没有必要贬低，
因为我们也确实看到了在很多的企业中流程管理发挥的作用。所以我
们单独写了本章内容，就是希望能够把流程真实地还原，希望大家能
够体会流程管理的本质。
如果你所在的企业是创业公司，还在从0到1苦苦挣扎的过程中，
这章内容可以先忽略。如果你所在的企业已经解决了生存问题，处于
快速扩张阶段；如果你所在的企业已经达到一定规模，但效率已经出
现了瓶颈；如果你所在的企业内卷特别严重，和周边部门的配合特别
不顺……你都可以好好地阅读本章节，领悟一些思想。