接着《搭讪是产品经理的基本功，需求管理也是！（中）》来继续讲需求管理。
之前我们已经通过需求分析和筛选，评定了需求的优先级，这时候就应该把这些整理好的需求，通过一个表格给呈现出来，功能需求列表Feature List就是这样一个承载器。
输出功能需求列表
什么是功能需求列表？顾名思义，就是把需求分析、筛选和评定优先级之后的结果，以产品功能的形式展现出来，再用列表的方式将其呈现。这是需求分析之后，提出解决方案的第一步。
功能需求列表的价值，一是在于帮助产品经理自己理清思路，二是在于帮助项目团队的其它成员了解产品功能需求，好让他们提前做好相关准备。
我们来看一下功能需求列表大致包含哪些内容。
模块：一般来说，每个模块下分3~6个子模块是合理的，否则要考虑重新划分。
子模块：也就是一级模块的二级分类，这里就已经涉及到产品架构的梳理了（但我们这里只是大致地梳理一下，后期在产品设计的下一个环节“搭框架”会进一步调整）。
功能：要给用户提供什么功能，给这个功能起个名字。
功能描述：这个功能具体包含哪些操作，可以描述的具体一些，如支持用户填写基本信息可自由创建课程，进入课程空间就可对课程进行编辑和管理，还可发布、删除课程等。
用户价值描述：也就是可以给用户提供什么价值。
需求优先级：这块是整个Feature List工作中核心的部分，判断的准确直接影响着将来产品的方向，我们只需要将我们之前评定的需求优先级照抄过来就好。
开发量：一般由研发部门的项目经理或者开发来确定。
投入产出比：简单来说，就是商业价值除以开发工作量（或开发难度），当然每个团队可以找出一个合适自己产品需求ROI的计算方法。
备注：觉得需要强调的，比较特殊的东西。
上图是功能需求列表的一部分，当然现在也有越来越多的产品经理直接通过脑图软件来进行功能需求的梳理，然后通过脑图软件自带的标注、附件、笔记、优先级排序等功能进行说明，比如下图这样的：
形式其实并不是那么重要，重要的是团队成员能够通过你的文档更加清楚地了解产品的功能需求，也便于产品经理和团队成员进行沟通。有了这份功能需求列表，我们就可以召集团队相关成员进行一次需求评审会议了。
参加需求评审会议的可以有产品经理、老板/领导、运营以及市场相关人员、开发主管、测试经理等。为了保证需求评审能够顺利进行，最好提前做好相关的准备，产品经理要能够讲清楚需求的来源，为什么要做这个需求，做这个需求有什么意义，这个需求需要哪些功能配合，同类竞品是否有该功能需求，为什么这个需求的优先级比较高……整个需求评审的过程，考验了产品经理对需求的熟悉程度以及对需求的判断能力。同时，参与评审的人也将会对你提出的需求提出自己的看法，是否同意该需求，并且会提出同意或者不同意该需求的理由。需求评审是多人围绕已经收集到的需求进行评审的过程，通过集合大家的智慧，能够避免一个人闭门造车拍脑袋进行决策的局限。
如果时间比较充足，有些产品经理在需求评审会议上还会展示产品低保真原型，用来辅助说明，让大家更加理解这个需求以及需求以后会是怎样的样子，这样也能够让自己在讲解需求的时候更加有依有据，避免错过一些有用的需求。当然，我们这里只是第一次需求评审，到了后期产品原型乃至ui设计稿全部定稿的时候，依然需要进行产品的需求评审。
路漫漫其修远兮～
如何管理需求——需求池
之前就已经说过，需求是每个产品经理日常工作都离不开的一部分，贯穿着产品的整个生命周期。所以，如何管理需求，就成为所有产品经理必备的一项技能了。
在这里要给大家介绍一下需求池这个东西。
什么是需求池？嗯，你可以把它类比为一个需求的收集器。需求池其实就是存放跟产品有关的未来可能会做的功能点的聚集地，然后在规划新版本的时候，从池子里根据“轻重缓急”和“优先级”来筛选出几个需求，排一排、整一整，弄成一个新的版本项目计划。
需求池工具有很多，比如Project、Execl、MindManager等等都可以作为需求池管理工具，你也可以使用一些团队协作软件（如tower、tita、明道、teambition等）里面的项目管理功能来做需求池工具。
一般来说，我会将需求池按产品的功能模块来进行划分，这样所有关于产品功能的需求都会被归类到相应的产品模块里。当然，这个需求池里还会包含来自运营及其它部门的需求。我们要做的就是告诉这些需求提出者，他们的需求我们都重视了，已经放到了需求池当中，但是是否安排开发需要根据所有需求进行“轻重缓急”和“优先级”的权重比较才能决定。我们需要定期去审核和分析这些需求，是做还是不做、要做的话是什么时候做？
对需求池的建议有两点：
第一是不必考虑能不能做或者是做了没用什么的这样的限制，先不必设置伪命题，只要是觉得OK的，都可以先列出来，在产品生命周期管理中，靠谱的、不靠谱的、紧急的、不紧急的；
第二是需求池需要产品经理经常去整理，不然就失去了需求池本身的意义，如果你不去整理，不论是市场环境，用户行为都有可能发生变化，任何一个产品都是变化很快的，这个时间段的需求有可能过一段时间就失去意义了。这个整理其实就是复原了一次需求的分析和筛选过程，同时还要去进行需求的优先级定义，每一次安排产品版本计划的时候都要重新审视一遍需求。
最后的总结
需求管理是一个完整的闭环过程，同时也贯穿着产品经理工作的每一天，比如：
我们是不是每天都要去思考这个需求是否需要去做？这个需求到底重要不重要，紧急不紧急；
我们是不是经常都要去用工具把需求给做出来，用visio这样的流程图工具去梳理业务流程，用axure这样的原型工具去设计产品原型，做的同时还得思考这个功能需求究竟放在产品的哪个功能模块合适；
我们是不是每天都要去和各种人沟通需求，和设计师沟通需求，和前端工程师沟通需求，和后台开发沟通需求，还要和测试、市场、运营、销售等沟通需求。同时，你还要和用户谈需求，让用户了解和认识你的产品；
不得不说，要做好产品经理真不是一件容易的事情。
