当产品上线后，我做的第一件事情，就是回过头来好好整理了一下需求的管理方法，分享出来希望对大家有所帮助。
“一个产品之所以被称之为产品，一定是因为它至少满足了某些需求。”
我认为这句话很好的解释了“产品”的概念，一个需求的聚合体，不一定是一个网站，不一定是个软件，不一定是个互联网的产物，但它一定满足了某些人的某些需求。
成功的产品和失败的产品最大的区别是能否很好的满足需求，从这一点出发，我认为需求管理是所有阶段的产品经理都需要慎重对待的一件事。 我真正意识到需求的重要性，是在我从事产品工作的第一个月后，逼迫我作出这种认识的，不是我的老板而是糟糕无序的产品。在我刚刚接触产品的时候，因为没有人告诉我怎么做，我常常感到一种不自信，这种不自信体现在需求上，就是不懂拒绝，来自各方的需求，一层层堆叠在开发周期上，看到就是一阵头大。因此，当产品上线后，我做的第一件事情，就是回过头来好好整理了一下需求的管理方法，分享出来希望对大家有所帮助。
需求从哪里来，你就到哪里去
既然是分享给和曾经的我一样迷惘的产品新人看，我觉得有必要先来解释一下什么是需求。一个产品项目在还没有启动之前，就会确定下这个产品的产品价值，这决定了产品的前进大方向。但是，大方向虽然确定下来了，但是具体做什么／怎么做都是最实际的问题，这里的具体做什么和怎么做，就需要产品经理和其他决策者一起通过需求分析得到。
需求是人们对产品的期待，渴了要喝水，饿了要吃饭，这是广义上的需求，狭义的需求，则是经过筛选后留下的对特定产品服务特定场景／用户有正面影响的诉求和建议。 需求的定义告诉我们，既然需求是对特定场景/用户有正面影响的诉求和建议，那想要真正了解需求，就必须抓住需求的来源（即特定场景／用户）进行深入的分析，这就是
“需求从哪里爱，你就到哪里去”。
有朋友问我，他想开一个VR体验馆，从产品的角度应该怎么做需求调研，我给他推荐了几个VR爱好者的群和论坛，让他从这些特定人群中挖掘他们对VR体验馆的期待和需求，上海有几家做的比较好的VR体验馆，我也建议他多去体验一下，看看人家好在哪里。我写这文章的时候，总是一直回忆自己当初从什么都不懂的小白一路走来时爬过哪些非常深的坑，遇到过哪些翻来覆去找不到答案的问题，这些问题很有可能也是许多产品同行正在苦恼的问题，能够解决他们的需求。 这其实证明了，需求的来源很多，但是始终绕不过一个原则，那就是同理心原则。有人会问，怎么去培养这种同理心呢，比较笨的做法是和我以前一样，公司所有职位都尝试一遍，自己做一遍，细心体会，不过这个往往只在小公司小团队中适用；还有一种办法是请整个公司各个部分的同事来一起收集需求，描述需求，这种方式的优点是不必事必躬亲地去体验，适合多人协作场景中使用，但是缺点是会需要占用一部分时间来互相沟通需求，这种沟通的过程，就叫做需求评审会，当然这是后话。 回过头来说，需求的来源，前文提到，主要来自于特定场景和特定用户，这是最核心的一部分来源，单独拿出来说，是希望大家能够把“从用户中来，到产品里去”作为自己收集需求的第一选择，但实际工作中，我们也不可能有非常多的时间和所有用户一对一的沟通交流，这就要求我们通过更全面的渠道获取到需求。根据我的工作经历，归纳总结下： 老板提出的需求； 用户直接反馈的需求； 公司内部同事反馈的需求； 通过数据分析／问卷调查得到的需求； 自我驱动产生的需求。 在我的工作范围内，需求基本上来自于这5个渠道。老板提出的需求其实是基于老板对产品的理解，往往很难拒绝，但是如果对于实现产品价值有很大的影响，必须尽自己所能说服老板。用户直接反馈的需求，前面提到了，就是找到产品的潜在用户群或者实际用户群，1对1地交流沟通，这依赖于个人表达技巧和用户的表达意愿。公司内部的所有成员对产品会有各个角度的不同理解，了解他们的需求往往可以让你考虑问题更加全面细致。通过数据分析／问卷调查获取到的需求往往来之不易，因为这需要长期地／有先见性地预估到某些问题，数据分析帮助我们发现问题，问卷调查帮我们验证问题，但中间这个提炼需求的过程，属于个人能力和素质，需要一定的专业能力。自我驱动产生的需求，用大白话说，就是产品sense，基于你对产品和市场的了解，猜测性地提出的某些可能对产品发展有好处的需求，这同样难得一见。
需要提示各位的是，尽管需求获取的来源看似很多，但实际工作中如何为整个团队建立起一种“产品至上”，“发现需求人人有责”的价值观并不容易，这也意味着，说服所有人共同来完成需求池的搭建与积累，还需要一些更具操作性的方法。
需求管理，人人有责，但是产品经理责任最大 产品经理在整个产品生产与发展的过程中要占主导地位，要善用自己的职能和特点来说服大家一起加入到产品管理工作中来，身先士卒是必须的，所以需求管理和收集的工作也一定是由产品经理带头开展。
既然是分享，我来说一说流程跑下来以后，我认为比较适合的方法论。
1、使用单项需求卡片规范化地收集需求 需求来源渠道会不定期地产生一些需求，有的时候产生需求的人本身并不会意识到他们提出来的到底是什么，而收集需求的产品经理／需求分析师也往往无法通过不包含信息量的文字了解实际需求，这也就要求提出来的需求满足精细化／规范化／量化的标准。每个团队会有各自规范化需求的方式，我习惯于使用单项需求卡来完成这个规范过程。 单项需求卡 以上这个单项需求卡片，包含了对需求场景和提出需求原因的描述，量化了需求考核标准，还关联了与此相关的人事物，如果需求采集人员确实有认真思考并按要求填写了需求卡片中的所有内容，基本上就可以自发地筛选掉很大一部分仅仅是“拍脑门”想出来的需求，能够大大减轻产品经理的工作量，而且通过这种方式上交需求，往往会促使提出需求的人思考更多更全面，也可以让产品经理／需求分析师更直观地了解需求的前因后果。当然，卡片中要求填写的内容，往往也可以作为面对面沟通需求时的问题，比如和用户沟通时，针对某个他提出的需求，就可以引导他回答卡片中的一些问题，由产品经理完成卡片。
2、建立／维护需求池 需求池是对现有需求的一个汇总和统计，它的主要作用在于帮助需求评估和管理。需求池中的需求，由产品经理／需求分析师按照单项需求卡片中的记录一条条记录入需求池中。需求池不需要像单项需求卡片那样描述得非常详细，需求池中的需求，其实是经过产品经理阅读需求卡片后，“翻译”成可以被开发人员直接理解的需求，这个必须由产品经理亲自来把控，以免造成误读。 需求池 需求池的规范不一而足，但是建立的初衷是帮助产品经理和开发人员以及所有相关的团队成员来确认产品工作任务的。因此，需求池中除了一部分来自于单项需求卡片的内容外，还需要由开发人员来评估开发量，需要和相关成员开需求评审会来确定需求后续状态，从而判断该需求是否进入开发队列中，预计何时完成。 3、需求跟进 需求池中的需求如果在需求评审会上被拒绝或暂缓，需要在备注中说明情况，也必须通过邮件的方式告知提出需求的人（我认为这是一种尊重，这样才会有人愿意不断配合你提需求），切忌石沉大海一般毫无反馈；如果需求已经进入开发队列，产品经理则需要不断跟进需求的状态直到开发完成，通过需求卡片中规定的验收标准验收产品，这里也同样切忌只管头不管尾，产品上线后要持续对新的改动进行观察，随时做好版本回退的准备。
总而言之，需求跟进流程确保每个需求都能有一个结果，这是产品经理最大的职责。 痛苦的抉择，来自于不断的思考，正确性也来自于此 如果一味只听别人说而不多加思考的话，只会拖累自己也拖累产品，这是我经过失败的教训得到的经验。一旦开始思考，你就会发现对于哪怕一个看似很简单的需求，需要考虑的问题也非常多非常繁复，而需求与需求之间的关联，也往往让你不知道该如何抉择。 在需求池中有这么两个可以帮助产品做需求决策的参数：一个是优先级，一个是性价比。 优先级来自于需求卡片的描述，经过对需求细致了解后作出的感性判断（这里的感性只是相对性价比而言）；性价比则比较量化，可以通过价值／开发量进行计算，性价比越高，理论上越值得做。开发量可以通过开发时间来预估，价值则需要参照产品现阶段的OKR（Objectives and Key Results即目标与关键成果法）来进行评估，比如说某功能需求可以完成现有OKR的50%，那么该需求的价值可以定为50，开发量为10个story，则性价比为50/10=5。 当我判断一个需求是否做怎么做何时做的时候，需要50%的感性，也需要50%的理性，这两个数据确实可以帮助我进行需求评估与决策，相信也可以帮到你们。思考需求中所有你能想到的有关的因素，深入地挖掘需求背后的本质，然后使用优先级和性价比来做最后的决定，然后一切都会非常顺理成章，因为正确性就在思考中产生。
尾记 前几周开始写产品工作心得体会的时候，还没有想清楚之后要怎么写。后来，看到有很多同行给我留言评论，向我讨要一些产品工作资料的时候，我意识到产品经理这个行业的隐形门槛之高，很多时候它考校的不是你画原型的能力，也不是写代码的能力，而是你的思维方式和工作方法。 目前还没有“产品”这个专业，所有人都是摸着石头过河，通过网上的一鳞半爪揣测自己有没有走偏；另一方面，很多时候产品经理的重要程度无可比拟，一旦有所差错就是万劫不复。如果说互联网已经渐入正轨的话，产品经理这个职位的专业性还没有摸到轨，只有BAT这些少数互联网巨头才有相对专业的产品经理培训，更多的产品新人其实面临的困境其实超乎想象。
网友评论