在设计一款产品时，我们需要经历一系列的活动；而需求分析往往是最重要的一部分，我们只有知道用户的需求，才能引导我们产品设计的方向。
并且在软件工程中，也只有需求被称之为“需求工程”，足以可见需求的重要性。
这张图所呈现的意思是：如果我们在需求阶段发现错误，只需要1个单位时间修复，到了设计阶段，则需要花费5个单元的时间修复，等到代码阶段需要10个单元，到最后的运行与维护，需要200以上的时间单元进行修复。
越往后，修复的代价会呈现指数级上升，甚至因为堆砌了一堆无用的功能，导致系统越来越臃肿，最后造成用户的流失。
所以，需求分析很重要，那么我们到底如何进行分析？又该如何验证呢？
苏杰老师曾提出Y模型理论，将需求分析模型化，这篇文章也主要对该分析思路做进一步的思考延伸。
如何进行需求挖掘与分析？
我一直认为所有事物都不像表面看起来那么简单，因为我们往往看到的都是冰山上面的东西，而冰山下的存在才是这个事物的核心。
正如我之前探讨过“深度思考”是有层级架构的，对应起需求分析，它也有属于自己的层级架构。
第一层：观点与行为；
第二层：目标与动机；
第三层：人性与价值观。
这三层逐步挖掘出用户最底层的核心述求，首先我们通过观察用户所展示出来的行为，对该行为我们可以做进一步的目标分析，针对目标则拥有更多的方案选择；
但挖掘还得再进一步，找到这个目标所包含的人性和价值观，才能真正实现产品的最大价值。
接下来我们通过一个简单的案例去研究一下这三层对应的思路。
“酒店前台人员向产品小A提出了自己的需求：请在酒店入住界面中，增加平面图，实时显示房型、房态和入住信息”
这个案例背景就这么一句话，此时角色有了，需求接收方有了，同时需求点也有了，如果我们仅在第一层进行分析，我们只会沿着用户的思路去延伸，去思考和研究这个平面图的形态。
“产品小A沿着酒店前台的需求咨询了几个问题：你们酒店有很多楼层，只怕一张平面图无法涵盖所有的楼层，是否可以进行筛选楼层查看？具体使用频次高不？”
在这一层，我们只是针对用户给到我们的观点去分析，如果仅分析到这里，可想而知我们的后果是什么；我们花费大量的力气做了个平面图，当真正交付给用户时，用户大概率是不会满意的，所以我们需要再往下挖一层。
“产品小A想要挖掘背后的目标和动机，于是继续询问酒店前台：你们这个平面图具体要解决什么问题呢？你要实现的目标是什么？”
此时我们才开始探讨了这个需求背后的动机，这几个问题进入到需求分析的第二层，同时我们还能进一步挖掘到这个需求延伸的一些场景，对用户的目标和场景进行结合策划。
“针对要解决的问题和目标，前台略微思考回答：有时候客人需要相邻的两个房间，但我在这里遇到了困难，因为酒店楼层太多，房间号相邻并不代表房间是相邻的，所以想要平面图解决这个问题，增加办理入住的效率”
这里，已经将需求的锚点延伸到“如何找到相邻房间的问题上”，我们可以有更多的解决方案去解决这个难题了。
比如在入住界面增加房间号相邻的筛选项，只需要前期花费一点时间录入相邻的房间号，在数据库增加字段和索引，前端增加对应的字段和筛选，在满足需求的同事，不仅减少了工作量，也让系统没那么多冗余的内容。
当然我们挖掘到这一层，已经可以满足大部分用户的需求了，但我们还可以继续往下一层探讨。
酒店前台提出的需求是为了解决这个难题，但是他为什么解决这个难题呢，从目标层来看，他是为了效率，解决相邻房间难办理的问题；
但是从第三层人性与价值观来看，这个问题导致的后果可能是“由于没法满足入住效率，导致客户投诉，从而影响自己的升迁和提薪”。
此时整个思考点会转化成“减少客户投诉”和“能做出更多成绩给领导查看”。
延伸这个案例，产品小A可以继续询问“你们在工作期间，什么会引起客户的投诉呢？哪个投诉量更大？你们平常做的好与坏除了客诉量，是否还有其他的指标？平常领导是如何评估你们的工作情况的？”等等。
通过案例，我们层层挖掘出酒店前台的核心述求，在每个层级上，我们都可以有更多的可行方案去满足用户的需求，然后在众多成熟元素中灵活组合一个最佳方案。
产品经理一定要避免只在第一层思考，只有不断向底层探寻，才能真正挖掘出用户需求背后的含义。
如果上述案例太抽象，也可以用我们熟知的马和汽车的案例出发。
第一层：用户想要更快的马，我们围绕着这个点，可能会想研发一个新的饲料，改进一下训练方式。
第二层：用户其实是想要更快的到达目的地，需求就不再是要一只简单的马了，而是“更快”比“马”重要，所以汽车应运而生。
第三层：今天的汽车已经满足快了，但我们可以看到，当前汽车的关注的功能点已经越来越发散，比如全景天窗、高级灯光等等，都和快没啥关系，大多是为了满足“让自己更舒适”“让自己获得他人尊重”的人性需求。
经过了层层分析，我们得到了多个方案，方案往往带来的都是较为抽象的，此时需要考虑具象化，形成可使用的产品形态。
那么，我们又该如何判断这些方案可行性，如何验证这些方案呢？
验证需求方案
首先我们得知道，我们做的设计，都是提供给用户使用的，如果我们抛弃了用户，那再好的解决方案都无法产生价值。
俞军在《俞军产品方法论》也说过，企业需要和用户产生价值交互，而这个价值交换的桥梁则需要产品实现，所以产品和用户是密切不可分割的。
所以验证需求方案最重要的视觉是“用户”，这里我们可以采用“用户模拟场景法”，或者称为“用户故事”去验证需求的合理性。
我们需要假定这个需求已经实现，此时可对目标用户进行分层，简单的分层方法可通过“新手用户”“老用户”进行划分，思考分层用户在主场景下如何使用功能；
当模拟完用户后，发现用户对这个功能并不感冒，则可以判断这个解决方案并不可取，需要思考下一个解决方案。
用户模拟场景法可通过文字描述出来，此时则形成“用户故事”，用户故事可以佐证我们的方案可行性。
用户故事一般的描写手法是：
“作为一个<用户角色>, 我想要<完成活动>, 以便于<实现价值>”
一个完整的用户故事包含三个要素：
- 角色（who）：谁要使用这个
- 活动（what）：要完成什么活动
- 价值（value）：为什么要这么做，这么做能带来什么价值
如果我们只是用输入输出、功能逻辑来描述需求，此时是没有任何画面感产生的，而通过用户故事，能够让整个画面活跃在大脑中，毕竟科学验证过，人类的大脑喜欢故事，对于0和1，也确实太过抽象了。
最后
最后，需求分析的整体思路是：
挖掘需求——得到最佳方案——验证需求——编写用户故事佐证需求。
产品经理只有对需求不断论证、不断推翻，最后得到的实现方案，才是真正可让人信服的，而不是拍拍脑袋说，这个方案我感觉可以，这个方案我感觉就应该这样的。
