老司机分享：产品新人如何做需求管理

“一个产品之所以被称之为产品，一定是因为它至少满足了某些需求。”

我认为这句话很好的解释了“产品”的概念，一个需求的聚合体，不一定是一个 站，不一定是个软件，不一定是个互联 的产物，但它一定满足了某些人的某些需求。成功的产品和失败的产品最大的区别是能否很好的满足需求，从这一点出发，我认为需求管理是所有阶段的产品经理都需要慎重对待的一件事。

我真正意识到需求的重要性，是在我从事产品工作的第一个月后，逼迫我作出这种认识的，不是我的老板而是糟糕无序的产品。在我刚刚接触产品的时候，因为没有人告诉我怎么做，我常常感到一种不自信，这种不自信体现在需求上，就是不懂拒绝，来自各方的需求，一层层堆叠在开发周期上，看到就是一阵头大。因此，当产品上线后，我做的第一件事情，就是回过头来好好整理了一下需求的管理方法，分享出来希望对大家有所帮助。

需求从哪里来，你就到哪里去

既然是分享给和曾经的我一样迷惘的产品新人看，我觉得有必要先来解释一下什么是需求。我在上一篇文章《见微知著，怎么做产品的数据驱动》中提到过，一个产品项目在还没有启动之前，就会确定下这个产品的产品价值，这决定了产品的前进大方向。但是，大方向虽然确定下来了，但是具体做什么／怎么做都是最实际的问题，这里的具体做什么和怎么做，就需要产品经理和其他决策者一起通过需求分析得到。需求是人们对产品的期待，渴了要喝水，饿了要吃饭，这是广义上的需求，狭义的需求，则是经过筛选后留下的对特定产品服务特定场景／用户有正面影响的诉求和建议。

1. 老板提出的需求；
2. 用户直接反馈的需求；
3. 公司内部同事反馈的需求；
4. 通过数据分析／问卷调查得到的需求；
5. 自我驱动产生的需求。

在我的工作范围内，需求基本上来自于这5个渠道。老板提出的需求其实是基于老板对产品的理解，往往很难拒绝，但是如果对于实现产品价值有很大的影响，必须尽自己所能说服老板。用户直接反馈的需求，前面提到了，就是找到产品的潜在用户群或者实际用户群，1对1地交流沟通，这依赖于个人表达技巧和用户的表达意愿。公司内部的所有成员对产品会有各个角度的不同理解，了解他们的需求往往可以让你考虑问题更加全面细致。通过数据分析／问卷调查获取到的需求往往来之不易，因为这需要长期地／有先见性地预估到某些问题，数据分析帮助我们发现问题，问卷调查帮我们验证问题，但中间这个提炼需求的过程，属于个人能力和素质，需要一定的专业能力。自我驱动产生的需求，用大白话说，就是产品sense，基于你对产品和市场的了解，猜测性地提出的某些可能对产品发展有好处的需求，这同样难得一见。

需求管理，人人有责，但是产品经理责任最大

产品经理在整个产品生产与发展的过程中要占主导地位，要善用自己的职能和特点来说服大家一起加入到产品管理工作中来，身先士卒是必须的，所以需求管理和收集的工作也一定是由产品经理带头开展。既然是分享，我来说一说流程跑下来以后，我认为比较适合的方法论。

1、使用单项需求卡片规范化地收集需求

单项需求卡

以上这个单项需求卡片，包含了对需求场景和提出需求原因的描述，量化了需求考核标准，还关联了与此相关的人事物，如果需求采集人员确实有认真思考并按要求填写了需求卡片中的所有内容，基本上就可以自发地筛选掉很大一部分仅仅是“拍脑门”想出来的需求，能够大大减轻产品经理的工作量，而且通过这种方式上交需求，往往会促使提出需求的人思考更多更全面，也可以让产品经理／需求分析师更直观地了解需求的前因后果。当然，卡片中要求填写的内容，往往也可以作为面对面沟通需求时的问题，比如和用户沟通时，针对某个他提出的需求，就可以引导他回答卡片中的一些问题，由产品经理完成卡片。

2、建立／维护需求池

需求池是对现有需求的一个汇总和统计，它的主要作用在于帮助需求评估和管理。需求池中的需求，由产品经理／需求分析师按照单项需求卡片中的记录一条条记录入需求池中。需求池不需要像单项需求卡片那样描述得非常详细，需求池中的需求，其实是经过产品经理阅读需求卡片后，“翻译”成可以被开发人员直接理解的需求，这个必须由产品经理亲自来把控，以免造成误读。

需求池

需求池的规范不一而足，但是建立的初衷是帮助产品经理和开发人员以及所有相关的团队成员来确认产品工作任务的。因此，需求池中除了一部分来自于单项需求卡片的内容外，还需要由开发人员来评估开发量，需要和相关成员开需求评审会来确定需求后续状态，从而判断该需求是否进入开发队列中，预计何时完成。

3、需求跟进

需求池中的需求如果在需求评审会上被拒绝或暂缓，需要在备注中说明情况，也必须通过邮件的方式告知提出需求的人（我认为这是一种尊重，这样才会有人愿意不断配合你提需求），切忌石沉大海一般毫无反馈；如果需求已经进入开发队列，产品经理则需要不断跟进需求的状态直到开发完成，通过需求卡片中规定的验收标准验收产品，这里也同样切忌只管头不管尾，产品上线后要持续对新的改动进行观察，随时做好版本回退的准备。

总而言之，需求跟进流程确保每个需求都能有一个结果，这是产品经理最大的职责。

痛苦的抉择，来自于不断的思考，正确性也来自于此

如果一味只听别人说而不多加思考的话，只会拖累自己也拖累产品，这是我经过失败的教训得到的经验。一旦开始思考，你就会发现对于哪怕一个看似很简单的需求，需要考虑的问题也非常多非常繁复，而需求与需求之间的关联，也往往让你不知道该如何抉择。

在需求池中有这么两个可以帮助产品做需求决策的参数：一个是优先级，一个是性价比。

优先级来自于需求卡片的描述，经过对需求细致了解后作出的感性判断（这里的感性只是相对性价比而言）；性价比则比较量化，可以通过价值／开发量进行计算，性价比越高，理论上越值得做。开发量可以通过开发时间来预估，价值则需要参照产品现阶段的OKR（Objectives and Key Results即目标与关键成果法）来进行评估，比如说某功能需求可以完成现有OKR的50%，那么该需求的价值可以定为50，开发量为10个story，则性价比为50/10=5。

当我判断一个需求是否做怎么做何时做的时候，需要50%的感性，也需要50%的理性，这两个数据确实可以帮助我进行需求评估与决策，相信也可以帮到你们。思考需求中所有你能想到的有关的因素，深入地挖掘需求背后的本质，然后使用优先级和性价比来做最后的决定，然后一切都会非常顺理成章，因为正确性就在思考中产生。

尾记

前几周开始写产品工作心得体会的时候，还没有想清楚之后要怎么写。后来，看到有很多同行给我留言评论，向我讨要一些产品工作资料的时候，我意识到产品经理这个行业的隐形门槛之高，很多时候它考校的不是你画原型的能力，也不是写代码的能力，而是你的思维方式和工作方法。

目前还没有“产品”这个专业，所有人都是摸着石头过河，通过 上的一鳞半爪揣测自己有没有走偏；另一方面，很多时候产品经理的重要程度无可比拟，一旦有所差错就是万劫不复。如果说互联 已经渐入正轨的话，产品经理这个职位的专业性还没有摸到轨，只有BAT这些少数互联 巨头才有相对专业的产品经理培训，更多的产品新人其实面临的困境其实超乎想象。

自知经验浅薄，但还足够热爱，所以每周会坚持给大家分享一些产品工作中“术”这一层面的东西，包括流程，包括数据，包括需求管理，当然还有更多，会随着工作和学习在今后不断补充进来。我给自己的要求是，每篇文章中，都要有大家确实能够用到的“干货”，可能是个思维导图，可能是个工作文档，有需要的朋友可以在文章中留下邮箱，我会在每周末统一回复。

最后，感谢支持和鼓励！

tips：本周的“干货”是文中提到的《单项需求卡》和《需求池》文档，有需要的朋友直接在评论中留下邮箱，看到后我会发到指定邮箱。