对于PM来说，要管理好需求，离不开四个层面的列表管理。
1、Feature List：需求特性列表，日常的需求管理，管理好了，治大国如烹小鲜，管理不好，每时每刻被动煎熬。
2、Feedback List：反馈列表，各个渠道反馈的问题记录，可能有用户的骂声，Thats Great！，用户的痛点出现了！维护好反馈列表，有可能会转化为需求。
3、Bug List：缺陷列表，自己经常把玩产品过程中遇到的Bug记录或者交互异常问题，严重则进行立即修复Hot Fix发版，不严重下个版本顺带解决，当然也可以使用TAPD、禅道进行管理。
4、Version List：版本列表，每次发版内容记录，版本新特性记录。Review每次发版，进行功能效果评估。
本次主要简述用户需求管理中的Feature List，需求功能管理：
现实中关于需求管理会出现很多问题，诸如：
需求跟着跟着跟丢了，没有记录导致的
需求开发周期长，需求忘记了，没有记录导致。
需求来源渠道不明，没有记录导致。
需求太多、太复杂了，无从下手，没有树立需求池的概念。
明白了没有记录就没有发生，就很难再出现扯皮的现象了，显然需求的记录和管理是很重要的，这是产品的基础能力。
需求的来源也是很广泛的，诸如：
来自用户研究、调研、访谈的
来自数据分析的，数据驱动产品迭代
来自Boss的
来自市场部、商务部的
来自运营团队的
来自各个渠道的用户反馈的
来自脑暴峰会的
PM自己想做的等等….
可见需求来源太多了，先不说如何辨别需求的真伪，单纯的管理需求似乎就成了问题。
那么，如何真正意义上的进行需求管理呢？
需求管理应该分为三个层次，需求侧、技术侧、运营侧，需求的管理包括：需求策划管理、需求实现管理、需求效果评估管理。停留在需求侧是大部门产品经理的现状，兼顾技术侧的，有点偏重项目管理的角色，协调运营侧的，是产品负责人的角色，可以调动周围几乎所有资源，达成某种使命，这样的产品经理就慢慢的靠近CEO了，渐渐有了使命感，领袖的诞生就藏在表格里，潜移默化着每一位产品经理，看你能管到哪里…
这里提供一份相对完整的需求管理基础架构（排除第三方管理工具，仅供参考）
首先
需求侧管理：
1、需求编号：需求的编号，方便在需求池里管理检索查询需求。
2、需求涉及端口：移动端、PC端、Web端、微信小程序、支付宝生活号等。当业务复杂时，或者产品经理负责的端口较多时，这种需求管理是很高效的。
3、需求主要模块：基于端口下的模块，比如移动端下的、首页、我的、消息、发现、等。
4、需求子功能：基于主要模块下的子功能，比如消息模块，涉及系统消息、内部IM消息、评价消息等。
5、需求详情：需求真实意图描述，如果是比较简单、不复杂的小需求，直接描述要解决什么问题。如果不是小需求，则不仅需要描述要解决什么问题，还要把为什么要解决问题的原因一并记录下来。（解决问题的原因，多数情况下需要产品汪刨根问底的去问，去了解实际上用户的需求到底是什么和想解决怎样的用户需求）
6、需求来源：刚才我们已经说明了需求的几点来源，不再赘述。
7、需求类型：需求的类型每个公司都不一样，一般来说需求类型主要是记录此类需求属于哪一个类别的，主要需求类型有：新增功能、功能改进、体验提升、BUG修复等。
8、需求优先级：需求的优先级有很多种，P1、P2、P3、P4等；高、中、低等，自己能看懂就行。
9、需求版本号：需求规划的版本号，产品的最高发版权限。
技术侧协调：
PM这个词产品经理和项目经理共用，当公司没有项目经理，或者需要产品进行时间进度管理时，显然产品的责任就上了一层，产品负责人，需求的策划管理层次完成后，开始执行你的实现落地管理。
10、预期时间：预估上线的时间，这个时间对高层的领导来说很重要的，有的领导有明确的deadline，那就必须记录清楚，并执行到位。
11、PRD：产品经理开始协调交互设计师，讨论需求，进行PRD落地。
12、UI：确定PRD后，将文档同步给UI，将设计师进行输出UI设计稿。
13、SRV：后台组拿到PRD，进行数据库创建、预研实现方案等。
14、iOS： iOS和安卓都属于前端FE,管理之所以分开，是因为每个公司技术储备资源都不一样，两个前端研发进度也会有差异性，所以分开管理。
15、Andriod：同上
16、QA：进行测试验收，质控管理。
17、发布状态：预估什么时候能达到发布状态，这个预估也非常重要，一个人预估能力是否准确，也间接说明了他对产品、交互、设计、前端、后端、测试等整个团队职能的深度理解。
18、上线时间：上线前还要进行ShowCase，进行一轮生产环境测试，将相关人员拉到大会议室，进行全员找茬，很管用。上线后记录上线时间，进行时间存根留底。
运营侧协调：
运营侧的需求协调主要涉及数据、内容、和渠道发布的管理。
19、产品运营：上线前后的数据分析，及汇报，产品经理需要知道一手的数据信息，要保证数据信息渠道畅通，并协调运营分析结果，挖掘潜在的用户行为，驱动产品方向，懂技术的产品可以了解可视化数据以外的细节数据，动用结构化查询语言SQL操控数据库里的每一个死角，（产品懂技术，无疑于流氓会武术）。
20、内容运营：上线前后的内容供给，产品涉及的图片、文案、信息、案例等都需要在需求开发阶段协调内容运营资源进行整理输出，作为需求目标达成有力支撑。
21、渠道运营：渠道运营除了ASO、新增、活跃、下载，传包外，还有收集渠道侧的用户反馈，及提供渠道侧的具有参考意义的数据信息，产品上线前后需要和其了解需求方向上的信息，以便输出新的决策。
需求的管理贯穿整个团队，所以产品的需求管理不只是需求的记录，而是需求的策划、实现、效果评估都需要。每个产品经理的需求管理方式可能都不尽相同，适合自己的方法论才是最好的，但是需求管理的好坏、管理能力的强弱是一眼能看出来的，至于我们想治大国如烹小鲜，还是每时每刻被动煎熬，就要看我们的需求管理能力了，优秀在路上，慢慢培养吧…
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
