需求分析方法论

按照需求分析流程，我把需求分析方法论，分为三个阶段，分别是：收集需求阶段，评估需求阶段，精炼需求阶段。

• 收集需求：尽可能全面的收集需求，不管需求能不能实现，这个阶段不要去考虑能不能实现的问题，务必要做到三个全面，即人员全面，结构全面，工具全面，后面逐一展开讲这三个全面是什么意思。
• 评估需求：深入全面的评估需求，辨别需求真伪，及判定需求优先级。
• 精炼需求：对需求进行精炼，挖掘出真正重要的需求，切忌不要堆砌需求，做一堆的没用的功能。

一、收集需求阶段：

收集需求是为实现目标而确定，记录并管理相关方的需要和需求的过程。这个过程在项目实践中非常重要，它为定义产品范围和项目范围奠定基础。

我们最先接到的需求，一般来自直属上级，老板，或客户。这些需求，一般都是高度概括性的需求，只说了一个大概要什么，实现什么目标，

这个用专业术语，叫做高层级需求。高层级的需求颗粒度不够细，没法直接交给产品开发人员直接去开发实现。这个时候就轮到产品经理或项目经理，

或需求分析师BA来调研并收集需求。

首先，先说一下收集需求的人员全面。

意思是，把需求涉及的所有干系人都列出来，然后全面的收集这些人员的需求，做到尽可能全面，不要遗漏某些相关方的需求，特别是重要相关方的需求。

一定要有这样的意识，任何未被识别的需求，都是高等级风险。

其次，收集需求要做到需求分类结构的全面。

意思是，我们要考虑需求类别的全面。

需求的类别包括：

业务需求。也就是高层级需要，比如解决某个业务问题或开辟某个新的市场，或实施某个项目的原因，等等。

功能需求。也就是要实现什么系统功能，比如要实现什么系统流程，打通什么数据，和什么系统交互，等等。

非功能需求。比如网页加载数据要在1到3秒内完成，要满足100个用户同时正常的访问系统，等等；

过渡需求。也就是我们常说的临时方案，当某个问题很难短期解决的时候，我们要规划短期长期方案。短期方案，其实就是属于过渡需求。

质量需求。也就是我们的交付成果要满足什么标准，比如通过国家xx标准，或xxx海外的认证。

安全需求。需求要符合公司的IT系统的安全管理制度，例如系统只能在公司内部网络访问，且需要限制访问进入到某个页面需要用户进行二次授权才能访问等。

合规需求。需求要符合公司，法律的合规要求等，比如开发使用到的中间件JDK要有商业授权，涉及用户敏感信息必须要脱敏等等。

第三，收集需求要做到工具全面。

意思是，我们要根据实际情况，采用合适的收集工具来完成我们的数据收集工作。

下面介绍几种常用的5种需求收集工具，及应用的场景。

访谈。这种方式其实是用的是最多的，直接和相关方进行一对一，或一对多的交谈。一般需要提前准备好的调研问卷，针对被访谈者的回答进行发问，深入讨论，然后记录他们的回答。当然了，如果你对要访谈的内容非常熟练，可以即兴提问，然后记录他们的问题。对于复杂的需求或新人来说，建议在访谈之前设计好要问的问题(调研问卷)，以免访谈的时候遗漏了某些问题，导致需求收集的不完整。

问卷调查。问卷调查方法是提前针对不同的用户群，设计一套或多套调研问卷的题目，然后通过二维码，H5链接，小程序等途径触达用户，让用户自主填写问卷调查的反馈，来达到收集数据的目的。一般来说，该方法要伴随一定的奖励机制，否则问卷调查的效果不是特别好。如果你要调研的对象是地理位置分散，分布在不同城市，用户也是多样化，不能一个个去访谈来完成，那么你可以采用问卷调查这个工具来展开数据收集和分析。

头脑风暴。头脑风暴是大家在一起，就某个需求各自表达自己的想法，观点，大家在一起火星撞地球，碰撞出一些火花出来，配合归纳整理，然后形成需求的一种方法。头脑风暴一般适用于新产品从0到1的开发，或者一些需要创意的工作。

焦点小组专题会。这个很好理解，就是围绕某个焦点话题，召集专家一起与相关方沟通，讨论，了解他们的期望和诉求，需要不断的互动。

竞品分析。竞品分析其实就是在做某个产品前，做调研一下竞品，分析它的市场定位，目标群体，产品功能模块，核心交互流程，UI设计等方面，归纳出他的优点与不足，然后借鉴它做的好的地方，并想办法突破它不的地方，重点关注，并纳入需求，等待后续进行综合分析，看能否在竞争对手的不足上进行突破，形成自己的独特优势。

二、评估需求阶段：

产品经理，项目经理或BA，需要明白的是，每个需求的实现都有利有弊， 是把双刃剑；每个需求也会与其他已上线的需求相关联，甚至牵一发动全身。所以，产品经理需要分析、评估一个需求带来的影响，并判断要不要实现这个需求，要如何实现这个需求。如果能能够做到扬长避短，并使整个产品获利，那就更好了。这就需要产品经理做好四类分析，分析需求的影响范围，分析它的利弊，辨别需求真伪，判定优先级。

分析影响范围。你要看这个需求涉及与哪些已上线的哪些需求有关系。一旦上线之后有什么影响，要一个个分析验证，这个需求会不会导致流程问题，数据问题，功能问题，性能问题等，然后针对每个问题，评估一下有多大影响。另外还需要考虑，是否牵涉到什么前置条件，比如需要规范流程，出台管理制度，数据初始化等。

分析利弊。你需要分析这个需求上线后，对产品的用户来说，具体有什么好处，能否增加他的兴奋点，增强用户的粘性。另外，也需要考虑会带来哪些弊端，比如会不会损害用户体验，会不会数据，权限等问题，这个不能回避，需要仔细的去分析论证利与弊。如果弊大于利，不要去做这些需求，大胆舍弃。

辨别需求真伪。每个产品经理或项目经理，每天都面临很多需求，需求池早都囤积了大量的需求。这个时候我们在评估的时候，就要分析哪些需求是真实需求，哪些是伪需求。那怎么辨别呢？我个人的方法是，梳理这个需求涉及的用户角色，场景，流程来进行分析。通俗一些讲，就是分析这个需求的用户是谁，他在什么场景下，要做什么事情，流程路径是什么。把这个梳理出来之后，你在看这个需求，在这个路径中，是否有冗余的操作等等。如果有，就属于伪需求。如果某个需求没有，导致这个流程路径走不通，这种一般来讲，就可以认为是真需求了，但不是绝对的，需要看具体的业务。

判定优先级。我相信大部分人，排需求优先级都是拍脑袋。坦白讲，我过去，其实也是拍脑袋排需求优先级。有的人说，我不是拍脑袋，我是根据用户提的优先级来排，或者根据已经清楚的需求来作为高优先级，不明确的需求做为低优先级。这么认为其实也不能说错。但是，只要你愿意去问自己有没有更专业的方法论呢，其实是有的。比如卡诺模型（KANO模型），PMBOK第七版里面讲的价值交付，优先交付有价值的需求等等。这里就不展开了，如果你感兴趣，可以先自行去了解。（后续我会单独来讲这块自己的理解，因为这篇文章的内容已经超长了，阅读量一定会很难看。。。）

三、精炼需求阶段：

在经历完前两个步骤，接下来还应进一步梳理，精炼需求，挖掘出对产品价值最大的需求。说实话，这个和步骤二有一些重复。在这个阶段，我觉得更重要的还是把最重要的需求挖掘出来，进行需求分类，一定程度的抽象，把能合并的需求进行抽象合并，形成优化精炼后的，带有优先级顺序的产品待办列表。做到这个步骤，需求分析基本就大差不差了。