来源：丽睿客
第29件事 评估需求的八种方法
我们采集到用户的需求之后，就需要对各种各样的需求做评估，即评估那些需求该做，哪些需求不该做。这是一项产品经理必须具备的基本功。这里介绍几种评估需求的方法：
1） 人性法：
打算实现一个功能之前，看这个功能是否符合人性，跟那个或哪几个人性相匹配或对应，如果非常匹配，那就值得做；反之，可以考虑不做。
在使用人性法来评估需求的时候，并不是说一个产品需要反应的用户的多个或全部人性。也就说产品反映的用户人性并不是越多越好。应该根据自己所拥有的资源，挑选其中一个或几个人性，将所选人性做到极致即可。
2） 马斯洛需要层次法
马斯洛需求层次的的评估方法重要性仅次于人性法。打算实现一个功能之前，看这个功能满足的是马斯洛需求中的哪一层需要，从而决定是否该做。千万不能盯着底层需要，因为中层和高层需要也慢慢变成用户的刚需。
具体的评估方法就是对应地层需要的功能应该做，同时挑选一个或几个对应的中层或高层需要的功能。
3） KANO模型法
将要获取到的需求记录归类到基本型需求、期望型需求和兴奋型需求中。
使用KANO模型最简单的方法就是考虑每个主题或故事，对它所属的类型进行讨论。我们可以设计一套问卷，对用户进行问卷调查。KANO建议通过对一个功能问两个问题来确定分类。一个问题是：如果产品中有这个功能，用户会觉得如何？另一个问题是：如果功能不存在，用户又觉得如何？对每个问题采用5点度量方式进行回答：A表示我喜欢这样；B表示我期望这样；C表示我没有意见；D表示我可以忍受这样；E表示我讨厌这样。经过访谈后，根据归类矩阵，将问题进行归类来确定需求的类型，如图：
注：M代表Must-have，是基本型需求；L代表Linear，是期望型需求；E代表Exciter，是兴奋型需求；R代表Reverse，是相反的需求；Q代表Questionable，是可疑的结果；I代表Indifferent，是无关紧要的。
具体的评估方法就是对应基本型需求的功能必须要做，不能在这方面失分；对应期望性需求的功能必须要做，提高其质量，力争超过竞争对手；对应兴奋型需求的功能选择1或2个必须做，让用户尖叫。
4） 伪测试法：
伪测试指的是先不实现功能，只提供一个按钮或文字链接或图片入口，用户点击之后提示此功能正在建设当中。根据用户的点击率数据情况来决定是否实现该功能。这也是灰度发布的一种形式。
具体的评估方法就是测试用户中有超过40%的用户点击或使用了，则表明值得做。
5） PK法
正反两方就某一个功能或需求进行投票PK，比如说，支持和反对。然后根据数据情况，再决定是否该做。这种方法一般在论坛上或社交媒体上用的比较多。
6） 专家法
由相关的产品专家、用户体验专家、产品运营专家等一起来评测需求是否该做，主要是利用群体智慧来评估需求。
7） 定位法
根据产品定位来评估需求是否该做。
8） 场景法
根据用户的场景来评估需求是否该做。比如，对于现在的打车软件比较火（嘀嘀打车、快的打车等App），假设某些用户的场景是这样的：用户经常会去一些陌生的地方办事。用户初到一个自己不熟悉的环境，或多或少都会有一些恐惧心理，再加上如果他还是个路痴，就很容易表达不清楚自己所处的具体的位置，这时又要打车去另一个地方办急事，他们该怎么办？确定用户的场景之后，快的打车研发了一键打车的功能，就很好地解决了这种场景下的用户痛点，再加上用户一般是比较懒惰的，恰好利用了人性的懒惰。这个功能做得很赞。
第30件事 定义需求优先级的四种方法
在日常生活中，处理任务的优先级有四种情况：重要且紧急、重要不紧急、紧急不重要、不紧急不重要。
这四种情况也是我们处理需求优先级的原则，即“重要性+紧急性”。我们把需求的“重要性+紧急性”统称为商业价值原则。基于这个商业价值原则，下面主要阐述需求优先级定义的四种方法：
1） 新产品未上线：
这种情况没有相关运营数据作为支撑，所以从需求对用户的重要性和紧迫性来判断需求的优先级是一种比较合理的方法。那么如何判断需求对用户的重要性呢？一般情况下，用户需求的重要性依次为：基本型需求>期望性需求>兴奋性需求。
第1层和第2层属于基本型需求，第3层和第4层属于期望型需求，第5层属于兴奋型需求。如何评定哪些需求是基本型需求？最简单方法就是：去掉这些需求后，看这个产品还能否使用。
2） 免费型产品已经上线
这时候因为有了运营数据的支撑，通过运营数据，能聚类分析出用户的行为，甚至可以给用户画像。那么如何定义需求的优先级呢？这里还是采用需求的商业价值原则，即“重要性+紧迫性”原则。用户有需求，产品利用相应的功能或内容来对应和满足需求，可以根据功能的使用率、使用次数和重要性，形成一个需求重要性的计算公式，根据计算的结果和紧迫性来定义需求的优先级。
用户需求重要性的判断标准：用户基数、使用次数和类别重要性。其中，类别重要性分为基本型、期望型和兴奋型需求三类。
用户需求重要性=功能使用用户百分比（用户使用率）×功能使用次数百分比（功能或内容使用率）×类别重要性百分比（期望型需求、兴奋型需求）
注意：最底层的基本型需求不在计算范围内，因为默认其为最高级别。这个需求级别的公式就是综合考虑有多少用户需要、用户是经常需要还是偶尔需要、对用户重要还是不重要三个因素。
对用户来说，基本型、期望型与兴奋型需求并不是一成不变的，是一种动态的变化过程，并且运营数据也在不断地发生变化，需要及时做出相应的调整。
因此，明确需求的重要性之后，还要按照先做重要且紧迫的需求，后做重要不紧迫的需求，接着做紧迫不重要的需求，最后做不紧迫不重要的需求。
3） 收费型产品
收费型产品的优先级如何定义呢？定义的标准就是商业价值，即“重要性+紧迫性”，这里的重要性主要指的是经济收益（将战略上的收益也归结为经济收益，包括有形的和无形的收益），经济收益高且紧迫的功能需求先做，经济收益高且不紧迫的功能需求后做，紧急且经济收益不高的功能需求再往后做，不紧迫且经济收益不高的功能需求最后做。
4） 前置/后置需求
前置需求的开始日期或完成日期决定后续需求的开始日期或完成日期。注意这里的后续需求就是后置需求。有时候必须先完成前置需求，然后才能实现后置需求。从需求的优先级来看，前置需求的优先级肯定要高于后置需求优先级。前置需求的重要性和紧迫性都要高于后置需求。
总的来说，对于上述四种定义需求优先级的方法，在公司范围内，在特定的产品阶段是可以搭配使用的。需求优先级定义的原则基本上是一样的，都是商业价值原则，即“重要性+紧迫性”。
不管在哪一种方法下，基本型需求的优先级默认都是最高的，至于期望型需求和兴奋型需求的优先级，要根据具体的实际情况运用上述一种或几种方法来综合评定，而不是用“拍脑门”的方法确定。
第31件事 管理需求
需求的工作量如何估算？研发优先级如何定义？使用什么方法或工具来管理需求？在项目迭代过程中遇到需求变更时怎么处理？
1） 需求工作量的估算
（1） 选定参照物：选择一个中等工作量的功能或需求作为参照物，作为基准来衡量需要估算的需求工作量。
（2） 团队成员定义工作量：多位团队成员给出评估；
（3） 进一步明确需求：如果分歧很大，很有可能是没有明确这个功能主要有哪些功能组成，这与在实际的产品工作中遇到的问题是一样的，研发人员也估算不出来，因为需求不明确。明确主要功能之后，成员再次给出估算数字。
（4） 确定结果：如果团队成员的分歧不大，使用较高的那个数字作为需求或者使用出现次数较多的数字作为工作量。
2） 需求变更
产品需求变更在实际的产品工作中是正常的，没有需求变更是不正常的。产生变更的原因多种多样，对变更的需求进行评估，需要评估影响的范围有多大，是否有必要进行变更。确定需要变更时，还要看看是否一定要在当前这个版本迭代变更，在需求已经通过评审并进入项目环节时，尽量减少不必要的需求变更。
一旦确定需求需要变更，通常要以口头和书面文档形式通知相关人员。表5-2所示是需求变更记录表，表中包含的内容有编号、当前需求变更所属的是什么、变更前的需求主要描述是什么、变更后的需求主要描述是什么、为什么要提出需求变更、是谁提出的、是在哪一天提出的、最后是变更后的需求文档存储的地址。需求变更记录表以及更变文档都需要放在一个约定好的固定的位置，这样相关人员都能及时获取。
3） 需求管理工具
需求管理起源于需求获取，终结于需求的关闭，产品经理需要跟踪需求的进展和状
网友评论