在PMBOK中WBS（Work Breakdown Structure 工作分解结构）是开展项目范围管理的主要工具，是项目计划、执行、控制的基础，是项目成功的关键。而大量的IT项目不成功，大多是因为范围管理的问题，譬如需求变更、需求蔓延、架构重构、代码重构、缺陷居高不下等等。不管是采用传统的瀑布模型、统一过程，还是当下流行的敏捷过程，每种软件过程对范围管理都确实好办法，从“控制变更”到“拥抱变化”，从“堵”到“疏”，更像是无奈之后的掩耳盗铃。

我们不仅要问，难道在这个所谓的VUCA时代，WBS在IT项目中失效了吗？怎么才能做好IT项目的范围管理？下面我们结合“拼写检查器”的案例来看一下。

业务需求

项目发起人提了这样一个需求“纠正文档中的拼写错误”，面对这样10个字，作为项目团队首先应该做什么？

很早之前我们在学习“需求工程”的时候就被教导过，需求是分层次的。项目发起人一般只会提出项目的目标，也就是为什么要启动这个项目，这称之为“业务需求”。业务需求看似明晰，实则非常Ambiguity！什么样的文档？怎么算错误？如何纠正？纠正有时间限制吗？有运行环境限制吗？

仅从业务需求难以开展有效的WBS！如果把项目范围比喻成一幅需要遍历的地图，“业务需求”阶段的这幅地图，却有很多地方看不清，对于新手来说这些未知区域很难估计，也许是坦途，也许是深沟，还有可能是高山。如果就此着手进行系统实现，只能是带入项目组的很多想当然，最终呈现出来的结果很可能与用户的本意相去甚远。

用户需求

带着疑问，首先需要我们做的就是找用户澄清。用户是实际使用系统的人，客户是为项目付钱的人，很多时候这两者并不一致。用户作为使用者与系统交互，他可能会这么说：“我在拼写检查器中编写英文文档，不时需要检查一下文档中是否存在拼写错误，如果有拼写错误，就从一个替换项列表中选择一个词替代它。”这是用户需求。按照用例模型的术语，这是Actor对Use Case的期待。通过这个描述，这份地图的某些未知区域变得清晰了，我们至少可以做出如下WBS。

看起来我们已经有了进步，但仔细想一想，依然存在一些疑问，譬如：怎样算是拼写错误？用户的回答也许是：“牛津词典里没有的词就是拼写错误的词”。

那么” You are a good man.”这样一个句子如果误写做“You are a god man.”这个“god”算是拼写错误吗？我知道这让你头疼了，这是个难题，涉及语法、语义，也许使用AI技术能解决，但项目组没人熟悉AI，更不知道该用什么模型、到哪里去找语料。再想到时间与预算，我相信很多人不愿意跟客户提起来，甚至都不愿意想起它。相信我，凡是你想敷衍过去的，早晚会被翻出来。这时候需要一点勇气，开诚布公地向用户说明：这项功能不包括在项目范围中。尽早澄清“不做什么”也是项目范围管理的重要组成部分，也许是冒了点风险，但效果远好于验收之前才提出这个问题。

系统需求

这样整幅地图就完整了吗？

IT系统还有其特殊性，一方面涉及人机交互（HCI）的方式，另一方面也有自动化带来的一些优势，可以让用户更快捷、更方便地实现目标。这些是需要开发人员提出来，与用户进行探讨确认的，譬如：

1)  拼写错误怎么表示？也许是“用红色高亮度显示”；

2)  替换词怎么呈现给用户？也许是“显示替换词对话框”；

3)   同样的拼写错误是逐个替换还是批量替换？也许是“实现整个文档范围内的批量替换”；

4)   替换之后是否需要提示替换结果？也许是“统计显示替换情况”。

此外，还有一些例外与非功能需求需要考虑，譬如：

1)   系统提示的所谓“拼写错误”如果不是错词怎么办？

2)   需要的“正确的替换词”没有出现怎么办？

3)    文档检查需要多快？

所有这些需求，是用户很少想到的，但又是这幅地图中必不可少的一部分，是系统实现难以避免的。这些开发人员关心的问题一般是由开发团队提出问题与解决办法，再跟用户确认。而“用户需求”则通常是由用户给出答案的，二者合在一起就形成了系统需求。系统需求是由用户与开发团队双方讨论确认的，而不是“用户需求是给用户看的，系统需求是给开发人员看的”，完整的系统需求包含用户需求。

系统需求(functional requirement)（包括功能需求、非功能需求）定义了开发人员必须实现的功能，用户使用它们完成自己的任务，实现业务目标，满足业务需求。

到此为止，我们就有了一幅细节更加完善的地图，一个更明确的WBS。

设计与实现

悲剧的是清晰的系统需求还不是地图的全部，项目范围依然还有一些部分掩盖在迷雾之中。不同的设计方案，不同的数据结构与算法，都会影响项目范围，影响WBS。以“检查每个词是否在牛津词典”中为例，我们来分析一下。

首先，在“检查词”方面，至少有两个策略：一是从文档的头部开始，逐个词都拿来对比一下；二是可以先做一点预处理，譬如生成所有词的倒排索引，这样重复的词只需要检查一次。

其次，对于参考的“牛津词典”，我们可以自建词库，也可以用第三方的服务，即便是第三方的服务，可能有的是本地软件包，有的是互联网上的Web服务。接口可能差别很大，集成时如果还要考虑安全性、高可用性、低时延，又会多出不少事情。

每一个选择意味着不一样的项目范围与WBS。一个开源的“牛津词典”实现可能会需要更长的集成调试时间与更多的缺陷修改人员。

迄今为止，这幅地图终于清晰了吗？可是项目也接近尾声了。

WBS的目标是为了更好地进行项目的计划、执行、监控，可最终我们却发现早期的WBS大多粗略，很难估算；即便估算，误差也很大，对项目的计划、执行、监控作用有限。只有到了IT项目的后期我们才能得到满足估算要求、满足过程控制要求的WBS，可这时候我们已经不需要它了！

银弹在哪儿？

这是VUCA时代的过错吗？IT项目的范围管理乱象在VUCA这个词出现很早之前就有了，如同“拼写检查器”一样，很多所谓的需求蔓延与变更不是用户变了，而是随着项目的开展我们看清了更多细节，有时候这些细节需要投入的时间与资源远远超过了最初的估算。Volatility（易变性）、Uncertainty（不确定性）、Complexity（复杂性）、Ambiguity（模糊性）只是让它雪上加霜而已。

与传统的工程项目相比，IT项目在每个阶段、每个环节几乎都存在多种选择，在需求环节如此，在设计、实现环节也不例外，IT项目大多具有高不确定性。IT系统的实现更像是命题作文，题目一样，可每个人、每个团队的做法却大相径庭。这种内在的不确定性，导致了传统的软件过程、项目管理方法的失效。

那么敏捷是银弹吗？敏捷强调迭代，强调小步快跑，强调试错，强调止损，不管从哪个角度看，采用敏捷都很难说是提高了IT项目的范围管理能力，更像是没有办法的办法。迭代强调可运行的交付，也就是把进度摆在了第一位，范围反而是最方便的牺牲，实在来不及就砍掉一些Feature！所谓的风险驱动、价值驱动很多时候不过是一句空话。

更糟糕的是敏捷越来越成为懒惰的借口，成为粗疏的软件工程的借口。因为可以拥抱变化，因为有现场客户，需求有用户故事、有3C卡片就够了，没有必要去探究业务需求、用户需求、系统需求；因为可以不断重构，架构没有必要设计，找几个框架撑起来就够了，以后重构的时候会慢慢浮现的。这样的近视与懒惰能给我们带来什么呢？

此外还有大量的商业项目，这些项目可不是开口合同，敏捷转型给这类项目、给项目团队又带来了什么呢？

敏捷的背后首先是信任，分包商与承包商之间的信任、公司管理层与项目团队之间的信任，项目管理者与团队成员之间的信任，项目团队成员之间的信任。没有信任做支撑，看到的只能是无尽的敷衍与扯皮，项目范围失控在所难免。

如何做好IT项目的范围管理，如何利用好WBS？我能给出的建议只有三点：

1)    尽量录用能找得到的、用得起的最有经验、最熟悉项目领域的人，特别是在项目初期，这样能尽早有一个尽量靠谱的WBS，为项目受控提供可能；

2)    不论采用哪种软件过程，尽可能一次做对。

3)    尽量开展AAR，把经验教训转化为组织过程资产，下次少走弯路。