3.3　IPD流程的灵活性与敏捷开发

3.3.1　IPD流程的灵活性

流程的好处不容置疑，有流程，工作就能有序开展，可以避免冲突、混乱、效率低下。没有流程，工作不受约束，过程不可重复、不可衡量，无记录，也没法改进。但是，如果过度流程化，每项工作都定义太细，文件一大堆，规矩一大堆，严格遵循这样的流程所花的时间就会大大增加。开发项目的时间通常很紧，没有多少人花时间认真去看流程，更不要说去遵守教条的规定。

流程结构化设计的方法是业界普遍的做法。IPD流程采取的是一种改进运作效果的平衡方法：既采用适当的层次结构，统一的高层框架、模型、关键活动，同时又不定义太细。这样，一方面使IPD流程可重用、可衡量、可比较和可改进，另一方面在操作层面具有相当的灵活性。任何项目都具有独特性，需要完成的工作都有差异，因此，项目性流程定义太细是没有意义的。

在华为，IPD流程不是僵化的，而是非常灵活的，可以适用于所有的软硬件开发项目以及服务、解决方案开发项目。IPD流程提供了统一的概念、模型、框架，并基于业界实践以及华为实践积累了大量的检查表、操作指导等。这些实践是宝贵的资产，不需要后来的项目团队重新去摸索，但却具有相应的场景适应性。虽然华为也在不断地总结场景，按场景构建适应性流程（见下节描述），但终究不能穷尽所有场景，新场景也会随业务发展而产生。因此，每个项目团队应该根据自身项目特点灵活应用IPD流程。以TR检查表为例，TR检查表是华为多年来积累的宝贵资产，方便团队成员检查产品技术成熟度的状况，但IPD流程实际上并不是要求所有项目僵化地使用公司发布的TR检查表。公司发布的TR检查表是指导性文件，是经验、知识的积累，除法律、法规、质量、网络安全等红线要求外，都需要根据实际情况进行调整，每种产品线都应该在此基础上构建适合自身特点的检查表。IPD流程不要求所有研发的项目团队都逐一地执行公司发布流程中描述的所有活动，每种产品都可以，也应该在公司IPD流程的基础上根据本产品的特点，客户化本产品的IPD流程；每一个PDT经理可以，也应该根据项目的实际情况对活动进行一定的调整，包括活动的裁剪、合并、增加，这是PDT经理必须具备的项目管理基本技能。

为了更好地帮助PDT灵活应用IPD流程，华为建立了根据项目具体情况灵活应用IPD流程的机制和指南，明确了DCP、TR这些关键点的合并原则和操作程序，以及下面层次的活动合并、裁减的自主性。

比如，华为IPD明确规定，任何产品开发项目，PDT都可以根据项目本身特点对IPD各阶段详细操作流程中的活动进行适当的裁剪、合并或增加。PDT应记录活动裁减情况及其原因，写入IPD核心流程规定的《产品质量计划》中的过程偏差部分，并作为项目文档保存。凡是技术评审或DCP的合并、裁减，必须提交IPMT审核同意后才能执行，下面层次的活动合并、裁减，由PDT经理依据项目具体情况作出判断并对此负责。概念阶段和计划阶段的应用调整需在Charter评审之前提出，在Charter评审材料中体现，Charter评审时经过IPMT批准并写入《产品质量计划》中；计划阶段以后的流程客户化需要在PDCP之前提出，在《产品质量计划》的过程偏差部分体现，PDCP时经过IPMT批准。

不过，流程的灵活应用需要良好的判断能力，需要PDT团队深刻分析和理解要完成的工作，因此对IPD流程灵活性的掌握能力与对IPD流程的理解、理论水平以及实践经验是分不开的。这就要求PDT经理具有丰富的研发经验，PDT经理之间不断地进行经验分享与交流，要求PQA⁽¹³⁾不断提升技能，以更好地制定符合业务本质的项目过程手册，避免教条。

3.3.2　基于业务分层与业务分类的IPD流程场景化

在华为，IPD流程的灵活性还体现在可以根据不同的业务层次与业务类型选择合适的、已定义好的场景化流程。

从业务分层（见第4.1节）的角度来看，华为的业务分层从技术／芯片、子系统、平台、产品、解决方案到集成服务层，其中每一层由下一层组成，经过多层形成一套完整的产品或解决方案。每一层业务特点不同，开发流程有很大区别。需要构建差异化的流程与管理体系。

从业务分类角度来看，随着华为公司战略的调整，客户选择从传统的运营商扩展到消费者、企业和政府，业务类型也从传统的有标准的通信设备逐步扩展到IT产品、专业服务、芯片、终端产品、独立软件、跨产品／服务的解决方案。这些业务类型的商业模式、产品形态、架构模型、投资决策模式、开发模式、运营模式等差异较大，需要在统一的IPD核心理念基础上，构建差异化的流程和管理体系。比如终端产品，它是面向2C市场的，具有极致体验、上市既上量、时尚又艺术、机会窗时间短等不同于面向运营商市场的通信设备节奏稳定、逐渐上量、版本演进、生命周期长等显著差异化特征，需要制定符合终端业务本质的、高效的场景化流程。又如云服务，其本质是运营业务，关注用户全生命周期价值、用户发展、运营效率。和传统的产品与解决方案的商业模式完全不同，IPD非常多的理念与流程并不适应云服务，因此华为并不要求云服务执行IPD流程和管理体系，而是要求为其单独构建云服务流程和管理体系。

图3-4所示为根据华为公司业务分层及业务分类构建的IPD场景化流程示意图。

流程的建设以及优化是一个公司最重要的工作，也是最基础的工作。华为从1999年启动IPD变革以来，研发体系流程优化从来没有停止过。到2018年，IPD流程已经从1.0演进到了8.1。场景化流程建设是流程建设与优化的重要方面，并随着公司业务范围的扩展不断丰富，使得每一个特定人群，针对不同类型的研发项目场景，能使用最合适的流程，这实质上也简化了流程。华为在建立了IPD流程框架和模型之后，最初是围绕面向运营商的有标准的通信设备（含嵌入式软件）来构建可操作流程的（流程图、模板、操作指导、检查表等），使得有标准的通信设备开发有了规范的过程指导。后来又构建了技术／平台开发流程，支撑有标准的通信设备开发的技术、芯片／器件／模块开发，接着又建立了芯片／器件／模块及解决方案开发流程。2011年后，随着公司战略和商业模式的变化，华为公司业务从为客户提供有标准的通信设备扩展到消费业务、企业业务，因此又投入重金构建了终端产品开发流程、专业服务开发流程，也构建了独立软件开发流程。

流程是对业务流的一种表现方式，是优秀作业实践的总结和固化，越符合业务流的流程就越顺畅。华为智能手机业务近年蓬勃发展，就是得益于终端产品开发流程的建设与不断完善。随着华为公司战略的调整，华为会不断构建和完善符合不同业务本质的场景化流程。

3.3.3　将敏捷的DNA植入IPD

我们要有快速响应的能力，也要有坚实的基础。未来要实现大带宽、大流量，传统IPD依然是坚实的基础，适合传统硬件和嵌入式软件；IPD进一步发展就是敏捷；未来，IPD更要联合客户敏捷，对接客户业务流，做到商业敏捷。

——任正非

一、敏捷的引入

IPD传统模式虽然可以根据具体产品和项目的特点进行灵活应用，但总体还是对既有活动的合并、裁减或增加。从宏观看还是采用大瀑布开发模式。这种模式针对传统嵌入式大型系统设备、硬件产品游刃有余，但随着业务的发展，在日益丰富的业务场景下，已显得力不从心。

随着通信产业发展，云计算、大数据等新技术的诞生，传统CT（Communication Technology）运营商也日益面临OTT⁽¹⁴⁾厂家的竞争。华为的业务也随着战略调整，从运营商业务，逐步扩展到企业和消费者业务，独立软件、云服务等业务期望获得更快、更个性化的服务与响应。这种情况下，传统IPD按年／半年度一刀切的“火车节奏”交付版本已无法满足客户需求，需要根据交付场景按需而变。与此同时，业界敏捷开发运动如火如荼，各大公司纷纷采纳，俨然已是软件开发的主流方向，因此华为借鉴业界敏捷思想，结合自身特色，开启了IPD的敏捷变革之旅。

二、华为敏捷简要历程

华为的敏捷一直都是业务驱动的，解决业务问题是敏捷实施的唯一动力。

2003年，华为通过CMM⁽¹⁵⁾5级认证，2006年IPD-CMMI⁽¹⁶⁾流程覆盖率达100%。然而此时却发现大量基于瀑布开发模式的项目存在惊人的需求和设计变更（如U产品，Charter的需求到TR5时变更48%）以及痛苦的系统联调（前期各项目组分别开发，集成后问题爆发），造成大量的返工和浪费。鉴于此，2008年前后，华为从业界引入了敏捷开发的一些基本实践，核心是迭代开发与持续集成，提前发现问题，及时调整改进。我们把这种通过团队层面快速闭环反馈，提升质量的敏捷实践称为“项目级敏捷”。

“项目级敏捷”实施1～2年后，研发能力和效率得到了有效提升。随着业务发展，为了快速响应不同客户越来越多的诉求，研发团队同时启动和交付了大量客户化版本。版本多、分支多的问题逐渐成为影响客户、销售、交付以及研发效率提升的主要问题（某PDU⁽¹⁷⁾数据表明，并行开发的同步工作量占总工作量25%以上）。在这个背景下，华为提出了“One Track”的概念，从版本规划环节入手，梳理“火车节奏”，建立全量特性池，基于价值进行优先级排序，一个开发主干，版本全球应用，极大提升了交付质量和效率。我们把这种“一个主干”为核心特征的开发模式称为“版本级敏捷”。

2015年，运营商在互联网厂家的竞争压力以及终端用户多样性需求驱动下，要求设备供应商具备按季，甚至月度交付的能力。按照传统概念、计划、开发、验证、发布阶段依次实施的做法肯定难以满足客户诉求，因此我们考虑优化决策模式，将商业决策和需求决策分离。商业决策按年度规划并实施，而需求决策按季度／月度迭代进行。将一次大包决策分为多次小包决策，然后每个小包分别开发、验证和发布，大大缩短了版本TTM（Time To Market）。这种持续规划、持续开发、持续发布的流水线交付模式被称为“产品级敏捷”。

与此同时，云化、虚拟化浪潮席卷全球，运营商启动数字化转型战略，迫切需要和供应商一起通过快速的创新和试错来探索市场，应对挑战；同时华为交付模式也日益多样化，基于开源和生态的交付比重逐步增加。基于此，华为面向未来，提出“商业敏捷”概念，基于不同的商业场景和业务诉求，采用不同的研发模式。在运营商和企业市场，华为期望联合客户，卷入生态合作伙伴一起联合创新、开发和交付，提升产业链的竞争力；对于公有云等自运营产品和服务，探索DevOps⁽¹⁸⁾开发模式，构建从规划到运维运营的E2E全功能团队，实现运营驱动开发，最终实现业务的敏捷交付。

三、华为敏捷变革的两个关键维度

业界敏捷早期主要都是针对小团队实施敏捷开发的，比如最为广泛应用的Scrum⁽¹⁹⁾框架以及著名的“2个比萨团队”，都是小于10人的规模，这和华为IPD下动辄几百、上千人的集团军作战方式是有很大区别的。为了将业界敏捷引入华为，除了深刻理解敏捷理念，还要在具体操作方面结合华为的组织和流程特点做大量的创新与适配。

从华为近10年的敏捷变革经验来看，要在整个IPD层面做好敏捷，最核心的是要提升以下两个方面维度的敏捷能力：

1. 价值流敏捷性

价值流敏捷性称之为敏捷的水平拓展能力。核心是在“客户—需求洞察—商业设计—架构与系统设计—开发—测试—服务—客户”这个价值链中，把敏捷影响的范围从传统小团队内的“开发—测试”向前后两边延伸，最终打通“从客户中来，到客户去”的完整价值链。这个过程，要不断卷入新的角色，不断调整和优化现有流程和组织职责，用更短的链条，更高效地协同和反馈加速价值的流动。仅仅单个小组运作好，甚至独立的多个小组也运作好，依然不能有效解决问题。大企业中每个角色和职责都是环环相扣，只要有环节和角色没搞定，价值就无法顺畅流动起来。

2. 组织敏捷性

组织敏捷性称之为敏捷的垂直压缩、扁平化管理能力。核心是在“员工—主管—经理—部长—总裁”这种多层级的汇报和决策链条背景下，构建一个高效、快速的决策机制，从战略到执行，透明高效；从基层向上反馈信息，通畅，快捷；这都需要企业做到分层决策，组织扁平化，适度自治，权力和“炮火”授权到一线作战团队。这种变化，涉及组织的调整，不同层级决策范围和决策方式的变化。

华为IPD针对上述两个维度的敏捷性都有改进，实践表明，组织的敏捷性难度更大，但改进获得的收益也更大。

四、敏捷变革对IPD的主要变化

通过敏捷变革，华为IPD在以下几个方面与以前相比有了较大改变：

1. 商业决策与需求决策分离

涉及战略、商业的部分由IPMT决策，具体的需求交由产品管理和开发团队共同决策；需求包由从前在Charter/PDCP时一次大包决策，变成随着产品的开发过程，迭代滚动，依据商业价值排序，分拆为小包迭代决策，基于小包快速开发和交付。

2. 全功能团队建设

基于价值流，构建完整交付团队。从以前的模块团队，为单个模块的交付负责，转变为对服务／特性从需求到上线／发布全程负责。这要求团队成员技能上一专多能，决策上适度自治，拥有部分决策权和管道空间，能针对服务／特性的体验优化类需求在团队内自主决策并快速闭环。

3. 能力建设，内建质量

敏捷是基于能力的变革，要做到快速交付，就必须做到实时高质量，要求把质量内建到开发过程的每个活动中，强化架构解耦合自动化测试，通过工具自动化，将开发活动各环节质量随时可视化管理，最终支撑按节奏开发、按需发布的敏捷交付模式。