需求功能分析方法论

        在作为一名产品坑的需求分析人员，我们需要形成一套自己的需求分析方法论，在这里，我将把自己的需求分析过程以及包括一些常见问题的解决方案与大家进行分享。

需求功能分析方法论

---

一、分析需求来源

        每当我们接受到新任务时，通常是以邮件或公司内部交流工具进行通知的。我们第一步要看的是任务内容，然后通常任务来自运营人员或者上级的新功能需求，此时要注意，我们不仅仅是看任务内容，在阅读新需求申请之后，首要进行的是对该需求目标的确定。这个需求它到底是为了谁在什么情况下完成什么的操作，即：场景与问题。

        当然有时候新需求很多，然而运营人员实际写需求申请时字面形式仅仅是一个功能。这时候我们需要注意，在实现字面功能的背后，我们是否还忽略了与此相关的后台或有连锁反应的功能，这种情况下，所涉及到的所有功能都属于新需求中需要分析到的地方。

        在分析需求来源时，核心目标是产出最好的方案，但是比方案更重要的是：需求本身。所以，时刻问自己一个问题：这是当前最重要的事吗？有的需求是一开始就很容易分辨，不是当前最重要的事；有些是做着做着发现的，这时候要果断叫停，表面上看是烂尾了，但是对团队和公司的帮助确是巨大的；当然有时候是把之前烂尾的需求完善后完成的，之前时机不合适，现在可能时机成熟了。

二、优秀的需求分析来自于你对问题有更深刻的理解

        每当你决定做什么前，提前问问自己，这个是不是符合真实场景，核心问题是什么，你的解决方案是什么。

        分析需求三要素：场景，问题，解决方案。

        当我们分析完成这三处的时候，基本上表层的问题就能解决，但是更深层次的问题，这些还是不够。

        每个阶段解决当前场景下的问题，不断积累，才能把一个功能做大做全。不要总想着，一口吃个胖子或事一劳永逸这些，场景调研和功能设计，总是相辅相成的。

        接着，要不断问自己为什么，让别人问为什么。一个人的理解是有局限的，完善的意义就在于知道了你之前不知道的事情，所以你就知道的更多。

        完善当前需求场景的两个技巧：问自己为什么，别人问自己为什么。

        产品需求分析师是一个需要独立思考的岗位，但不等于要独立完成，尤其在你拿不准或者不知所措的时候，你应该想到是时候该离开座位出去找人聊天了。

三、需要拥有即时决断的能力

        这一点主要针对于开发过程中所涉及到有技术难点或者，提出更好的或不同的方案的情况下。这时候需要我们对于解决方案能够决断，妥协或者坚持己见都可以是解决方案。一味地坚持结果打脸，以后别人也不会认同你。小问题，轻风险，在我们承受范围内，学会变通，可以更好地解决对立和冲突。

        当然不是说一直变通，当一个老好人，还是要先应该考虑这样做的结果会是什么。如果在同样的情况下，用技术认同的新方案不会造成用户理解负担，也是可以的。在多数情况下，我们做的功能，需要得到市场的验证，一旦实现后，我们要考虑能不能获得自己想要的结果。

四、建立在项目组中的角色

        涉及到需求、设计、实现，需要你确定的前提，你必须得让每个人清楚的了解。你得让他人清楚你在这项工作中，扮演什么样的角色。在需求定义的时候，你就是定义的核心，其他人想要改，必须要经过你，擅自改动，你一定不能同意，直接打回拒绝；尤其是在项目后期，未经决策和批准，实现结果与预期不符，直接将问题记录，陈清利害，找相关负责人予以解决。

        如果事实证明了自己需求定义和功能设计不够完善，那也要重新走一遍变更流程，并在项目中记录实际情况，因为对方在项目中应该提前表明，而不是到了后期，板上钉钉的时候，才知会出来。

        学会维护产品需求分析师的职责范围，有助于让你建立更多的自信。做或不做，不再仅仅是因为一句话，而是有需求分析师这个角色的协调而推动产品进展。这样才能让别人理解你，让别人更加相信你。