当产品经理输出一份需求文档给开发的时候，可能会存在这样的情况：
- 由于时间关系，需求文档的内容很简略，遗漏了较多的细节，开发并不能直接对着需求文档就进行开发；
- 需求文档已经尽可能列出作为产品经理能想到的细节了，但是不知道这个需求文档有没有列全；
- 开发拿着需求文档就开始做，开局一把梭，还没做完就发现需求错漏，又要推翻重来，极端情况下到上线了才发现需求有问题，不得不带来一连串的加班；
- 即使开发做了需求分析和设计，也不知道这么做了是不是就已经全了，有没有错漏，没有形成一个行之有效的方法论。
面对这样的情况，并不是无解，只是缺少了一种行之有效的需求分析方法。面对需求，设计先行的方式一直在团队中践行，已经有接近3年的时间了。设计先行包含了需求分析和系统设计两个部分。在需求分析部分，我也总结出一些行之有效的方法，主要分为三大步骤：
- 角色与价值分析： 这一步骤的目标是要明确自己做的需求是有意义的，不做无意义的需求。主要分析需求面向的用户角色有哪些，对于这些用户，带来了什么价值。
- 需求概要分析： 这一步骤的目标是要梳理出需求的骨架。通过用例图、活动图/泳道图/流程图、术语表的方式，描述需求中包含哪些用例模块，用户的使用流程，梳理出需求的骨架。
- 需求详细分析： 这一步骤的目标是尽可能地发掘需求细节。通过对各种思维方式的运用，分析业务实体对象、状态值，发掘出需求的细节，逐步填充需求骨架。
后续会用多个篇章介绍如何这几个步骤如何实施。下面先介绍角色与价值分析。
角色与价值分析
首先要明确的是，每一个需求都不是凭空产生的，都是为了解决用户的某个问题而产生的。如果用户在使用上没有问题，自然也就不会有相应的需求。 也就是说，实现需求是为了创造价值。价值可以是给为用户解决了ta使用上的问题，也可以是为公司带来营收，比如补全和竞品的差距，帮公司招投标等等 因此在开始需求分析之前，要明确这个需求的价值在哪里。
所谓价值，就是我做了这个事情，会对谁带来什么好处。那自然会诞生以下问题：
- 这个需求面向的用户群体是谁
- 对于这些用户群体，他们现在遇到的问题是什么
如何找到用户群体
通常来说，我们一直在做的产品，都会有一些显而易见的用户群体。以视频会议为例，我们会很容易地认为，我们做的需求都是为了那些使用我们视频会议软件开会的用户服务的。那这些用户基本上就是和我们差不多的打工人吧！再加上管理打工人的管理层，基本上视频会议产品的就这些了！但其实不然。无可否认，这些的确是比较典型的用户，但这只是冰山一角。那如何分析出我们面向的用户群体有哪些呢？
要找到需求面向的用户，最重要的是要找到梳理出用户角色。把角色找全，才能正确地理解每种角色在业务中是如何完成自己的任务，以解决自己的问题的。其次，把角色找全，也不会出现到开发、测试阶段才发现有功能上的缺失，最终导致反复的沟通和返工。
那有什么方式可以比较好地找到用户角色呢？这里提供两种方式：模拟用户行为 和 闭环思维
模拟用户行为
当你拿到一份需求文档或者交互文档的时候，你可以假设这个需求已经实现了，想象自己在使用一个完整的产品，找到一个功能入口，尝试去使用它，把使用的流程梳理出来。接着，在你梳理的使用流程里面，对于每个环节，思考一下这个环节会对哪些角色有影响，以及哪些人做哪些事情的时候，会对我使用有影响。经过这样的梳理，基本上能把角色覆盖得差不多了。
闭环思维
这种方式主要是对模拟用户行为这种方式的补充。模拟用户行为的方式，只能模拟出一些正常的、核心的流程，也就是需求文档上写出来的那些流程。当产品经理考虑不周全的时候，需求文档上自然也就没有写，那你对着文档去模拟，也比较难模拟出来。所以，这个时候就需要利用闭环思维来协助你发现一些文档上没有写出来的部分。所谓闭环思维，就是用户使用流程要有始有终，操作也要对称。
比如，有加入会议，就会有离开会议；有开始会议就要有结束会议等等。
我曾经遇到一个需求，要求在视频会议中可以开始录制，录制完成之后，会议的组织者和超管可以到管理后台获取录制文件。一开始都把精力放在了这两个角色上面，殊不知，真实的场景下，会议的组织者可能只是帮别人预约了会议，自己并不会参加。但是在视频会议中的主持人可以开始录制，但是他不能获取到录制的文件，这就会出现一个比较尴尬的事情，主持人只能找会议组织者，或者企业超管才能拿到录制文件。
如果用闭环思维来考虑这个需求，当我作为一个主持人时，我开始了录制，那会后我肯定想找到这个录制文件。那我该怎么找呢？自然也就想到了会议的主持人是否也可以在会后获取到录制文件 这个点。
如何分析用户遇到的问题是什么
提到用户需求，有个很经典的例子：当用户说想要一匹更快的马的时候，其实他想要的是快，但是由于用户自身认知的局限，所以他能想到的是一匹快马，而不是一辆跑车。同理，当产品经理说，我们要做某某需求的时候，我们就要先想一下，用户现在遇到的问题是什么，产品经理提出的需求，只是提出了一种解决问题的方式，至于是不是最合适的方式，还需要再分析。
先看下什么叫问题。对一个问题的描述，通常是在描述现状和预期的差距。也就是说，当你能客观地描述清楚用户的现状，用户期望做到的事情，以及其中的差距是什么，那问题就描述清楚了。那不妨 在分析需求的时候，尝试给自己、给产品经理问出这三个灵魂拷问：
- 用户的现状是什么
- 用户期望做到什么
- 差距在哪里
如果大家都能客观地回答这三个问题，那用户的问题就理解清楚了。基于此，我们再看产品经理的需求，就不会仅仅局限于他提出的那一部分需求了。在一些情况下，产品经理的需求文档里，会夹杂着几个不相干的小需求，可能只是他们认为的对这个需求的“优化项”，也有可能是为了其他需求做的一些铺垫而带进来的需求。当我们清楚地认识到用户的问题所在，自然也就能分辨出，哪些需求是解决了用户的问题的，哪些是一些锦上添花的需求，即使不做也不会有影响。自然地，当需求很庞大的时候，也可以有效地进行优先级排序，甚至把部分需求砍掉了。
总结
角色与价值分析在业务分析中是最重要的一环。角色分析漏了，容易造成返工，价值分析错了，后续工作就做了无用功。无论多紧急的需求，都需要做好这一步，否则后续的工作很有可能是白费的。可以说，角色与价值分析，是业务需求分析的基础与核心。
