作为产品经理，总会在各种时刻接到各种来源的需求，运营、技术、测试、老大……如果不幸做的产品还有对外合作，这些来源还得double一下。这种情况直接导致手头待做的内容越积越多，如果没有及时记录分类，就会影响后续的版本规划和需求跟进。
非要方法论的话，需求管理就是解决５个Ｗ的问题：what、who、where、when、why。建立需求库，根据where来进行需求分类，在需求详情中说明剩余４项即可。
ps：懒得看文字的可直接到最后看思维导图
一、需求分类（where）
合理的分类应该是对产品流程和结构的梳理，从这个角度分类能更快速地找到符合版本规划的需求。即使不是为了整理需求，按照以下的方式梳理一个产品，也能短时间内大致了解一个产品的结构和关键点。
１、一级分类
一级分类涵盖了用户从新增到流失的整个过程，包括关键新用户留存、行为转化率、体验问题、和流失召回。其中行为转化率会包含多项，通过下面的步骤就能简单提取出来：
- 用一句话描述：“用户来是做什么的？”——即核心功能是什么
- 稍微细化下流程：“用户做这件事的步骤是什么样的？”——即产品涉及的主要场景
- 找到关键的页面：“这个流程中必经的页面有哪些？”——即产品关注的重点转化率
以淘宝为例：
- 买东西
- 打开app—>寻找想要的商品—>购买—>收货
- 重点转化率：访问>商品详情页>订单页>付费
所对应的一级分类就是：访问>详情转化率，详情>订单转化率，订单>付费转化率。
一级分类所对应的内容，有时还需要根据KPI和产品的宏观规划作出调整，从而方便聚焦到当前产品的的主要关注点。
２、二级分类
二级分类是产品中承载功能的不同模块，通过将上面分析的用户使用流程进行细化，就可以得到。
- 细化流程：“每一层转化，用户都能通过什么功能实现？”——单独页面承载的功能
- 细化场景：“什么能帮助用户做决策，促进转化？”——附着于页面的辅助功能
同样以淘宝为例：
- 从打开app到找到需要的商品，可能通过搜索、分类、首页推荐or广告、关注的店铺、买手推荐……这些都能构成一些独立的页面
- 能够帮助用户做决策的部分，包括评论、销量指标、产品智能排序算法……这些会在不同页面上作为信息展示，或者本身是不被用户察觉的背后逻辑。
二、需求详情（what、who、when、why）
需求详情主要包括以下几项内容，不同产品根据自身情况，可能有所删减：需求内容、解决问题及预期效果、需求调研方向、需求来源、优先级、版本计划。
what
需求内容——要做什么？
如果不是单独页面就能承载的功能，最好在这部分说明下相关页面，避免遗漏。
why
- 解决问题及预期效果——为什么做这个？
- 需求调研方向——凭什么认为这么做了有效？
如果不想在需求评审时，被开发GG以及运营MM问得哑口无言招架不住，就加油在这部分多下功夫吧。需求调研方向包括但不限于数据表现、用户反馈、调查问卷、竞品分析、相关论文……
who
- 需求来源——需求相关方是谁？
列这个的目的主要有两个：帮助评估需求的优先级、帮助了解需求细节。
通常一个需求的来源，可能是产品、交互、运营、开发、测试、合作方、领导。来自领导及合作方的需求，极有可能和公司整体的战略方向相关，或影响产品的正常发布流程，所以这两个来源的需求，一经确认，通常优先级较高（即使有些鸡毛蒜皮感觉不值得做）。而来自其他非产品的需求，则需要和需求方深入沟通了解他们的核心诉求如何，以方便具体方案的制定。否则很可能你做出来的东西和运营要的南辕北辙。
when
- 优先级——重要性紧急性如何？
- 版本计划——哪个版本做？
这部分没什么好说的，毕竟做需求整理就是为了看看有什么要做的需求，优先级如何，来跟哪个版本的。
附：思维导图（分类以音乐App为示例）
作者：谭喵
来源：人人都是产品经理
