流程构建类似于全新产品的研发过程，一般是当企业研发流程混乱、严重不适应业务发展时进行的。因此，流程构建的工作量很大，将会对现有工作习惯造成很大冲击，其实施风险也较大。在进行流程构建时，基本步骤如图3-17所示。

图3-17流程构建的基本步骤

​ 流程体系设计

首先需要明确研发流程体系中包括的典型流程以及相互的接口关系。某公司决定以集成产品开发体系为参考，建立符合其研发特点的流程体系。如图3-18所示。

图3-18流程体系设计

可以看到，整个研发流程体系包括需求管理、产品规划、产品开发、技术实现和生命周期管理等主要流程。产品规划流程主要输出《产品路标》，并且生成《项目任务书》后启动产品开发流程；需求管理流程负责处理来自外部和市场的需求信息，按照重要性和时间紧迫程度，需求有三个分发路径，其中纳入《产品包需求》的需求将会随着《项目任务书》，一并作为项目启动的必要输入。

​ 流程框架设计

接下来需要对产品研发流程划分阶段，明确各个阶段的含义与目的、重要的输出成果；并且定义关键性的业务决策点和技术评审点。以集成产品开发流程为例，划分了概念、计划、开发、验证、发布和生命周期六个阶段，并且设立了四个业务决策点和六个技术评审点。如图3-19所示。

图3-19研发流程阶段

针对概念阶段，其阶段目标为“对产品机会的总体吸引力及是否符合公司的总体策略做出快速评估”，主要关注分析市场机会、成功因素和业务风险等。典型输出件包括《初步的业务计划》《初级项目计划》《产品包需求》。

概念阶段的主要活动如图3-20所示。

图3-20概念阶段的主要活动

​ 流程细节设计

接下来需要将流程框架细化为操作级别的流程。在流程细节设计时，首先明确流程中的角色，再将各角色在流程中所承担的活动横向展开，并考虑活动之间的协作关系和交付件。

在进行细节设计时，细节展现到何种程度，这是个需要仔细斟酌的问题。

一方面需要考虑流程执行者的普遍业务能力，即管理制度与团队技能相适应。

如果执行者业务能力较强，则流程细节可以保持较粗的颗粒度，执行者能够在实际工作中有针对性地调整和补充细节，并不会由于流程简练而遗漏关键任务，进而影响工作质量。反之，过细的颗粒度则会带来冗余，影响工作效率。

如果执行者业务能力较弱或者缺乏经验，则需要展现详细的工作细节，否则容易导致工作不完整，最终影响工作质量和效率。

下面两张图都展现了研发阶段流程的细节片段，不同之处是后者更加详细。我们无法简单地断定哪个流程的细节设计更加优秀：前者更加适用于富有经验的项目经理；后者则更加适用于初级的项目经理。如图3-21、图3-22所示。

图3-21概念阶段流程1

图3-22概念阶段流程2

另一方面需要从流程使用者角度考虑细节设计，这其实反映了管理制度对产品的适配。研发流程的使用者主要是各级项目经理和项目团队，它需要符合项目经理的管理跨度和范围。

某公司重视流程的可视化管理，于是花费很大的精力，将覆盖公司全业务的十三大类、数百个流程均细化至操作级别，并绘制在一张大图上。于是带来的一个明显问题是流程查找极为不易，流程执行者查看的仍然是和自己工作相关的部分流程。这样的流程总图除了看起来很震撼之外，在实际工作中并没有价值。务实的做法是将流程分层级、分类别地展现出来，既便于检索使用，也便于流程的管理。

如果研发流程的活动并不复杂，在项目经理能够直接管理全部活动的情况下，将活动细节全部展开是可行的。但是对于流程活动比较复杂的情况，项目经理应当负责顶层计划的管理，各领域负责人负责底层计划的管理，甚至根据其产品的复杂程度，有些企业的研发流程可能要依次分为若干层级。

图3-23展示了概念阶段的详细流程片段。

图3-23 概念阶段的详细流程片段

​ 制定裁剪规则

那么对于非全新产品研发项目，比如改进、增强、定制类项目，如何使用产品研发流程？让项目经理以完整的流程为基础进行裁剪，是否可行？事实上是不行的，全新开发流程是活动全集，在全集中裁剪出仅剩下不到一半活动的流程，对于项目经理而言是不可接受的。

因此，就需要考虑项目特点，预先为典型项目裁剪出合适的研发流程。项目经理开展工作时，在这个裁剪后流程的基础上制定出符合自己需要的项目计划。切莫轻视流程裁剪的工作，它直接决定了项目经理对流程的接受程度，也影响了项目管理的效率。

图3-24展示了流程裁剪的典型思路。

图3-24 流程裁剪的典型思路

​ 交付件模板设计&评审运作规则设计

接下来需要进行操作级别的定义，包括活动的详细描述、文档模板的定义、技术评审和业务决策的具体过程、评审要素表设置等。这类工作非常繁杂和琐碎，由于工程师/项目成员直接使用模板开展设计工作，因此这也是最为增值的环节。如果细节模板的质量不佳，一方面影响工作效率；另一方面也让项目组对流程持抵触态度。

高质量的文档模板具备如下明显的特征：

​ 体现产品特点和技术要素；

​ 能够帮助工程师提高工作质量；

​ 简练、明确、无冗余。

下面我们观察几个交付件模板的样例：

图3-25“可测试性”需求的片段

图3-25是产品需求文档中“可测试性”需求的片段。在模板中，描述了可测试性需求的具体含义，而且后面给出了一个样例。

虽然改进者的工作很用心，但是通常需求工程师具备一定的经验，对“可测试性需求”已有清晰理解，大段的描述信息就显得多余。在实际工作的时候，需求工程师还要将这些描述信息删掉，容易打断思路，使用效果并不理想。

再看图3-26的需求模板片段。

图3-26 需求模板片段

我们无法看到模板对产品特征的体现，这是一个“放之四海而皆准”的模板，并不具备针对性；需求定义人员需要考虑精度、时间特性要求的具体指标，这样的模板聊胜于无。

我们再看图3-27这个系统级产品设计方案的框架。

图3-27 系统级产品设计方案的框架

我们可以很直观地体会到“自顶向下”的设计思路，从系统总体设计思想到子系统划分和需求分配，再到各个子系统的架构设计、最后是各类专项需求的设计。设计文档的撰写过程，就是指导工程师进行设计的过程，而且体现了产品的技术特征，因此这个设计文档模板框架是高质量的。

为了提高交付件模板的设计质量，通常会邀请业务专家参与设计工作，把产品特点、设计过程和技术要点融入模板中，令使用者提高工作质量和效率，这样才能为工程师所接受。

从流程体系设计到细节模板设计，是逐步细化、深入业务的过程。不同企业可能具有极其相似的流程体系，但越到底层，越会出现明显的差异性，流程设计的难度也越高。细节设计关系到流程执行的最终质量，因此需要给予更多关注。

前面阐述了流程构建的主要步骤和方法。在多数情况下，企业的研发流程并没有混乱到需要重新构建的程度，只需对研发流程进行梳理即可。