产品经理日常：刚接到一个新需求，应该怎么处理？

作为产品经理，接收需求简直是我们日常工作中再基本不过的事情了，只要和你有交集，都有可能产生需求，有可能是用户直接反馈的需求，也有可能是公司运营、市场等部门同事给你反馈的需求，也有可能是老板直接给你提的需求，当遇到这些需求的时候，我们应该怎么去做呢？

我们首先需要去判断下这个需求的真伪，接下来根据我们分析需求的优先级进行排序，让我们的产品围绕核心目标朝着一个健康的方向不断进行迭代。中间最关键一点就是要做好沟通反馈，不然给你反馈需求的人会认为你没有重视起来，对于需求方来说会产生很多负面情绪，所以这一点一定要重视起来。

接下来，我们再来聊聊怎么去分析需求，或者说怎么去判断需求的真伪，我们知道在设计某个功能的时候，就是为了解决用户在某个场景下所发生的需求，从而解决这些问题，这个功能才会存在价值。那么，如果用户提的需求我们理解的不正确，设计的功能很可能无法真正解决问题，甚至仅仅是解决了用户的表面需求，出现功能做了，用户也不会去用，导致我们时间和精力都浪费了，最后的结果也不太令人满意。

那么，当我们遇到需求的时候，是否应该立即去处理呢？

我建议应该这样去做：

1. 用户为什么会产生这个需求？

当需求方向你阐述完某个需求后，向他询问：提这个需求的目的是什么？即为什么会产生这个需求？这个问题可以帮你完全理解需求，并辨别需求的真伪。

2. 用户在什么场景下会使用这个需求？

即搞清楚什么人在什么情况下会用到此功能。明白了这个，才知道如何更好地设计功能来满足需求。

3. 是否有可能衍生出新的场景？

为了避免设计的功能因扩展性不足，后期推翻重来，在一开始，就应该做尽可能全面的考虑。通过需求方的场景，扩展思考，是否存在衍生的场景。思考的过程，也是帮助你抓住和理解需求本质的过程。

4. 技术层面如何看待这个需求？

接到需求，并充分理解了需求后，跟相关技术负责人花几分钟时间讨论一下，听听他从技术上对需求的考虑。通过此过程，你们基本会对需求点及实现方式达成共识，在后期正式开发时，阻碍会小得多。

5.做了这个需求对用户有什么影响，以及用户对这个需求的紧急和重要程度是怎么样的？

一定要问清楚，处理这个需求对用户的有利影响和不利影响是什么，从而判断需求的类型，以及紧急重要程度，最后一定要多询问一句，需求方对这个需求的紧急重要程度的认知，避免我们分析完需求的紧急重要程度和需求方理解的不一致，导致最后出现矛盾。

那么，当需求方对需求不明确的时候，应该怎么处理呢？

我建议这样处理：

1.最直接的方式，谁提出的需求，找谁搞清楚需求，最好让需求方把场景描述清楚，还原需求的真实使用场景，有助于帮助我们来更好的理解需求，有可能需求方调研清楚以后，该需求可能就不会存在了。

2.如果需求方也说不清楚自己想要的是啥，在你听完他不清晰的描述后，利用你的专业技能，帮他梳理，并跟他确认，你的想法是否正确，是否就是他想要的

3.向对方提问题是搞清楚一件事情最好的方式，或许可以尝试这么问需求提出者：什么人在什么情况下会做什么事？你现在实际操作中觉得哪里是最困难不方便的？你觉得最好的操作方式应该是什么样的？类似这类问题，既是帮你搞清楚问题，也是帮对方梳理思路。

当需求明确后，后续的工作流程就会清晰很多，我们做个复盘，来看下我的工作流程：

第一步，与需求方进行沟通，主要是复述你接收到的需求，确保需求接收正确没有存在理解偏差。

第二步，我把它叫做清洗需求池，把接收到的需求进行清洗，分类出那些是已有替代功能完成了的，哪些是在之后的版本中有规划的了，哪些是与公司战略及产品目标不符合的需求，哪些是可以在这个版本加入的需求，同时评估需求的可行性、优先级、难易度。

第三步，将上述第二步的结果形成文档，并提交需求方，最好是自己亲自讲解，获取需求方的同意。这一步至关重要。

第四步，需求的具体分析，梳理逻辑关系，业务流程。

第五步，进行原型设计，如果需要出PRD，再这个阶段也一块进行输出。

第六步，开原型评审会（就是我们常说的kick-off会议），与UI、研发一同沟通需求及PRD，对会上的东西进行及时的补充和改进。

第七步，跟进UI设计稿，确认设计稿。

第八步，协助研发开发，开始编辑测试用例和测试文档，并准备种子数据（如果有测试，就协助测试完成，如果没有，就自行完成）

第九步，测试，验收产品

第十步，上线，交付产品

以上流程中有的阶段可能会反复进行，最为重要的就是我们的沟通能力，下期我们继续讲解如何提高沟通协作能力，最后还是希望大家持续关注，微信公众号中搜索“小宝谈产品”，让我们一起在产品和运营的路上不断前行～