马丁老师严肃地说道：“我们在这里再次申明这个概念，‘可交付物’是指项目过程及最终的产品、服务或结果，并能帮助项目最终达成要实现的成果，符合干系人的需求、期望的范围，并达到验收的质量要求，并会实现一些长期的积极影。例如，为客户创造价值、交付的企业获得利益、对于所处的环境和相关干系人获得收益等。”

大家一定要记得，交付物的概念不仅是可见的产出，还可以包含一些特定的产出，如服务能力、管理机制等。从可交付物的角度来看看“菜多多”App的最终文安效果，无论从菜单布局、背景、配图，还是图标、字体、颜色等方面，是不是有种“大片”的既视感。

“菜多多”App的UI设计如图5-2所示。

图5-2 “菜多多”App的UI设计

（一）需求

我们指的需求是为了实现商业目标或满足业务的需求，对于某个产品、服务或结果达到相应的条件或具备一定成熟的能力。需求的来源既可以是高层级的商业战略所需要的，也可以是在验收标准中非常详细的要求，更或者是在项目过程这种发现的问题的解决方案，并且会随着项目的逐渐开展而不断发展演变。

需求是项目初期开展的一项重要工作，也是最需要相关干系人参与、合作的。密切地参与会使需求范围清晰，表达明确、内容详尽且版本更加稳定（第七版2.3.4）。

需求交付的重点，在于需求的设想、演进和管理，如下：

1.需求启发

即需求的发掘过程，需要相关干系人一起进行调研、访谈、头脑风暴等或焦点小组等形式，以及其他的方法等，来引导需求的产生并收集。需求的产生还可以通过交付过程的数据分析、缺陷日志的审查、触发的变更和相关干系人的反馈或其他方式而获取。

需求描述标准建议参考如下：

(1)​ 清晰，语义表达准确，即不会产生二义性，只有一红解释需求的方式。

(2)​ 简洁，描述精炼，尽可能少而明确的文字表述。

(3)​ 可核实，至少有一种方法可以验证需求已被实现或满足。

(4)​ 一致性，前后逻辑一致，没有相互矛盾的描述。

(5)​ 完整，需求能完整的包含当前项目或产品的全部内容。

(6)​ 可跟踪，每个需求都可以用唯一的标识来确认和识别。

例如，比较共识的可以遵循SMART原则：S-明确的、M-可衡量的、A-可实现的、R-相关性的、T-时限性的。

2.不断演变和发下的需求

若在项目初期无法确定需求或起始需求不清晰时，可以参考行业竞品分析、原型设计、领域建模、频繁演示或用户故事等方式进行需求的渐进明细，通过“眼见为实”的方式以固定周期交付成果，并可将完成运行的成果进行灰度验证或小范围的试运行来演变新的需求。这类情况比较适合迭代、增量、敏捷等适应型项目生命周期。

3.管理需求

因为需求的产生过程及不断演进，都在一直变化中。确保需求持续有效、有价值，是减少或规避返工浪费、范围蔓延的较好方式。同时也可以避免客户不满意、预算超支、进度延迟而导致的项目失败的风险。所以无论需求的来源或收集过程如何，都需要建立管理的机制和规范，需要时应设立需求管理角色及岗位，来确保需求管理的有效落实。此角色可以是商业分析师、产品负责人、系统分析师、价值流工程师或其他相关角色等。

为了提高需求管理的效率，可以应用一些专用软件、待办事项列表、用户故事地图、索引卡、跟踪矩阵或其他方法等，来确保需求管理的灵活性与稳定性之间的平衡，既可以支持需求的灵活应变，每个新的或演进变化的需求都能得到相关干系人的认可，也可以保证需求的一致性、完整性和稳定性。

（二）范围定义

马丁老师继续说着，我们提到的范围是对应项目，以及项目中的需求来说的，项目范围的管理是一项全局性、基础性的工作。随着需求的识别、明确后，满足需求的范围也逐渐被定义下来。范围会随着需求的演进而变化，要确保不能无限扩大和蔓延。

范围的关键在于范围的详细分解和可交付物的完成，如下：

1.范围分解

主要的范围管理方式通过范围说明书来阐明范围和通过工作分解结构（WBS）来将范围分解，以识别与项目的主要交付物和对应的验收标准，包括详细的范围说明和交付成果。WBS有助于团队实现项目目标及范围的全部层级分解的内容，并能对应到明确的交付物和交付周期，以及更细节的交付物所需的所有活动或工作。

从适应型项目生命周期来说，范围的分解和渐进明确的另一种方法可以通过敏捷章程、产品路线图、产品发布计划或产品交付层级结构等来确定，再进一步通过确定价值主题和用户故事地图。用户故事的规模大小分为史诗级故事、特性故事、用户故事，以及用户故事可以再进一步分解为任务，一般任务大小是可以按小时计算的。在相关干系人的配合下，一般会有产品负责人或产品经理来负责编制和定义故事的细节，项目其他成员一起参与，并进行任务的分解，避免在范围变化时造成规划的浪费。例如：

（1）为了完成价值主题，在初期先分析创建史诗级故事，属于大颗粒度的或者场景化的逻辑容器，基本上是一个迭代较难完成的。

（2）所以需要将史诗进一步分解成为特性，相对描述的更具体、更贴近功能层面。代表着产品的特定行为，特性的颗粒度相对小一些，可以在几个迭代内完成。

（3）再进一步分解就是一个个用户故事，是从最终用户角度通过清晰、简洁的描述方式标书的详细需求。通过用户故事来承载诸如功能、性能、安全、技术探针或数据源等方面的内容。

用户故事包含三部分，即3C，card-向特定用户提供的成果的简要说明，Conversation-通过对话进一步澄清细节，Confirmation-该用户故事的完成标准。格式遵循：

图5-3 格式

一般用户故事描述的原则可以参考INVEST：

图5-4 用户故事描述的原则

2、完成可交付物

是根据不同交付物的特点，根据所使用的方法和各自的方式来呈现组件或项目的完成情况。在范围分解的同时也一并明确了交付物的负责人及计划的交付时间，便于跟踪管理。

(1)​ 验收或完成的标准，是针对项目交付结果所需要满足的标准一般都记录再范围的说明书中，客户按照预期定义的验收标准来验收交付物；

(2)​ 技术绩效测量指标，往往交付物的技术要求或技术规范也会单独记录，并通过一些方法进行测量统计，来表明从客观上满足绩效要求。这些记录有些会单独的记在说明书或规范文件中，有时也可能记录在WBS的扩展信息中，详细说明WBS每个任务项可交付物的信息；

(3)​ 完成的定义，在软件系统或应用程序的适应型项目生命周期中较常应用这个定义，也是从客户使用的视角来明确交付物需要达到的所有标准和检查清单。

这时，马丁再次看向大鹏，大鹏马上理解了马丁老师的意思，一个机灵就站起来说道，从马丁老师对范围的定义中理解，我给大家补充说明下，我们截取“菜多多”的WBS的一部分，就可以看出对于需求的理解，以及范围的分解，例如图5-5，购物车是“菜多多”其中的一个价值主题，“购物车”本身是史诗级的；“添加到购物车”是特性级的，属于功能层面的一个主要功能点；“添加商品数量”是用户故事级的，分解到这一层已经属于客户的一个操作层面的动作了。

“菜多多”的需求范围WBS分解，示意图如图5-5所示。

图5-5 “菜多多”的需求范围WBS分解{与图4-2重复}

（三）完成的目标不断移动

每个项目的目标都是交付最好的成果，但对于瞬息万变的市场来说，随时都可能调整发布计划中的特性，或者引入新的技术需求来符合市场趋势的发展。在这里我们所谓的“不断移动”，就是指这些变化因素都会导致“足够好可以发布”和“已完成”的目标也会随着相应的持续改变。

所以，项目团队就需要灵活的方式，尽早而频地交付可发布的成果，并根据市场的反馈来实际调整计划和“完成”的项目目标。项目团队会跟踪项目计划的目标实现率（相对于进度完成率）。

一种情况是完成项目的时间耗费越长，与“完成”的目标就可能相去甚远，有时被称为“完成漂移”。

例如，PMBOK（第七版）中相应章节举的例子，图5-6显示了一个开发新智能手表的场景。初始进度计划显示，开发具有一组初始功能和特性的手表需要12个月。随着竞争对手类似产品的上市，在这组初始功能和特性的基础上不断扩增，以便紧跟市场变化，这将上市日期推迟至第14个月。第13个月，另一个竞争对手上市了一款功能更多的产品。增加这些功能会将上市日期延迟到第16个月。项目团队将在某个时点决定是否发布产品（即使它没有最新特性），或者在上市之前继续对这些特性作出更新。 

图5-6 开发新智能手表的场景（插图来自PMBOK第七版）

“菜多多”团队在初始特性（feature）是注册/登录、首页、分类、搜索、购物车、订单、其他，初始计划是从2022年3月市场调研开始至2022年12月项目结束。

但在迭代开发渐进明细的时候，发现一个必需的新特性。例如“吃什么”，经过团队与产品经理大鹏的调研和讨论，觉得“吃什么”是必须特性。那待办清单中的优先级需要重新排序，所以“吃什么”就排到“购物车”前面，“订单”和“其他”就需要漂移。相对初始进度计划来说需要延长1个月，从2022年3月开始至2023年1月结束，这样完成目标进行了第一次的移动。

之后在进入开发中后期的时候，测试骨干木宇在测试过程中突然发现：好像我们没有设计客户隐私保护方面的规则，这个需要尽快安排了，否则上线后会违反政策的。所以，就又开始一顿优先级排序和任务拆分，插入新特性“客户隐私保护”在“其他”前面，那最终计划再一次延长1个月，从2022年3月开始至2023年2月结束，这样“菜多多”团队完成了目标的第二次的移动。

“菜多多”团队具体完成的目标不断移动过程，如图5-7所示。

图5-7 目标不断移动过程

另一种情况是在相对稳定的项目因为需求的不断明确和细化，可能产生“范围蔓延”的情况。就是项目团队不得不接受一些额外的优化需求或增强需求，从而产生范围边界的扩展。虽然从需求的角度是“理所应当”的，但不会对此调整相应的进度、预算或资源，也就是说需要项目团队在自己“消化”。

为了应对范围蔓延的情况，项目团队往往会建立变更控制机制，即通过评估需求变更带来的潜在价值，以及实现其所需的潜在资源、时间和预算，并上升提交至项目治理机构、产品负责人、项目发起人或高层级管理团队来正式批准。

例如，我们在“菜多多”中看到的，刚开始特性只有注册/登录、首页、分类、搜索、购物车、订单、其他等，在大鹏、木宇与于倩通过市场调研及同业分析后，又增量识别出“吃什么”这个特性，并且也是可能增加“菜多多”的竞争力和用户体验“爽点”的特性。同时，再加上之前测试骨干木宇识别到的“客户隐私保护规则”。这样就会导致原有的“1.0版本”的发布计划的增加，只能再进一步对特性分解后，进行用户故事的价值评估，重新排序优先级，形成新的“1.0版本”（如“价值的交付”中提到的优先级列表）。

“菜多多”的完成目标移动，如表5-2所示。

表5-2 “菜多多”的完成目标移动