第四章 X 公司研发流程的改进
4.1 X 公司原有的产品研发流程【1】
首先，市场部门负责规划并实施市场调研，收集市场数据信息，这些信息既包括从客户收集的初级资料，也包括一些经过处理过的行业内信息。市场部门对这些信息进行分析汇总，识别出各个业务领域的机会，形成商业需求分析说明书。
研发管理部门取得商业需求分析说明书后，着手准备项目的立项。项目立项相关的材料通过逐级审批，由各部门领导评估项目文件。如果项目立项成功，则项目管理部门根据说明书中有关用户和市场的分析数据，开始做产品需求的整理和分析工作，之后形成详细的产品需求文档并进行项目资源评估。产品需求文档交付研发部门进行系统设计和详细设计，研发部门将具体的产品需求转换为产品功能，并进行软件模块的划分和开发，研发团队也可能根据最终用户的要求进行一部分产品的定制，最终的开发成果会交付测试部门进行测试，测试部门按照和研发部门共同制定的测试计划对产品进行测试。当产品的质量达到发布水平时，销售部门将产品正式发布给用户。同时后续的产品服务团队接手产品售后维护和意见反馈。
4.2 X 公司研发流程存在的问题分析
(1)研发项目风险大
和传统的软件产品相比，外部市场环境和技术趋势的变化对互联网的产品的影响更大。公司已有的产品立项评审主要还是面向技术可行性的评估，对市场和投资回报方面的评估不足。对产品评估是主要由研发部门负责，采取逐级审批的领导决策机制，缺乏系统规范的审批制度。研发部门对市场规划部门提交的需求说明书进行分析，对产品功能的合理性和技术可行性进行评估，以决定是否开始产品项目的研发。虽然这个评审过程可以在一定程度上对研发项目进行甄别和筛选，防止对公司资金和资源的浪费。但是，评审过程只是在项目立项时进行，项目一旦获得批准并进入研发阶段，就没有后续的评估环节，无法有效地对监控项目的进展情况和边界范围进行监控，研发失败风险仍然很大。这些问题直接导致的后果是直到项目开发的后期甚至到产品正式发布前才发现重大问题，产品无法按原计划上市，甚至因为技术和市场等原因使项目中途失败。这种情况不但给企业造成大量的资源浪费，而且也给企业的形象带来负面的影响。
为了降低项目的风险，就要在建立规范、系统的产品审批流程。根据 IPD 的管理思想，要把产品研发作为一项投资来看待。即便是产品立项成功，但是由于复杂多变的市场环境和不断增加的用户需求，产品研发的过程中仍然存在着很多不确定因素。因此，仅仅凭借产品立项时的技术评审来产品的研发显然是不够的，要在研发过程中不断的对研发的阶段性成果进行商业和技术两方面评审。产品的商业评审主要是针对市场定位和未来的投资回报进行评估，以选择最佳的产品研发项目进行投资，更重要的是及时淘汰没有市场前途的产品研发项目，把公司有限的资源分配到有市场前景的项目上去。另一方面，原来评审工作是由公司的研发部门主导的，由于专业水平和能力的限制，研发部门也无法进行业务相关的评审工作。因此，要建立规范、系统的产品评审过程，就要在组织结构方面提供支持。通过由财务、市场、研发、售后、测试部门主管组成的集成产品管理团队(IPMT)，共同主持研发过程中的商业评审和技术评审，尽可能的建设产品研发过程中的不确定性，从而有效的控制风险。
(2) 产品的研发周期长
X 公司的产品研发周期一般在 10 周到 12 周，相对于同行业的领先者已经落后。过长的产品研发周期严重影响了产品的上市时间。研发人员对进度的评估过于乐观，在技术开发工作开始以后，才发现技术储备不足。没有技术预研流程，一些重要的多个项目通用的产品特性没有事先准备好，导致研发团队不得不延迟项目的研发进度。由于技术的原因导致产品推迟上市，这种情况严重地影响了公司的市场战略布局，削弱了产品的竞争力。
公司没有规范的研发工作流程，类似产品研发项目却采用不同的产品研发工作流程，项目的质量和进度不易控制和评估。虽然随着研发团队成员技能的提高，在一些小型产品项目中可以省略一些步骤，但是，对这种做法必须依照详细的规定进行，不能由开发人员凭主观经验而决定。而且，由于没有规范的工作术语和规则，造成了研发人员容易对工作目标产生误解，拖延了项目的进程。
按照 IPD 流程管理的要求，建立结构化的管理流程加快产品研发的速度。虽然公司开发的各个产品是不同的，但是其开发过程所经历的具体步骤是相似的，而且产品研发组织的结构和运行机制也没有太大的差别。因此，这些类似的研发工作可以被定义为标准的产品研发阶段，并且详细规定整个研发工作的框架结构。
在研发工作管理框架内，建立通用术语描述工作的具体内容，消除沟通中的误解。
结构化的研发流程明确规定了每个阶段需要输入的文档、详细工作过程及过程技术后产生的阶段性成果。所以，从分析各个阶段的工作过程入手，在保证工作相关性不被打乱的情况下，可以将部分流程并行的进行，比如在产品设计阶段工作进行的同时，PDT 团队也可以为产品研发工作做好准备。而相对独立的通用功能模块的开发更是可以和其他产品并行的开发。
(3)产品研发流程工作效率低
公司的原有研发流程是类似于顺序的线性结构，每个阶段的工作的都要等上个阶段工作的完成。上一个阶段在工作的还在进行的时候，下一阶段所涉及到的职能部门只能等待，造成不必要的资源浪费。而且，各个研发阶段开发活动的定义不明确，虽然有些研发工作也可以并行进行甚至提前开始，但是并没有明确的结构化的流程保证这些提前工作步骤能够顺利地执行，这种看似“按部就班”的流程，实际上拖延了产品的研发进度。当然，用户需求频繁的变化也使得产品发布时间一再拖延。
因此，要提高产品研发工作的效率，要从研发工作流程入手，清除导致研发效率低下的障碍。通过分析结构，可以发现目前产品中存在着很多的类似功能，这些功能的内部实现也很类似。比如，目前公司的互联网产品中大多存在着数据库访问，网络通信，用户信息管理等功能。所以，可以将目前的产品结构按照产品的功能进行分解，提取出功能相同的模块和通用的技术基础。这些通用的功能模块和技术可以作为独立的内部产品，由技术开发部门先行开发完毕，在实施产品研发过程中提供给 PDT 使用。
4.3 改进后的 X 公司产品研发流程【2】
这个阶段的工作成果直接影响到项目的立项是否成功。概念阶段的主要工作是 PDT 核心团队以产品研发计划书的内容为基础，从产品的角度分析市场机会，和其他职能部门沟通，验证需求的可行性，形成最终的用户需求的清单。由于互联网行业的特点，用户的需求十分繁杂而且变化迅速，而经过市场流程搜集的用户需求是比较初级和粗粒度的。 因此，必须概念阶段对产品的需求进行细化和优先级排序，筛选出最佳的待实现需求集，形成可实施的产品概念。
在此过程中，产品研发团队(PDT)对计划书中与商业需求相关的内容进行修改和调整，以保证需求列表是合理的，可实现的。需求整理的过程中也可以参考市场上比较畅销的同类产品或者公司以前的类似产品，把最能体现产品特点和优势的需求加入需求列表。PDT核心团队要根据产品需求列表编排项目开发进度，对以后开发和测试活动的时间进行预估，形成初步的项目任务列表。
PDT 核心团队与技术研发部门配合，评估产品的技术可行性，确定技术方案。
为了提高开发的效率，保证产品开发活动进度和质量要求，要求研发团队要基于现有的模块构建平台(CBB)进行产品开发。产品构建平台提供了在以往开发中积累的提供独立功能的公共软件组件和算法，这些软件组件的质量稳定并且易于配置的。因此，技术研发团队要对产品需求进行分析，检查目前公司的产品平台能否满足待开发产品的技术需求，如果现有的公共软件组件不能满足产品开发的需要，就要在需求列表中加入待开发的产品组件的功能需求。
除了功能需求以外， PDT 核心团队还要与其他部门合作，确定产品的非功能需求。由于互联网产品要安装在多种终端上运行，软硬件环境比较复杂。所以，为了保证软件产品能够被有效和充分的测试，PDT核心团队要与测试部门配合，按照质量标准确定产品的可测试性需求。其他非功能需求还包括：产品的性能，安全性，兼容性等方面的需求。这些非功能需求不是产品的特性，但是满足这些需求可以给用户带来更好的体验。
另外，PDT 核心团队的工作还包括在财务部门的配合下编制的项目预算并进行初步的成本收益核算，尽早发现潜在的财务风险。与市场和销售部门配合进行销售量预测，并制定市场营销计划和推广计划。
概念阶段产生文档主要有：（一）规范的产品需求文档，包括： 详细的产品功能需求说明和非功能需求说明；本产品和以往产品、产品线之间的关系及依赖；产品对终端的软硬件运行环境的要求；常见的用户使用场景。（二）产品项目计划，文档中包括：市场环境概述，主要竞争产品对比分析，产品（产品线）开发进度安排，预计的产品测试版发布时间和产品正式上市时间；必要的质量控制指标；项目成本预测；对可能的风险进行预测。
在这个阶段的最后，开始概念阶段决策评审(DCP1)。 PDT 核心团队向 IMPT提交产品需求文档和业务计划，集成产品管理团队(IPMT)评估对产品的可行性和盈利性进行评估，并就具体的问题向 PDT 团队的成员提出质询，PDT 核心团队则做出必要的解释和澄清。如果评审通过则正式组建 PDT 团队并授权 PDT 团队开始设计阶段工作，任命产品经理统筹 PDT 的工作，并对 PDT 核心团队进行扩充，为进入下一个阶段做好准备；如果产品概念没有通过评审，IMPT 需要综合考虑企业内外部的情况，决定是否重新进行概念阶段的信息收集工作，还是终止项目，防止对企业资源造成不必要的浪费。
(2) 设计阶段【3】
设计阶段以概念阶段产生的产品需求文档和项目计划为基础，完成从产品需求到产品功能的映射，进行整个产品的概要设计。这个阶段是保证软件产品质量和开发进度的关键环节。所以，按照软件工程理论的要求，在进入具体的技术开发阶段前必须要开展规范和系统的设计工作。
概念阶段形成的产品需求文档是从用户的角度描述产品的需求，而需求是粗粒度的，并不能完全体现实际的产品功能。例如，用户的需求是在网络办公软件上显示当前要处理的事务，这个需求实际对应了用户界面显示，数据查询，用户输入管理等诸多功能。用户需求和产品功能之间的映射是复杂的，所以在产品经理的协调下，市场部门和技术研发部门首先分析需求文档，设计出可以满足整个产品需求的系统结构。再从整体结构分解出子系统和各个独立的软件模块，确定各个系统组成要素的功能。
技术研发团队在公司已有的公共组件库中查找相应的功能模块。如果这些软件功能模块已经在公共模块库中，那么配置或者修改这些模块得到所需的功能，否则，详细描述新的软件模块应该具有的功能。系统的概要设计中也要规定这些软件子系统或者模块之间的动态关系，比如通信过程和组件之间的调用方式。各个子模块的实现策略和调用接口，模块之间的依赖关系等内容都要在概要设计阶段进行明确的说明。因为互联网终端的多样性，所以在设计阶段还要考虑产品和终端的适配问题，对产品的可安装性和可配置性提出要求。此外，产品的用户界面以及用户交互的流程等设计要素也包含在概要设计中。
PDT 团队要按照细化的产品功能列表调整项目开发进度，更加精确的评估后续开发和测试活动的时间，形成完整的项目计划。产品经理按照项目计划中的工作分解结构(WBS)分配任务给 PDT 团队成员，并配备所需资源。PDT 团队还需要测试部门的配合，在这个阶段根据功能列表制定测试计划。
这些工作可以促使设计人员在进行设计的时候提高软件的可测试性，测试人员也开始配置测试所需要的软硬件环境，研究每个软件功能的测试方法并编写测试用例(Test case)。
设计阶段产生文档主要有：（一）产品规格说明书，从整体和局部两个层次描述产品的设计，主要内容为：软件概要设计所确定的产品整体架构和系统流程图；各个模块的功能和通信方式的描述；实现策略和软硬件运行环境；软件测试计划等内容。(二)最终的产品项目计划：其中内容包括：更新以后的产品开发项目计划及里程碑交付点；详尽的项目的进度安排，在 PDT 团队协调下各个职能部门的任务；更准确的产品发布时间表；针对每个功能模块制定的质量指标；经过细化的项目预算，成本收益等主要的财务指标；风险管理方案也更加详细具体。上述文档提交以后要开始技术评审（里程碑）(TR1)。技术评审是产品研发团队从技术角度对产品规格说明书进行评审，确保客户需求被正确映射到了产品功能。具体的做法是判断软件技术可行性，产品的整体架构设计是否得当，子系统和模块的分解是否合理，基本模块的功能和职责描述是否清楚并有利于技术实现。以规格说明书为基础对产品的技术可行性进行进一步的论证，确定现有的技术平台和组件库(CBB)是否可以支持该产品的开发，以及开发新的软件模块的必要性。同时也对产品的可安装性，可配置性等方面的设计进行评估。如果通过技术评审则研发项目开始进入开发阶段，否则，重新论证产品的技术可行性和软件结构和模块的设计，对产品规格说明书中相关的内容做出修订。在技术评审阶段(TR1)在原则上不会终止项目，如果发现产品所需技术过于复杂，则要求技术研发部门调整产品的设计，寻找新的技术方案，对产品的规格做成修改。
技术评审之后要进行设计阶段决策评审(DCP2) 。IPMT 对最终的产品项目计划进行评审，审核计划中更改的内容，确认产品的竞争优势，尤其对概念阶段决策评审(DCP1)中遗留的问题进行核实 。IPMT 从企业全局的角度审视已经细化的项目进度表和人员配备情况，保证各类资源的平衡分配和高效使用。如果通过设计阶段决策评审，那么表明 IPMT 和 PDT 团队对产品的概念、产品开发进度、市场活动等整个项目的目标达成一致，也意味着产品立项成功。并且 IPMT 和 PDT双方要达成协议，IPMT 提供所需要的资源，PDT 要对产品交付时间做出承诺。与该项目相关的绩效考核指标也计入组成 PDT 团队的各个职能单位的考核体系。售后服务和支持部门开始编写用户手册和售后维护方案的编写工作。如果没有通过评审，则视具体情况重新修订业务计划或者终止研发项目。
在这个阶段，开始对产品研发项目实施软件配置管理。软件配置管理是一种对软件开发资源，包括计算机程序代码，设计文档和其他数据的监控和管理的手段。软件配置管理可以有效的组织在设计和开发阶段中产生的各种数据资料，跟踪研发人员对项目做出的修改。当项目出现问题的时候可以及时回溯项目修改的历史，提高纠错的效率。软件配置管理工作由技术研发部门的软件配置管理团队(SCM)负责。由于公司开发的互联网软件产品的特点，所以在设计和开发阶段对项目进行调整和修改是不可避免的，也是十分频繁的。公司规定所有对项目的修改和变更必须要经过配置管理流程，避免这些修改扰乱项目的进度和质量。
(3) 开发和测试阶段【4】
开发和测试是产品研发的实施阶段，也是对此前各阶段产生的设计和预测进行验证。X 公司的产品研发流程中没有把开发和测试作为独立的阶段，是和软件产品开发工作的特点有关。软件技术复杂多样，软件开发工作不易用标准的流程来规范，人为因素很大，这导致工作成果的质量不易控制。所以，只有在开发过程中通过不断反复的测试和验证活动来修正开发过程中的错误，避免项目的进展偏离目标。开发活动和测试工作交织在一起，作为一个整体推进研发工作的实施，并且这个阶段的工作要确保产品可以成功上市，也是执行产品计划的关键步骤。
这个阶段的工作包括技术开发部门对设计阶段产生的产品规格说明书中的定义的各个软件模块进行详细设计，确定模块内部的数据结构和处理算法的具体实现。如果要重用公共组件库中的模块，则要求对这些重用的模块进行适配，满足这个系统的功能需要。在详细设计中要考虑技术实现的细节。软件实现技术发展迅速，新技术不断涌现，但是在详细设计时 X 公司的技术选型原则是选择适用的技术，保证产品开发的进度和质量。详细设计还要关注软件模块的可测试，可集成性，为后续的测试工作提供条件。
详细设计文档产生后要进入详细设计阶段的技术评审（TR2），产品经理组织PDT 中的研发部门和测试部门的人员对详细设计文档进行评审。审核的内容包括再一次核对产品规格文档中对模块功能的要求；检查模块结构设计的合理性；模块实现策略；评估效率。客户服务部门和技术支持部门依据产品规格说明书完善用户手册的内容。如果详细设计文档通过了评审，那么由技术开发部门经理负责，按模块将具体开发任务落实到每个开发工程师，准备进入编程开发阶段。测试部门也要按照详细设计文档中的描述，进一步完善软件测试计划。如果详细设计文档没有通过评审，研发部门要对详细设计文档的内容进行修订，必要时重新分析产品规格说明书和产品需求文档，澄清设计时所面临的问题。技术评审（TR2）后，如果原有设计需要修改，或者有新的设计要素要加入到项目中，则要经过变更管理流程的控制。
详细设计的结果获得通过后，研发部门安排软件工程师开始进行编程开发工作。程序的源代码的编写要按照技术开发部门制定的代码编写规范来进行，保证代码的质量，从源头上减少错误的发生。在代码编写过程中，研发部门内部组织软件研发工程师做非正式的代码评审(Code Review)，提高代码的质量和执行效率。软件工程师完成一个软件模块的编写工作后，开始对模块进行单元测试。因为单元测试是从技术实现的角度检验模块的功能和性能，需要了解模块内部的技术实现细节，所以由软件开发人员而不是测试部门来承担这项工作。如果编写好的模块通过单元测试，就将该模块的程序代码提交到软件配置管理系统。每个模块都是经过这样开发，测试，修改，再验证的过程，并且逐步的集成到项目中。
在所有软件开发完毕后，软件工程师进行系统集成工作，对各个模块进行配置和必要的修改，把它们与公共组件库中的模块集成为一个产品的原型。测试部门产品原型的集成测试工作，集成测试的目的是及时发现模块之间的整合与协作问题。
软件开发人员可以根据集成测试的结果对软件模块的程序代码进行修改，重新做集成测试，如此反复，直到各个模块可以协调的工作，产品的原型可以稳定的运行。
测试部门将最终的原型产品进行功能确认测试，功能确认测试确保产品概念的一致性，并按照测试计划中的每个测试用例对产品的功能进行全面的测试，并将测试中发现的问题按照严重程度和性质（功能，可安装性，安全性，性能问题）和问题处理的状态(确认，维修复，已修复)进行分类并提交到缺陷管理系统，并向 PDT 团队交付功能确认测试报告。报告中包括测试的环境、测试用例列表、详细的测试结果、对产品研发成果的初步结论。
产品经理根据功能确认测试报告开展技术评审（TR3）。产品经理组织 PDT 团队逐项分析测试报告中的问题，首先要核对测试用例和产品规格文档中的功能说明，排除测试用例本身的问题，然后根据问题的性质和严重程度制定对策。对于产品原型功能，可安装性，用户体验方面的问题，则由市场团队和技术团队共同分析问题的原因。
如果是软件模块级别的问题，则有技术部门负责修复，要将改动的数据和程序代码提交到软件配置管理系统以便跟踪修改的过程。技术部门要针对修改所涉及的功能模块重新做单元测试和集成测试（回归测试），确认所做的修改已经解决了问题，并且没有对产品的其他部分产生不良影响后，交付测试部门再一次进行功能确认测试。对所有被确认为是技术开发产生的问题，都要经过上述的修改，重新测试，确认修改这样的过程。测试部门对修改后的问题重新进行功能验证，对于已经解决的问题要在缺陷管理系统标记状态，否者将问题发回技术部门继续修改。
如果经测试阶段发现必须对产品的设计进行修改(包括概要设计和详细设计)，那么要进入变更管理流程。技术研发团队要提交设计变更请求，要重新经过设计阶段的技术评审（TR1 与 TR2）对修改后的设计进行核查。在确认修改的无误后方可进行开发，并由测试部门对修改过的功能确认测试。
当产品原型通过功能确认测试并达到质量要求后，研发部门制作内部测试版本(alpha 版本)并交给测试部门和市场部门进行内部测试（alpha 测试）。alpha测试主要检验产品的易用性和用户体验以及性能是否已经达到发布的标准。产品发布给企业内部员工或者合作企业内部试用，在使用过程中发现的问题被报告给测试部门。测试部门通过内部测试报告的形式提交给 PDT 团队审核，由 PDT 团队决定是否直接修改模块或者做出设计变更。如果最初的内部测试版本不能满足进入外部测试（beta 测试）阶段的要求，那么有技术部门进行修改后发布后续内部测试版本(alpha2, alpha3)。
在进行内部测试版本测试的同时，市场部门也开始挑选外部测试用户。外部测试用户主要是公司以往产品的客户和潜在用户。客户服务部门根据产品的性质准备的培训材料，并开始准备为外部测试用户提供支持服务。
直到产品原型的质量表现稳定，功能完备，研发部门制作外部测试版本(beta版本)，由市场部门分发给公司外部用户使用。外部测试主要是验证产品的规划是否符合产品的概念设计，公司对细分市场的布局是否合理，销售渠道是否畅通。
如果用户需要通过数字分销渠道进行产品的下载和安装，那么也要检查产品的可获得性。客服部门负责收集用户的反馈信息，并形成外部测试报告并提交给 PDT团队审核。PDT 团队要决定是否需要继续修改产品，发布后续的外部测试版本(beta2, beta3...)。
开发和测试阶段产生的文档：（一）详细设计文档，主要内容包括：软件模块的内部结构和算法，模块的实现策略，模块的调用接口；（二）最终的产品规格说明；（三）测试报告，包括：集成测试报告；功能确认测试报告；内部测试（alpha 测试）报告；外部测试（alpha 测试）报告；（四）质量达到发布标准的产品PDT 团队收到外部测试报告后，进行测试阶段技术评审（TR4）。这次技术评审将综合评估内部测试和外部测试的结果，从技术角度全面评价产品的性能，可用性，可维护性，可测试性。产品经理对目前已经实现的产品功能和产品规格说明书进行对比，提出改进意见。这些改进意见并不是产品的缺陷，并且意见有可能形成新的需求加入到以后的产品版本中。
在测试阶段技术评审（TR4）之后产品开始进入发布前决策评审(DCP3)。经过设计，开发和测试阶段，产品的功能已经按照规格说明书完成开发。通过各个层次的测试和验证，产品的质量趋于稳定。IPMT 将全面审核产品经理提交的评审材料，对市场计划的开展情况进行评估。因为互联网市场环境变化快，用户需求多样化，所以 IPMT 要结合当时的外部市场情况和销售预测判断产品是否需要按计划发布。如果为了使得产品能在最佳的时机上市，取得最好的销售业绩，销售团队可以修改上市计划，调整上市时间。如果通过决策评审，则表示产品已经准备就绪，可以正式进入发布阶段。
(4) 发布阶段【5】
经过测试的产品在此阶段正式发布给用户使用，IPMT 和 PDT 共同完成对产品市场表现的评估，并对产品的典型用户建立案例库。通常的观点认为产品经过开发和测试阶段以后，就可以交给销售部门推向市场了，剩下的工作与研发部门就没有关系了。而 IPD 管理体系设立发布阶段是为了更好的执行产品的市场推广策略，积累产品的早期用户，并及时获得市场的反馈。发布阶段不只是销售人员的工作，也要有产品研发团队和客户服务团队的共同配合，把产品顺利、及时地推向市场。
发布阶段的主要工作包括：市场部门进行实施营销计划并收集早期用户的反馈信息。市场部门针对不同的用户群开展广告、用户试用等促销推广活动，并进一步完善产品的市场策略和定价策略。对于企业用户，市场部门会和企业一同开展相关的培训活动，对产品的部署上线提出指导意见。而对于面向普通消费者的产品，市场部门会通过各类分销渠道，包括与运营商合作、第三方软件下载网站等数字分销渠道开展大范围的市场推广活动。
PDT 团队在发布阶段的工作是向市场部门和客户服务部门提供详细的产品技术手册和用户手册。产品经理在产品需求分析阶段就已经开始编制用户手册，并在产品设计和开发阶段逐步完善手册的内容，在发布阶段用户手册和产品技术手册将作为产品包的一部分发布给用户。技术研发部门也要为客户服务部门提供技术支持，解决用户的问题。
IPMT 团队根据产品的发布后的初期市场反应对 PDT 团队的工作进行绩效评估，并召开产品研发工作总结会，对研发过程中积累的经验和发现的问题进行汇总和分类，建立产品实施案例库为以后产品研发工作的重要参考。IPMT 开始制定产品支持与维护计划，为产品的售后支持工作做好准备。
PDT 作为一个临时的开发团队的使命在发布阶段后也即将结束。X 公司规定在产品发布 2 至 3 个版本以后，经过 IPMT 批准后 PDT 团队可以解散。这样的规定是因为产品上市初期可能存在一些棘手的技术问题，而这个阶段技术支持部门还没有完全掌握产品。所以，要求 PDT 团队在产品发布后不会马上撤出项目，以便及时的对产品发布早期发现的问题做出响应。产品在发布第三版之后，一般不会出现重大的技术问题，这个时候技术支持部门可以顺利接手产品的后期维护工作，PDT 团队也可以解散，团队中的成员回到各自的职能部门，由部门主办领导，准备接受新的研发任务。
发布阶段产生的文档：（一）最终的产品营销方案，用于指导市场部门的销售工作，对市场策略和产品定价做出规定。（二）市场宣传资料，包括售前产品推介资料，产品宣传策略等；（三）详细产品支持与维护计划，作为后续产品售后服工作的基础。（四）产品研发过程总结，对 PDT 的工作进行总结和评估。
(5) 产品支持与维护阶段【6】
软件产品正式发布给用户使用以后就进入了售后支持服务和维护阶段。软件产品的运行维护和支持工作量很大，一些大型项目的维护成本占整个产品研发成本的 4 倍左右。目前一些大型的软件研发组织更是投入 60%以上的人力从事产品维护和技术支持工作。X 公司以前没有对技术支持服务和维护引起足够重视，产品维护服务与技术和市场部门协同不好，无法及时处理用户的反馈和产品出现的问题，导致错失产品改进和创新的机会，而且对紧急需求的不当处理也打乱了新产品的研发计划。
因此，X 公司在实施 IPD 研发流程的过程中重新组织售后服务部门，针对已经上市的产品成立专门的产品支持与维护团队，一方面为了维持现有上市产品的持续竞争力，保证软件系统的高质量的运转，为用户提供高质量的售后服务，使用户可以通过产品获得更多价值。更重要的是树立产品生命周期的观念，对产品的实行全生命周期管理（引进期、成长期、成熟期、衰退期），针对产品生命周期的不同阶段制定不同的服务与维护策略。
产品支持与维护阶段的工作包括：产品支持与维护团队要及时处理用户反馈的问题，以便发现新的用户需求，帮助产品研发团队把握产品改进和创新的机会。
产品支持与维护团队与市场部门共同建立案例库和客户管理系统，发掘更多的产品销售机会；研发部门对产品的问题进行分类，管理产品需求的变更，在保持产品质量的同时减少各类紧急需求对研发计划的冲击。市场部门也要在此阶段对前期制定的市场营销方案的执行效果进行评估和验证，跟踪产品的市场表现，关注对手的产品情况调整市场策略和定价方案；产品支持与维护阶段的主要文档：产品支持与维护计划；产品需求变更文档。
4.4 X 公司的迭代开发过程【7】
X 公司为了适应互联网行业快速变化的用户需求和市场竞争环境，把开发过程的不确定性和项目的风险降到最低，在采用迭代开发模式具体实施 IPD 产品研发工作流。和传统的周期较长的线性顺序工作流程不同，迭代开发是通过把原来的整个开发过程划分为执行若干次周期较短的“迭代”，重复执行这些“迭代”来完成一个产品的开发过程。一次迭代中包括有若干任务，而且每次迭代结束是会得到一个可以使用的具有部分功能的工作成果（迭代产品），这个迭代产品类似于测试版本，由测试部门交付给用户使用，迭代过程就是根据用户的反馈对产品的设计逐步求精的过程。迭代开发模式也需要用户的支持和理解，客服部门要做好客户的教育工作，使客户了解迭代开发的目的并配合收集反馈信息。
X 公司根据产品开发的现状，将详细设计、开发和测试这三个阶段的工作组成一个迭代周期。一个迭代周期要经历从详细设计技术评审（TR2）至功能确认测试技术评审（TR3）的一系列工作，在决策评审(DCP3）之前发布本次迭代的阶段性成果。每一次迭代都要设立一个迭代目标，包括此次迭代需要交付的功能集合，交付产品的质量要求。迭代周期内的各个阶段(详细设计、开发和测试)的工作活动可以根据迭代目标进行调整，简化一部分开发活动和评审流程，达到快速交付产品，及时得到用户反馈的目的。
一个迭代周期大约持续 2 周的时间，由研发团队的产品经理从产品需求文档中的需求列表中挑选优先级比较高的核心产品功能进行详细设计并经过设计阶段的技术评审（TR2）进入开发阶段，开发人员编程开发本次迭代选取的软件功能，并完成这些软件功能模块的单元测试。
测试部门将开发完成的软件功能模块进行集成并进行集成测试及功能确认测试，在对功能确认测试报告进行技术评审（TR3）后，由技术研发部门、测试和市场部门根据此次迭代的情况和产出的工作成果来决定是否发布内部测试版本(beta)版本，外部测试版本（alpha）版本。在产品的质量和功能要求达到此前设定的迭代目标后，此次迭代的产品会马上发布给客户使用，客服部门会及时处理客户的反馈，及时总结此次迭代所存在的问题，为下一个迭代周期的工作做准备。
迭代开发过程缩短了一个产品的发布周期，PDT 团队可以通过频繁更新的产品版本收集得到用户的反馈，及时调整产品的设计，降低研发项目的成本。X 公司以前一个产品的开发周期大约为 10 周到 12 周，用户要经过 8 到 10 周的时间才可以看到产品的测试版本。如果用户要求对产品的功能进行较大范围的调整，那么肯定会拖延产品的上市时间。此外，在产品后期修正产品概念和需求分析阶段的问题，代价是十分高昂的，要重新进行产品的测试和阶段评审工作。而迭代开发模式，产品从概念阶段到发布到用户只需大约 2 到 3 周的时间，在每次迭代结束，用户都可以看到一个已经实现了部分功能，但是可以稳定工作的产品。用户可以根据产品的使用情况提出改进意见，这种对产品功能进行必要调整在互联网产品的开发过程中是很常见的。此外，迭代过程也使团队成员可以尽快看到自己的工作成果，有利于鼓舞整个研发团队的士气，增强团队的信心。PDT 团队在每次迭代产品发布后都进行迭代周期评审(IDRn)，根据反馈信息来安排以后的工作任务。一般经过 3 至 4 个迭代周期，产品的全部功能已经实现，产品的质量也可以达到正式发布的要求，并得到用户的确认后，产品进入发布决策评审(DCP3），准备正式发布给用户使用。
4.5 技术研发流程
为了加产品研发的速度，提高研发工作的效率，X 公司提出了的技术研发和产品研发相分离的原则，由技术研发部门的经验丰富的研发工程师组成 IDT 团队负责基础应用技术和公共产品功能模块的研发，形成技术研发流程。技术研发关注专业技术水平的提升和技术基础设施的建设，而产品研发更专注于如何满足用户的需求，快速的将产品推向市场。
X 公司组织技术专家，对从技术角度对产品的结构进行分析，对涉及到的技术进行分类和梳理，将可以帮助产品取得竞争优势的独有技术和各个产品研发团队共享的通用功能组件的预研任务分配到 IDT 团队。IDT 团队依照产品研发流程对公用技术组件，比如网络通信模块，用户数据处理模块，信息搜索算法等的进行集中开发。【8】
技术研发流程分为:技术需求分析、开发与测试、发布和 CBB 管理四个阶段。
（1）主要分析产品研发所需要的技术资源，评估各种可能的技术难点，并形成必要的技术文档。
（2）开发与测试：对 CBB 进行详细设计并进行开发；开发的成果交由测试部门经常测试。
（3）发布：对技术研发的成果进行适配，发布给产品研发团队试点使用，并评估 CBB 的技术成熟度。
（4）CBB 管理：对已经投入使用的 CBB 进行优化和技术更新，保证 CBB 的可用性和可靠性。
技术研发流程可以产品研发流程并行的、独立的运行，为整个产品研发过程的并行模式创造条件。技术研发流程与产品项目研发的最主要区别在于技术研发注重过程，允许研发结果失败。
4.6 并行开发模式【9】
并行开发模式就是集成的、并行的设计和开发产品和相关服务的系统方法。
并行开发可以有效提高产品研发的效率。并行开发过程不仅需要先进的信息化管理手段，而且也需要企业组织架构的保证。X 公司为引入 IPD 开发模式而建立的针对各个产品的 PDT 团队，为推行并行开发模式提供了良好的组织基础。而建立技术研发流程，实现技术研发和产品研发的分离，也为并行开发提供了必要的技术保障。
X 公司在技术研发和产品研发的分离的基础上，对产品研发流程进行优化，对原来类似线性结构的、顺序进行工作流程进行必要的分解和整合。X 公司组织来自不同职能部门的业务专家和技术专家，共同对研发流程中各个阶段的工作任务进行分析，找出可以同时甚至提前进行的工作步骤。例如，在产品概念形成的同时，产品技术团队就可以提前投入部分人力进行概要设计；在产品详细设计阶段进行的时候，技术团队也可以同步开展必要的技术准备，研究产品开发的技术可行性，并在公共组件库中寻找适用的公共模块(CCB)；而测试阶段的工作更是需要渗透到研发工作的各个阶段，监控和验证各阶段的工作过程和成果。公司在分析各工作步骤之间的关联和约束的基础上进行并行规划，在不影响整个研发工作的质量的情况下，尽可能的使各个工作步骤并行的、异步的进行，从而有效的提高研发工作效率，减小产品研发进度延迟的风险。
