1.3 需求管理

文/章冀灶（晟远）

我们将从需求的定义、规划、澄清、拆分、进度管理这五个方面来介绍如何管理需求。

1.3.1 需求定义

1.什么是需求

我们经常提到“需求”“用户痛点”，那么到底什么才是“需求”呢？

我们可以将“需求”理解为用户的需要，即产品现状无法解决的用户痛点。用户之所以选择一个产品，一定是为了解决某些痛点。接下来我们将举例说明到底什么是需求。

示例一，淘宝直播是淘宝推出的一个导购产品。对于C端用户来说，他们希望在看直播的同时能够与主播互动，解决自己在收看直播的过程中对于商品所产生的疑问。

评论功能是与主播互动非常有效且直接的功能，用户可以通过提问快速得到主播的回复，因此评论功能可以作为淘宝直播的一个功能需求。

示例二，小红作为某社区App的高活用户，粉丝数将近十万。持续运营粉丝及商业化是KOL（Key Opinion Leader，关键意见领袖）的强诉求，那么对于社区平台来说，应该为KOL提供什么样的功能呢？

自运营的功能是KOL的强诉求，例如，圈子自建、管理等能力就是KOL在自运营诉求中的基础需求。

从某种程度上来说，未满足的用户的真实诉求、用户的吐槽点都应该是产品的需求，产品需求源自用户，也服务于用户。

2.需求结构

需求因其层次的不同会具有不同的结构，一般情况下，需求结构主要分为三层，如图1-9所示。

（1）业务场景层

业务场景层主要包含可发布、可运营的基本单元。对于明确的业务目标，业务场景可提供相对完整的业务能力，包含业务链路上的一个或多个产品功能。

（2）功能需求层

功能需求层主要包含可测试和可部署的基本单元。功能需求包含一个或多个开发任务，是用户可以感知到的功能，服务于具体的业务场景。

（3）开发任务层

开发任务层主要包含基本的开发单元。开发任务既包括团队的任务，也包括需要依赖其他团队配合开发的任务。

从图1-9上半部分可以看出，整个上层结构都是基于产品规划层面，将功能需求与业务场景对齐，快速交付业务场景，并形成业务目标的反馈闭环。当然，在某些情况下，功能需求也可以直接与迭代目标对齐，以保障迭代目标的达成，形成相应的反馈闭环。

而图1-9下半部分则主要是基于整个交付团队层面，是将开发任务与功能需求对齐，以保障持续高质量的需求交付为核心目标。

上面的描述可能比较抽象，下面我们通过一个实例来说明。

1）迭代目标。淘宝直播团队在2020年上半年的某个迭代中希望能实现直播频道留存的增长，次日留存从×××增长到×××。

2）业务场景。要想实现上述的迭代目标，核心的策略是用营销活动、产品策略等方式留住用户，提升用户的活跃度。经过业务、产品、开发等相关人员的协商，最终团队决定采用签到领红包、秒杀等营销方式来达成用户留存的目标。在这个场景下，签到领红包、秒杀等营销活动就属于业务场景，在需求阶段我们就应该明确各种营销方式，助力达成目标。

3）功能需求。这里我们以签到领红包的业务场景为例，从功能需求的维度来看，签到领红包一般可以分为签到、红包领取、红包发放、红包消费等功能，那么对于产品人员来说，应该针对上述这些功能进行详细的需求设计，以保障签到领红包的业务场景是可以实现功能闭环的。

4）开发任务。以上述的红包领取业务场景为例，在淘宝天猫的场景下，该业务场景与登录、卡券包等依赖方及内部的一些开发任务相关，所以一般情况下，我们可以将开发任务拆解为卡券包、红包发放接口联调、淘宝天猫登录接口开发及联调等子任务。只有完成所有的开发任务及完成联调部署之后，才算是实现了其中一个功能需求。

我们可以发现，需求包含了很多层不同的结构。日常生活中，我们也需要拆分需求，最细的颗粒度就是开发任务，那么，如何进行有效的拆分呢？具体细节我们将在1.3.4节中展开讲解。

3.需求来源

需求的来源是方方面面的。根据需求来源的不同，我们可以将需求分为内部需求和外部需求。外部需求主要是指针对用户研究、访谈等所产生的需求，内部需求主要是指领导层的指示、业务方的需求等。

通常情况下，在淘宝天猫，我们一般会根据来源角色的不同将需求分为三类，分别是产品运营类需求、视觉交互类需求、技术类需求。下面我们就来分别看一下这些不同类型的需求。

（1）产品运营类需求

产品运营类需求一般由产品、运营人员提出，来源于产品的需求一般是基于整体产品架构设计而产生的需求，而来源于运营的需求则一般都是运营人员在平台使用、用户调研等过程中产生的需求。无论是产品需求还是运营需求，所有的需求都应该经过可行性分析、优先级定义、方案设计之后再进入到后续的评审等环节。

这里以躺平App为例进行说明。产品人员会定义整体产品的基础架构，例如，发布体系、消息体系、圈子互动体系、导购交易体系等，均是基于基础产品架构功能而定义的产品类需求。运营类需求与之类似，例如，社区希望刺激用户生产优质的内容，那么运营就会针对该目标提出相应的营销活动需求，然后产品人员将基于运营的活动需求进行可行性分析等，直至产出PRD（产品需求文档）。

（2）视觉交互类需求

视觉交互类需求一般由UED（交互视觉设计）人员提出，主要是基于产品交互体验的一致性、便捷性、友好度及视觉品牌的认知提出的需求，该类需求一般会从用户体验的角度出发，通过交互优化、视觉升级等方式为用户提供体验更好的产品。

（3）技术类需求

技术类需求一般由技术、测试等相关人员提出，主要是为了构建高可用、安全、顺畅的产品，通常会分为安全性需求、性能需求、稳定性需求等。安全性需求主要是为了保障用户在产品体系中的信息安全、支付安全等，保障的是用户的基本权益。性能需求则主要是为了保障用户的使用体验，能够为用户提供流畅的操作体验，性能需求的指标一般会包括帧率、CPU等。稳定性需求主要是为了保障产品在使用过程中各项功能的稳定性，尤其是对于移动端App的使用，大家会更多地关注崩溃、卡顿等问题。

从本质上来讲，无论是什么样的需求，或者是来源于谁的需求，首先都应该从用户诉求、用户痛点出发，服务好我们自己的用户。用户是产品的核心，你所服务的群体将是未来用户增长的核心目标群体。

1.3.2 需求规划

1.需求目标

战略目标可拆解为四层：战略、战役、项目集（项目组合）、项目。项目目标对于战略来说是最小的单元，但对于小团队或项目组而言，其又变成了一个核心的方向，我们需要将项目目标继续往下拆解，以方便项目的落地，即项目/团队目标→迭代目标→需求目标。下面我们来看一个具体的实例。

（1）项目/团队目标

阿里巴巴躺平App的定位是好物分享推荐社区。该团队2019年上半年的目标主要分为如下几点：DAU达到×××，次日留存/第30日留存达到×××，互动率达到×××。

（2）迭代目标

该项目组采用双周迭代（指从业务需求的产出到最终发布上线的时间为两周）的方式来保证产品的持续交付。项目经理将上半年的6个月分成了12个迭代，并且针对每一个迭代对相应的目标进行了拆解，例如，2019年上半年第一次迭代中，DAU为×××，次日留存/第30日留存为×××，互动率为×××。

（3）需求目标

一个迭代的目标需要通过该迭代中的所有需求来实现，所以需求也需要有相应的目标。例如，分享的需求，主要是用于帮助拉新回流，那么从目标的角度来衡量，我们可以将分享的需求定位在对于拉新的增长刺激。

上述的例子可以说明各层级间目标的相互依赖关系，但是部分读者可能还会产生这样一个问题，即我们已经有了项目目标、迭代目标，为什么还要为需求设定目标呢？

我们可以清楚地看到，在项目的运转过程中，需求是助力项目目标达成的最小单元，如果过程中我们没有对需求目标进行设定及衡量，那么极有可能会出现的一种现象就是，我们做了一堆未经深入思考和论证的需求，做了很多可能无法助力项目目标达成的需求，这就很容易导致整个项目组走弯路、偏离正道行驶。下面，我们简单总结一下设定需求目标的好处。

❑ 需求目标可以更好地帮助衡量需求的实现与项目目标的关系，减少未经思考论证的需求的产出。

❑ 需求评审（下文将提到）能够根据不同的视角针对需求的目标进行讨论，多维度判断需求目标设定的合理性。

❑ 需求上线后有助于通过线上数据的反馈与之前设定的目标值进行对比，分析超出预期或者未达到预期的原因，为后续的持续迭代做好相应的分析及输入。

总而言之，前期的目标设定在项目运转过程中起到了非常重要的作用，PM（项目经理）应该持续关注目标的设定、目标的合理性及上线后的数据反馈等，帮助整个项目组在需求实现上建立相应的闭环，持续驱动大家朝着正确的方向前进。

2.需求优先级定义

当需求目标明确之后，接下来就是需求分析的阶段。任何一个项目组的研发、测试、设计等资源都是有限的，我们需要在有限的时间内尽快交付需求，同时为了使ROI（投资回报率）更高，需要更早地交付优先级高的需求。那么到底应该如何确定需求的优先级呢？

需求优先级=（（企业收益-企业成本）/企业成本）×用户获利值×目标用户占比

当然在很多场景下，尤其是在互联网行业中，我们通常很少以上述公式分析需求的优先级，而是借助一些工具来对优先级进行分析和判断，通常采用的是KANO（卡农）模型。

KANO模型是东京理工大学教授狩野纪昭发明的用来对用户需求进行分类和优先级排序的有效工具，以分析用户需求对用户满意度的影响为基础，体现了产品满意度和用户满意度之间的非线性关系（引自百度百科）。KANO模型一共包含五类影响因素，具体说明如下。

❑ 必备因素：满足此基础需求时，用户才会使用产品。如果不提供此需求，那么用户满意度会大幅降低，甚至流失。比如说，社区类App没有发布器。

❑ 期望因素（线性因素）：KANO模型是从线性需求模型演变而来的，线性需求在产品中实现得越多，用户就越满意，如果不提供此需求，那么用户满意度会降低。例如，社区类App中的圈子自建、圈子管理功能。

❑ 兴奋因素：用户意想不到的因素。不提供此需求，用户满意度也不会降低，但是在提供此需求后，用户满意度会有很大的提升。例如，短视频App中的视频瘦身功能。

❑ 无差异因素：无论是否提供此需求，用户满意度都不会变。

❑ 反向因素：用户根本没有此项需求，提供后用户满意度反而会下降。

基于KANO模型，同时结合业务目标，我们更容易得出需求的优先级。在实操中，我们通常会对上述三类因素分配一定比例的资源投入，常规资源配比为“必备因素‥期望因素‥兴奋因素=6‥3‥1”（也可视项目组具体情况而定）。

3.需求负责人机制

我们的项目管理团队面临的现状是，对接大淘宝上千名技术开发人员的PM只有十几个人。显而易见，每个人的精力有限，只能关注重点的战役、项目集，对于参与人数在几百甚至上千的大型战役、项目集PM无法完全深入到每一个项目的细节中，但又必须统筹整体的进度、风险、目标达成情况等。那么，如何才能做好统筹呢？

这时候就需要有一个纵向的PM梯队，也就是说，很多技术人员将兼职PM，腾出一些精力负责其项目的交付情况、关注项目的细节等。

位于整个梯队最底层的其实就是所谓的需求负责人。需求负责人对需求目标的实现负责，包含前期需求价值评估、可行性分析、需求排期、进度跟踪、风险把控、保障稳定发布等一系列流程。简而言之，需求负责人就是需求的第一负责人，如图1-10所示。

需求负责人的核心职责具体说明如下。

❑ 需求价值评估阶段：负责人要尽可能地深入理解需求，做好价值判断，明确需求的目标。

❑ 可行性评估阶段：确认方案的可行性，明确上下游依赖，排除项目潜在风险。

❑ 项目排期阶段：明确技术方案，组织技术方案评审，对项目进行排期。

❑ 项目开发测试阶段：做好进度跟踪，把控风险，推动解决关键问题，每日同步项目进展，监控关键风险点。

❑ 项目上线阶段：做好稳定性观察、舆情观察，上线后跟踪数据效果。

在实操过程中，我们将负责此需求的最主要的开发人员任命为需求负责人，由该开发人员统筹全局。因为该开发人员对于整个需求的实现、可能产生的风险、开发的成本预估等会更准确。

在需求落地的过程中，需求负责人一定要注意，不仅要关注需求的交付及系统的设计，而且还要关注需求价值、可行性评估等。很多时候我们会发现，风险的引入从需求阶段就已经开始了，需求的逻辑不清、价值不明导致了上线后未能达到预期。需求的交付仅仅是需求全生命周期中很小的一个环节，要想保障需求价值的高效交付，需求负责人更应该关注端到端的链路。

4.需求计划管理

需求计划管理是指管理需求端到端全生命周期的计划，即明确需求各关键节点的时间，例如，定义需求目标、需求/交互/视觉评审时间、开发联调时间、提测时间、发布部署时间等。需求负责人应按照实际、客观的情况制定相应的详细计划。在计划的制定过程中，需要综合考虑可能影响到时间计划的因素。可能产生影响的因素包括需求优先级、资源投入情况、工时评估、封网计划等。

在制定需求计划的过程中，为了更高效地产出及提升可视化，我们一般会借助工具来进行相应计划的制定及管理。例如，在淘宝天猫内部，我们通常会使用Aone（阿里内部的项目管理工具）进行计划的制定、管理及持续跟踪，市场上使用较多的还有研发效能工具Teambition等。当然，也可以使用一些线下的工具来制定相应的计划，需求负责人可根据自己的习惯来选择。但在一个项目组中，PM应尽量使大家通过同一种工具来进行管理，以方便对项目进行长期的管理，以及与项目组成员查看项目计划的习惯保持一致。

甘特图或Excel表都是用于制定计划的辅助工具。如果在制定需求计划时，发现该需求的上下游依赖特别强、依赖关系非常复杂，那么我们建议需求计划的制定最好是采用甘特图来进行，其余的情况借助于Excel表应该就可以满足需求了。图1-11为Excel计划图。

从图1-11中我们可以发现，需求计划必须要包含一些元素，如需求描述、需求优先级、PM（即需求负责人）、开发人员等。下面分别解释一下各元素的定义。

❑ 需求描述：明确展示该需求，方便所有项目成员对需求情况一目了然。

❑ 需求优先级：通过卡农模型等方式明确需求的优先级，并将其标注到需求计划表中。

❑ 需求负责人：提前定义好所有需求的负责人，负责该需求端到端的交付。

❑ 开发人员：列出该需求涉及的所有相关开发人员，只要是有依赖关系的人都应该列出来。

❑ 工期：评估实现需求各依赖模块所需要的工时。

❑ 联调、提测等时间：明确定义好涉及开发的各端的联调、提测的时间点，包括测试介入、测试发布等时间点。

在需求计划的制定过程中，我们应该优先关注高价值、高优先级需求的排期，将核心的资源重点部署在该类需求上。

这里需要强调的一点是，对于涉及横向依赖的需求，PM一定要梳理好彼此之间的依赖关系，上下游的交付节点至关重要，因为一旦出现依赖关系梳理不清、交付节点不明确的情况，就极有可能会出现最终交付延迟的问题。

项目计划得到最终确认之后，PM应第一时间同步给项目组成员，让所有项目相关方确认排期的合理性，如有异议再线下重新对焦，直至确认最终的排期计划。

1.3.3 需求澄清

需求的澄清通常通过撰写PRD或举办评审活动。

1. PRD

PRD（Product Requirements Document，产品需求文档）一般由产品经理根据需求撰写，是需求进入交付环节之前非常重要的产物，也是产品经理将业务需求、用户需求翻译成产品语言的产物。PRD的作用具体如下。

❑ 降低项目成员沟通成本：项目成员可以通过文档理解和查看逻辑问题，而无须线下找产品经理确认。

❑ 梳理逻辑，避免遗漏：PRD会梳理所有的产品逻辑。

❑ 信息存档：方便后来的产品经理对于过往需求有更全面的了解，同时也可以作为团队沉淀的资产。PRD可以算作对产品的注释。

但是实际上，每个产品经理都有自己的风格，所写的PRD也千差万别。为了更好地统一大家的认知、提升其他成员的浏览效率，应该针对需求模板对PRD进行相应的统一。淘宝天猫常见的需求模板包括如下几个方面。

❑ 需求背景：填写需求来源、需要解决的问题和达成的目标等，用于描述需求的重要性等。

❑ 需求方案：填写需求的详细逻辑，业务流程（正常还是异常）和业务规则等。

❑ 需求验收标准：填写需求的详细逻辑和内容，数据类需求需要增加明确的指标定义。

❑ 依赖方：填写需求所要依赖的业务和模块。

❑ 数据埋点：确认数据埋点的需求，以方便后续进行数据分析。

利用上述统一的需求模板，一方面可以统一大家的PRD格式，另一方面也会督促PM在写PRD之前考虑清楚需求的价值和目标，这在一定程度上可以避免一些没有经过深入思考和论证的需求直接进入开发过程，从而导致开发资源的浪费。

2.评审活动

（1）需求评审的意义

需求评审是产品经理阐述需求设计思路的重点环节，也是从需求设想到开发阶段的必经之路。需求评审一般扮演着非常重要的承上启下的作用，需要在需求评审会上让各参与方都明白产品的设计思路、产品价值、背景、目标及可能需要的依赖。如果评审会上还有不明确的点，那么在会后还需要继续讨论，直至明确敲定所有的细节。下面简单总结一下需求评审的几个目的。

❑ 明确业务和产品价值。需求是为提高用户体验、解决用户痛点等服务的，那么我们做需求也要明确其最终实现的业务或产品价值到底是什么，需要通过需求评审会议做一次全方位的传达。

❑ 达成一致意见。现实中一个需求的实现往往需要项目组各端成员的协同，那么拉齐大家对于需求理解的一致性是非常有必要的，同时也能了解大家对于需求的疑问以及让成员明晰所要面临的挑战。

❑ 明确最终需求。评审会的各参与方可以从不同的角度思辨需求的真伪、完善度及合理性，从而保障最终得出的是真正的需求。

（2）需求评审的参与人

需求评审会需要所有决定需求实现的相关人员都参加，包括业务方、产品经理、UED（交互视觉设计师）、项目经理、开发人员、测试人员、相关依赖方等，只要是会影响到需求按时上线的相关人员都需要参加。

❑ 业务方：运营人员往往也会提出一些需求，需要产品经理翻译为产品预演并结合整体的产品设计给出合理的解决方案。

❑ UED：产品人员一般会在需求评审会之前就准备好产品的原型，UED需要实现整体的交互流程、页面展现等，并最终向开发人员提供交互稿或视觉稿。

❑ PM：如果项目组有专门的项目管理人员，那么一定要参与评审，帮助落地整体需求。

❑ 开发人员：包括客户端、前端、服务端等所有与需求实现相关的开发人员都需要参与，同时建议技术总监一同参与需求评审会。

❑ 测试人员：测试是对需求质量进行把控的重要一环，因此测试人员必须参与需求评审会。

❑ 依赖方：如果该需求的实现需要依赖其他团队的上下游链路，那么依赖方的产品人员和开发人员也要参加需求评审会。

（3）需求评审流程

需求评审的流程一般分为三个阶段，分别是评审前、评审中、评审后，如图1-12所示。在各个评审阶段，我们都要提前做一些准备工作。

1）评审前。准备好需求之后，产品经理或项目经理应至少提前2～3天向参与方发送需求评审会议，明确评审会议的时间、地点，同时附上PRD，让参与方能够提前了解需求细节。

2）评审中。需求评审会上，主要由产品经理讲解需求的背景和价值、功能模块及整体的优先级，同时如果提前准备好了交互流程，那么交互视觉设计师也可以在会上讲解交互流程。评审会上参与方应对所有不明确、依赖边界情况、技术实现困难点等问题提出自己的疑义，尽量在会议中明确敲定各个问题，如需进行线下讨论，那么产品人员应与所有相关方将存在疑义的问题点全部讨论清楚。为了保证需求评审会的高效，需要特别注意如下列举事项。

❑ 评审过程中要确保PRD与交互稿保持一致。

❑ 产品经理或项目经理一定要控制好整体会议的流程及进度，避免大家在讨论的过程中跑题，组织者应尽量控制会议的效率及讨论的方向。

❑ 如果会议中出现大的歧义或疑义点，应记录下来，在会后进行小范围讨论，评审会上先明确敲定大家一致认同的需求点。

❑ 切忌在会上讨论技术方案，技术方案应通过单独的会议进行对焦，评审会上开发人员可以根据自己的经验提供一些建议和反馈，但不要展开对细节的讨论。

3）评审后。评审会议结束后，如果会上所有的逻辑都已明确，那么产品经理应将最终版本的PRD明确后，提交给项目组的相关人员，同时设计师开始介入进行UI设计，开发人员设计技术方案并评估工作量。

如果会议中还存在有待明确的点，那么会后产品经理或项目经理应连同相关人员明确敲定这些有疑问的点，并且在得出明确结论后，及时同步给所有的相关人员，建议通过当面沟通、邮件、群沟通等各种形式同步最终结论，以防部分人员因信息不齐而导致需求遗留，或者造成开发资源的浪费。

1.3.4 需求拆分

软件开发过程中，需要回答两个最本质的问题，即做什么和怎么做。在这两个问题中，做什么无疑是最重要的。然而，软件开发中普遍面临需求不够清晰或者需求过大的问题，这些都成为限制软件持续交付的主要原因。那么，是否有一种实用的方法实践，能够快速地完成需求分析，理清需求背后的问题，并使需求得到合理的拆分呢？

1.需求拆分的原因

（1）需求的拆分方式直接决定了研发的模式

在传统软件交付过程中，一个大的需求不会在问题域拆分，而是由架构师主导在实现域从实现的角度按模块拆分，再由不同模块的开发人员负责具体模块的开发工作。这种拆分方式下，只有当所有的模块全部开发完成之后，才能进行一次批量的集成测试。这就是传统意义上的瀑布模式。在这样的交付方式中，开发团队与业务方缺少有效的互动。对开发团队而言，产品交付只是完成手头上的一件工作，交付团队无法在业务上建立真正的心智连接。

如果需求是在问题域进行拆分，即将一个大的问题（需求）拆解成若干个小问题（需求），那么每一个小的需求便可以独立交付给开发团队进行开发，因为需求相对较小，各开发职能人员很容易协作并完成需求的实现，同时因为拆出来的每个子需求都是独立可交付的，这样就实现了持续交付。

两种需求拆分方式的对比见图1-13。

所以，需求的拆分方式直接决定了团队的研发模式，而研发模式又直接决定了交付的效率。

（2）过大的需求会隐藏细节，而问题就在细节里

细节是魔鬼。软件开发中隐藏的细节，足够摧毁一切看似有序的计划。当用户故事只停留在宏观层面讨论时，需求看起来往往是很清楚的，或者虽然觉得有哪里不清楚，但是却说不出具体问题。如“支持二手商品交易中提供货物担保”，这个看似简单的需求，实则背后隐藏着大量的细节。

❑ 需要提供什么样的担保服务？

❑ 谁可以提供担保服务？服务商的资质需要审核吗？

❑ 哪种品类的商品可以提供担保服务？

❑ 非标品如何提供担保服务？

❑ 担保服务的服务费用如何结算？

❑ ……

如果细节没有得到澄清，就会为软件交付带来问题和风险。那么，既然需求拆分如此重要，为什么又很难做好呢？需求拆分的本质究竟是什么？

2.需求拆分所面临的挑战

并不是大家不知道需求拆分很重要而不做需求拆分，而是因为要想做好需求拆分非常困难，因为需求拆分必须符合以下几项原则。

❑ 足够小：只有足够小才能保证足够的灵活性，选择价值高的部分先交付，并保证在迭代内交付，以做到持续交付。

❑ 端到端：只有端到端地进行交付，才能保证所交付的价值是有意义的。

❑ 独立性：独立性有助于集成，以及灵活安排开发实践。

❑ 完整性：拆分完之后，我们需要能够看到整体的结构。需求在拆分完之后，应该还是一个需求，这就意味着它能独立测试，实现一个独立的功能。

没做需求拆分并不是因为没有足够的技巧来对需求进行拆分，而是因为缺少足够多的信息，也就是本身对需求的阐述不清楚，比如没有明确清晰的目标、没有具体的用户操作流程及步骤、没有明确定义的业务规则……需求除了是产品交付的单元，还是沟通的载体，需求的拆分过程实质上就是需求沟通的过程。

需求拆分如此重要，却又如此难，那么，我们应该如何处理呢？

3.如何做好需求拆分

要想做好需求拆分，首先需要了解需求的信息组织结构。芭芭拉·明托（Barbara Minto）在《金字塔原理》一书里提到过，任何信息的组织，都应该是结构化的。需求的信息组织呈现的是金字塔结构，金字塔的最顶端是需求的目标，中间为用户操作流程，底部为基本业务规则，可以达到以上统下、归类分组的效果。三个层次，自顶向下，逐渐明晰，如图1-14所示。

需求分析的澄清过程，本质上是收集和梳理需求信息的过程，即回答目标是什么、支持这个目标的操作流程有哪些、每个操作流程中又有什么样的业务规则等问题的过程。

4.实施步骤

下面我们试着通过一个实际的例子来讲解需求拆分的实施步骤。首先来看具体的需求及其细节。

躺平App引流需求

项目背景：计划通过发放红包的方式从站外引流，提升躺平App的DAU。

项目目标：拉新用户×××，目标用户为×××，促进躺平App DAU增长×××。

项目方案：引流入口的曝光和营销逻辑由导流端实现，用户触发后会记录用户信息和引流商品信息，尝试拉起躺平App客户端或者引导至下载页；此方案为躺平App被拉起后，或者通过用户自主下载安装并打开后的承接。

需求细节

1）领取红包的触发条件：导流端拉起App时，会弹出红包领取卡片窗口，红包卡片弹出时间为用户登录后，具体如下。用户自行下载App、打开后主动登录，经校验如果是符合红包领取条件的用户，就弹出红包领取卡片。如果用户不符合领取条件（比如已经领取过），不会再弹出红包领取卡片窗口。

2）拆红包：用户在登录状态下点击领取，即完成拆红包的动作。

3）如用户未领取红包而是主动关闭红包领取卡片，或者用户通过导流端二次触发打开App，都不再弹出红包领取卡片窗口。

4）领取后展示领取结果页面，可能存在“领取成功”“不符合领取条件”“已领取过”“已领完”几种状态，具体详情请见交互稿。

5）领取红包调用资金平台的红包发放接口。

6）成功领取红包页面，点击“去查看”前往红包卡券页，点击“去使用”前往购买引流商品详情页。

7）红包卡券页中，本次需求使用卡券包的H5页面。

实施步骤如下。

（1）澄清目标，明晰场景

从上述躺平App引流需求案例中，我们可以明确的一点是，该需求的核心目标是为了拉新。考虑到数据保密的原因，此处没有直接透露该拉新需求的核心目标，在实际操作过程中，我们需要在需求提出的时候就明确本次需求的数据化目标，即该需求需要实现的拉新DAU等一系列数据化目标。

很多项目组在落地需求的过程中经常会偏离方向，实现一堆没有价值、并非项目真正目标的需求，但并没有做出一个好的产品，无法满足用户需求。

当然，如果不了解真正的目标，没有目标驱动，会难以保证产出的效果，因为自己都搞不清楚为何而做、将去向何方。当接到一个需求时，我们要问的第一个问题就是，这个需求的目标是什么。即第一步就应该澄清以下几个问题。

❑ 目标用户是谁？

❑ 需求需要解决什么问题？

❑ 现存的解决方案是什么？

以下目标都是错误的，也比较常见。

❑ 笼统的目标。如“为了获得GMV 1000万”这样不具体的业务目标，或者是“为了让用户用得爽”这样无法度量的用户目标。

❑ 编造的目标。不清楚目标是什么，于是从需求功能倒推进行猜测。可能是为了什么？猜测是为了什么？

如果很难搞清楚目标，那么可以试试这样一个小窍门，就是向小朋友学习，不断地提出问题，如下所示。

❑ 为什么×××？为什么×××？为什么×××？

❑ 不做这个需求会怎么样？

澄清需求的目标，同时也是对需求的目标进行拆分的过程，一个大的需求目标，可以拆分成多个子目标。目标的拆分，也是对需求的拆分。

有了明确的目标，我们需要知道基于该目标的用户场景有哪些。用例可以帮助我们描述用户场景。

与此同时，还需要通过系统上下文，明确需求的各参与方。系统上下文会将需求的各参与方（用户或系统）列举出来，并将它们之间的关系用相对简单的模型进行呈现，对业务团队而言，这个系统上下文，就是业务上下文，开发团队也非常容易与具体的实现模型相关联。

系统上下文只需要列出简单的模型即可，而不需要是一个完整的精确模型，模型的演进细化是逐步的。从上面列举的躺平App引流需求的表述中，我们可以简单列出如图1-15所示的对象模型。

接着我们再从目标出发，列出相应用户的使用场景（即用例），这样对用户场景也做了分解（如图1-16所示）。用户只关心系统所能提供的服务，即开发出来的系统如何使用，并不关心系统内部的结构和设计，这就是用例的基本思路。在这个阶段，我们也只关心这个层次。

（2）用户操作，理清流程

列出具体的用户使用场景，由多个场景一起完成某个业务目标，这样的需求分析依然没有结束。接下来我们再就某个用户的使用场景做更深入的分析。例如，如何实现这样的场景？用户会进行哪些操作？操作如何与系统进行交互？系统与其他外部系统是否也有交互？它们之间的交互过程又是怎样的？顺着这些问题深入到具体的细节，每个用例都可以产生相应的用户操作流程及系统交互过程，如图1-17所示。

随着信息的逐层细化，我们又会有新的发现，例如，在该用户交互工作流中，会引入新的参与者、新的对象，我们可以基于之前的系统上下文进行更深入的细化，打开更多的细节，从而形成新的领域模型，并逐渐演进。

下面就来说明一下这个阶段常见的两个误区，希望能够引起大家注意。

1）在做交互图或对象模型时，不是从业务操作和业务领域对象的视角进行描述，而是直接进入实现的细节。这个误区在技术开发团队中很常见。而且我们在这里用到的图表，很可能会被技术人员理解为技术时序图。图1-18中结合了用户的交互路径图及技术时序图，是为了方便大家理解，在实际操作中用户的交互路径图和技术时序图是解耦的，路径图在前，技术时序图在后。

2）追求完美，担心出错。在构建用户操作过程和领域模型的过程中，追求完美会使得我们迟迟不敢有所动作。其实大可不必，有比没有好。先打一个草稿，然后基于草稿，不断讨论和演进，这才是正确的分析过程。

（3）列出规则，逐步细化

完成以上两个步骤之后，流程的主要操作步骤、交互过程就都梳理出来了，这个时候，就需要进一步明确业务规则。例如，用户领取红包的规则、发放红包金额的计算规则、个性化商品推荐规则，等等。将规则列举出来之后，我们需要对规则做一个更具体的描述。例如，领取红包的规则为需要符合淘宝天猫用户人群画像，红包发放规则为××用户的金额为5元红包、××用户的金额为10元红包，等等。

这个阶段常见的两个误区如下。

1）业务规则定义过于复杂，难以列举穷尽。例如，“小于10的数”，这种定义方式就无法列举穷尽。具体的表述应该是“0到9的整数”。举例的方式可以帮助我们走出这样的误区。

2）另一个误区，则是完全穷举。有的规则组合非常复杂，很难穷举，这个时候，我们应该看看在操作步骤上是否可以进行再拆分。比如，一个四个变量的规则组合，可以拆分成串联的两个变量的规则组合。

综上所述，我们可以发现，需求的拆分过程是从目标出发，到相应的业务场景，再到具体的用户操作和系统交互，最后落实到交互过程中的业务规则并进行逐层分解。从目标获取需求的范围，操作交互过程获得需求说明，而规则是对需求说明业务规则的提炼，在以上实践中，我们分别获取了基本上下文、用例图、工作流图及业务规则。需求拆解金字塔图示见图1-18。

（4）总结：由外而内，动静结合的需求拆分方法

以上分析过程，是一个由外而内、逐步分解的过程，从用例到用户的操作流程，由上下文到领域模型，是一个逐步打开细节的过程。用户的操作流程代表场景，是一个动态的过程，而领域模型作为可视化的术语表，是一个静态的模型，场景结合模型，可以达到动静结合的效果。

这里还有两点建议，具体如下。

1）信息可视化。字不如表，表不如图。沟通过程中，文字的还原度是很差的。图表的沟通方式具有如下优势。

❑ 可以快速理清内在逻辑，找到不足之处或矛盾之处。

❑ 可以通过少量必需要素传达大量信息。

❑ 可以将复杂关联性可视化。

图表的绘制过程就是一次需求分析过程。

2）分析协作化。所谓一人计短，二人计长，一个人或单一职能的思考难免会存在局限。在软件开发中，需求评审的过程需要多个角色共同参与进来。业务角色可以提供业务目标、业务场景和视觉交互，开发角色可以确认需求的影响范围以及实现的可行性，而测试角色则可以站在用户操作和系统行为的视角提供更多的输入，所以，需求分析拆分是团队协作的过程。

1.3.5 需求进度管理

拆解完需求任务及确认完详细的计划之后，接下来就要进入开发、测试等环节。在前期制定出一个合理的项目计划，只是为项目进度的科学管理提供一个可靠的前提，并不等于项目进度不存在问题。在项目的实施过程中，外部环境和条件的变化往往会造成实际进度与计划进度发生偏差。如果不能及时发现这些偏差并加以纠正，那么项目进度管理目标的实现就一定会受到影响。所以，必须实行项目进度计划控制。

很多公司一般都会用相应的项目管理工具来做项目的全流程管控，因此进度控制是项目管理工具一定要具备的功能。通常情况下，项目组会借助于电子看板来管理需求进度，同时还会配合一些类似于风险管理等之类的功能。下面详细介绍常见的站会机制和看板实践。

1.站会机制

站会，相信熟悉互联网行业项目运作方式的人都耳熟能详。该词经常出现于敏捷项目管理相关书籍中，描述上虽然各有差异，但是它是项目运作不可或缺的重要一环。

站会最大的意义在于，基于面对面沟通的前提，将项目相关人员聚集到一起，快速、高效地对焦项目的进展和风险。站会对于信息同步、问题暴露及进度的把控都具有非常重要的影响。为了更高效地实现站会的意义，站会的组织形式及开展流程等会采取一些套路。下面就结合笔者项目管理过程中的经验，以每日晨会为例来说明。

（1）明确站会议程

站会主要是评审前一天项目的进展，同步今日的计划。在同步进展的同时，需要重点同步项目是否存在风险等问题，任何可能影响到需求延迟交付的风险均应及时进行同步。PM一定要及时记录问题点，但不是在会上展开讨论，而是于会后找相关人员进行线下对焦。如果是需要项目组相关人员支持的点，也应该在站会中及时提出以获取支持，以便彼此之间更好地配合。

（2）固定时间

开站会的时间一般是在一天工作的开始时或者结束时。比如，每天的上班时间或者是吃晚饭前的时间，在这两个时间点开站会，效率一般都会比较高。同时固定开站会的时长。站会的持续时间应尽量控制在15分钟之内，时间过长容易导致大家分神，同时会议的效率也不高，但核心还是要将该明确的事情明确。

（3）适当鼓励

尤其是在团队整体氛围比较紧张、士气低落的情况下，PM应借助于站会的场子鼓舞一下士气，同时提升项目组的氛围，让项目组成员在更为轻松的氛围下工作。

2.看板实践

在敏捷Scrum团队中，看板的使用非常频繁，可以说整个团队与看板形影不离。

从价值层面来说，看板主要是保障价值交付、提升可视化及保障过程透明。相信在Scrum模型下工作的大多数团队都会有一个典型的Sprint BACKLOG（迭代待办事项），上面列着TODO、DOING、DONE，如图1-19所示。

BACKLOG的问题是上面只有任务，任务除了表示谁在做什么之外，是无法提供更多信息的，那就会带来如下几个问题。

1）纯粹的交付任务无法直接体现价值。上文中曾提到过，需求是交付价值的最小单元，而需求又会包含一个或多个开发任务，因此如果在看板中仅体现开发任务是无法明确业务价值的。我们应该多关注需求而不是任务。

2）任务之间的耦合等待，会导致交付效率低下。各个角色应该跳出自己的任务视角，多关注需求，通过需求交付来对齐任务之间的耦合关系，从而有效地减少任务之间的等待时间。这样的改变可以让我们关注真正的价值，即产品需求，而不是任务。但是，需求的交付需要经过从产品设计、开发到测试的完整过程，需求项目真正进行到了哪里、是否有阻塞、上下游应该在哪个时间点对齐等问题依然存在。

要想解决问题，首先得看见问题，否则需求交付各阶段的各个职能之间就像是盲人摸象一样，这时候我们需要能够看到需求的全貌。

全局看板可以打通各职能之间的协作，用每张卡片代表一个需求，将从“选择”到“发布”的几个阶段串起来，清楚展示需求端到端的交付过程。这就像一幅作战地图一样（如图1-20所示），让整个需求交付团队有了一个整体的视角。我们可以看到需求项目进行到了哪里，出现了什么问题，是什么原因导致需求阻塞不前，等等。

解释一下图1-20中的看板。

1）从“已选择”到“已发布”是一个需求的完整生命周期，从“开发中”到“已发布”属于需求的交付周期。

2）已选择：由业务方和开发团队代表共同完成，明确要解决的问题和达到的目标之后，通过需求分析按优先级将需求放入该队列。

3）就绪待开发：开发、测试和产品共同澄清需求，并明确定义交互过程和澄清标准。

4）待测试：对于所有移交测试的需求，开发人员对照冒烟用例验收标准进行自测并通过Show Case演示环节。

5）已发布：按照业务规划和版本计划上线。

接下来，我们用一个实例来说明如何通过看板模板来提升可视化。图1-21所示是我司某团队的实物看板。

看板的中的深色卡片代表需求，对应于可交付的用户价值。需求在看板上从左至右流动，经过看板上的每个阶段，直至交付。从最左的“选择”列决定做一个需求开始，直到上线结束。这是一个端到端的过程，拉通了产品、开发、测试、运维等各个环节。

在“开发中”这个阶段，需求被分解成了各项任务，图中浅色便签纸条即代表任务。任务与其所属的需求处于同一行，我们称之为泳道。泳道的首列（深色卡片）是需求，下属任务（浅色便签）按模块不同放在各自的列内，如前端、后端、依赖等。运行过程中，同一需求下属的任务应尽量对齐进度，快速完成需求。所属的任务全部完成后，需求进入待测试阶段，泳道清空，下一个需求就可以进入了。

以端到端的价值流动过程为基础，团队能够即时看到问题，例如，需求是否顺畅流动，在哪里发生了停滞和积压，是否存在瓶颈等。

在这个案例中，我们可以看到，有效的可视化需要做到如下四点。

❑ 用户价值驱动：需求反映用户价值，是流动的主线索。

❑ 前后职能拉通：以端到端的需求交付为线索，连接各个职能和环节。

❑ 左右模块对齐：保证任务向需求对齐，以快速交付需求。

❑ 即时暴露问题。

其中，第四点是前三点的结果，它们共同作用，提升了整体项目交付过程的可视化。看板就像一面镜子，让我们看到需求在流动过程中的状态、问题和瓶颈，从而打造持续快速的交付价值，奠定持续改进的基础。