笔者在前文《关于洞察挖掘产品需求的思考与总结》中介绍了收集和挖掘需求的方法。本篇将接前文，介绍在获取到一些需求之后，如何进行需求管理？

在相对成熟的产品团队里，需求管理是产品经理的核心工作之一，团队内可使用云协作类的应用软件进行协作管理。我们从以下几个方面来讨论需求管理：

一、需求方案初判

作为产品经理，需要在沟通需求时，对需求的实现方案、所耗成本和资源、预期效果、是否有实现同样目标的低成本替代方案等，有一定的判断力，即需求方案初判。

举一个案例：

距离活动日只剩3天，某客户部门提出要增加一个需求：活动日当天，做一个购买套餐，加价1元即可获赠会员的优惠活动。

分析当时的客观情况：

• 前后端开发人员都在满负荷的开发周期中，较困难调动人员临时支撑新增加的需求；
• 之前的订单体系中不支持在一个订单里同时购买套餐和会员，此前未考虑类似这样的需求的拓展性，服务端有一定的开发量，客户端也需要开发适配并更新线上版本，产品、设计、开发、测试、审核发布一共只有3天时间；
• 业务部门对此需求上线后可创造收益的预期暂不明确。

综合来看，如期实现这个需求的难度较高。那么有没有替代方案可以满足该部门的需求呢？

经再次沟通了解到，该部门的活动方案所涉及到的用户基本都会有电话和微信沟通，只要工作人员在活动日通过电话沟通确认用户购买这一促销方案，微信发送公司的收款二维码，让用户扫码支付1元后，由工作人员在后台批量为用户开通会员即可。

换用了一个思路，便用很轻的方式解决了该客户部门的紧急需求。

其实从产品的角度来看，这也算是一个产品MVP。如果该活动经分析，效果和成本可以有很好的平衡，即可作为一个需求，再排期到版本里进行开发，实现线上所有用户都能自助购买这一促销优惠方案。

在这个案例里，产品经理对当时产品开发资源、时间紧急度、替代方案的思考，就是对一个需求的方案初判的过程。对每一个需求都有这样的思考和判断过程，会更合理的对待需求和待解决的问题。

当然，在产品经理做了需求方案的初判之后，和业务部门的沟通也是非常重要的。共同站在产品和公司的立场出发是跨部门沟通与合作的基础原则，沟通确认性价比最高的方案，让产品和功能以更敏捷的方式推向市场，试错迭代，快速优化。

二、需求优先级

在通过需求的初判之后，会挡掉一些不合理或可以采取更轻的解决方案的需求，对于留下来的需求，需要记录进需求池。

在记录进需求池的时候，需要对需求的优先级进行排序标注，有两种常见的排序方法。一种是基于四象限法则，另一种则是基于KANO模型。

1. 四象限法则

有些情况下，因为需求的来源和影响因素不同，在排期上总会不易协调。

营销部门需要我们配合做活动，业务部门着急需要满足大客户的要求，开发需要留出做加固，运营部门需要解决用户投诉的体验问题……

所以有时产品经理抉择起来会很痛苦，需要综合权衡排期和利弊，考虑最合理并且能说服别人的理由。

最常用的判断方法是 Stephen Covey提出的紧急重要四象限法则，如图所示：

我们把重要并且紧急的需求排在最前，重要但不紧急的需求其次，不重要但紧急的需求再次，最后是不重要不紧急的需求。

在判断需求是否重要时，可以参考如下：

• 不做，会造成问题和负面影响
• 做了，会产生正向的效应和影响
• 跟战略布局有关
• 跟核心用户利益有关
• 跟大部分用户权益有关
• 跟效率、成本、收入、利润有关
• 跟用户体验有关

在判断需求是否紧急，可以参考如下：

• 不做，错误会持续发生并造成严重影响
• 不做，短期内可控但长期会有糟糕的影响
• 做了，立刻能解决很多问题、产生正面的影响
• 做了，在一段时间后可以有良好的效果

2. KANO模型

另外一种很常用的方法是东京理工大学教授狩野纪昭（ Noriaki Kano）提出的KANO模型，是对用户需求分类和优先排序的有用工具，以分析用户需求对用户满意的影响为基础，体现了产品性能和用户满意之间的非线性关系。如图所示：

基于四象限法则或KANO模型，可以完成需求优先级的判断。通常我们会用P1、P2、P3、P4来标注不同的优先级，P1优先级最高，P4最低。

三、需求来源和负责人

确认完需求的优先级之后，将需求记录进需求池。我个人在带领团队工作中，使用的需求池管理模版很简洁，如图所示：

需要在需求池To-do List中需要记录的一些字段都是非常重要的。我们在前文中有提到挖掘需求的几种不同方式，再加上各个部门提出的多样的需求，因而需求的来源是较复杂的。

我们在记录的时候，将“需求来源”广义定义为：需求的来源方，或产品经理所挖掘需求的方式和其成立的结论支撑。

需求来源和需求负责人的记录，是为了在出现人员变动或排期较长已经记不清的情况下，能够通过当时的需求负责人和需求来源的方式推演复现需求。

此外，需求负责人需对需求从提出到设计开发到上线数据分析的全过程负责，通过表格也能够一目了然每一项具体需求的责任人是谁。

四、需求排期

我们这里所讨论的需求排期，指的是还未进入设计和开发阶段的需求排入到具体开发版本的情况。

之后笔者在写到需求评审完成之后，交付开发的时候所描述的需求排期，指的是已经进入到设计开发阶段的需求实现的生产要素UI设计、前端开发、后端开发、测试各需要的时间以及适当并行分工的情况。

在确认了该需求被记录进To-do List的时候，产品经理需要综合该产品线的全局需求优先级情况，对该需求进行版本排期，并根据版本排期推算大致的可上线时间范围。

这么做的原因主要是：需求所涉及到的业务、运营、市场等部门，往往需要根据大致的可上线时间，做提前的安排和规划。尤其是连接线下业务的功能，需要线下提前部署准备好功能上线后的工作。

产品经理在确认需求的版本排期的时候也需要和涉及到的相关部门负责人员沟通，并在沟通后以以邮件的形式确认并通知。

做好产品，从产品思维阶梯到工作流程执行都需要有适合自己的方法论，笔者会从建立思维框架、需求挖掘、需求管理、产品方案设计、原型设计、产品需求文档编写、UI设计、评审与会议、跟进协调开发测试、产品发布、数据分析与需求验证、数据驱动与敏捷开发的流程节点，分享自己的方法论，不定期更新，感谢阅读。

下一篇文章，主要和大家分享《产品工作流程与方法论—产品方案设计》。

#专栏作家#

吉倩倩，人人都是产品经理专栏作家，专注于互联网产品与运营领域的研究和总结，在用户研究，需求分析，产品设计，数据研究，产品运营方面有深刻的思考。

本文原创发布于人人都是产品经理，未经许可，不得转载。

题图来自 Unsplash，基于 CC0 协议