需求收集、分析_需求收集模板

什么是需求
需求定义
满足需求的三种方式
需求的核心
需求收集
需求来源
内部
外部
需求收集步骤
需求分析与管理
需求分析
什么是需求分析
如何挖掘用户真实需求
需求管理
需求优先级
需求池
需求筛选
需求打包
商业需求文档(BRD)
项目立项
需求设计
RPD文档设计
产品Demo、(原型设计)
PRD文档、原型评审
设计评审(概设、详设)
测试用例评审
开发
测试
上线发布
复盘总结
扫码关注，深入了解
每个产品经理都需要经历产品0 ~ 1和1 ~ 100的过程，所以小编就结合自身的理解整理总结一个产品从0 ~ 1的完整流程。0~1的流程为：
需求收集–>需求分析与管理–>需求筛选–>项目立项–>需求设计–>需求评审–>开发–>测试–>上线–>项目总结

什么是需求
需求定义
需求就是实现与理想存在差距，人们想弥补差距从而产生了需求。

满足需求的三种方式
需求是源于实现与理想的差距，所以减小这个差距由三种方式：

改变现状。是我们最常用的，去开发某种产品，但也是最笨的办法
降低理想。把人们的预期打压降低，比如我们常说的“打个预防针”、“丑话说在前头”
转移需求。因为人类的注意力有限，所以引导用户关注其他事务，就会觉得差距没有那么大。人的行为是需求驱动的，想改变人的行为，就要寻找更强烈的需求展示给他，而让他不在纠结原来的需求。
需求的核心
由用户才有需求，用户才是需求的根本。所以我们需求要以用户为中心，但是也不能全听用户，因为可能用户的需求并不是他真的想要的，所以我们要去发掘分析用户背后的真实需求。“以用户为中心，分析挖掘用户真实需求，用户需求转化成产品需求”。

需求收集
需求收集是一个产品从0到1的一个开端。需求经常会是以很零散的方式展示在我们面前，比如老板某一天忽然跟你说想搞一个充电桩小程序，就一句话，剩下自己去研究。所以面对这些情况，我们就需要从各方面进行需求收集。

需求来源
内部
产品自身问题：比如bug、体验优化、性能优化、逻辑调正
内部人员需求：比如老板需求、市场销售同事需求
头脑风暴：就是一群人在一起瞎想
数据分析：对产品数据进行数据分析，然后整理出来需求
外部
市场分析：市场环境引起的需求，市场调研分析，一般会产出市场分析报告
竞品分析：分析竞品优劣势，取长补短
用户需求：用户提出的需求、用户反馈以及对用户研究
需求收集步骤
明确目标 --> 选择采集方式 --> 制定采集计划 --> 执行采集 --> 资料整理。

明确目标：明确为什么要收集需求，是为了解决什么问题，范围是多少。只有明确的目标，才能有效的执行，方向才不会错。

选择采集方式：有用户访谈、调查问卷、竞品分析、市场分析、用户分析、数据分析等方式，可以使用四象限法来定义我们的采集方式。

制定采集计划：计划明确目标目的、明确访问的内容等等

执行采集：在采集过程中我们要注意：

避免一组固定的问题：固定的问题会让被访者产生被审问的感觉，我们应该准备好问题清单，但清单只起一个引导作用，并不用照着读。首先关注目标，任务其次：比用户行为更重要的是行为背后的原因，多问问用户为什么这么做。
避免让用户成为设计师：听用户说，但不要照着做，用户的解决方案通常短浅、片面。
避免讨论技术：特别是碰到一些略懂技术的用户，不要与其纠缠产品的实现方式
鼓励讲故事：故事是最好的帮助设计师理解用户的方法。
避免诱导性的问题：典型的诱导问题是“如果有××功能，你会使用么？”一般来说用户会给出毫无意义的肯定答复。
资料整理：在采集过程中我们可以使用单项需求卡片来收集，单项需求卡片模板

ps: 在采集中，不一定按照模板来执行，可以灵活变动。

需求分析与管理
当我们完成了需求收集之后，此时的需求还是比较混乱的，很多需求都是表面需求，需要我们通过需求分析挖掘真实的需求，并且对需求进行规划管理，纳入需求池，方便管理，这就第二步需求分析与管理。

需求分析
什么是需求分析
用户需求：用户自以为的需求，并且经常表达为用户的解决方案。
产品需求：经过我们的分析，找到真实的需求，并且表达产品的解决方案
需求分析：从用户提出的需求出发，找到用户内心真正的渴望，再转化为产品需求的过程。
如何挖掘用户真实需求
马斯洛需求理论

需求管理
需求优先级

定义需求优先级的好处在于确定那些需求比较重要，那些需求先做。集中力量办大事。需求优先级判定，可以依照下面几个公式即可：

需求优先级 = 需求价值 / 成本
需求价值 = 用户价值 * （公司价值 + 战略契合度 + 老板意志）
成本 = 开发周期 + 技术风险 + 政策风险
优先级等级：高、中、低
需求优先级评估模板

用户价值：可以从需求重要程度、紧急程度、持续时间三个维度来分析。
重要性：可以参考时间管理里“重要与紧急”的概念。这里的重要度又可细分为：满足后“一般”到“非常高兴”；未实现“略感遗憾”到“非常懊恼”，更多可以学习 KANO 模型加深理解。
紧急度：在时间维度上判断这个需求是否迫切，紧急不重要的需求通常表现为解决了短期的问题，如果熬过去没做，对长期影响不大；或者解决了局部的问题，如果不做对于大多数用户没有影响。比如某个用户是大老板的朋友，通过大老板“天外飞仙”地提过来一个需求，就很可能是一个超级紧急的需求，但重要性未必很高
持续时间：需求是有生命的，有的长寿有的短寿，比如迎合过年过节的运营活动需求，一般就比较短寿。试想8月我们录入了一个庆国庆的主题运营活动，如果到了9月底还没资源做，那一年内也就不用再考虑这个需求了。
所以总结规律如下：
重要且紧急>重要不紧急>紧急不重要>不紧急不重要
KANO模型把需求分为基本需求、期望需求、魅力需求、无差异需求、反向需求。

基本需求：用户使用你产品想要解决的核心需求，也是产品的必备功能，如果没有该功能，用户会极度不满，甚至放弃你的产品；即使有了该功能，用户也认为是理所应当的，用户不会因此对你的产品满意度增加，比如微信的聊天功能。
期望需求：用户的痒点，产品满足了这类需求，用户满意度会因此增加，也可以成为自己产品的竞争优势；此类需求得不到满足或表现不好的话，客户的不满也会增加。
兴奋需求：用户自己都没想到的需求，产品拥有此功能，即便表现的并不完善或完美，用户满意度也急剧提升；即便没有此功能，用户也并不会对产品对满意度降低。
无差异需求：用户感觉无所谓的需求，不管产品提供与否，用户的满意度都不会因此变化；虽然用户满意度不会变化，但是过多的无差异需求，浪费公司资源，使产品变的臃肿，因此也最好不要去做。
反向需求：该类需求提供对应的功能后，用户会对产品的满意度降低；比如前一段时间钉钉的“在家上课”功能，对于我们祖国的花朵来说，这就是一个反向需求，因此他们才会在应用商店怒刷一星。

需求池
需求池是用于管理需求的变更记录，让我们能清晰知道需求的进度情况。下面是需求池模板：

需求属性    属性说明
编号    需求的顺序号，唯一性标识
提交人(*)    需求的录入 PD，负责解释需求
提交时间    需求的录入时间，辅助信息
模块(*)    根据产品的模块划分
名称(*)    用简洁的短语描述需求
描述(*)    需求描述：无歧义、完整性、一致性、可测试等
提出者    即需求的原始提出者，有疑惑时便于追溯
提出时间    原始需求的获得时间，辅助信息
Bug 编号    将一些 Bug 视为需求，统一管理
分类    新增功能、功能改进、体验提升、Bug 修复、内部需求等
层次    基础、扩展（期望需求）、增值（兴奋需求）
开发量(*)    需求的开发工作量，表征实现难度，单位人/天
状态(*)    需求状态。待评审、待开发、开发中、待测试、测试中、待上线、已上线、遗留、丢弃、待确认
需求优先级(*)    需求的优先级。高、中、低
编号：看似作用不大，最初表格中没有这一项，但有一次大家把列表打印出来讨论，当提到某个需求的时候，发现很难告诉大家是哪个，因为 Excel的行号没有一并打印出来，所以后来我们都把序号加上了，作为需求的唯一性标识。有时候在某个需求的备注里，也会写“与 273 号需求类似，可以参考”。
提交人：必填，提交人是 PD，我们的需求管理方法比较轻量级，更多的是只管理产品需求，而用户需求并没有很好的整理，经常只是一堆各种格式的文档，所以提交人要负责在今后的任何时候解释这个需求的来源，提交人有义务充分理解原始的用户需求。
提交时间：这是一个辅助信息，记录提交人是何时录入这个需求的。模块：一般来说，根据人类记忆的特点，产品有 5±2 个模块比较合理，如果超过7 个，你就要考虑重新划分，甚至增加一个基本属性叫“二级模块”。
名称：用简洁的短语描述需求，要给用户提供什么功能，比如：黑名单。
描述：这里可以具体解释一下名称里说的功能是什么意思，比如：用户可以选择联系人并加入黑名单，或者将某联系人移出黑名单，在黑名单里的联系人无法给用户发消息。描述只要说此功能要做什么，无须解释怎么做，注意语言的无歧义性、完整性、一致性和可测试性等
提出者：即用户需求的提出者，有疑惑时便于更进一步追溯。
提出时间：原始需求的提出时间，区别于提交时间，这是个辅助信息。
Bug 编号：可选，这是因为我们把产品的某些 Bug 也视为需求，所以加入这个表格统一管理。
分类：可以分为“新增功能、功能改进、体验提升、Bug 修复、内部需求”等。其实产品需求远非我们直接可以想到的功能需求，还包括了很多非功能需求，比如：性能、可培训、可维护、可扩展……有很多需求不是为终端用户做的，而是为销售、服务、测试团队的同学做的。
开发量：必填，需求的开发工作量，单位为人/天。通常是技术经理，或者系统分析师、架构师。
状态：必填， 需求状态
需求优先级：必填，需求的优先级
需求筛选
在工作中，往往都是资源有限的，尽可能抢占资源，所以对需求要进行筛选。

需求打包
将类似的功能点打包，通过业务逻辑图的方式可视化，可以更直观地给别人讲解

明确功能互相之间有依赖关系。那些只能先做的功能，应该在产品需求列表里注明；功能与人力资源之间的依赖关系也会经常存在，比如有些功能只能由团队里的特定成员来做。在这里评估工作量的时候不会考虑“谁来做”的问题，在正式立项以后，组建团队的时候会重点考虑，当然长期来说，为了避免这类风险，提
升与平衡团队成员的能力是王道。

需求的粒度尽可能小。商业价值很高的功能，如果细分的话，我们会发现其中也有价值相对低的部分，所以需求的粒度应该尽量细，前提是细化引起的管理成本上升在可接受的范围内，给个生活中的例子帮助理解：大开间办公区域里的灯，不可能用一个开关控制，也不可能每一个开关只控制一盏灯。具体细到多少，要根据具体情况具体分析。我们的经验是，在需求列表里出现的任意一行，工作量最好不要超过“5 人天”。

商业需求文档(BRD)
BRD: Business Requirements Document,商业需求文档。这是产品生命周期中最早的文档,其内容涉及市场分析、销售策略、盈利预测等,通常是给大老板们演示
的PPT,也就比较短小精炼,没有产品细节,有点像创业者给投资人看的商业计划,主要为了获得认可,争取资源。
BRD包含内容：

项目背景：我们在哪里？为什么要做这个项目，解决什么问题，可以列出一些数据说明项目的必要性。
商业价值：我们去哪里？最关键的重点！大老板们最感兴趣的，做了这个项目以后有什么价值，一定要说在点子上。一般我们还会预测一下相关数字的变化，提出这个项目的商业目标。
功能需求描述：我们怎么去？通过做哪些事情来达到目标，把打好包的需求描述一下，可以用功能列表的形式表达，但最好能画出业务逻辑关系。当然我们也经常会搞点技巧性的东西，比如故意加入一些让老板砍的需求，希望老板砍完之后心有愧疚不好意思再砍我们真正想做的东西，这有点类似谈判技巧里的玩意，大家可以试试，但不要在这上面太花心思了。
非功能需求描述：提一下重要的非功能需求，如果有的话。
资源评估：第二个重点！大老板们要看成本，他们在了解达成项目的目标需要多大的花费以后，才能做出决策。
风险和对策：有的项目会有一些潜在风险，这个时候不妨抛给老板们看一下，并且给出自己的对策，说不定你觉得是很大的麻烦，在老板那里一句话就可以搞定。而且由于信息的不对称，我们无法了解某些功能是否会与公司将来的战略冲突，这时候提出来也是让老板们把一下关
项目立项
当我们确定了需求之后，于是就踏上了新的征程，一切都从项目立项(kick off)开始。项目立项的用途就是号召大家，告诉所有人要开始干活了。也是一场“誓师大会”

项目立项的工作内容：项目背景、项目意义、目的和目标、需求、功能点概述、项目架构（人员分配）、项目计划、沟通计划

项目背景：说明为什么做这个项目
项目意义、目的和目标：做项目之后的美景，以及解决什么或达成什么算成功
需求、功能点概述：大概说一下有什么需求
项目架构（人员分配）：描述人员的分配
项目计划：项目的时间节点和里程碑；各个阶段资源的安排与分配
沟通计划：明确沟通的要求
需求设计
RPD文档设计
PRD: Product Requirements Document,产品需求文档。PRD是对产品功能的进一步细化,是PD新人写得最多的文档,也就是我说的“需求开发”过程。文档主要
包含整体说明、用例文档、产品Demo等,会对产品功能做具体描述。

修订历史:写清楚每次修订的日期、版本号、说明和作者,便于以后追溯
项目概述:简单描述项目的背景、意义、目的、目标等,描述业务领域知识,让文档读者明白这个项目是为什么而做,这部分内容可以参考KckO会议所用PPT里面的内容。如果此PRD没有包含项目全部需求的话,也应做相应说明这部分需求是什么,其他需求在哪里等
功能范围:给出本PRD的业务逻辑图,重点描述系统中角色的职责、与周边系统的关系、全局的商业规则等
用户范围:对本PRD涉及的角色、系统做出简单的说明
词汇表:对本PRD涉及的专有词汇、术语、缩写等做出说明
非功能需求:如性能需求、数据监控的需求等。我们公司曾要求过针对毎个新功能设置监控点,并且在功能上线两周后,由PD给出数据分析报告,以验证是否达到预期的商业目标,从而不断改善前期判断的准确度。
其他说明:其他任何需要说明的内容都可以写在这里
总体说明之后是用例文档部分,首先需要对这个PRD中所有的用例来个说明,给用例的可视化表示,说明各个用例之间的关系,一般有类图、用例图、状态图几种
表示方法,其中用例图最为关键。
产品Demo、(原型设计)
使用axure画的原因一般有草图、低保真、高保真，具体看每个公司的要求

PRD文档、原型评审
于需求的相应部分完成以后进行,评审会上PD把PRD和UC说给开发、测试听,Demo评审则由UE的同学主讲。一般我们会在做出比较大粒度的PRD之后马上安排一次评审,当然也会有UC和Demo的半成品,以期尽早发现问题,比如业务规则的不合理,产品界面太丑陋,某功能技术上无法实现,等等。PRD评审会重点关注偏商业的内容,强烈建议叫上老板营销人员、服务人员,甚至用户一起来听。

设计评审(概设、详设)
是在概要设计与详细设计完成之后进行,由开发工程师把对需求的理解以设计文档的形式说给PD、测试听。

测试用例评审
测试评审,俗称T℃评审,是在T℃编写完成,测试开始执行之前进行,由测试工程师把对需求的理解以TC的形式说给PD、开发听。

开发
开发阶段的工作内容：设计 --> 评审 --> 编码 --> 单元测试

测试
测试阶段的工作内容：测试用例、评审、冒烟测试、功能测试、集成测试、回归测试

上线发布
上线发布的工作内容：上线评审、预发布、发布、线上验证

复盘总结
项目上线之后，我们需要及时对项目进行复盘，小结一下做这个项目的心得体会,比如碰到了哪些问题,原因是什么,怎么解决的,如何避免再犯;项目的资源评估是否合理,收获了哪些经验,如何提高准确度;根据数据监控的反馈,分析出了什么结果,项目的商业目标是否达到,等等。
————————————————
版权声明：本文为CSDN博主「JIEAD」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_39280536/article/details/120753668