需求的生命周期：先要进行需求收集、需求分析，并且开始设计需求整理需求池；汇总完所有需求后，产品经理就要组织并主持需求评审会，主要围绕紧急程度、风险把控、开发难度、技术资源、预期效益、版本周期、预期资源等展开讨论与博弈；需求prd完成后，给到开发人员、测试人员转化需求，产品正式上线
我们可以把需求管理活动归纳为三个阶段：需求收集、需求设计、需求研发。
一、需求收集
需求来源于哪里？
按照内部和外部划分如下：
一、内部：来自业务部门（运营、售前、售后、商务、市场、客服等）、产品团队、商业分析团队-BI、用户反馈、上级高管、头脑风暴
二、外部：数据分析（python爬虫、第三方购买、自家后台）、用户研究（访谈、问卷调查、建立用户模型、A\B测试；）、竞品分析、客户方、社区论坛（如微博、知乎、七麦）、应用市场（用户评论）、政策方向
如果按照C、B、G端特点进行划分，C端是用户需求，特点是提高生活学习效率，获取有用资讯，满足生活娱乐的需求；B端是企业客户需求，特点是提高工作与沟通效率，获取用户以及精准定位用户，获取销售产品服务；G端是政府需求，特点是连接城市居民，服务城市地方人民更好的就业、发展，宣传法律政策，进行税收。
用户往往也不知道自己需要什么，产品经理在收集需求时，讲究在实践中积累、沉淀，借助头脑风暴、电话访谈、满意度调查、问卷调查、会议评审、用户行为分析等手段验证用户的真实需求，同时通过全局性感受让自己成为用户，洞察用户需求的本质；也可以通过场景化故事与用户画像等手段定性、定量化分析需求
当年广研团队的负责人张小龙要求QQMail的产品经理们每人每月要看1000条用户论坛帖,100篇网络评论文章,10个用户CE,从而打造精益求精的QQ邮箱产品。
二、需求设计
需求设计是按照需求池中需求的优先顺序进行方案设计，确定项目资源和排期。
需求价值评估与优先级排序
建立需求池模板实例：
需求状态：待排期、待开发、开发中、待测试、测试中、待上线、已完成、已废弃 需求类型：全新需求、改进需求、政策性需求（刚性）、bug需求
把控需求排期，做真正有价值的需求——我们在分析需求的价值时，首先想清楚解决了什么场景下什么角色的什么问题（需求的场景有几个要素：用户-who、时间-time、空间-where、动机-why、行为-what），同时辨别真伪需求。“伪需求”指的是当前用户并不一定需要，但是根据他们遇到问题所提出的解决方案之一，伪需求并不一定能够完全解决他们当下的问题，因为用户往往倾向于提供解决方案，而不是思考本质需求
可以从用户、商业、平台、研发等多个维度综合量化需求的投入产出比。首先，确定这个需求是刚性需求还是非刚性需求，这个需求解决了用户的什么问题，估计具体产生了什么用户价值（提升了用户体验，促进了用户增长，增加了用户黏性等）。其次，估计是否具备满足这个需求的相关资源，研发成本大概是多少，整个项目存在怎样的风险（技术风险、政策风险、法律风险等），风险是否可控。最后，估计有多少用户存在这样的需求，潜在的市场规模有多大，是高频需求还是低频需求，是否具备稀缺性等
这里可以参考一个公式（需求价值=新体验+长远价值-旧体验-替换成本-风险成本）
·技术风险：需求所开发的功能是否会影响到产品核心功能
· 运营风险：ROI不符合预期
· 政策风险：国家新政策出台是否影响到产品在大背景下的市场生存
优先级和重要性是需求池的核心，在筹备、开发、测试等阶段，高优先级和高重要性的需求都会被优先安排资源。优先级对应不同优先等级的需求组，重要性让同一优先级的需求组有了排序规则。SWOT分析、KANO模型、MoSCoW原则都是划分优先级和重要性的工具。
示例一、优先级等级划分
示例二、给同一优先级的需求排序
KANO分析模型：详解跳转知乎https://zhuanlan.zhihu.com/p/425692034
从喜欢、理所应当、无所谓、可以忍受、不喜欢等维度调研用户满意度，绘制kano模型评价结果表，分析需求合理性
马斯洛需求理论
1-衣食住行 2-具备安全机制，如财产、人身、生活安全保障 3、建立情感归属关系 4、得到社会认可，如成就、社会地位 5、实现个人理想、人生价值，如创造力、个人能力
此外，借助“四象限法则”可以将需求拆分成 重要紧急、重要不紧急、不紧急但重要、不重要不紧急四个维度
在做产品的过程中，利用用户体验五要素可以更好的理解用户以及设计产品。一、战略层：用户需求，产品目标二、范围层：功能说明，内容需求. 三、结构层：交互设计，信息框架. 四、框架层：界面设计，导航设计 五、表现层：视觉设计的体验
在产品整个生命周期中，需求往往因为某些原因需要变更：政策变革、业务形态发生变化、需求调整或者优化、产品经理前期对业务思考不足、与业务方对接需求时信息传递有偏差等，我们要管理好需求变更日志，方便查询或者追责。变更文档以表格形式记录变更原因、变更前后内容、变更时间、变更状态、项目负责人、进度情况等
为减少对业务理解不到位带来的需求变更，多查看行业内的报告，了解自身产品实际数据、运营情况，业务发展方向，从而能够更好地对业务需求进行决策。
为减少内容不明确带来的需求变更，可采取对需求反复评审，充分沟通业务规则，整理会议文档的措施，避免因需求完整性、逻辑性、合理性而产生的问题
对于临时插队或者修改的需求，要走好需求变更的流程：提交变更、审核变更、执行变更（申请通过后，产品经理要评估可能带来的风险，修改相关文件，与业务、产品、开发三方沟通一致）、关闭变更
对于可扩展性的需求，要说明具体功能未来会存在需求变动，提醒技术人员针对需求做出技术的可扩展性设计。
三、需求研发阶段
需求评审
需求评审也是需求落地的一个重要环节，闭环需求评审流程包括准备、讨论、汇总。
一、评审前准备：组织需求评审前，将需求池文档、原型、相关文档发给相关人员，通知参会时间和会议内容
二、评审中讨论：讲解需求背景、描述用户需求、介绍功能模块、讲述业务流程、演示原型、集体讨论业务规则，同时明确讨论结果、记录会议纪要、安排开发人手、预估上线时间。在评审过程中，保持中立。尽量多给出方案选项，让开发和运营去battle；少参与争论，多记录
三、评审后汇总：汇总会议纪要，将评审发现的补充完善到prd
在需求研发阶段，采用看板模式可以更直观的把控需求流转进度，并做出决策。比如，某个状态的需求看板积压太多，就要尽量不让前一个状态的需求流转状态，调查开发资源以及测试资源是否出了问题，并且找到解决方案。这里用Teambition工具来给出图示。
每一个需求卡片记载具体信息：需求名称、相关人员、需求描述、需求类型、需求优先级等
在需求管理的实际场景中，研发资源是稀缺的，然而来自四面八方各部门的需求都会被打上越快越好的标签。产品经理应对这些需求的方法是化散乱为规律，化紧急为预测。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
