产品需求管理经验分享

前言：文章来自Worktile产品经理的产品需求管理经验分享。

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

下面我通过需求流转的不同阶段来介绍我们如何做需求管理：

需求收集

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

以下是在需求收集阶段我们会设置的一些关键属性：

1.需求描述

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

2.功能分类

因为Worktile有“项目”、“消息”、“简报”、“网盘”等不同的应用，不同的应用是由不同的产品经理负责的，所以让需求提交人选择【功能模块】的原因是为了方便产品经理根据自己负责的应用筛选需求；

3.需求类型

新功能、交互优化、视觉优化、技术需求、其他，根据不同的需求类型，会有不同的跟进角色或不同的处理优先级；

4.客户类型

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

5.是否为定制开发客户

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

需求评审

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

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

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

1.需求合理性：合理需求、待定、需求不明确、不合理需求；

2.优先级（评估为合理的需求，我们会根据重要程度标记优先级）；

3.异常处理结果（对于不明确的需求，或者不合理的需求，通过异常处理结果进行阐述，也可以用评论代替）；

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

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

此外，需求评审会，还会对状态为“已计划”、“研发中”的需求，以及需求合理性为“不明确”的需求重新排查，排查后会更新对应的状态和属性。

评审会后，产品经理将合理的需求拷贝或直接移动到产品的迭代项目中稍作修改，作为正式的产品Backlog，并关联原始需求以便查找，之后就会进入设计、研发阶段。

小结

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

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

产品设计

产品经理会将决定要做的需求，根据优先级顺序细化方案后，交由设计师设计；

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

规划迭代

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

在迭代会议中，研发会将这个迭代的所有需求逐一确认，并在需求的相关任务栏中进行拆解，创建成一个个的研发任务；

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

产品研发

迭代规划完成后会正式进入研发阶段，迭代开始后会有：需求讲解、研发、演示、验收测试等环节，验收测试完成后结束迭代并上线；

在工程师编码的过程中，研发负责人和产品经理都会随时通过`燃尽图`来关注迭代的进度，并在每日站会中沟通进展。

这里还需要提一下，在迭代结束前2天左右，研发、产品和设计会一起演示迭代的产出。

演示时，会根据演示情况在对应的需求下创建相关的缺陷，待演示结束后进行修复。

演示中出现的bug修复后，由产品经理进行最终验收，并决定是否可以上线。

写在最后

以上是我们用Worktile管理一个需求从提交到上线的完整过程。当然随着用户及需求量的增加，我们的需求管理流程还需进一步优化。工具本身是为了简化流程提高效率，是承载管理者或产品经理想法的一个载体，具体如何去做还是要看团队的习惯和在工作中形成的默契，至于哪个工具好用那就更是仁者见仁智者见智了，分享这些只是为大家提供一个思路或参考。文章来源于Worktile官方博客，希望能给大家的需求管理工作带来一些帮助，同时也欢迎各位大神莅临指导。