本节书摘来异步社区《嵌入式系统开发之道——菜鸟成长日志与项目经理的私房菜》一书中的第2章，第2.4节，作者：邱毅凌，更多章节内容可以访问云栖社区“异步社区”公众号查看

02-04项目范围（Scope）管理

嵌入式系统开发之道——菜鸟成长日志与项目经理的私房菜

刚刚我们已经强调了，必须尽量在项目初期排除不确定性，否则，越在项目前期犯的错误，对项目成败的影响就越大。在此我们看到了一个惊人的数据—68倍！前期的分析与规划工作做得越仔细，后期出现‘惊喜’的机会就越低。虽然所有人都了解这个道理，但往往都过份低估了项目独特性可能带来的影响。

有相关经验的工程人员，常会认为同质性高的项目没什么了不起，没必要做太多规划工作，做就对了！等到项目后期才发现，新项目和以前做过的项目还是有些差异，此时已完成的系统架构已经无法容纳这个差异，最后只能投入更多的时间或人力，进行架构性的改变。

这就是68倍的由来。过度轻视项目的困难度、走一步算一步的工作方式，最严重的往往是：根本不知道项目的真正目标（通常是自以为知道，但其实对细节完全不清楚），就直接往错误方向硬干，做越久，偏差越大，最后想要拉回来更是难上加难！

所以PMP知识体系告诉我们，当项目启动后，首先就是要花时间做好项目的范围管理，唯有定义出正确的范围（Scope），之后做的进度、成本和人力计划才是有意义的。

所谓项目范围除了包含该做的项目，也要弄清楚不该做的工作，两者同样重要。项目团队的人力、时间与预算都是有限的，没有理由对项目范围不加限制，任由工程师天马行空的按照自己的想法去做。在项目管理的思想中，这绝对是缺乏纪律的行为，称为镀金（Gold Plating）或范围蔓延（Scope Creep），这都是应该要尽力防止的事情。

从幻灯片的流程图中可以看出，需求分析也是个循序渐进、不断修正的工作，甚至经常发生已经到了项目执行阶段，客户才要求更动规格的事。此时，项目计划既已完成，就应该执行变更管理流程，在新计划中适时反应项目范围变化所带来的影响。

范围管理有两项重要的工具，一项是我们现在要谈的工作分解结构（Work Breakdown Structure，WBS），另一项则是变更管理。

在评估工作量时，有个人人皆知的简单概念：事情越大越复杂，越不容易估计准确。因为这样很容易就会忽略一些重要的细节，所以人们早就知道由繁化简的道理，并将其应用到项目范围管理中。简单来说，就是将一件复杂的工作，切割成许多较容易执行的小工作，假使这些小工作还是太复杂，就继续切割，并反复递归地执行这项分割工作，直到我们有把握评估每件小工作的特性为止。

举例来说，最初的项目范围可能只是一句话：开发一台多媒体播放器。谁也没办法由此精确估计出Schedule、Cost等项目特性，所以必须继续将开发工作切分为软件、硬件、结构、生产，然后再为每个项目继续分割，可能会得到：选择MP3译码IC、系统架构设计、实现电源管理模块、准备备料计划等较可掌握的小型工作。

工作分割最终会长成一个树状结构，根（Root）为项目目标，树叶（Leaf）则为许多小工作，这个树状结构即称之为WBS。至于工作要切割到多细才合理呢？如果切割太细，则项目范围分析时难免会触碰到太多技术细节，一旦工作项目太多，会使得项目计划过于复杂，而且容易扼杀工程人员的创意空间；如果切割太粗，则项目计划就会有评估不准的风险。

对此PMP给出了建议：WBS最底层的工作（Leaf）要非常具体，不容模棱两可，而且至少必须切割到约一周或40个工作小时的工作量—这是一项经验值，这种工作量的工作，用于评估不至于产生太大的误差，且工程人员仍保有足够的发挥空间。

制定WBS是项目规划阶段最重要的工作，除了将项目目标切割为项目计划中的基本单位外，更重要的是，在制定WBS的过程中，我们可以过滤出所有规格、管理与技术上的盲点，并在项目初期尽快理清所有不明确之处。

就算从没听过PMP或WBS，一般人在解决问题时也都会自然地将其切割为许多小问题，然后逐一寻求解决方案。WBS的思想很靠直觉，大部分项目都知道要按此思想做事，但并未真正把WBS画出来。所谓没图没真相，我们就无法对WBS的合理性做严谨的review，而且在拟定计划时，很容易就会忽略某些工作项目。

记录WBS的方法有很多种，我会建议使用Microsoft Project来做（要用Excel来记录也无妨，但在制定项目计划时，还是得复制到项目管理工具上）。

WBS有两种描述方式，一个是图表法（如幻灯片的左半部），优点是一目了然，但当项目工作较为复杂时，这样的图难免显得杂乱，且较难以工具进行处理。所以通常我们会用另外一描述方法—在纸上画出树状结构草稿，然后使用如幻灯片右半部的列表来做管理。

在进行任务分解时，由上至下的标准必须一致，否则，当项目较复杂时，很容易因为任务分割标准不一，导致任务重复。一般使用的任务分解方法如下。

按照子功能分割
按照系统架构
按照项目生命周期
参考以往类似性质的项目
初版WBS完成后，一定要经过相当严谨的检查与公开review。再强调一次，如果WBS有问题，之后进行的Schedule、成本（Cost）、人力资源（Human Resource）等评估都会跟着出问题。

WBS其实就是项目的Scope Baseline（基线或基准），它除了描述本项目中所有必须执行的工作之外，同时也说明不在WBS中的工作，都是没必要执行的！有时候，后者反而是容易被忽略的思想，项目主管放任工程人员执行了半天似乎与本项目有关却不属于项目目标范围内的工作，这样的行为对项目来说都是非常不利的！

项目有一个重要的特性—必须先做‘对’，行有余力才做‘好’。嵌入式系统产品开发项目更是如此，客户要你做低价位的MP3播放器，你却做了一个可以播MP3的智能型手机给它，你说客户该哭还是该笑？

总之，WBS绝对是项目计划的基础，如果连要做什么都不知道，项目运行宛如瞎子摸象，要顺利结项只能靠老天保佑了。

接下来，我们将谈谈项目范围管理的第二项重点—变更管理1。

变更管理是在项目谈行阶段用来处理项目计划与实际状况有落差的情况。如幻灯片中的流程图所示，项目在执行时，追踪与监控工作必须同步运行，一旦发现计划与实际状况不符，或客户提出规格更改要求时，就必须提出变更需求。

在变更处理流程中，相关人会评估接受此变更的影响。还记得我们前面说的项目铁三角吗？某一边的更动，势必要影响其他的两个边。如果这个变更真的轻微到不会对项目其他的面造成影响，那我们也没必要为此担心。一旦某项变更会严重影响进度或需要增加成本，则必须所有关系人（例如：PM、公司高层、客户代表等）讨论同意后才能接受此变更，并将所造成的影响全部照实Update到计划书中。假使项目关系人无法接受变更带来的负面效果，就只能放弃此变更，或请工程人员另觅他法。

无论如何，我们不能放任一个已知的问题在项目中，而不去处理！

对项目来说，变更宛如万恶根源，是很负面的字眼，也是项目经理的梦魇。变更可能会对项目的正常进展带来无尽的麻烦，但奇怪的是，几乎没有项目不会碰到变更。特别是电子产品开发项目，电子产品的生命周期短、开发复杂度高，有时真的就是计划赶不上变化，当客户说出‘若不改规格就不用卖了’时，身为伙伴的我们不配合也不行。

面对这种状况，流着眼泪、带着微笑地接受绝对不是最好的处理之道，这只是让冲突点延迟爆发而已。最好的方法应该是如上所述，召集所有关系人，大家一起审视原先拟妥的计划书，共同面对问题，以寻求解决的方法，让RD加班只是方法之一，缩减规格、增加预算或时间，甚至放弃变更都可以拿出来讨论。

面对变更需求绝对不能慌乱，务必使变更在受控制的前提下对项目产生影响，千万不可任其随意变化。项目经理一定要把持一个铁的原则—因为变更会影响项目进行，因此，所有的变更一定要经过CCB（Change Control Board，变更管理委员会，即与此变更有关的关系人参与决策的会谈）的同意，并造出新的计划书，而工程人员只需随时按照最新版本的计划执行即可，严格禁止接受客户私下变更规格的请托。

实际上，我们会把变更处理流程制定的越简单越好，并鼓励员工一旦发现任何计划与实际状况有落差时，马上向主管报告，若连主管也无法处理时，则提出变更需求。项目经理会视状况召集需要参加CCB的项目关系人，变更审查时必须谨慎，必要时，一定要深入进行技术的review。

项目团队存在的目的只有一个，就是让该项目顺利结项，假使发现某项变更请求可能会使项目出现大问题，也应将此突发事件视为当前最高优先级的工作，项目经理必须尽力协调，务必要将其处理妥当，直到造出新计划为止。否则，放任项目继续执行下去并无任何意义！