企业在云效上到底应该用需求来管，还是任务来管？需求、任务总是傻傻分不清楚。
今天我们跟踪云效《阿里巴巴DevOps实践指南》一起解决交付问题的第一步，是搞清交付的是什么。否则，交付对象是模糊的，明确的过程就无从谈起，更无法保证过程效率。搞清楚交付的对象，具体包括它来源于哪里，为什么服务，有怎样的层次结构以及各个层次承载的价值。 接下来，我们将基于最典型的需求层次结构，介绍这部分内容。
典型的需求层次
典型的需求来源及需求层次关系
上图展示了典型的需求层次结构，它包含三个层次：业务需求、产品需求和技术任务。
01 业务需求
需求协作和交付过程，最终必须为业务服务——交付业务价值，并保障业务成功。业务需求来源或转化自原始的用户诉求或业务和产品的初始想法。这些原始的需求经过过滤、归类和分析转化为正式业务需求。
不同特征的组织，业务需求的习惯名称不同。比如：强调用户驱动的可能称之为“用户需求”，对外以产品形式售卖的可能称之为“解决方案”或“产品特性”。不管名称是什么，它们的共同特点是都服务于业务的目标，且最终都要落地为产品功能。在本篇中，我们统称其为“业务需求”，强调这个层次的业务属性。
业务需求承载业务价值，它是系统验收的基本单元，也是运营和发布（Release）的基本单元，需要时可以被独立地发布和运营。它一般由业务人员（如业务运营或业务分析师）负责收集、创建和维护。
02 产品需求
产品需求可以分为两类。第一类拆分自业务需求，直接服务于今天的业务，它一般由业务负责人或产品经理基于业务需求拆分而来；第二类源自产品的规划，它们不直接服务当前业务，而是为未来的业务做基础和提前的准备，典型的包括：产品的基础功能、提前的技术布局、技术重构等。它们通常由产品经理和技术团队创建和维护。
产品需求承载产品的具体功能，是产品集成和测试的基本单元，通常也是系统部署（Deploy）的基本单元。一个业务需求设计多个产品的功能时，它会被拆分到多个产品，对应多个产品需求。例如，业务需求是“在供应链中支持预先锁定库存”。为了实现它，需要供应链计划、库存管理、履约服务、财务结算等多个产品的功能改动，就对应多个产品需求。
03 技术任务
技术任务承载具体的实现工作，它是工作分配（Assign）的基本单元，也是实现的基本单元。技术任务分解自产品需求，它包括不同职能的任务，如前端、后端、算法等。技术任务的拆分通常由技术团队完成。
不同上下文中的层次结构变体
现实中，业务和产品复杂度不同，其层次结构也不同。下图是三个不同变体。从左到右分别适用于简单、典型和复杂的业务和产品。
基于不同的业务和产品复杂度的需求层次结构调整
图中的第一种模式适用于简单的业务。这时，业务与产品一一对应，业务需求与产品需求也合并为一层。这一模式下，原始需求直接转化为产品需求，产品需求分解为技术任务。这一模式适用于简单的互联网业务、企业应用或工具产品，业务在初创时都适合这一模式。
对于复杂的产品和业务，如果产品需求只有一个层次，可能会让产品需求过大。这时，可以将产品需求分解为两个层次——产品特性和产品需求两层，也就是图中的第三种模式，它适用于电信产品、基础技术产品、复杂的企业应用等复杂的业务领域。不过，对于大部分场景，第二种典型中的三个层次就已经足够。
赋予每个层次明确的意义和目的
不同方法体系，其需求层次结构的定义的依据不同，结果也不同，如：Scrum中常用Epic、Story和Task来描述需求的层次关系。这一层次结构的划分依据是规模。其中，Story（用户故事）是从用户角度对需求的描述，它要求能够在一个迭代完成；Epic（史诗）是巨型故事或故事集，需要被进一步分解为Story；Task（任务）是对Story的进一步拆分，要求能跟踪和更新日常进展，通常可以由单个人完成，工作量不超过20工作人时（Person Hours）。
需求类型的不同命名方式
作为通用方法，Scrum追求普适性，其推荐的需求层次刻意回避了业务属性。但是，它在提高普适性的同时，让协作过程的业务意义模糊，导致无法定义精准和有效的协作流程。
我们认为，只有明确需求层次以及每个层次承载的价值，我们才能够定义有意义的协作过程，过程相关的人员的职责和活动，并判断这一过程是否与所承载的价值匹配。因此，我们在设计需求的层次结构时，要求明确每个层次的意义和价值。
总结
以上，我们分析了需求的来源、需求的层次结构、以及每个层次所承载的价值。它是一个标准参考模型，本身具备较好的普适性。基于业务的特征不同，也可以加以定制。比如：因业务的复杂性不同，而增减层次；或者业务交付方式不同，而将业务需求改成其他名称。
清晰定义需求的层次结构，明确各个层次的价值。基于它们，我们就可以定义协作过程，实现并交付这些价值，保障协作和交付的效率和效果。下一节我们会介绍业务驱动的协作。
