需求的生命周期中,我们究竟该做什么？.pdf

需求的生命周期中，我们究竟该做什么？

产品经理们在处理来自不同地方的需求时，有着不同的工作方式和方法：分类管理、定期维
护等不一而足。那么，对于需求的整个生命周期来说，我们究竟应该怎么做呢？

下面是我的经验。

一.获取阶段

需求的来源有很多。业务越复杂，需求就越杂。一个淘宝，产品需求就可以拆分成分类、检索、
排序、商品展示、营销活动、支付、配送、售后等等。

你的职级越高，也代表着身边人提需求的可能性越大。初入行的产品专员或助理，主要是得到被安
排的任务；初级产品经理，需求来源主要是用户和上级；产品负责人，需求来源就要增加老板和其
他相关部门；而作为老板，谁都可能跟他提产品需求。

所以在获取到需求这一时刻，就必须做一个判断，并且记录。如果不做判断堆在那里，等做的时候
根本没办法梳理出头绪，可能大部分时间都在疲于折腾需求清单。记录当然是为了方便回溯。获取
到的再小的需求也记下来，不要指望你随时能想起来每天听过的每个需求。

做判断的内容具体是什么呢？

第一，判断需求本身的重要性
同样是页面写错了一个字，把「登录」写成「登陆」，和把「奖励15元」写成「奖励50元」，重
要性不言而喻吧。有个大致的预估。

第二，考虑需求来源

需求来源会表明一些事情，要慎重思考。比如老板提到的，未必是目前你能理解的，但他认为特别
重要，就暂且把这个当成特别重要的，这是政治任务。再比如是用户提到的，但细想他并不是目标
用户，他的需求就不必太关注。

第三，简要得到需求背景

我自己工作中有三类需求绝对不记：没说清楚原因的，不记（你做个XX出来，别管那么多）；不
说清逻辑的，不记（啊，这里我也没搞懂，你先看看）；不是实际遇到的，不记（哎，我觉得可能
有人会这样用）。

需求背景没搞清楚，完全是浪费时间。有一句话的记录，但不说背景，也是浪费时间。记的时候，
我会确保格式是问题+方案，「XXX在用我们的XX功能时，感觉XXX，我们可以尝试XXX这
样的方案」。

最后，依据这三个因素，判断属于大致哪个类别的。一般的需求管理都会分P0-P3或者P1-P4，总
之先打个标签。这里的技巧是尽量标记为比估计的更重要一层的需求，就是你感觉是P2的，暂且
先标为P1。这样以防错漏，低优先级的标成高的没关系，但高优先级的标低了会出现麻烦。这时
候的预估往往不准确，但没关系，等后面第二步再说。

比如这样：

二.讨论/设计阶段
隔一段时间，我们会开需求讨论会，整理需求池，也就是记录所有获取到需求的表单。

我们会详细讨论每个需求的情况，确认几个事项：

1.需求的优先级

之前的判断是粗估，这里的判断就要精细了。一般需求的重要程度很难量化，尤其来源复杂的情
况下。营销部门着急要我们配合做活动，不做就少赚好多钱，业务部门着急要我们配合做一套自动
化结账工具，做了能节省很多成本…有时抉择很痛苦。

这里还是用最常用的判断方法，紧急重要四象限法则（请自行百度「四象限法则」）。重要程度大
致按这种排序：

不做会造成严重的问题和恶劣的影响的
做了会产生巨大好处和极佳效果的
跟重要合作对象或投资人有关的
跟核心用户利益有关的
跟大部分用户权益有关的
跟效率或成本有关的
跟用户体验有关的

紧急程度按这个排序：

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

大家把能考虑到的因素想全，会标上P1–P4的优先级。

2.方案的方向

需求有不同的解决办法，我们会讨论清楚到底用哪种解决。比如我们发现有刷单现象，可以事前
提醒，告知用户目前地理位置或订单信息有嫌疑；可以事中限制，必须到达指定地点、拍摄当地照
片等等操作来限制用户；可以事后惩戒，提供给客服或者业务部门疑似刷单的名单和证据，罚款或
者封号。这几项到底做哪个？还是做其中哪几个？优劣在哪？需要好好讨论。

有时会有大概的方向，再去跟相关部门和需求相关的同事确认。这不在本文讨论范围内，暂且不提
。
3.指定负责人

我之前经历过两种需求分配制度。一种是每个人负责的需求范围有清晰的边界，那需求对应哪个
模块，就直接分配即可；另一种是团队作战，每次指定或者认领，谁都有可能接手任意需求。

前一种的好处在，模块清晰，负责人可以对自己负责的部分足够熟悉，但缺点是，工作量很可能不
平衡，有的同事一直在忙，有的可能就比较闲，因为需求不是平均按模块分布的。

在我们需求分配时，大致还是按照模块分配，但在出现工作量不平衡的情况时，会酌情调整一下，
让活少的同事予以配合。

不管怎么样，一定一定要指定负责人，他需要对需求负责，一直到产品上线后，出了的问题他也要
承担责任。要保证运营良好的工作责任制。

4.划定时间节点