搭讪是产品经理的基本功,需求管理也是!(下).pdf

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