机缘巧合，不常刷微信的我，凑巧看到了向右奔跑发的微信，SO，我来参与“来简书聊聊你的产品之路｜@产品专题征文”活动啦！，你写不一定会得奖，但不写那肯定没有啊，这一想，立马动手，虽然我还是拖延了几天，哈哈。好，言归正传。
很多时候产品人员接受到的需求就是一句话，对于新晋的产品人员要是一脸懵，无从下手，那该多心慌。为了安抚新手们稚嫩的容易受伤的心灵，作为职场老人皮糙肉厚的我，决定手把手的来传授你们如何解读需求。下面从需求的概念，如何获取需求，如何分析需求，如何决策需求这4个方面来让大家有个全面的认知。
1.需求的概念？
怎么来理解需求，需求是什么样子的呢？刚开始需求是没有实际形态的，它是一个慢慢从抽象到具体，从粗到细，逐层分解的一个过程。如下图所示：
需求逐层分解图
>业务需求
按面对不同的服务对象，可以分为TOB和TOC的产品，TOB的产品更多的是面向业务部门，给业务部门提供系统化的解决方案，而TOC产品是直接面向大众面向个人用户，相对来说需求更难把握，产品千变万化，各不相同。业务需求是对产品需求一个高层次，概括性的，粗线条的理解。业务需求可以包含商业需求，上图中我把商业需求独立出来，是为了说明它的重要性，也是为了让大家对业务需求理解更清晰。
>用户需求
怎么理解呢？可以从“NEED”和“WANT”去理解。NEED，可以理解为本质的需求；WANT，可以理解为对本质需求的一种表象，即表象需求。比如，我渴了，想吃西瓜。这里解决渴是本质需求，想吃西瓜是表象需求，但其实没有西瓜的话，能喝点白开水也是好的。当然如果你能提供给我一杯西瓜汁那就更好了。只有抓住本质需求才能更好的为用户提供更满意的服务。
另外从卡诺模型（Kano model)）来理解，这是日本东京理工大学教授狩野纪昭(Noriaki Kano)构建的理论模型，用来帮助提高企业产品和服务满意度的一个模型。在这里也可以更好的帮助你理解用户需求。请先看图：
Kano模型-图片来自网络
必备属性-基本需求：产品必须要有的功能或特性，不满足，产品不可用，满足了也不会增加用户满意度。比如，音乐APP不能播放音乐，车不能开。
期望属性-期望需求：这类需求得不到满足或表现不好的话，客户也不会有什么不满，但提供了可以提高用户的满意度。比如，音乐APP能听歌，还能给歌手发私信。
魅力属性-兴奋需求：超出用户预期，顾客满意度急剧上升。比如，不仅能听歌，还能通过识别音乐旋律来找到自己喜欢的歌曲。
无差异属性-无差异需求：做和不做，不会产生任何影响。比如，我能通过歌手名字找歌，然后又做了根据名字拼音也能找歌。
反向属性-反向需求：此类需求会引起用户强烈不满，导致满意度大大降低。比如，你每听一首歌，都在音频前面先播放个广告语。
>功能需求
功能需求是对业务需求和用户需求的最小颗粒度分解，用户利用这些功能操作来完成任务，也是我们进行产品设计和产品研发的基础。
>非功能需求
当你专注在业务上时，往往比较容易疏忽这些需求。包括哪些呢？有性能，安全性，稳定性，健壮性等等。比如闪退，长时间无法加载等等，虽然不涉及具体业务，但是如果疏忽它，很可能因此致命，但往往也是最容易疏忽的。。
2.如何获取需求？
来源有很多。老亨利·福特说过：“如果你问你的顾客需要什么，他们会说需要一辆更快的马车。因为在看到汽车之前，没人知道自己需要一辆汽车。”我为什么要说这一点呢，因为自己的观察和思考是最重要的来源，要善于抓住本质需求，用户给不了你答案。另外有老板要求，业务相关人员调研，运营需求，客户反馈，客服反馈，用户反馈，用户调研，数据反映，头脑风暴等等。越全面，越有助于产品需求的的构建。
3.如何分析需求？
前面提到过了，要挖掘用户需求的本质，或者说底层动机。那么我们要做好三块工作：调研，归纳整理，打碎重组。
>调研
关注点“人？何时何地？做啥咋做？”，就是对于这个业务来说，相关的人员会在哪些时间哪些场景下来怎么处理业务内容。这个时候就要找相应的用户去调研，通常调研越全面，并不是说调研的人越多越好，而是有效的目标用户，这样才能把握产品需求，也更有效。
>归纳整理(横向)
归纳出角色，场景，需求，实现路径或流程，以及功能。如图所示：
需求归纳
简单举个列子如下：
需求归纳举例
>打碎重组（纵向）
需求和需求之间是有联系性的，我们不能单一的来看待某一业务需求，也需要根据业务的相关度组合来看。如图所示：
功能业务相关性
简单举个列子如下：
需求相关性举例
所以，通过调研，再从横向纵向两个方面考虑，才能系统化的来分析需求。
4.如何决策需求？
简单说来就两点，一，通过自己的主观判断来抓重点，当然你前期的分析工作已经为你的判断提供了依据。二、根据一系列调研方法客观量化来确定。下面具体说下如何根据Kano模型来量化决策。
首先发布用户调研，如下图：
调研内容
然后，统计数据结果，如下图：
调研结果统计
最后，进行数据计算分析，如下图：
如图所示，功能需求的决策已经一目了然，必备肯定优先级最高，期望和兴奋中，无差异最低，可做可不做。
最后，说点需求之外的东东。人的认知不同，需求不同，一万个读者眼中有一万个哈姆雷特。文化环境不同，需求不同。如，股市涨跌颜色显示，国内绿色表示跌了，但在外国，绿色是涨了。时代不同，需求不同。今天的期望需求，到明天可能已变成了基础需求。比如，指纹支付。总之，产品需要持续更新，与时俱进。照搬过去的、别人的理论方法并没有什么卵用。还是要靠自己活学活用。共勉！
附：Kano统计评价对照表
网友评论
如果只从业务逻辑来梳理需求还是很粗，还要从具体场景出发知道各个角色的对于业务逻辑延伸的不同需求，甚至几者之间的需求还可能有冲突，需要依照产品、市场定位做出取舍。
当然这应该是比较粗的梳理，我说了我们实践过程中执行遇到的具体需求问题。
另外ToB的需求梳理相对C也有点难：如果是B端的系统比如产品设计工具、数据分析工具、SEO工具和C端一样只需要找到特定职业人群调研即可，但是一旦涉及到整个公司通用或者角色通用较多的企业系统，比如我们目前做的办公系统、CRM系统、ERP系统，设计角色越多，需求调研就越麻烦，我们在实际需求调研过程中非常费劲，钉钉的企业共创是非常好的思路，但是代价非常大。
瞎评论，写写我们执行过程中遇到的场景。