蜗牛派在系列文章产品管理流程及规范（二）——产品需求的时候，对需求层级、需求来源、需求收集做了分析，但对需求的管理及迭代规划未作进一步说明，所以本篇文章对此进一步展开分析。
需求管理
需求池
需求收集之后进入进入正式的需求池进行管理，可以按照一定的时间比如每周一次从各方收集需求，并进行初步沟通之后，放进需求池。并根据需求本身的变动，调整需求池中的相关状态，标注相关的记录，批注。
ID——需求的唯一ID号，需求身份标识，增加一个需求ID增加1
端口——需求所涉及的端口，前端如——安卓、iOS、小程序，后台——平台、供应商、商家，这里是对需求做一个初步的划分，如果涉及到多端，一般记为综合或拆分成多条子需求对应到各端口。
模块——需求所涉及到的模块，例如会员管理、用户管理、商品管理等；
需求名称——简单描述需求是做什么的；
需求描述——更详细描述需求的相关信息，例如需求提出的背景、需求要达成什么目的、需求的详细说明等；
需求来源——记录需求的来源方，例如产品、市场、运营；
类型——”记录当前需求的类型，a、新功能；b、功能优化；c、bug修复”；
优先级——记录需求的优先级，a、一般用高中低；b、数字表达；c、需求的优先级是动态的，会随着战略、业务目标的变化而调整”；
提出时间——记录需求被提出的时间；
提出人——提出这个需求的人及联系方式，有助于在需求详细设计时追踪到原始需；
状态——”需求当前的状态，根据不同的阶段，可以大致分为；
a、记录——进入需求池（初始状态）；
b、论证——需求开始评估论证；
c、待设计——论证完成后有价值并决定近期开展后续工作；
d、设计中——正在进行详细设计；
e、设计完成——原型及UI已经设计完成；
f、研发中——已正式安排研发周期；
g、已上线——需求正式上线；
h、已关闭——针对需求因各种原因提前终止其生命周期；
预计版本——对需求计划上线的版本进行规划，产品部门规划的实现版本往往会超前正在研发版本；
实际完成版本——版本上线后，更新需求实现的实际版本号；
上线时间——记录版本实际上线的日期；
备注——各种情况的补充说明，例如需求关闭的原因，需求优先级变动原因，版本规划变动；
需求优先级
需求优先级的分析可以采用KANO模型、四象限法则、权重加权三种方式进行：
KANO模型
以分析用户需求对用户满意的影响为基础，选择了两个维度：a、需求实现度；b、用户满意度。用这两个维度将需求区分，将需求分为5种，分别是：兴奋型需求、期望型需求、无差异需求、基本型需求、反向需求，针对不同类型的需求采取不同的措施。
A、兴奋型需求——也称魅力型需求，随着满足用户期望程度的增加，用户满意度也会急剧上升，但一旦得到满足，即使表现并不完善，用户表现出的满意状况则也是非常高的。反之，即使在期望不满足时，用户也不会因而表现出明显的不满意。
B、期望型需求——也称为意愿型需求。是用户的满意状况与需求的满足程度成比例关系的需求，此类需求得到满足或表现良好的话，客户满意度会显著增加，企业提供的产品和服务水平超出用户期望越多，用户的满意状况越好。比如说，支付方式，相对来说，是越多越好，这样用户会有更多选择，当没有一种支付或是其中一种没有资金的时候还有别的可供选择，能覆盖更多的用户。
C、无差异需求——不论提供与否，对用户体验无影响，比如现在各平台都有的签到，打卡功能。
D、基本型需求——也称为必备型需求、理所当然需求，是用户对企业提供的产品或服务因素的基本要求，比如现在互联网基本都有的客服功能。
E、反向需求——又称逆向型需求，指引起强烈不满的导致低水平满意的需求，比如将产品流程设计的非常复杂，引起用户反感。
四象限法则
四象限法则将需求分为：重要且紧急、重要不紧急、不重要但紧急、不重要也不紧急四类。选择的两个维度是：紧急和重要。
第一象限——这个象限包含的是一些紧急而重要的需求，这一类的需求具有时间的紧迫性和影响的重要性，无法回避也不能拖延，必须首先处理优先解决，比如支付功能出问题。
第二象限——需求不具有时间上的紧迫性，但它具有重大的影响，需要ｗｂｓ方法分解任务、提前进行规划，按照计划逐步执行，比如数据埋点统计分析
第三象限——需求大多是些琐碎的杂事，没有时间的紧迫性，没有任何的重要性，这种需求的提出本身就存在一定问题，没有考虑清楚，可能是头脑发热，也可能是看着别人有就想做，与本身产品没有任何关联性，对这类需求可以放任不管，比如后台目录的颜色美观性
第四象限——是那些紧急但不重要的需求，这些事情很紧急但并不重要，比如由于商品图片过大导致的加载慢（可以通过优化压缩上传图片解决）等，可以先采用替代方案执行
权重衡量
对需求赋予一定的指标，进行量化分析，如工作量大小、对用户价值大小，对公司价值大小、紧迫程度、与核心流程相关性，可以将各指标赋予一定的权重（所有指标项权重相加为1，各指标项确定各自的程度数值，工作量按天计算时间越大，赋值越低）进行加权，得出综合值大的，则优先级高。如下图，需求2的综合得分为6.8》需求2的综合得分5.6，先做需求2
迭代规划
固定任务
任务量固定，时间上可以进行调整，比如一个大的版本上线，新开的功能模块上线，即使采用MVP的方式，也会超出一般迭代的周期。这种方式一定是以保证业务、功能需求的完整性，系统性为主，不能完全按照时间来。否则的话，功能逻辑的完整性和链条就会缺失，上线之后会带来极坏的影响，如果功能不完整还不如不上线的好。
固定周期
当产品进入稳定期之后，业务也较为稳定顺畅，则按照固定周期进行迭代，比如两周时间上新一个版本，则以时间为准，固定时间端，按照优先级并考虑工作量合理安排需求。
紧急需求
在上一个版本发布之后，发现重大ｂｕｇ，需要紧急修复上线，这种肯定不能按照常规方式处理，直接将优先级提高，修复上线。
插入需求的处理
紧急需求与插入需求有些类似，均是常规计划之外的。但两者又有不同之处，紧急需求是不得不做的，不做将会带来严重影响的。但插入式需求是计划已经排定，但又有新的需求进来，比如业务部门，上级领导等。这个时候从几个方面进行处理：
Ａ、先不急着拒绝，先分析需求的优先级，如果需求确实优先级高，看需求规模，工作量大小，人力资源，是否能不动本次版本需求的基础上进行增加，如果可以则直接增加进去，如果不行，则将优先级低的需求进行删减。
Ｂ、需求优先级不高，则沟通安排到之后的迭代，并讲明原因
总结
本文主要对需求的层级、需求来源、需求收集方法、需求管理池、优先级的确定及需求迭代进行了分析。
