需求分析要做好，首先得破解需求分析难点的“三板斧”

　　正如我们都知道的一样，产品需求可以来自用户、客户、销售、领导，也可以来自竞品、技术、以及自我反省。总之，需求来源广泛，只要你留意观察收集，就会发现很多很多的需求反馈，正式的、非正式的，直接的、委婉的，甚至是反馈者都不知道反馈的是自己对产品的需求。
　　产品的需求是产品不断更新迭代、日趋完善的不竭动力，很多人懂，也都能说来一些。但是总是不够全面，仿佛需求分析很大、很多，给人一个很难全面掌握了解的印象。那是因为所处的环境不同、公司性质不同、产品属性不同，产品需求的处理与分析也大相径庭。你不可能要求一家由产品经理兼任交互设计与用户研究的初创型公司，像BAT一样有团队来做一个产品；你更不可能要求一个以技术为导向的公司能够有一个团队来做用户研究。
　　很不幸的事，作者就是在这样的刀山火海里面走出来的。在这样的环境中，作者对需求的处理就没有那么多的精雕细琢，更多的是粗暴直接的方法与技巧。
　　从作者的经验来看，在小公司，或许没有项目经理、用户研究院、交互设计师，一个产品经理单挑一个或多个产品，直接获取干巴巴的需求，直接与UI设计对接。
　　作者认为需求分析的难点在于，确定哪些需求是急迫的、在下个版本中一定要解决的，属于A类需求，哪些是大众的、有必要做的但是并不急在下个版本解决，属于B类需求，又有哪些需求是“伪需求”，是由于用户的不常规的习惯、或者特殊情况下出现的需求，属于C类需求。只有在确定这些需求归属何种需求的情况下，才能在有限时间、资源的预算中有序的推进产品不断完善。
　　对于一个刚入门的产品经理，在没有经验、底气情况下，需求分析也是一样，这篇文章就是对需求的提出、调研以及解决来阐述作者在解决需求分析的个人经验，破解需求分析难点的“三板斧”。
　　第一板斧：数据会说话
　　任何一个互联网产品都不可能给你充足的时间、人力资源让你做一个完美的产品。在这个每一分钟都会变化的环境中，我们都在遵循一个敏捷开发的产品节奏。需求就是我们进行开发的开始。在我们获取大量需求的前提下，对需求进行分类整理，合并同类项，将具有相同或者相似需求整理在一起，研究同类需求的共性以及有没有共同的解决方案，接着就是查看共性需求的比重，如果一个共性需求在收集的需求中的比重达到了50，你说这个需求要不要做？对这一类的共性需求在需求报告中标注为高优先级。对于需求特性较为分散的差异化需求，也可以算出所在的需求比重，再拿出以往的需求分析，可以看出差异化需求是否具有低频持续化，如果有，这个差异化的需求就是有必要做，但是不急于一时，可以在需求分析报告中标注为中优先级。如果没有前期的数据分析积累，那么，就需要持续关注这个需求，并把当前的分析就可以作为数据积累，在后期的需求分析中用到。
　　另外一点，针对不能直接接触用户、需求的产品经理来说，网络埋点是一个不错的选择。我们可以通过网络埋点，发现对于某个页面或者button的用户浏览和点击量，来确定问题的优先级。
　　第二板斧：永恒的竞品分析
　　古语有云：知己知彼，百战不殆。作为需求分析中一个很重要的方法，竞品分析不仅仅是检查我们所获的需求是不是真正的需求，还是我们获取需求、调整产品方向的重要参考。竞品分析不是在我们做需求分析的时候才去做，而是时时在做，在我们做需求分析的时候，着重的去了解相似功能的模块。比如，作者的工作经验中，作者会每个月出一份行业竞争对手的分析报告。单份的竞品分析作用可能有限，但是，连续几个月的竞品分析作用就很有用了。当我们拿着很多需求，参考竞品在类似问题上是怎么解决的，不仅可以提供设计思路，有时会在技术方面也会有很多启发。如果可以参考的竞品很少，或者竞品中没有满足类似需求的功能模块，那么你要注意了：可能是你的想法很有预见性，是一个潜在的需求；还有另外一种可能，就是这是个坑，小心别跳下去。竞品分析中有一个很重要的至于竞品分析的方法不在今天探讨的层次维度，以后再谈！
　　第三板斧：需求讨论真正的演武场
　　对产品经理来说需求讨论会是把想法真正落地的演武场。当你拿着自己分析好的需求、制作好的Demo，在需求讨论会上向项目、UI、开发、测试等阐述自己的观点时，你不会获得大家一致认可的结果。这个就要你去坚持，不能因为开发说一句“这个实现不了”就放弃你的想法，试着去找到替代方案，或者在开会之前就想好第二种方案，因为你的方案被大家反对不看好的概率会高达99。
　　需求讨论会，一般会经过三次讨论：第一次是产品经理阐述需求，以及需求的紧急程度，需要Demo的要给出，保证参会的关键人员能够完全明白你的意思，最好能让他们根据自己的理解复述一下需求，使需求的传达不会出现偏差。最后，让相应的人员根据需求去调研相关技术方案的可行性。第二次需求讨论会就是讨论技术方案的可行性，以及在相应时间预算中能否保质保量的完成，从而调整这次版本迭代中要解决的需求，使确定的需求在各方面的承受范围。最后就是各相关人员会后评估与自己相关的工作量。第三次需求讨论会就是根据反馈过来的工作量，确定解决最终需求的时间点，以及每个阶段的时间和确定最后的升级时间。
　　当然，所有的问题都不会有固定的解决方案，就像在做需求分析时这三板斧不会一板接一板的抡，可能会一起抡，有可能在做数据统计的时候竞品分析也同时在做，也有可能需求讨论会上你还要调整需求。但是，需求分析宗旨是不变的，就是发现需求中的真正的需求，并根据需求的优先级合理安排解决需求的时间节点和版本。
　　当有人质疑你的需求时，你能够有理有据的给出解释，除非有些人为不可抗拒的因素，你的需求分析一定能够通过并顺利实施。