入职两个月第一篇文章~
背景
由于所处企业的特殊性，产品经理的职责与通常意义上的略有不同：
1､需求由运营同学提出，产品同学不需要冲在一线去收集需求；
2､所产出的“产品”准确来讲一个解决方案；
尽管存在这两点特殊性，但产品经理在工作上的流程与职责是不变的：在流程上，需要评估需求的合理性、价值、可行性，产出产品方案，然后去落地；在职责上，产品经理永远是产品的owner，对产品的生死存亡负责。
正文
接下来，就谈谈我对需求梳理的一些理解。
首先，需求梳理是产品流程中的一个环节。它的输入是产品需求，产出是产品方案。我们通常定义的产品流程为需求->设计->开发->测试->发布，似乎没有需求梳理这个环节，我认为主要因为这个环节没有比较“纸面”的工作，它通常在产品经理的大脑中完成。可以认为，需求梳理是需求与设计之间的桥梁，它将原始的需求转化为产品方案，进而才能按照这个方案去做设计。
其次，需求梳理是产品流程中最重要的一个环节。为什么这么说？因为它是产品需求与产品方案之间的桥梁！需求梳理将抽象的产品需求转化为具体的产品方案，过程中需要完成对需求的深入分析、对需求价值的判断、对可行性的分析。只有经过这样的梳理，才能判断需求是否合理、得出的产品方案是否能够真正满足需求以及方案是否能够落地。
那需求梳理应该如何做？首先明确需求梳理的目的是全面的分析需求，产出靠谱的产品方案。话说起来简单，“全面”、“靠谱”这两个词是谁也不敢保证的，它需要建立在对业务和技术架构都有充分的了解的基础上。产品新人面对需求时，往往想到一点是一点，没有经验来告诉自己是否分析全面，也没有一个框架来查漏补缺，本质还是没有方法论支撑。凭借两个月的“切身体会”，整理了一张需求梳理的脑图，以问题的形式来指导需求梳理。
图中左侧两个模块是对需求背景的了解。一个需求必然是在某个（些）业务场景下产生的，通过对场景的深挖（流程、角色、特殊情况等）能够对需求有更完整的认识，明确需求涉及哪些结点和角色，在后续的分析中从这些点出发，保证考虑的全面性。其次，再从业务现状入手，了解当前业务是如何进行的，有什么痛点？这是判断需求价值的重要依据。
右侧三个模块则是完成分析、产出。首先判断需求价值，决定做或是不做。在需求合理的情况下，还要考虑紧迫程度如何，决定何时做。需求的价值体现一方面是能解决痛点，另一方面是能带来额外价值，最好能以具体的数据说明。这样做的好处一是让自己对这个价值有具体的认识，二是在面对挑战时更有说服力。
判断为有价值的需求，就要考虑解决方案了。这是一个从发散到收敛的过程：首先试着深挖痛点，从更抽象的角度看问题，并根据前面对业务的了解，全面的看有哪些解决方案。然后分别评估各方案工作量与风险，选出当前情况下最优的解决方案。（这个流程可参见我之前整理的《设计流程》系列文章，http://www.jianshu.com/p/1e11a840f040
最后，则是方案的落地了（注意方案落地与产品落地的区别）。以上确定了产品方案，但它只是产品经理的“一厢情愿”，还需要与具体实施人员确认可行性，确认风险如何处理等问题。另外还需要与对方确定工作量与时间安排，有了这些要素就可以制定出大致的产品落地计划。到此，需求梳理的工作算是完成了，接下来要做的就是 JUST DO IT!
题外话
现实往往并不那么美好。并不是需求梳理完了，就可以按照计划顺滑地推行了。需求变更、场景考虑不全面、异常流程处理等等一个个坑，谁踩谁知道。但是，这些都不可怕，首先这些都是正常的，快速应变处理就好；其次，即时总结，避免下次再踩。
