网上科普有关“需求收集”话题很是火热，小编也是针对需求收集寻找了一些与之相关的一些信息进行分析，如果能碰巧解决你现在面临的问题，希望能够帮助到您。

在需求分析前需要插入一个工作环节——需求收集。进行需求分析首先要有需求来进行分析，获得需求的过程叫做需求收集。

我们做的产品，是要以解决用户的需求为基础的，若我们不深入用户，不了解用户，不听取用户的心声，不明白用户真正需要什么，而只是闭门造车，苦下功夫，结局只可能适得其反。

需求收集就是让我们听取用户和公司的心声，明白他们需要什么，想要什么，怎样让他们过得更好。同时，通过不断地收集这些信息，可以让我们的决策更加精准，也可修正我们的规划。

上面说到需求大体上有两类，用户需求和业务需求。业务需求通常是规划时确定好的内容，有时也是上级直接指派给你的要求，因此这类需求，要直接通过公司内部进行收集，收集上司的要求、收集运营和技术等队友对产品的看法和实现难度……这里着重分享用户需求的收集方式：

1.最常用的方式之一是用户反馈 一般，都会由运营兄弟通过各种方式维护与用户之间的关系，然后收集到用户在各种情况下提的建议与反馈。收集渠道通常有如下几种：

1. 产品自有反馈体系

2. 微博

?3. 微信公众号

4. 运营微信群

5. 运营QQ群

6. 贴吧

7. 知乎等

8. 客服、运营、销售

9. 应用市场评价，如app store 上面大多需要与客户维系好关系，按照重度用户、轻度用户、游客等方式对提出的建议分类。有时候身为产品有时候要化身为心机boy，通过贴吧和知乎这样的地方，想办法勾引更多的人参与话题，获得比较高水平的评价。

2.竞品分析

想要更快的明白这个行业是什么情况，多看看竞品；想要增加一些新的灵感，多看看竞品；想要让产品不至于偏离主线，多看看竞品；不想掉队，看竞品；想要发展，看竞品。虽然说了这么多看竞品，但记住，过犹不及，你毕竟不是别人，你的产品毕竟不是别人的产品，主流也并不一定会成为下一个独角兽。竞品，只是参考。

3.头脑风暴

这是非常简单却也是非常难的方式，很多人都会用，但用好，绝不是那么容易的。以拍脑门奠定基调的头脑风暴，最终必将拍碎了脑门。

头脑风暴是几个人坐一起自由联想思考事情，看似简单而没有成本，但是需要一定的操作才能做好。

1. 头脑风暴人数不能太多，越多的人会导致难以思维过于散乱，并且影响到每个人的表达，难以组织。人数大致在6、7人以内为宜。

2. 头脑风暴需要组织。没有组织，会导致思维过于散乱，而难以解决问题。头脑风暴，终究是为了寻找解决问题的办法。首先，收束方向，有方向的使劲，就像脑图一样，一层一层的寻找；同时，每一个点时间都不宜过长，否则你会浪费大量时间，每一点以3到5分钟为宜，当然还是要视情况而定。

3. 提示几句，不要对脑暴抱有太大期望；也不要抱有多给点时间万一能脑暴出来一个点子呢？脑暴时间不一定能产出好的点子，但有时脑暴会给人带来一些触动的灵感，有了脑暴的这么多想法，很有可能在日常生活和工作中就能有新点子产生。

?4.数据分析 通过内在的产品产生的用户行为数据以及外在的各种行业行为数据，通过一定的手段将其提炼出来，来优化产品。现在社会通常是用数据说话。数据分析就是一门比较难掌握的学问。

?5.定性定量分析 定量：调查问卷 定性：用户访谈、用户观察、竞品对比、圆桌会议

6.别忘了身边同事，以及老板 。

第5章项目范围管理。 - 草稿 - 草稿

一、1款产品从0到1的的，大致流程分为如下几个阶段：

立项阶段：接受需求—明确需求—市场调研—竞品分析—产品规划

需求明细、初步设计：通过市场调研、竞品分析不断分析需求—需求整理—需求评审（优先级、成本、必要性、目标KPI）-产品设计（交互沟通和意见收集、交互评审、视觉沟通和评审）—输出需求文档（考虑技术实现、各端配合、兼容）

开发测试：产品启动会—开发评估开发周期—项目经排期—测试开始写测试用例（测试根据checklist写testcase）—开发沟通（及时补充缺少的资源，协调各端）—项目验收、参与测试（体验产品、跟进测试协调bug修复）—上线（发布前制定上线策略）

运营阶段：配合运营活动，收集数据—根据意见和数据反馈优化产品（流程、界面等方面）

迭代：结合新的需求和原有的产品规划进行需求管理—产品迭代设计，新一轮产品迭代

说明：需求的挖掘存在整个流程中，只是需求方不同，需求的类型不同，方法也有多种

二、所有的步骤里都需要保持和需求方的沟通，持续碰撞需求

Step1:立项阶段

从 0到1的立项阶段特别重要，一般新产品立项的需求来自Boss，和Boss沟通基本上是在战略层的需求对接。在整个过程中利用定量的方法去确定遇到的定性需求。

? 需求方会说要做一个什么（市面上已经有的产品），然后开始描绘产品能做的事情，有什么功能，能和公司其他业务板块有什么联动。这个阶段要和需求方明确的一个共识是：要不要做。

这个时候产品经理需要考虑的是：

1、需求方最本质的需求是什么？做这产品的目的是什么？它能给我们带来什么（商业化的目标和业务化的目标）？

2、我们要服务的客户是哪些？现有客户还是新的客户？能为客户带去什么？

3、为什么做这种类型的产品？

4、我们做这个有什么优势？或者说能建立的产品壁垒在哪？

5、和现有的业务怎么配合？

6、我们有什么资源（时间、人员、用户等）？

? 带着这些疑问我会一个个去向需求方询问，去碰撞，去挖掘需求方的本质需求，我需要代入的角色有需求方、产品本身、用户。多个角度去评估这个项目成立的性价比和可行性。这个时候在决定做不做这个问题上和需求方达成共识。

? 决定做了之后，开始做 竞品分析、市场调研、用户研究 。做好这些研究后，根据研究的结果反馈去做产品定位。

? 产品定位首先要确定slogen。slogen的确定就为产品的类型、产品的方向、产品服务的人群，产品要解决的核心需求做好了一个范围。根据slogen，产品经理知道产品要做什么，不要做什么，slogen就是一个产品灵魂的文字描述。

Step2：需求明细、初步设计

范围层

先开始做产品的初步规划，前提是充分理解业务（有一个方法就是模拟用户去玩竞品）在理解业务流程的情况下去，先确定主要的任务流程，再确定子任务流程，确定好了任务流程后整理出产品的功能需求，因为在产品上走一个任务流是需要产品有对应的功能去承载的，所以每一个任务流程都对应的1到N个功能，之后做出产品的 任务流程图 、 任务级别图 和 功能结构图 ，建立了主干，还要和需求方核对一边需求。

结构层

根据任务流程确定每一个任务步骤需要的信息，做出 信息结构图 ，用于后台的搭建。

框架层

开始根据主功能的第一步开始设计 原型图 ， 功能结构图 和 信息架构图 从粗到细，大到小的去设计原型图（导航设计—信息设计—界面设计），做好原型图，写好 PRD ，开评审会（项目启动会kick-off），参加的人有UI、开发、测试、项目经理、运营。评审会过了之后。项目经理开始评估项目，排工期（UI、开发、测试），正式进入开发阶段

Step3（开发测试）：产品启动会—开发评估开发周期—项目经理排期—测试开始写测试用例—开发沟通—项目验收、参与测试—上线

表现层

? 项目启动会之后，最先是UI排期，这里就开始进入产品表现层的大部分设计了。 产品需要和UI保持积极的沟通 ，在整个表现层的设计中，UI会提出自己关于信息元素排列和交互的建议，一般产品都是根据用户使用场景去分析，还有就是遵循一般的设计原则，例如：亲密、对齐、重复、对比原则；删除、组织、隐藏、转移策略等。因为这些原则和策略是用户的在不断的使用中积累提炼出来的习惯。至少遵守这些规律不会犯错，不会挑战客户。

项目经理排好工期后，就开始进入开发阶段了，这个时候产品需要做的最主要的三件事情是， 和开发保持沟通 ，做好信息同步； 准备下一个版本的需求 ； 和运营对接 ，看怎么做运营活动，增加产品的数据指标。

在0到1的过程设计中，比较重要的是要建立产品多维度的 一致性 规范，为之后打下基调，一致性的地方包括：

1、视觉一致性：颜色（主色调、辅助色、点缀色、字体颜色），风格（扁平、投影、拟物等），属性（字体、图标、）

2、行为一致性：操作（删除、滑动、点击、下滑刷新、动作、动画表现），操作系统（ios、安卓、PC网站、相关的兄弟应用）

3、感知一致性：交互位置（确定、取消按钮、保存、相同操作的按钮在相似的位置），文本（提示语、操作提示、功能按钮、编辑提示）

这些细节整体性的影响到了用户体验、产品的调性和扩展兼容性，所以在第一版就要做好坚实的基础。另外，就是建立信息推送机制、版本更新机制、最基础的数据埋点，这些都需要在第一版确定好。

? 关于推送信息，最基本的是 更新的推送 ，还有就是根据实际业务进行的 活动推送 。

? 关于版本更新的机制，版本制定的规则是：大小版本穿插，大版本增加新功能新需求的版本，会强制升级，小版本是针对目前已有功能的优化版本，选择升级。所以相邻的两个版本不会有太大影响，实际情况会根据计划和当时的情况进行调整。

? 最基础的数据指标：才开始是用第三方的数据统计，从基本的数据情况、用户趋势、渠道分析、留存分析都有。在做运营活动时 ，根据不同的需求再做不一样的数据统计。 一致性的设计、推送机制、更新机制、基础数据的统计是第一版需要建立好的。

?从0到1整个产品的流程大概就是如上的过程，完整走完一款0-1产品会考验产品的各方面能力，非常锻炼产品的基本功。欢迎大家评论区一起讨论学习，共同进步。

项目范围管理包括确保项目做截止的所需，全部工作已成功完成项目的各个过程项目管理范围，主要有待于定义和控制哪些工作？应该包括哪些项目？哪些不应该包括在项目内。项目范围管理过程包括。

5.1规划范围管理? 为记录如何定义确认和控制项目范围及产品战略，而创建范围管理计划的过程。

5.2收集需求。为实现项目目标而确定记录并管理相关方的需要和需求的过程。

5.3定义范围 制定项目和产品详细描述的过程。

5.4创建WPS，将项目交付成果和项目分解为较小的，更易于管理的组件的过程。

5.5确认范围。正式验收已造成的项目和交付成果的过程。

5.6控制范围，监督项目和产品范围的动态管理范围基准变更的过程。

项目管理的核心概念。

产品范围。某项产品服务或成果所具有的特征和功能。项目范围有时也包括产品范围。

从预测型方法都是隐形方法或敏捷方法，下面这些可以处于连续区间内的任何位置，在原则性生命周期中，在项目开始时对对橡木可交付成果进行定义，对任何范围变化都要进行渐进管理，而在适应性或面解决生命周期中通过多次迭代来开发可交付成果，并在每次迭代开始时定义和批准详细的范围。

采用适应性生命周期指代对应，对大量变更需要相关方持续参与项目，因此应对适应性项目的整体范围分解为一系列，你实现需求合理执行工作，有在一个迭代开始时，团队将努力确定产品未完成项中，哪些最优先项下一代中交付，在每次迭代中都会重复开展三个过程收集需求定义范围和创建WPS相反，在预测性项目中，这些过程在项目开始时开展，并在必要时通过实施整体控制过程进行更新。

在预测型项目中，经过批准的项目范围说明书工作分解结构和相应的工作分解词典构成项目基准范围，只有通过正式变更控制程序才能进行基准变更，待开展确认范围，控制范围及其其他控制过程时，基准被用作比较的基础，而采用适应型生命周期项目的使用未完成项，包括用户需求和用户故事反映当前需求。

项目范围完成情况是根据项目管理计划来衡量产品范围完成情况，根据产品需求来衡量，在这里需求指特定协议或其他强制性规范产品服务或成果所必须的条件和能力。

确认范围是正式验收已完成的项目和交付成果的过程，从控制质量过程运出的核实可交付成果是确认范围，过程输入而验收可交付成果是确认范围过程输出之一，有获得授权的相关方正式签字批准。

项目范围管理的发展趋势和新兴实践。

组织开始认到如何用于商业分析通过定义管理和控制需求活动来提高竞争优势商业活动分析，可在项目启动和项目经理任命之前就开始根据需求管理实践指南，需求管理过程中需要评估而需要评估，有可能始于橡木组合规划项目及规划和单个项目。

需求管理过程结束于需求关闭，把产品服务和成果移交给接受方，以便长期测量监控实现维持利益。

项目经理与商业分析师之间应该是伙伴是合作关系。

对于需求不断变化，风险大或不确定性高的项目，在项目开始通常无法明确判断项目范围，而需要在项目期间逐渐明确明确方法，特意在项目早期拓展定义和协商范围时间并未持续探索和明确范围而延长，创建相应过程时间。

5.1规划范围管理。

规划范围管理是为记录如何定义确认和控制项目范围及产品范围，而创建范围管理计划的过程等过程的主要作用在项目期间如何管理范围提供指南和方向，本过程仅开展一次或仅在项目预定展点开展。

范围管理计划是项目或项目信息管理计划的组成部分，描述将如何定义，指定监督控制和确定项目范围。

5.1.1项目规划范围管理输入。

项目章程记录项目目的项目描述，假设条件制约因素以及项目意图实现的高层级需求。

5.1.2规划范围管理，工具技术。

5.1.2.2数据分析。

适用于本过程数据分析技术，包括备选方案分析，本技术用于评估收集需求，详细项目和产品范围，创造产品确认范围和控制范围的各种方法。

5.1.2.3会议。

项目团队可以参加项目会议来制定范围管理计划。

5.1.3规划范围管理。输出。

5.1.3.1范围管理计划。

范围管理计划是项目管理计划的组成部分，描述将如何定义，制定监督控制和确认项目范围。范围管理计划要对将用于下列工作的管理过程作出决定。

制定项目范围说明书。

确定如何审批和维护范围基准。

正式验收已完成的项目和交付成果。

5.1.3.2需求管理计划。

需求管理计划是项目管理计划的组成部分，描述将如何分析记录和管理项目和产品需求根据从业者商业分析实践指南。有一些组织称之为商业分析计划。

5.2收集需求。

收集需求是为了实现目标而确定记录并管理相关方的需要和需求的过程。本过程主要作用是为了定义产品范围和项目范围奠定基础，仅开展一次或近待项目预定点开展。

收集需求。

输入。1.项目章程，2.项目管理计划。范围管理计划，需求管理计划，相关方参与计划。三项目文件。假设日志，经验教训登记册，相关方登记册。4，商业文件 商业论证。5协议。6，事业环境因素。7组织过程资产。

5.1.3项目文件。

经验教训登记册。经验教训登记册提供了有效的需求收集技术，有提升，对使用迭代性和适应性产品开发方法的项目。

相关方登记册，相关方登记册，用于了解哪些相关方，能够提供需求方面信息及记录相关方对项目需求和期望。

5.2.1.4商业文件。商业文件会影响收集需求过程是商业论证，它描述了为满足业务需要而达到的必要期望和可选标准。

5.2.2.2数据收集。

头脑风暴。头脑风暴是一种用来产生和收集对项目需求与产品需求的多种创新技术。

访谈是通过相关方直接交谈来获取正式或非正式的方法，访谈的典型做法是向被访者提出预设提醒的问题，并记录他们的回答，访谈是一个访谈者和被访谈者之间的1对1的谈话，但也可以包括多个访谈者和多个被访者。访谈有经验的项目参与者，发起人和其他高管以及主题专家，有助于识别和定义所需产品可交付成果特征和功能。访谈也可以用于获取机密信息。

焦点小组。焦点小组是召集预定相关方和主题专家，了解他们对所讨论的产品服务和或成果期望的态度，有一位。训练的主持人引导大家进行互动式讨论，焦点小组往往比1对1的访谈更热烈。

问卷调查。问卷调查是指涉及一系列书面问题，向众多受访者快速收集信息，问卷调查方法最适用于以下情况。受众多样化，需要快速完成调查。受访者地理位置分散，并且适合开展统计分析。

标杆对照。彪悍对照将是集合计划产品过程和时间与其他科比组织的时间进行比较，以辨识别对家时间形成改进意见，并为绩效考核提供依据，标杆对照所采用的可比组织，可以是内部，也可以是外部的。

数据分析。可用于本过程数据分析技术，包括文件分析文件分析，包括审核和评估任何相关文件的信息。

5.2.2.4决策。

投票。投票是一种未达成某种期望结果，而对多个未来行动方案进行评估，具体决策技术的过程，本技术用于生成归类和排序产品需求，投票示例包括。

一致同意? 每个人都同意某个行动方案。

大多数同意 获得群体中超过50%人员的支持就能做出决策。把参与决策的小组人数作为基数，可防止因平局而无法达成决策。

相对多数同意。根据群体中相对多数人的意见，多数角色即便未能获得大多数人的知识，通常在候选项超过两个时使用。

独裁性决策制定。采用这种方法，将由一个人负责整个集体制定决策。

多标准决策分析。该技术接触决策矩阵，用系统分析方法建立诸如风险水平不确定性和价值收益的多种标准，你对中国创意进行评估和排序。

5.2.2.5数据表现。

亲和图 用来对大量创意进行分组技术，以便进一步审查和分析。

思维导图。把头脑风暴中获得了创意，整合成一张图，用于反映创意之间的共性与差异，激发新创意。

5.2.2.6人际关系团队技能。

名义小组技术。名义小组技术用于促进头脑风暴的一种技术动作，通过投票排列最有用的创意一遍，进一步开展头脑风暴或优先排序。

观察和访谈。观察和交谈是指直接查看个人在各自环境中如何执行工作或实施流程。当产品使用者难以或不愿清晰说明他们需求时，就特别需要通过观察来了解他们的工作细节，观察也称为工作跟随身边通常由膨胀观察员或者观察业务专家如何执行工作，但可以由参与观察者来观察，通过实际执行一个流程或程序来体验该流程或程序是如何实施的，以便挖掘隐藏的需求。

引导。引导与主题研讨会结合使用，把主要相关方召集在一起，定义产品需求研讨会，可用于快速定义跨职能需求，并协调相关方的需求差异，因为具有群体活动的特点，有效引导引导，会有助于参与者之间的建立，信任感情关系改善沟通从而有利于相关方达成一致意见。

联合应用设计或开发JAD。这一例会议是由于软件开发行业这种研讨会注重把业务主题专家和开发团队集中在一起，以收集需求和改进软件开发过程。

质量功能展开。制造业采用qfd这种引导技术来帮助客户确定新产品的关键特征，qfd从收集客户需求需要开始，然后客观对这些需要进行分类和排序，并为实现这些需要而设定目标。

用户故事。用户故事是对所需功能的简短的文字的描述，经常产生于需求研讨会，用户故事描述哪个相关方将从功能中收益它需要实现什么目标，以及他期望获得什么利益。

5.2.2.7系统交互图。

系统交互组织范围模型的一个例子，它是对产品范围的可视化描绘显示业务系统及其与人和其他系统之间的交互方式，系统交互方式显示了业务系统的输入，输入提供者，业务系统输出和输出接收者。

5.2.2.8原型法。

全球化知识渐渐明晰的理念，需要从经历从模型创建用户体验反馈收集到原型修改的反复循环的过程，在经过度过的反馈循环之后，就可以通过应用法获得足够的需求信息，从而进入设计或制造阶段

故事板是一种原型技术。通过一系列图像或图示来展示顺序或导航路径故事，本用于各种行业的各种项目注入，**广告教学设计，以及敏捷和其他软件开发项目，在软件开发中估值来使用实体模型来展示网页屏幕或其他用户界面的导航路径。

5.2.3收集需求输出。

5.2.3.1需求文件。

需求文件描述各种单一需求将如何满足与项目相关业务需求，一开始可能只有高层企业需求，然后随着有关需求信息增加而逐步细化，只有明确的可跟踪的完整的相互协调，而主要相关方愿意认可需求，才能作为基准

需求文件的格式是多种多样，既可以是一份按照相关方和优先级分类列出全部需求的简单文件，也可以是一种包括内容提要，信息描述和附件等的详细文件。

业务需求，整个组织高峰期需要例如解决业务问题或抓住业务机会以及实施项目的原因。

质量需求用于确认项目和交付成果的，成功完成或其他项目需求的实现的任何条件或标准，例如测试认证确认的。

5.2.3.2需求跟踪矩阵。

需求跟踪矩阵，把产品需求从其来源连接到能满足需求和交付成果的一种表格式，使用需求跟踪理论，把每个需求与业务目标或项目目标联系起来，有助于确认每个需求都具有商业价值需求跟踪矩阵提供的，在整个项目生命周期中跟踪需求的一种方法，也可以确保需求文件中被批准的每一项需求在项目结束的时候都能交付，最后。需求跟踪矩阵还为管理产品范围变更提供的框架。

应在需求跟踪矩阵中记录每个需求的相关属性，这些属性这些属性有助于明确每个需求的关键信息，需求跟踪矩阵中进入典型的属性，包括唯一标识需求的文字描述，收入该需求的理由所有者来源优先，级别，版本，当前状态。为确保相关方满意，可能需要增加一些属性如稳定性复杂性验收标准。

关于“需求收集”这个话题的介绍，今天小编就给大家分享完了，如果对你有所帮助请保持对本站的关注！