第四章 产品开发过程

IPD产品开发流程通常包括产品开发袖珍卡、阶段流程、结构设计、外观设计、硬件设计和软件设计子流程，操作指导书，工作模板。特点是结构化、并行化、集成化。梳理产品开发流程的目的是企业研发人员可以参考流程进行产品开发，避免遗漏。

产品开发流程一般分6个阶段：概念、计划、开发、验证、发布和生命周期，如表4-1所示。通常前两个阶段需要确定需求、规格、方案，难度较大，后面四个阶段难度相对较小。很多企业因为前两个阶段水平不够或者投入时间不够导致后面大量的设计更改。

产品开发流程梳理的另一个目的是不希望一个人从头干到尾，不是每个活动都需要高水平的研发人员去做。高水平的人通常不愿意干低水平的事情，而且高水平的人干了低水平的事情对于企业而言投入产出比就低了。建议企业列出不同人员等级负责的活动清单，形成各个级别人员的标准，可以对研发人员进行认证，达到某个级别就大概知道能负责哪些事情。

4.1 流程设计原则

4.1.1 设计方法：瀑布和迭代

典型生命周期模型包括瀑布模型和迭代模型。瀑布模型由于酷似瀑布闻名，该模型通过强制提供文档来确保每个阶段都能完成任务，实际上往往难以做好。想象一下，我们去买衣服的时候，售货员给我们出示一本厚厚的服装规格说明，我们会是什么样的感触。所以瀑布模型在过程能力上有天生的缺陷，问题一般到最后才会暴露出来。迭代模型类似小型的瀑布式项目，所有的阶段都可以细分为迭代。每次迭代产生一个可以发布的产品。在某种程度上，迭代是一次完整地经过所有工作流程的过程，包括需求收集、分析设计、实施和测试等环节，如图4-1所示。

迭代模型和瀑布模型的最大的差别在于风险的暴露时间上，不管开发团队经验有多丰富，都很难预知所有的风险。瀑布模型一般有许多风险直到已准备集成系统时才被发现。而迭代模型能在生命周期中尽早发现和避免风险，计划会更趋精确，如图4-2所示。

IPD产品开发流程可视为典型的瀑布式模型。但是随着互联网时代的兴起，产品开发特别是软件产品开发追求以用户为中心、快速迭代、流程简化、研发工程师之间的充分沟通和自学习等能力，同时因为软件修改比较容易，所以软件产品大多采用敏捷迭代模型。产品开发未来的趋势是敏捷迭代模型。

IPD产品开发流程敏捷迭代可考虑从两个角度实现，一是在TR2～TR4A流程中实现敏捷，引入敏捷思想和实践。二是从一个产品中多个需求的串行开发转变到基于小需求包的并行开发。要求需求管理、版本规划、跨部门协同的实践更加充分。全流程角度减少需求等待时间，最高限度的缩短上市时间，更聚焦客户价值。

由于绝大多数快速成长型企业仍以瀑布式开发为主，故本书主题还是以IPD产品开发流程为示范，仅在软件管理章节加入迭代（敏捷开发）部分的内容介绍。

案例分析：互联网公司开发产品的“快”。

某游戏公司Q率先推出了一款“吃鸡”游戏，三天后同行W公司开发出类似游戏，一周后T公司也开发出类似的游戏。这些公司把996（早9点到晚9点，6天班）变成了724（7天24小时）。在互联网时代，最快推出的产品的公司往往“赢者通吃”，产品推出稍晚就需要花费几何倍数的推广成本，还不一定能达到效果。

4.1.2 流程设计原则

流程不能期望完美，要足够简单，在结构化和非结构化之间需要保持平衡，效率和质量之间也需要保持平衡。

■互联网时代一切崇尚极致的简单，尤其是快速成长型企业的研发人员变动也非常快，所以建议流程用简单的工具设计，研发人员能一眼看明白，最好零基础的人能一眼看明白。两个简单的原则是Don'tmake me think, Keep it sample and stupid（KISS）；

■能够一张图显示整体；

■流程并不是越全越细越好，能够快速展示重点活动，非重点活动另行展示；

■不要花里胡哨，也不要密密麻麻。

4.2 研发6大阶段流程概述

笔者提供的一种简单流程设计画法如图4-3所示。

4.2.1 流程活动概要介绍

流程活动概要介绍如表4-2所示。

4.2.2 核心监控要点

核心监控要点如表4-3所示。

4.3 6大阶段流程-项目任务书阶段

规范和管理研发项目的立项及项目的启动流程，确保研发项目的目标是明确的，满足客户需求，资源配置充分，减少不充分立项导致的损失。如表4-4所示。

4.4 6大阶段流程-概念阶段

规范和管理研发项目在概念阶段的流程，确保对客户的理解是充分的和完整的，为后续的设计和优化阶段确定明确的方向，为项目测试验收提供依据。如表4-5所示。

4.5 6大阶段流程-计划阶段

规范和管理研发项目设计阶段的工作程序、工作职责、工作方法，以确保项目设计分析的完整性和准确性。如表4-6所示。

4.6 6大阶段流程-开发阶段

4.6.1 结构开发

结构开发如表4-7所示。

4.6.2 硬件开发

硬件开发如表4-8所示。

4.6.3 软件开发

软件开发如表4-9所示。

4.6.4 测试开发

测试开发如表4-10所示。

4.6.5 资料开发

资料开发如表4-11所示。

4.6.6 制造工艺开发

制造工艺开发如表4-12所示。

4.6.7 样机制作与测试

样机制作与测试如表4-13所示。

4.7 6大阶段流程-验证阶段

小批量试产阶段为大批量生产前的可靠性验证和试产验证阶段，是为有量产订单的产品而服务的，如表4-14所示。

4.8 6大阶段流程-发布阶段

发布阶段如表4-15所示。

在GA日期之后，IPMT要成立一个生命周期管理团队（LMT）来代替PDT继续负责在产品的整个生命周期内监管产品，PDT随后将被解散。

4.9 各代表关注点及主要活动

4.9.1 市场代表关注点及主要活动

市场代表关注点及主要活动如表4-16所示。

4.9.2 财经代表关注点及主要活动

财经代表关注点及主要活动如表4-17所示。

4.9.3 测试代表关注点及主要活动

测试代表关注点及主要活动如表4-18所示。

4.9.4 采购代表关注点及主要活动

采购代表关注点及主要活动如表4-19所示。

4.9.5 制造代表关注点及主要活动

制造代表关注点及主要活动如表4-20所示。

4.9.6 服务代表关注点及主要活动

服务代表关注点及主要活动如表4-21所示。

4.9.7 PQA关注点及主要活动

PQA关注点及主要活动如表4-22所示。

4.9.8 质量管理代表关注点及主要活动

质量管理代表关注点及主要活动如表4-23所示。

4.10 产品开发过程专题

4.10.1 总体设计

在总体设计的设计初期，所处的状态可以类比于处在十字路口而又看不清楚路在何方，这个时候需要多方探索、综合论证。在进行总体设计方案论证过程中需要由具备各方面技术能力的系统设计人员组成系统设计组，对系统方案进行论证说明，向相关决策人员解释各种设计方案，同时需要有具备相关决策能力的人员根据相关的论证说明进行决策。

一项开发计划应当至少将10%～15%的资源投入到总体设计阶段。如果低于这一标准，将很可能导致无法对客户群做出准确把握。如果该项开发计划含有许多创新或实验的成分，那么这一百分比还应当适度提高。

以下是总体设计方案应该重点关注的内容：

♢在把握系统设计全局的同时关注系统设计的技术细节，系统设计方案是高层设计，但是高层设计不等于可以不关注系统实现的细节，在不影响进度的条件下，尽可能关注实现细节。因为对子问题的设计如果存在问题，那么整个系统的设计也不会完美；

♢不放过任何可能，在技术的论证过程中，对任何可能的思路都要进行充分的分析和论证，避免将隐患埋藏在这些可能中；

♢在开发中存在历史系统的情况下，对历史系统进行全面的分析可以帮助系统设计人员理解新系统的设计，同时明确从历史系统中可以继承和需要摒弃的内容；

♢能够进行深入分析和测试的内容尽量提前做实际的工作，总体设计不是仅仅靠思考来解决的问题，能够通过测试（仿真测试或者实际测试）来获取数据的测试一定要进行，实际的数据是设计最可靠的依据；

♢尽可能多收集数据，收集的数据包括和设计相关的各个方面，包括专利、历史系统的数据、技术发展趋势、标准的进展结论、标准的确定过程等；

♢集体讨论，进行尽可能多的过程分析评审，集体讨论是脑力激荡的过程，过程分析和评审是通过每一小步的控制来实现总体控制的有效方法。在系统论证的过程中需要进行重复收放的节奏控制，“放”是分头研究，“收”是集中讨论；

♢具体的方案给出若干选项，在可能的方案中通常没有绝对优或劣，对可能的方案都要给出若干选项，进行优缺点比较；

♢选择能最好满足所建立标准的解决方案，通常要确定选择的标准和原理，对以往的相关的老产品的解决方案的描述、评价；

♢为相互冲突的目标和方案做出优先级划分，明确权衡点，对优先级的划分是需要项目管理人员参与的工作，优缺点比较是决策的基础；

♢为验证设计输出满足设计输入的要求，制定产品设计功能的验证测试及试验方案；

♢明确需要的资源（人、财、物、时间）及费用；

♢提高设计文档的质量，形成的报告要有详细内容的表述，包括设计思路的清晰表达、风险预测、平衡点的选择等，设计文档是将所有经过思考的内容落实到纸面的工作产品，这些记录有利于后续的深入分析，同时也是解释前面问题的依据；

♢对模糊的内容做出量化，这方面是最难做到的，也是容易忽视的，例如系统的质量特性，要对系统的质量特性进行数据刻画，同时对达到该目标的可能途经进行分析。

验证总体设计方案的标准有：系统方案、系统设计与需求的一致性（可通过系统模型），系统方案与系统设计间的一致性，定义清楚各大模块间的接口，系统性能满足需求，模块划分合理，模块的输入输出接口定义恰当，充分考虑到模块的可重用性，模块细节描述清晰，可否直接用于开发。

4.10.2 流程裁剪原则

流程不是越细化越好，处于快速变化或者交期很短的行业，需求和产品变化非常快，产品生命周期短，流程结构化就不宜过于细化。企业研发规模比较大、产品比较复杂，涉及比较多的专业领域，流程可以细致一些，避免跨部门的沟通效率低，提高产品研发的质量。

（1）流程裁剪内容，如表4-24所示。

流程裁剪的目的是防止研发流程过度结构化，根据项目大小的不同，选择最优的流程和决策机制。

（2）裁剪流程，如表4-25裁剪流程。

4.10.3 并行工程

传统的开发流程特点：

♢信息流动是单向的，设计、制造过程中缺乏必要与及时的信息反馈，各环节配合不够紧密，设计制造不能一次成功；

♢基于图纸的设计，较多地依赖工程师的经验和试验数据；

♢缺少必要的产品开发、仿真工具，不能及早完善地考虑制造过程中质量控制等问题；

♢设计和工艺串行；

♢工艺设计完成前生产处于等待状态，生产准备时间较短，导致生产加工十分紧张，设备闲置时间较长；

♢产品的版本管理和变更管理手段落后，“孤岛”方式工作，集成手段差。

并行工程的目的是提高全过程（包括设计、工艺、制造、服务）中全面的质量，降低产品全生命周期中的成本（包括产品设计、制造、发送、支持、报废等成本），缩短产品研制开发周期（包括减少设计反复，降低设计时间、生产准备时间、制造时间、发送时间等）。

并行工程的方法有全三维设计，协同设计，MBD（ModelBasedDefinition，基于模型的工程定义），流程并行，流程并行工程如图4-4所示。

案例分析：某客车整车厂设计与工艺并行示例如表4-26所示。

4.11 研发主要支撑流程

研发主要支撑流程一般包括配置管理流程，产品认证流程，专利申请流程，外协管理流程，供应商物料认证流程，新供应商认证，问题、缺陷跟踪流程，物料描述变更流程，物料申请和维护流程，BOM发布流程，FAE流程等。

4.11.1 配置管理流程

配置管理流程如表4-27所示。

4.11.2 产品认证流程

产品认证流程如表4-28所示。

■网上登记后，会在网站上显示需要准备的资料清单。如果申请的类别是第一次申请，则先要取得相应类别的工厂检查报告，再进行下面的认证程序；

■样机一般由硬件工程师准备，在送检实验室之前最好先检测；

■收到样品后，认证工程师注意保存样品，以备以后查验，及时通知结构工程师修改物料清单；

■CCC标志尺寸大小和工程师要确认好，CCC标志有效期为1年，每年进行年效。

认证需要的资料清单如表4-29所示。

4.11.3 专利申请流程

专利是指发明、实用新型和外观设计。发明专利是指对产品、方法或者其改进所提出的新的技术方案。实用新型专利是指对产品的形状、构造或者其结合所提出的适于实用的新的技术方案。外观设计专利是指对产品的形状、图案或者其结合，以及色彩与形状、图案的结合所做出的富有美感并适于工业应用的新设计。发明专利权的期限为二十年，实用新型专利权和外观设计专利权的期限为十年，均自申请日起计算。没有按规定缴纳年费的，专利权终止。每年的缴费时间为专利申请日前一个月。

设立专职或者兼职的专利申报员，专职负责公司的专利的申请及日常管理工作。职责包括：

♢定期收集国内外相关的专利信息，尤其是竞争对手的专利信息，并对收集到的专利信息进行整理、分析、预测、做出研究报告；

♢负责对公司员工进行专利知识培训；

♢负责专利申请、专利运营、专利权维持和维护、专利纠纷处理等；

♢负责专利奖励和专利测评，鼓励和支持公司员工的发明创造。

专利申请流程如表4-30所示。

4.12 流程常见的问题及对策

4.12.1 流程需要优化的现象有哪些

■开发产品没有一个“统一方法”；

■术语和定义不一致；

■注意力集中在“救火”上；

■过多的澄清会议；

■中层管理人员太多（太多会议）；

■无法估计出资源需求（很忙、没有头绪）；

■进度表不准确；

■无法估计出资源需求；

■小组与小组之间的计划不衔接（对出现问题有不同的理解）；

■过量的任务间的相互依赖；

■对职责理解不够；

■浪费在没有附加值的工作上的时间（协调、重做）。

4.12.2 流程优化的技巧

流程优化的技巧如表4-31所示。

4.12.3 流程如何有效推行

■简单，不要复杂难以理解的流程，也不需要制定过多的流程规范；

■抓住主要问题，不要贪大求全；

■研发管理核心人员的支持；

■注意宣传；

■推广团队的稳定性及有效培训；

■纠正预防；

■IT系统落地。

4.12.4 如何保证流程体系执行的质量

保证流程体系执行的质量如表4-32所示。

4.12.5 ODM/OEM行业VOC活动介绍

VOC是ODM/OEM类型项目的典型活动之一，对认证、知识产权、技术功能、测试和物料需求进行评估。一般自主研发项目则没有VOC活动。

VOC交付的内容包括：客户原始需求列表、关键物料风险评估报告、Q&A问题整理列表。

■项目经理根据立项阶段获得的市场信息进行VOC；

■按照要求完成客户原始需求列表和规格信息，VOC应该包括客户对象、收集需求的时间、方式（交谈、邮件、电话或传真等）、责任人、结束的时间和客户确认的时间；

■项目经理组织需求分析人员进行信息分析，并分组提出问题，将问题写入客户原始需求列表的Q&A部分。分组为硬件、软件、结构、硬件测试和软件测试；

■项目经理召开需求讨论会，组织需求分析人员对Q&A问题进行确认，删除不需要的问题，补充需要核实的问题；

■项目经理将问题发给客户并规定客户回复的时间；

■收到客户回复后，项目经理组织需求分析人员进行理解和消化，确定是否需要开始新一轮的VOC。