需求管理方法论.docx

需求管理方法论.docx

《需求管理方法论.docx》由会员分享，可在线阅读，更多相关《需求管理方法论.docx（10页珍藏版）》请在冰豆网上搜索。

需求管理方法论

需求管理方法论

1需求管理的理解

一个方针：

做对的事情远比把事情做对更重要。

三个方向：

业务需求、用户需求、产品需求

最终目标：

挖掘需求本质，作出选择

在做需求管理之前需要对产品概念要有一定的理解与铺垫：

形成产品概念明确产品定位，

关注核心用户，聚焦典型场景，抓住刚性需求，点出竞争优势，做到一句话的解决方案。

以人为本将设计思维贯穿在整个需求管理。

2需求管理内容

需求管理要贯穿产品设计的始终，在管理过程中需要从初期考虑需求管理的完整周期，即初期确定需求，对需求进行采集与记录、中期评估需求，对需求进行分析与规划并给需求进行优先级排序、以及后期对需求的实现、追踪与验证。

需求管理的每个阶段都应该有相应的任务和产出物。

在第一阶段需求采集阶段我们需要尽可能的全面获取用户的需求，并且要有需求列表的产出；在第二阶段需求分析阶段我们要形成需求分析池，并且要对需求列表中的需求进行详细定义，在这一步就要求产出的文件要求需求列表和需求定义；第三个阶段就是需求的设计，我们在对产品原型进行设计的时候就要做好产品需求文档以及产品迭代计划的管理，这就要求我们要学会对产品进行版本的规范管理。

同时在这一步的产出物应该有需求文档、产品原型以及迭代计划。

在第四个阶段需求实现阶段，我们要不断的跟开发、项目经理、甚至客户进行沟通并跟踪需求的实现的情况，随时关注产品实现本身的情况以及随时可能出现的问题，并对问题进行跟踪处理，那么在这一步所要产出的就是实际产品本身；在第五个阶段需求验证阶段，我们需要对已经实现的产品进行已实现的需求验证，需求的验证是需要通过需求用例以及以及需求报告进行实事求是的验证，只有需求用例和需求报告都通过评审，产品整体运行正常，达到用户对需求的满意度那么该产品可以算是通过需求验证。

那么在这个阶段我们产出就是需求用例和需求报告。

综上所述在整个需求管理过程中有需求采集、需求分析、需求设计、需求实现以及需求的验证这五个阶段，下面就这五个阶段做详细的理解分析。

2.1需求采集

2.1.1需求的特性

2.1.1.1具有客观现实性

有客户提出了需求，那么需求就是客观存在的，有对应的用户并且对于用户来说该需求是可以实现的，那么就说明需求的特性是具有客观的现实性的，不可实现的只是我们实现需求的方式方法或许还没找到。

2.1.1.2具有主观差异性

任何需求的提出，都会因人而异产生不同的看法，这就要求我们在挖掘需求本质的同时，也要去区分出不同的细分用户群体的需求。

2.1.1.3具有动力发展性

需求的出现一般情况下都是会伴随用户心理倾向，而心理倾向会随着需求的沉淀继而转换为用户的行为习惯，而行为习惯的发生同时需要场景的支撑。

因此我们在获取用户需求的同时也应该获取到用户的心理对这个需求的倾向状态，将用户倾向的心理状态设计出合适的场景才能实现用户需求有效的行为转化。

2.1.1.4整体关联性

任何产品的使用都不是面向单一个体，需求的提出也都不是独立存在的，人和需求关联在一起就必然是和多个需求关联，因此我们在看待和接受用户需求的时候，不能单单的从独立单一的视觉去看待，需要根据整个产品的关联性，需要从用户群体、技术壁垒与实现、产品稳定性等各个方面综合考虑与衡量。

在追求细节的同时也要保持对产品整体的大局观。

2.1.2需求的来源

在采集需求的过程中，我们要明确我们需求的来源是多样性的，最初有可能是跟客户沟通了解客户的基本需求、那么跟客户沟通的时候还会有客户的领导或者客户领导的领导的需求等等，如果说在跟客户交流时客户本身也不太明确自己的需求时，这个时候就需要我们从竞品分析、行业报告或者公司战略以及用户沟通交流等方式获取需求。

从目前采集需求的来源我们总结了两个大的方向来源，一个是从内部获取的需求，另外就是从外部获取的需求。

从内部获取需求我们主要采用的是自我驱动去获取需求和从公司内部去获取所做产品的需求。

我们在自我驱动去获取需求时主要是通过竞品分析、行业报告或者参考文献等方面去总结提取客户需求。

那么从公司内部则主要是通过公司战略方向、同事沟通交流的头脑风暴以及针对性问题的提出与交流去总结提出客户的需求。

从外部获取需求的方式主要是产品用户和合作伙伴。

比如根据客户初步的需求去找需求对应的用户群体，去采访他们对于使用产品的要求、想法等，通过与产品用户群体的沟通交流或者用户访谈去提取精炼产品的需求。

另外一个就是去通过与合作伙伴针对性的提问沟通交流，去了解他们对产品的需求、想法或者建议意见等总结产品的需求。

总结以上各种方式与途径，我们可以看到采集和了解客户需求的来源是多种多样的，在采集需求的过程中，我们要尽可能广泛的去主动获取需求，在理解客户需求的同时要体会用户真正的是什么，要学会挖掘需求的本质。

同时在采集客户需求的阶段要避免被客户牵着走，要根据客观事实理性的看待需求，要充分发挥产品经理能动性与主导性。

2.1.3各个阶段的需求采集

在整个需求采集的全生命周期，不管需求采集处于哪个阶段，首先作为产品经理需要明确的一点就是，对产品需求的自我驱动应该是贯穿在整个过程的。

详细说就是在产品的规划阶段，我们要通过自我驱动和公司内部去初步的理解客户的需求；在项目的售前阶段，我们要通过自我驱动、公司内部、产品用户以及合作伙伴去深入了解并理解客户的需求；在项目实施阶段，通过售前阶段对产品的深入理解去在实践的过程中逐步完善需求；在产品最后上线的阶段，我们要根据已实现的需求和客户新提出的需求或者产品本身迭代的需求去不断的完善并优化产品。

这所有需求实现的过程对于作为产品经理来说，自我驱动是必要的也是必须的。

2.1.4用户研究的方法

对于用户需求的采集、场景的实现，我们要设计什么样的场景才能达到客户的需求，这就要求我们需要对场景的使用者——用户，对用户作出研究，只有我们充分了解了用户对产品的想法、期待、结合现实条件设计出来的产品才可能达到客户满意。

那么对于用户研究的方法主要有三个维度，定性与定量、使用场景、态度和行为。

对于定性与定量，我们主要是通过直接观察来获取用户行为或者态度的信息来给客户进行定性，而间接的通过问卷或者调查工具来获得信息来给客户需求进行定量。

对于使用场景，我们通过让用户像平常一样或者接近平时的习惯一样去习惯性的使用产品。

去研究用户的行为习惯也是为设计产品合适场景的一个重要手段。

对于态度和行为，首先我们要明白的是，态度表明用户说了什么，而行为则表明用户做了什么或者期望怎么做，所有这么信息的观察到最后就是为了挖掘用户的本质，为了设计出合适的符合人性行为的令客户满意的场景。

2.1.5避免需求雷区

在采集需求的过程中，很多时候用户也不清楚自己想要的产品到底是什么样子的，因此有时候会有一些天马行空的想法或者要求，在不同的阶段也许需求也不一样，而作为产品对于需求采集常碰到的几个问题主要以下方面：

1.“说”和“做”不一致

当出现说的和实际做的不一致的时候，这种情况可能往往是用户自己并没有完全考虑清楚自己想要的到底什么，因此我们碰到这种情况最好的处理方式就是边说边做，每一步都流程去核实客户的需求。

2.样本少，以偏概全

当客户拿着某个样本去替代某些需求的时候，我们需要考虑样本本身是否具有随机性，是否是以偏概全的，在这种情况下，我们要学会识别需求的差异性，要根据需求不断的对产品进行优化迭代。

3.被用户牵着走

在我们了解用户需求的过程，如果碰到比较强势的客户并被客户的要求牵着走，那么这个时候就要考虑是不是我们采访的用户对于问题没有聚焦，过于发散，处理这类问题的化，就需要我们及时将客户引导至我们对于产品所关注的焦点上。

4.用户被我们带着走

当出现这种情况的原因主要是我们可能试图让用户认为我们所作的是对的，并且带有一定的意见排斥。

这种情况就需要我们多反思并且多询问为什么。

在理解需求的过程不仅要避免以上雷区，还需要避免照着清单念问题要避免让用户产生被审问感、要多关注用户行为背后的原因、作为产品经理需要对产品的主导性负责要避免让用户成为产品设计师，因为做产品可能在技术上并不是完全的权威，并且用户大多也不善于谈论技术（但是对于懂技术的用户一定要沟通公司的技术人员进行沟通）因此我们在理解需求的时候尽量避免技术讨论，鼓励用户用讲故事的方式表达需求避免诱导性的问题出现。

2.1.6深挖用户需求

我们了解需求的最终目的是为了提出解决方案满足客户的需求。

而我们将产品转化为用户需求，实际上就是发现了问题的根本所在。

在深挖用户需求的方式上，我们需要从三个方面同时去理解。

一个是用户需求，在这个阶段用户只是提出了问题的现象或者只是模糊性的表达了需求。

我们要从用户的表面表达看到本质需求。

第二方面就是用户的动机，即产品的典型场景设计，在这个阶段我们要结合用户的角色、情景以及用户的行为去产品使用场景。

第三个方面就是要通过了解产品的定位去深挖产品的最终需求。

在深挖需求的过程中最需要注意的两点阻碍就是避免被用户牵引走而失去对产品的自主性以及脱离用户群体而使最终设计出来的产品无法落地。

2.1.7基于产品周期研究方法

2.1.8竞品分析

做竞品分析的最终目的就是提取自我产品的亮点或者优势。

那么这就涉及到我们在做产品的时候如何去做竞品分析，需要分析对手产品的哪些方面，是仅仅从功能上去做对比吗还是从其他方面去做分析。

那么做竞品分析的方式方法就是：

首先调研目标：

不同产品阶段的调研目标是不同的，因此这就要求我们去基于产品的关注点去做分析与对比。

其次选择竞品：

在选择竞品的时候，我们要从竞品选择的数量、选择的标准、企业的知名度、产品知名度、行业排名、业务的相似度去做对比分析，比如对于竞品的标准最好是相似的，对于企业的知名度、产品的知名度或者企业排名要选择高于或者与本身持平的企业或者产品，所谓有相同的起跑线才能评比出各自的优势程度。

第三是获取竞品的方式：

既然是做竞品分析，那么必然也会对对手的产品有一定的了解，如何细致的了解对手的产品关乎到竞品分析的深入还是浅出。

因此我们在获取对手竞品的方式可以通过对手官网的宣传、关注用户的体验信息、自己去试用对手的产品或者通过互联网、论坛等等其他各种渠道去获取对手的产品信息。

第四分析竞品的内容：

在通过前面三步的铺垫之后，我们可以说对竞争对手的产品已经有了一定的深入了解，那么在总结竞争对手的竞品内容之后，我们可以通过竞品内容的产品定位、产品数据、以及产品功能这几个方面和自生的产品内容去做对比分析。

第五竞品分析结果的应对策略：

在通过竞品内容分析之后，在设定产品范围框架的条件下，我们要通过SWOT分析法则将与研究对象密切相关的各种主要内部优势、劣势和外部的机会和威胁等，通过调查列举出来，并依照矩阵形式排列，然后用系统分析的思想，把各种因素相互匹配起来加以分析，从中得出一系列相应的结论，找出自我生产品的优势。

2.2需求分析

2.2.15W原则

我们讲到需求的分析其实就是根据客户业务、角色以及场景的问题分析，而分析问题的5个原则就是Who、What、Where、When以及Why。

也就是什么人需要在什么地方什么时间去做什么或者说为什么去做。

针对每一个需求都有这5个问题，即做这个需求的目的是什么、目标用户是谁、用户痛点是什么、给用户的价值是什么、给平台的价值是什么、使用场景是什么等等。

总之多从各个方面各个层面各个阶段各个角色多问问自己或者客户为什么是可以帮助我们在正确的需求轨道前行。

2.2.2避免伪需求

由前面介绍我们采集需求的方式和来源是多种多样的，因此在众多需求中如何去伪存真这就要求我们从需求的来源、需求的属性、开发的周期和优先级以及用户是否愿意买单进行分析。

从需求的来源我们要明确这个需求是谁提出的，这个人在整个产品或者整个项目中处于什么角色等。

从需求属性来看要明确用户提出的需求是刚需还是弱需是新增还是功能的优化。

从开发周期和优先级方面考虑，要明确该功能技术评估的难易度以及开发时长是否会对整个项目的周期造成影响，在评估这些技术层面的同时还要确定功能的优先级。

从用户是否愿意买单来判断该功能是否有存在的必要。

综上所得的分析我们要将所有的需求做一个统一的反馈量，即有多少用户反馈了该需求，需求的真实覆盖面是多少，即是否有必要向用户调研，当下阶段的重要性有哪些，客户新增的需求是否和当下阶段的重要性相冲突。

结合以上总总分析，我们可以综合得出哪些需求是必须的必要的，哪些是不必要的伪需求。

2.2.3需求分析过程

当我们从各种渠道收集到客户的各种需求的时候，需要对需求进行整合分析，而这个分析的过程可以将需求进行分类、然后筛选、进行分位、最后进行分级处理。

在一步一步需求分析中逐渐明确产品的功能需求、业务需求、高级需求、低级需求等。

2.2.3.1需求分类

对于需求的分类，分类越细致也就用户场景越细分，那么对于用户需求的挖掘程度也就越深。

需求深入的本质就是对“人性”的洞察。

那么对于产品或者项目的需求分类首先我们要做到的就是记录整理，记录所有的需求，整理所有的需求，再通过需求分类表将所有的需求再进行分门别类的记录整理，清晰的描述需求的本意。

需求分类表的内容应该包括需求的类型、所属的模块、需求的来源、需求的提出者以及提出时间。

2.2.3.2需求删选

将所有需求分门别类之后就要在这些需求中作出筛选，如何筛选需求、从哪些方面通过什么方式去筛选。

即逐一分析需求，将可行性的需求留下，不可行的需求放弃并记录放弃的理由。

需求删选的总体原则是要在满足需求的条件下提高实现降低理想。

需求删选的方向主要包括从战略定位、产品定位、用户需求、需求价值这个几个方面去考虑。

在战略定位上，要了解产品需求的起步阶段主要是关注核心功能、实现产品的快速上线，在产品的发展阶段则要注重产品的创新和优化，在产品的迭代阶段，要关注并增强用户的体验，提示运营能力。

在产品定位上需要判断需求是否会对产品的定位产生影响，而对于产品的不同阶段其定位也有所不同，因此需求的判断也要根据产品的定位进行跟踪判断。

在用户需求方面，明确该用户是否是目标用户或者核心用户，只有目标用户或者核心用户的关注点才有参考的价值与作用。

最后是需求价值的删选，我们在删选需求的时候要从需求的广度、需求的频率、需求的强度、需求的时机等各个方面综合考虑该需求是否被删选。

2.2.3.3需求分位

在经过需求的分类与删选之后，需要将需求进行分位，分位的方法主要是通过四象定位法去分，即重要和不重要需求、紧急与不紧急需求，重要紧急的需求我们要立即执行、重要不紧急的需求我们可以分解任务、指定计划然后按部就班的执行，对于不紧急也不重要的任务放在最后考虑，对于紧急但是不重要的需求采取的是能不做就不做。

根据四象定位法我们知道有紧急需求和重要性需求。

那么在工作中如何去区分重要和紧急呢？

首先紧急性的需求我们要从产品所处的阶段去考虑，即在起步阶段最紧急的任务就是核心功能的实现，在发展阶段就是功能的扩展和完善，而在迭代阶段的紧急需求就是用户体验的提升。

其次重要性需求主要是根据用户的惊喜程度来确定。

即在重要性需求过程中，基本的需求分位是大于期望型需求的，而期望型需求则又大于兴奋型需求。

所以对于重要性的需求，我们在排分位的时候要看该需求是给客户锦上添花还是雪中送炭。

2.2.3.4需求分级

在通过前面几个需求处理的步骤之后，我们还要对需求进行分级，而需求分级的方式依据则是SWOT态势分析法。

通过态势分析得出自我产品的竞争优势、竞争劣势以及竞争的机会和威胁。

我们在通过需求的分位，依据分位进行需求分级，其排序为重要且紧急的大于重要不紧急的大于不重要但是紧急的大于不重要也不紧急的需求。

根据业务逻辑分级，在业务逻辑上尽量将一个业务逻辑的内容放在一个迭代里面。

根据技术评估分级，即需求的实现的技术难度、在有限的人力资源情况下去做权衡做分级。

根据性价比评估分级，根据需求价值和开发量的评估来判断是否值得并分级。

2.2.3.5需求池

在做完需求分类、需求删选、需求分位与分级之后我们要做一个需求池，需求池不仅是包含以上需求的四种内容同时还可以全局的展现整个产品的功能进展情况。

需求池的详细内容应该包含需求类型、所属模块、需求名称、需求描述、需求来源、需求提出者、提出时间、优先级、迭代计划、需求状态、预计上线时间、实际上线时间。

即需求的分类就可以从上述需求池中的需求类型、所属模块、需求来源看出，需求筛选就可以从需求名称、需求描述中看出，而需求的分位与分级则可以从优先级和迭代计划里面看出。

2.3需求设计

2.3.1需求设计

需求设计的本质主要就是以客户为核心，将客户的需求落实到纸上落实到实际的产出上。

确保需求到功能的实现到客户的使用是可用易用的。

细说需求的设计主要包括产品架构的设计，产品功能列表的跟踪迭代、产品需求文档的跟踪与更新、产品原型的设计优化。

在产品架构图和功能列表上需要罗列各个迭代功能以便后去的设计有依有据。

产品需求文档的设计需要首先需要总体对项目或者产品进行说明，说明的内容有项目概述、功能范围、用户范围、词汇表以及其他说明。

其次在功能说明上，需要将功能概述、业务描述、功能详细说明、流程说明、界面原型、交互说明、前置条件、后置条件等详细描述清楚以便研发和测试进行参考。

另外需要说明的是产品需求文档是非常必要且重要的文档，在写产品需求文档的时候要以实用为关键，要完整、准确、清晰且简洁的表达需求。

并且产品需求文档的阐述形式要尽量符合阅读者的习惯，当需求有变化的时候要切记及时更新需求文档。

需求原型的设计是将客户需求转换为可见的实体最直观的形式，因此在设计过程中要遵循统一化和规范化。

如交互的规范、视觉的规范、文案的规范等。

需求原型的设计应该是从产品经理最开始的手绘、PPT或者其他任何工具抽象、低保真、全局展现到最后UI和UE的具体、高保真、细节的逐渐完善的过程。

2.3.2需求评审

需求评审通常是由产品经理来主导，通过讲解产品需求文档让相关人员了解具体的需求并提出疑问进行沟通的过程。

统一大家对产品需求的理解为后续产品的开发实现打好基础，帮助产品更好的实现落地。

在需求评审过程中不仅是知识的传递过程，同时也是发现不明需求或者需求遗漏的过程，通过大家的互相沟通讨论，可以打破产品经理对于产品需求的局限性。

产品需求评审的完整体系应该包括需求干系人、产品需求的评审的内容以及后续的评审。

需求干系人应该包括产品经理、公司领导、项目成员、目标用户、研发人员、UI/UE人员以及测试人员。

评审的内容应该包括项目的背景、迭代的目标、产品结构图、流程图、需求清单、原型图、PRD文档。

对于后续的需求评审，应该是记录评审结果有调整的确认下次评审内容的和时间，输出的功能表、已确认的研发计划、已确认的测试用例和计划。

2.4需求实现

任何事物的实现都有其时间、资源、资金的限制。

对于需求也不例外，因此需求实现的原则是尽量快步小跑，在满足基本需求的同时实现快速交付。

要实现交付目标那么在开发中就要及时获取反馈，尽量避免用户提需求变更。

即使有提需求我们也要辨别需求是否完整、是否脱离用户、是否不切实际等。

因此在需要在项目控制、沟通成本等因素上做相应的权衡。

2.5需求验证

需求验证是产品正式上线或者发布前必要且重要的工作。

产品需求验证需要对内部目标进行验证，即是否按照预期实现了需求，验证的内容有功能验证、流程验证和数据验证。

产品需求验证同时需要对外部进行验证，即用户对已实现的需求是否认同。

3需求的沟通与变更

3.1沟通的重要性

沟通不仅贯穿需求管理的全过程，同时沟通也是作为一名产品经理必备的技能，在整个需求管理过程中，我们会面临各种角色，有领导、有客户、有开发、有其他相关联系人等。

在不同的场景下，我们沟通的方式与内容也必须要有所不同。

在需求采集阶段，我们沟通的主要角色有公司领导、项目组成员、产品用户、合作伙伴，因此沟通内容可以是产品策略、竞品情况、用户需求。

沟通的方式可以尽量通过面谈或者会议来沟通辅助通过邮件或者电话等及时工具沟通。

在需求分析阶段，我们沟通的角色可能主要是公司领导和项目组成员，沟通的内容主要有需求的分类、筛选、分位、分级沟通的方式可以尽量通过面谈、会议来沟通或者辅助通过邮件或者电话等及时工具沟通。

在需求设计和实现阶段主要沟通角色为UI或者研发，沟通的内容主要是产品原型及产品的设计、技术实现、实现进度，沟通的方式可以会议为主，邮件电汇等其他通讯工具为辅。

在需求验证阶段主要和研发测试沟通，沟通内容为功能实现情况及设计实现情况，可以用以上任何工具沟通。

3.2与领导、客户沟通

在整个产品生命周期与领导、客户沟通中总结的常见问题有：

●沟通不及时

●沟通内容不明确

●没有充分理解对方的意思

●一个问题在多次沟通中反复提及

解决以上沟通问题的策略有：

●尽可能的里程牌式沟通

●一个里程牌内的小阶段充分沟通

●每次沟通都是层次递进并且详细记录沟通内容，避免遗忘且邮件反馈

●内容重复及确认，避免信息理解的偏差

沟通辅助的内容有：

●Demo原型以及PPT

3.3与UI沟通

与UI沟通的常见问题总结有：

●需求遗漏

●文案缺失

●元素缺失

●元素不凸显

●UI不合理

●UI不美观

与UI沟通总结的策略有：

●一定要讲业务逻辑

●需求要清晰明确，避免摸棱两可

●交互流程明确

●展示元素、文案确定

●以页面为单位，及时沟通、及时跟进进展情况并给出针对性建议。

3.4与研发沟通

与研发沟通总结：

采用DISC沟通法则

即：

●讲话讲重点，不要浪费时间

●沟通集中注意力、及时作出反馈

●有问题尽量提供判断题或者选择提不要问答题

●要及时频繁沟通交流进度

●要足够关注赞美与批评3：

1原则

●要留意工作任务争取工作权益

●要让对方先表达并在其表达之后提出遗漏或者作出补充

●要多一些包容使其有快速修复BUG的能力

……

总结沟通策略：

听到、听清、听懂、赞同、行动

沟通辅助内容：

●Demo原型

●产品需求文档

●流程图

●功能列表

●草图

3.5关于需求变更

对于需求变更的心态：

有变更是事物发展的正常现象，我们要用平常心拥抱一切的变化。

管理需求变更的目的不是要避免需求变更，而是有序的控制变更，减少和降低需求变更对产品开发的影响，包括成本和进度以及质量的影响。