需求多且杂，管理难题如何破解？

原创余春燕网易杭研项目管理

2020年10月19日 10:00

在互联网产品项目管理中，需求管理是非常重要的一步，决定着产品是否在做正确的事。而我们常说的需求管理，往往局限于从已有的需求池中选取达到准入条件、优先级最高的需求进入里程碑、版本，再对这些需求做优先级管理、WBS拆解、需求变更等，为计划制定做准备。

然而全生命周期的需求管理不应该从需求池开始。所谓需求的端到端，终点是需求上线为用户所用，而起点也来源于用户，当用户的诉求直接或间接的到达产研团队时，便是需求的开始。而从还不能称之为需求的诉求或建议到正式被产品经理写成需求进入需求池前，这个阶段的需求管理往往成为难题。

你一定经历过类似的困境：

B端产品的项目经理A，每天需要接收大量来自客户的诉求，这些诉求都需要经过统一的评估，确定是否要满足，什么时候满足。

客户的诉求有的符合产品规划与通用性，有的过于定制化。但我们往往不能仅通过是否符合规划来下结论，还需要考虑客户等级、对业绩的影响程度等多项因素。

决定要满足的客户诉求也需要归类整理，形成正式的产品需求。

常规项目管理工具仅适用于版本内的需求管理，所以A通过最原始的方法来管理这一环节：用表格来记录所有诉求，通过在线表格解决众多人协作的问题。但是结果并不尽如人意：

• 表格维护的时效性差，维护成本非常高。

• 维护表格的人太多，信息易错乱丢失。

• 与需求研发链路断开，无法进行端到端的跟踪管理。

• 表格信息量不够，众多信息无法回溯，无法进一步做数据分析来评估健康度，发现风险。

这种困境不仅仅B端产品才有，C端互联网产品、游戏产品每天也会有来源于用户、玩家的反馈，这个些反馈通过客服、网络舆情监控、官网反馈平台等渠道到达产研团队，同样面临着需求最前期的管理问题。

而Easy Project（后简称EP）提供的需求管理解决方案，帮助我们走出了这样的困境。

EP通过产品管理模块实现了需求端到端的管理，上文所说的需求起始端管理正是使用了建议、需求这两个子模块。

用户/客户的诉求在建议模块通过单据的形来管理。建议单据可以通过客服、售前等内部同事建立，也可以通过相应接口获取用户的反馈信息自动建立。

在EP系统中，我们可以结合产品实际需要，通过自定义字段配置我们需要的信息。如七鱼在创建建议时需要获取较详细的客户信息。同时EP与CRM系统Cloudcc打通，客户信息从CRM获取可保证信息的准确性。

通过建议列表，所有的客户诉求都被记录，建议单据的信息都能清楚的展示和查看，也能方便地做各维度筛选。解决了用表格的维护成本高、信息易错等困难。

建议单据建好后，会直接流转到产品经理的工作台，产品经理评估合理性后选择受理或者驳回。驳回时注明原因，方便对接客户的业务团队了解及分析回溯。

建议受理后，会弹出创建需求的窗口。如果建议是重复的，则可关联到已有的需求上；如果建议涉及的内容很多，则也可以创建或关联多个需求。因此建议和需求可做多对多的对应，在建议和需求的详情页都会清楚展示关联关系。这也是通过表格无法清晰记录的。

需求创建以后，即可进入需求设计阶段。需求在进入研发前设置了需求设计、评审和排期的状态，与标准流程匹配，更细粒度的展示研发前的需求进展。

需求设计、评审完成后，就进入了需求池中，排期完成确定对应的版本。在版本开发中，可以进一步拆解需求到任务、子任务，最后完成研发后上线。如此将需求管理与研发进度管理无缝对接，整个需求端到端的链路完全打通。

目前EP也支持与jira的打通，因此对于重度依赖jira来做研发管理的项目来说（比如智慧企业的产品），可以用EP来做前期的需求管理，EP的单据状态会与jira单同步，没有工具切换的烦恼。

需求的状态变化会自动触发建议的状态变化。当需求进入设计中时，建议自动进入解决中状态，需求的待上线会触发建议的已解决状态，建议也可随需求上线而关闭（这一步可根据项目实际情况，设置为自动关闭或手动关闭）。状态变化的时间轴记录了整个建议从提出到关闭的全过程，建议提出人可清楚了解当前的进展。

建议和需求列表都可以通过EP系统导出，导出的表格有很全面的字段信息，包括各状态变化的时间戳，这都方便我们做进一步的数据分析。我们可以直接通过excel做快速的简单分析，也可通过数仓做更进一步的分析，得出响应、交付周期等数据。这些数据不光可视化地反映当前单据处理情况，也为我们优化流程，完善规则等指明方向。

通过以上EP系统的应用，我们降低了需求在进入需求池前的管理难度，工具带来的便利性提高了需求管理的规范性和严谨度。

当然EP系统在这环节的应用还有很多的优化空间，对于不同类型的产品也需要更多合适的解决方案。如果大家也有需求前期管理的烦恼，欢迎找我们探讨！

继续滑动看下一个