需求管理 | 避免瞎忙，先把需求管好
需求管理的时间占了产品日常工作的32%，是每个产品经理必备的工作内容之一，将业务部门的需求清单于内部的需求列表进行比对管理，因此总结了一下小团队多而杂的需求来如何管理。
首先需要一个收集需求的管理池—需求池
一般通过需求列表对所有需求进行统一记录管理
通常需求列表包括：提出人、提出时间、所属模块、需求描述、需求分类、需求优先级、状态、责任人、项目名称给、开发量、计划开始时间、发布时间、进度、备注等，随便找了一张图贴上。
提交人：即需求的原始提出者，有疑惑时便于追溯
提交时间：原始需求的获得时间，辅 一致性的需求描述
分类：新增功能、功能改进、体验提升、Bug修复、内部需求等
优先级：需求的紧急重要程度
状态：需求生命周期：待讨论、暂缓、拒绝、需求中、开发中、已发布
项目名称:需求的发布项目
开发量:需求的开发工作量，表征实现难度
计划开始时间:开始开发时间
发布时间:计划发布时间
进度:当前需求进度
备注：其它任何信息，如：1.被拒绝的理由2.被暂缓的理由和重启条件3.其它相关文档……
需求那么多，我们应该先从哪个下手？
如何判定需求的优先级——KANO模型
基本型需求：满足用户“刚需”的产品功能。
期望型需求：不是“必须有”的产品属性，但是用户希望得到的。这类需求在产品中实现的越多，用户就越满意。
兴奋型需求：使用户产生惊喜的需求。当产品提供了这类需求中的服务时，用户就会对产品非常满意，这类需求可以为产品增加额外价格。
通过这种分类方法，讲需求大概分了三个级别，所以我们就可以排优先级啦，当然，如果老板提需求了，那么这些需求再怎么优先都是往后靠，虽然我们都有产品人的职业素养，但是工资是老板发的，听老板的。
如何提交需求
1、项目型需求
提交这类需求需说明：
业务背景&价值（为什么要做）：让其他产品同学明白业务价值以协调资源优先级
业务目标（可量化数字目标）：使项目有关部门的同学有统一目标。如果某业务线多次上线的活动都不能达到目标，那该条业务线后续再提交的需求优先级自然不高，而且更容易被挑战。
系统的概述：描述系统要实现的业务功能。可以通过环境图的方式描述用户、本系统、其它业务系统之间的交互关系。
落地方案（如何做）：产品设计需基于完整的落地实施方案，每个系统功能模块，以考虑到每一个实现细节逻辑和异常情况。
2、日常优化需求
产品小功能迭代或者体验优化
一般这种需求被提出的姿势都是：小陈，要把页面结构改一下，要加几个按钮神马的，这时候，我就会很郁闷——那还找我干嘛，你直接去找程序猿得了。
但是我们更应该耐心的挖掘解决方案背后的那个问题（或者更专业的，我们叫做用户需求）。然后，由我们亲自来做把用户的需求转化为产品功能这件事，这才是我们的核心职责（而不是细化功能这种事，没错，我指的是写PRD什么的）。
提交这类需求需说明：
目标用户：这件事，是为谁而做的，一旦运营开始从这里起步思考，就可以自己排除掉很多需求了；
问题描述：目标用户碰到的痛点，只说“何时/何地，怎么难受”即可；
改进建议：建议如何优化
严重程度：对问题严重程度的判断，“高/中/低”即可，具体的判断方法，可以根据用户重要程度（这个比较主观，需要团队一起讨论达成共识，我们的产品是为哪几类用户服务的，他们的优先级排序是什么，这是产品原则的关键内容），问题出现的次数、频率等因素（相对客观，比较好办）考虑；
现有方案：现在是如何解决此问题的，我会认为，一个值得解决的问题，通常已经有人着手解决了，所以也一定已经有一些解决方案，而没有现有方案的问题，通常不严重；
解决方案：建议的产品改进方案，可以以原型或者简单文档的形式，甚至可以口头说明，如果你不怕和开发撕逼的话。
如何跟需求方对接需求
需求方同学的需求提交上来之后自然需要得到明确的反馈，于是定期的需求对接会就很有必要了，需求对接会的主要内容包括：
针对提交的需求内容进行当面沟通确认，再确认，避免撕逼
我需要将每个需求的评估结果反馈、进展、预期上线时间等同步给需求方
上线之前，我要将已经在测试环境准备好的功能邀请需求方事前体验
我把已经上线的产品后台使用说明、前台逻辑说明等，同步给需求方
需求管理是每个产品狗的必修课，特别是需求方较多时，比如销售、财务、采销、仓库...巴拉巴拉，协调好各部门，才好按期完成每项需求，保证业务顺利进行。