前言

在一个软件工程项目组里有四种角色特别重要，即：架构师、领域专家、产品经理以及项目经理，在一个比较大的项目里或者大公司大部门里，这四类角色一般分别对应四个人，然而在中小型项目里，特别是创业型公司或大公司里的小部门，这四类角色可能是四者合一的，即从团队当中选定一位有能力担当这四个角色的成员。如果这个成员原来就是架构师，那么对这位架构师的要求就是除了专业技能之外还应该具有项目管理能力。

根据定义项目是“为提供某项独特产品或服务所做的临时性努力”，其本身的特点是“变化”，因此，项目管理对架构师本身来说也是具有很大的挑战性的一项管理工作。项目管理具有入门容易、精通难的特性，大多数项目管理给工程师的感觉就是定计划、看进度、催活、做汇报，实际上这是没有领悟项目管理的精髓。

PMBOK定义项目管理为：“项目的管理者，在有限的资源约束下，运用系统的观点、方法和理论，对项目涉及的全部工作进行有效地管理。即从项目开始到项目结束的全过程进行启动、计划、执行、监控和验收，以实现项目的目标。”，即项目管理有其自身的“观点、方法与理论”，而在项目的落地过程中，所有节点的计划、执行、监控、风险管理以及验收等都依赖于工作分解结构（WBS: Work Breakdown Structure ），不同的行业对项目管理有不同的需求，进而有不同的工作分解结构方法，本文讲述的是与软件工程紧密相关的工作分解结构法。

项目管理方法论

依据PMBOK理论定义以及软件工程实践，软件工程项目管理可以分为两大部分：一是5大流程，二是12大知识领域 ，如下：

项目管理五过程

项目管理五大过程包括项目的启动、计划、执行、监视和验收，如下图所示：

• 启动阶段，首先需要确定项目的目标和项目的关键负责人、进行业务分析、需求分析以及组建团队，并且宣布项目正式立项；

• 计划阶段，编写项目计划，把项目目标量化与质化，制定达到目标的里程碑，在这个阶段，还需要完成的是概要设计、目标分解、任务分派、风险评估等工作内容；

• 执行阶段，按计划开展项目，进行详细设计、编写代码、调试自测，阶段性的实现目标，这一步是软件工程最核心的一个步骤；
• 监控阶段，监控阶段与执行阶段是循环的关系，这一阶段需要准确识别偏差，判断影响项目进度因素，同时进行计划刷新与风险刷新以及任务刷新；
• 验收阶段，按照项目要求，进行项目验收，包括版本发布、文档归档以及项目复盘。

不同于理论，在实践中，这5大过程是个计划、执行、检查、更新的循环过程，而不是一个线性过程。

项目管理12项

项目管理1.0版里涉及 范围、时间、成本以及质量，这四者是个平衡的过程。项目管理2.0里，又增加了 业务与组织，项目管理是为业务服务的，同时给组织保证结果。而在实践过程中容易发现软件工程项目管理其实涉及12大领域，即：业务、范围、进度、成本、质量、资源、风险、采购、相关方、沟通、测试以及综合管理，具体如下：

• 业务管理，其涉及业务分析、客户管理；
• 范围管理，包括规划范围、需求分析、定义范围、工作分解、确认范围以及控制范围；
• 进度管理，其包括：规划进度里程碑，定义任务，排列任务优先级，估算人力资源，估算所需时间，制定进度计划表以及控制进度；
• 成本管理，包括规划成本管理，估算成本，制定预算以及控制成本；
• 质量管理，包括规划质量指标，QA测试，质量保证以及控制质量；
• 资源管理，这一部分与组织结构相关，是决定项目成败的关键要素，合适的项目需要合适的人选，其包括4个子过程：人力资源管理，组建团队，建设团队以及管理团队；
• 沟通管理，包括3个子过程：规划沟通，管理沟通，控制沟通；
• 风险管理，包括识别风险，风险分析，定量风险，提出应对以及控制风险；
• 采购管理，包括4个子过程：规划采购，实施采购，控制采购，结束采购；
• 相关方管理，相关方管理也是项目成败与否的一个非常关键的要素，包括4个过程：识别相关方，相关方参与，相关方满意度等；
• 测试管理，项目管理往往容易忽略掉QA测试的作用，在代码编写好后需要提前安排QA介入，记住一点没有经过QA严格质量测试的软件包是不能输出给客户的；
• 综合管理，综合管理的关键是综合平衡最优，平衡以上11项使之达到最优，包括制订章程，制定计划，指导与管理执行，监控项目，变更控制，结束项目。

不管是项目管理5大流程还是项目管理12项，其中有一个非常重要的工作即创建“工作分解结构”，工作分解结构是开展一切项目管理的依据与基础，可以说没有“工作分解结构”就没有项目管理。

工作分解结构

在工作过程中，人的认知是有差异的，比较资深的人员描述一个任务或问题时会比较的抽象，而初级工程师比较能理解的是具体的任务描述，为了团队具有较好的执行力，就需要把抽象的概念或描述分解成具体的可执行的行为或任务，这就需要一种合适的工具或方法来分解概念与工作。

工作分解结构法（WBS: Work Breakdown Structure，是一个“描述思路的规划和设计的工具”，是以项目结果为导向的工作过程的结构分解方法论，是将抽象的概念或任务分解成具体的行为的一种工具。将工作进行合理的分解是项目负责人的重要能力之一，缺乏项目分解能力的项目负责人容易造成项目失败，“工作分解”的好坏与否 也可以决定项目的成败与否。

如上图所示，项目管理有两大基石：工作分解结构法与 企业文化+组织结构， WBS在PMBOK中给出的定义是：“WBS是针对可交付成果对项目要素进行的分组，它归纳和定义了项目的整个工作范围，每下降一层就代表对项目工作更详细地定义。”。这一定义说明WBS所分解的目标是工作包(Work Package)，以可交付成果为导向的。企业文化与组织结构也是项目成功与否的基石，企业文化作保证，组织调整到位可以给项目提供坚强的基础资源与能力。

“工作分解结构法”的任务拆解是个有拆有合的过程。一个大的工程任务往往是由很多的小个的任务组成的，如何将一个大任务拆解成合适的小任务，能将大任务拆解成什么样的小任务，能拆解到什么粒度，拆解是否准确，这是”拆“的过程。怎样对任务进行量化与质化，怎么将任务落地到具体的执行人员上，怎么进集成怎么验收，这是“合”。任务拆解比较的考验工程人员的工程能力，任务拆解是否成功是工程进度与工程交付能否成功的关键要素。

如何进行工作结构分解

任务树分解法

如下图所示，工作分解结构就是把项目可交付成果，比如总目标一级级的分解成较小的、更易于执行的组成部分的过程，建立工作分解结构的过程就是将项目进行显性化、结构化，将复杂的总目标分解成一级任务、二级任务，最后分解成最小可执行工作包的过程。

工作分解结构可以按功能、组成、生命周期以及组织的形式进行分析，在软件工程项目中，通常以项目生命周期 + 功能以任务树的方式分解项目。如下图所示，

最终交付成果按生命周期分解成了 项目管理、业务、需求、设计与编码、集成以及交付这6项。然后设计与编码又按功能的形式分为一级任务特性：关键特性1、关键特性2、关键特性N，以此类推，直至分解成最小可执行工作包。

工作分解结构法是面向结果为导向的分解，分解过程中也需要适可而止，比如初级工程师需要给他分解到很具体的最小可执行工作包这种层次，而比较资深的工程师可以给他分解到关键特性这一层次即可，当然前提是这个资深工程师有能力承担这一特性的分解与执行。

此外，任务树适合项目汇报使用，而工作包表格适合团队内部协作使用，其能提供更详细的细节，因此在任务树拆解后，下一步是进行工作表格分解。

工作表格分解法

对比于任务树，工作包表格可以在右侧增加更多的细节，这有利于团队协作，以下图的软件项目工作包表格为例：

1，首先前三行定义了项目的目标、原则以及投入，说明了项目的交付目标、交付的原则以及约束、还有确定了人力资源的投入,；

2，任务分解成了一级任务、二级任务以及工作包、工作包名称；

3，除这些在任务树上也可以体现的内容外，还增加了 工作进展、状态、评论、风险、阶段目标、执行的人员、复杂度以及依赖条件；

4，输出最终交付成果。

工作包表格的这些细节可以使得团队协作更加顺畅，所以一般开发过程中选用工作包分解表作为项目跟进的任务进度表。

关键路径网络图分解法

除了任务树与工作包表格之外还有关键路径网络图分解法，在项目当中有些任务比较重要而复杂，有些任务相互独立、有些任务又有依赖关系，

如下图所示，S 表示Start，F表示Finish，SS 表示同时启动，FS表示先完成再启动。F11任务需要在F1任务启动后10天再启动，F23与F31任务可以同时并发进行，

而最终交付的目标需要 F2211 与 F3111 同时完成。

关键路径网络图分解法明确了任务之间逻辑关系、先后关系、时间关系，有利于项目计划进度时间的评估与规划。

工作分解结构法的理念与原则

以上内容讲的都是 工作分解结构法的 “术”的层次，其本身还有背后的理念 ，即“道”。工作分解结构法是“系统思维与分治思维”在软件工程项目中的应用。工作分解除了非常重要的专业技能，还需要遵循以下几个理念与原则：

1，滚动原则

如下图所示，项目的推进是一个 “分解、执行、检查、更新”滚动推进的过程，依据导弹思维，先保证大方向正确，开工，然后再在过程中调整小方向，直至最终精确的命中目标。项目管理也是一个逐步实现目标的过程，时间上近的获取的信息多、那么分解的层次与类目自然也就更细、更多、更准确，而时间上远的，因为信息不够完善，分解的层次与类目自然更少少，也没那么精确，在目标逐步达成后，可以进行刷新重新进行分解，完善工作包，直至最终达成目标。

2，MECE原则

MECE即“相互独立，完全穷尽”，是应用系统思维从全局的角度分解任务，既不重复也不遗漏，纵向递进，横向遍历。

3，量化质化原则

分解出来的工作包需要能量化，需要可量化的完成时间、可量化的验收标准，不能量化的任务需要质化，即以满意度的方式验收。

4，以上统下原则

工作包分解的目标是可交付成果，每一个下级成果有且只有一个上级成果，每一个上级成果是其下级成果之和，不同的交付成果可以分解到不同的层级；

5，适可而止原则

工作包并不是分解的越细越好，而应当根据项目特性的难易程度进行分解，难的复杂度高的分解细点、适当增加分解的层级，而容易的复杂度低的可以减少分层。

6，人事匹配原则

需要考虑每一级任务到底需要什么样的领域专家或者工程人员，任务要能匹配工程人员的能力，工程人员能力要能匹配任务，考虑到执行力，还需要将任务分解到人人有事做，事事能完成的层次。

小结

本文从宏观角度讲述了工作分解结构法的“术”与“道”，在宏观上理解了工作分解结构法，还需要微观上进行实践，才能做到“学以致用”。另作者能力与认知都有限，”我讲的，可能都是错的“，欢迎大家拍砖留念。

作者简介

常平，中科大硕，某AI独角兽深度学习首席软件工程师，前EMC 大数据资深首席工程师，主要工作背景在深度学习、流式大数据、云计算、分布式中间件以及Linux内核。

版权申明

本文的版权协议为 CC-BY-NC-ND license：https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh

在遵循署名、非商业使用（以获利为准）以及禁止演绎的前提下可以自由阅读、分享、转发、复制、分发等。

参考资料

[1] 《极简项目管理》 郭致星著