看了《从点子到产品》这本书，结合我们自己的工作情况，总结了一下从需求点到详细需求方案的必经环节，后面可以分享给产品新人，希望能给新人一些基本的确保做起来会正确的方式方法。
一、价值分析
与产品需求直接相关的就是产品价值，不管是来自各方的明确需求还是需要我们通过调研出来的需求，都要先考虑它的产品价值是什么；产品价值这个词或者说“要做价值分析”这句话我们的确经常说，但是，遇到现实实践中的工作任务的时候，我们往往会被周围其他看起来很重要紧急的事情给迷惑了，避重就轻的就把价值分析给忘了。需求的价值分析可以让我们清晰的看见这个需求的最原始的需求点、这个需求的必要性以及解决这个需求的方向，还可以确保我们后面做的一连串的动作都是有意义的，所以，一定要先做价值分析，
方法：场景法 5W who-when-where-what-why，why就是价值，why也是我们这个需求要帮客户／用户解决的痛点（问题）；
二、产品逻辑分析
通过价值分析确认了需求之后，接下来要做的是产品逻辑分析，也就是梳理业务逻辑；有了这个逻辑分析，可以确保后面的方案完整，不会漏掉某一个场景，还可以根据这个设置产品的相关逻辑规则；
方法：找张纸，把所有的可能发生的场景按照业务逻辑（业务发生的先后顺序）画出来，形成一个结构图，这也是整体方案和功能的初稿；
三、确定MVP（minimum viable product 最小可用产品）
有了业务逻辑分析结构图，我们就可以清晰的看见这个业务里所有的场景和业务线，就可以找到MVP；
方法：将场景做优先级的排序，找到优先级最高的那个场景或者是业务线，接下来如果有需要还可以继续做减法，直到可以实现这个需求的商业价值为止，这就是我理解的MVP，根据资源和开发进度的情况可以圈定开发迭代的功能范围；
四、方案可行性沟通（评审）
圈定了开发迭代的范围，就可以设计需求方案了。方案有了初稿之后要和UE、UI、开发人员一起做方案可行性沟通（评审），确保方案可以实行，开发可能会提出问题或者建议，适当的对方案进行调整；
方法：
还是画图（我是画在纸上），把要实现的功能在每个场景或业务线上明细出来，把要实现这个功能需要如何操作拆解出来，把界面大概布局设计出来，最后按照操作的顺序，把功能操作串起来，就形成了方案的初稿；
召集UE、UI、开发人员一起开会，沟通你的方案初稿可行性，开发也会在这个时候知道实现这个需求的技术难点在哪，是否需要提前准备等等，最后根据结果调整方案；
五、方案编制、详细需求编制
这时候才可以正式的编制详细需求方案了，UE、UI也可以同时出图，开发这时候也基本知道你这个需求的价值、需求功能都有哪些，开发计划也基本清晰了，这些都为后面的功能实现提升了效率，且增加了成功率。
详细需求文档要写的足够清晰和准确，不能因为怕麻烦而省略一些重要的描述，不能默认为开发能够理解这个功能的要求而简化文档，写得越细致，开发看的越清晰，还有，如果开发过程中文档需求实现方式或者哪个细节有变动，要及时更新文档，最后将文档保存起来，后面如果需要的话，可以及时找到阅读；书上是说交底之后，开发来找你沟通的次数越少，说明你的文档写的越好。
