作为产品经理，如何分析和管理你的产品需求？

分享一些我们团队关于产品需求管理的经验和思考：

需求是软件项目当中最重要一项输入。软件开发和传统生产行业最大的区别在于，需求总是模糊的、主观的和随时变化的。相对于电子产品、汽车等制造行业有形的硬件需求，软件开发的需求的描述和验收是个难以解决的问题。

但是需求又是整个项目能否成功的决定性因素，所以我们必须对需求进行管理，从而使需求成为整个软件工程的基线。使得所有产品、设计、研发、测试、运维工作能围绕着统一的需求开展。保证项目能顺利进行，完成目标。

需求之所以难以管理，原因有以下几方面：

1、需求描述的问题

一般来说，最容易造成开发出来的产品与设计功能不符的原因便是需求描述的问题了。其实大部分情况下，写需求文档的人没有错，看文档的人也没有错。共享文档不等于达成共识。只是因为面对同一段描述，人与人之间的理解不相同，而且这种情况是一定会发生的。所以对于需求，一定要基于团队面对面讨论，保证对需求的理解一致。

2、需求变化的问题

需求变化的原因很多，如一开始没有识别全，新增需求；业务变化导致需求变化；需求有误；需求不清晰等。需求变化将导致从设计方案到编码测试的修改，延迟交付，带来诸多麻烦。这就需要团队在迭代进行前，尽量保证需求清晰明确。

3、需求的优先级及排期问题

什么样的功能能对用户产生最大的价值，这是需求管理中最重要的问题。因为在软件开发中，你想要开发的功能，永远比你能投入的资源多。因此，找到这一部分最有价值的功能，优先处理，尽早交付，才是需求管理的核心所在。

问题分析之后，我们再来看看解决方法：

我接触过很多研发及产品团队，每个团队对产品需求的管理方法不尽相同，各有千秋。下面我来分享一下我司的产品团队是如何管理产品需求的，其实也就是一个产品需求在 PingCode（研发管理工具）中的流转过程，希望我们的经验可以对各位有所帮助，也欢迎各路大神交流指点。下面我通过需求流转的不同阶段来介绍我们如何做需求管理。

以下内容基于敏捷研发团队经验展开

1、需求收集阶段

管理需求的第一步首先是要进行需求的收集。我们的需求来源除了产品经理自己通过市场调研等各种渠道分析出的需求，来自用户的需求、建议、缺陷，都是由销售、客户成功的同事在一个公开的项目【公共 Backlog】中提交，然后产品经理和设计师会定期对需求池的需求进行评审处理。以下是在需求收集阶段我们会设置的一些关键属性：

需求描述

对于 2B 的产品需求，信息无非是角色、场景、原因、目的、预期这几点。但由于不同企业的角色、场景等信息复杂多样，所以无法形成统一的标准化数据来源，因此，我们规定以任务标题来描述需求最终的预期，其他必要信息通过任务描述来进一步补充；

记录尽可能多的需求信息，更全面的还原用户需求

功能分类

因为PingCode有“Agile(敏捷开发)”、“Plan(项目集)”、“TestHub(测试管理)”“Wiki（知识库）”等不同的子产品，不同的子产品是有不同的产品经理负责，所以让需求提交人选择【功能模块\子产品模块】的原因是为了方便产品经理根据自己负责的应用筛选需求；

需求类型

新功能、交互优化、视觉优化、技术需求、其他，根据不同的需求类型，会有不同的跟进角色或不同的处理优先级，这点我们从第一张图也能看到。

客户类型

客户需求销售或客户成功的同事在提交产品需求的时候，会有一个【客户类型】的属性，添加这个属性是为了便于大客户的需求能尽快得到满足（当然我们内部也是有需求的综合评估的，大客户的需求优先级会略高于中小客户）；

是否为定制开发客户

因为 PingCode 有独立的私有化定制项目组，所以如果是二次开发的客户会直接由项目组的同事负责跟进，产品经理就不会再跟进这个需求；

2、需求管理阶段

敏捷开发中，用户故事被广泛使用，但是我认为仅仅使用用户故事是不足以很好的管理整个项目的。（关于用户故事的诸多好处，就不在此多说了。）用户故事可以描述出真正有价值的需求，也能提供优先级和故事点规模为排期提供依据。

但是繁多的同级用户故事会让人迷失在其中，只见树木不见森林。每次的交付和发布都会变成功能的东拼西凑，甚至有时候还会为了单个功能的价值，偏离整体的产品愿景。

因此，我们按照 Epic Story - Feature - User Story（史诗-特性-用户故事） 的层级顺序去管理需求。团队也可有自己的层级关系定义，取决于团队的喜好。

按照 Epic Story-Feature-User Story 对需求进行层级划分的好处在于：Epic 一级可以与产品战略对齐，Feature 一级作为版本发布规划的对象，User Story 则进入迭代进行研发。

1. Epic Story

Epic Story 即史诗故事，简称为史诗。一般史诗被定义为一个非常大的用户故事，是产品中的主干任务或者公司级战略举措，一般情况下会持续数月。我们对史诗的风险、业务价值、工作量进行评估，得到史诗的优先级，再依据优先级对史诗进行排期。

2. Feature

Feature 即特性，特性是能对用户提供价值的完整功能。描述了产品具有的一个完整功能，特性一般也比较大，可能持续数周，横跨几个迭代。一般作为版本发布计划的规划对象。我们依据特性的风险、业务价值、工作量评估特性的优先级，进行版本发布的规划。

3.User Story

User Story 即用户故事，用户故事是能对用户提供价值的功能场景。一般来说，特性可以拆分为多个用户故事，每个用户故事都对用户有价值，但是单个用户故事却有可能不能被用户正常使用或者是整个功能的细分场景。我们会对用户故事的故事点进行估算，放入迭代计划中进行开发。

3、需求评审

由产品经理牵头，连同设计师组成需求评审小组，每周四定期将本周创建出来的问题统一处理，并加以分类；

在每周的需求评审时，产品经理、设计师，有时候可能需要研发的协助，共同评审上周创建的需求。我们会对这些需求，进行合理性的评估、优先级的评估、填写异常处理结果等。

所以这时候在任务详情中的信息，除了以上提到的 5 个属性以外，还有以下 3 个字段：

1.需求合理性：合理需求、待定、需求不明确、不合理需求；2.优先级（评估为合理的需求，我们会根据重要程度标记优先级）；3.异常处理结果（对于不明确的需求，或者不合理的需求，通过异常处理结果进行阐述，也可以用评论代替）；

所以，在我司【公共 Backlog】中的需求分为 6 个状态：未激活、已计划、研发中、已发布、关闭、不采纳，需求提交人根据需求状态就可以判断需求是否被采纳，如果被采纳已经进行到哪一阶段等信息，方便及时回复给客户。

当然，对于权限划分比较明确的团队，可以设置不同的权限和通知。比如：只有产品经理可以变更需求的状态、合理性、优先级，以及填写异常处理结果；这些属性变更后是否要通知到需求创建人、参与人等角色，以便迅速得到反馈。当然这些都是继续研发管理工具PingCode展开。

此外，需求评审会，还会对状态为“已计划”、“研发中”的需求，以及需求合理性为“不明确”的需求重新排查，排查后会更新对应的状态和属性。评审会后，产品经理将合理的需求拷贝或直接移动到产品的迭代项目中稍作修改，作为正式的产品 Backlog，并关联原始需求以便查找，之后就会进入设计、研发阶段。

简而言之，前两节讲了一个需求在 PingCode 中从提交到确认的过程和一些判断方法。在这中间我们还会通过对不同的状态、不同的功能模块、不同的合理性，筛选不同视角的视图统计报表，来精简不同视角下的信息量，以提高需求筛选效率，这也就是为什么需要添加这些属性的原因。

例如：我们只想看到客户对【项目】这个应用提的需求，那就可以直接通过设置筛选条件“功能模块=项目”就可以筛选出针对【项目】这个应用提出的所有需求；

4、产品设计阶段

所以在正式的产品 Backlog 中，我们将需求分为 7 个状态：未激活、方案设计中、方案待评审、评审通过待排期、已排期、已上线、关闭；

5、规划迭代

规划迭代时，我们会将【产品 Backlog】中所有完成产品设计的任务筛选出来，按照“功能需求”＞“交互体验需求”＞“视觉需求”的优先级顺序，确定每次迭代要做的功能；

在迭代会议中，研发会将这个迭代的所有需求逐一确认，并在需求的相关任务栏中进行拆解，创建成一个个的研发任务；并通过PingCode指派给相应的负责人，或团队人员自行领取。

如果某个研发任务比较复杂或很难估量工作量还会进一步拆分：

6、产品研发阶段

迭代规划完成后会正式进入研发阶段，迭代开始后会有：需求讲解、研发、演示、验收测试等环节，验收测试完成后结束迭代并上线，在工程师编码的过程中，研发负责人和产品经理都会随时通过燃尽图来关注迭代的进度，并在每日站会中沟通进展。

我们在 PingCode 的监测需求燃尽情况

这里还需要提一下，在迭代结束前 2 天左右，研发、产品和设计会一起演示迭代的产出。演示时，会根据演示情况在对应的需求下创建相关的缺陷，待演示结束后进行修复。演示中出现的 bug 修复后，由产品经理进行最终验收，并决定是否可以上线。演示中出现的 bug 修复后，由产品经理进行最终验收，并决定是否可以上线。

以上是我们用PingCode管理一个需求从提交到上线的完整过程。当然随着用户及需求量的增加，我们的需求管理流程还会进一步优化。

工具本身是为了简化流程提高效率，是承载管理者或产品经理想法的一个载体，具体如何去做还是要看团队的习惯和在工作中形成的默契，至于哪个工具好用那就更是仁者见仁智者见智了，分享这些只是为大家提供一个思路或参考。

最后附上工具链接，方便感兴趣的朋友也了解：

点击查看PingCode购买方案与价格（以及获取25人免费版）​