产品需求管理流程,敏捷开发中的需管理过程_敏捷开发需文档怎么写

本文目录

如何做好需管理系列—— 做什么和不做什么

如何做好需求管理系列(1)—— 做什么和不做什么

序:需求管理源于业务需要,始于需求挖掘,继而需求分析,需求定义,需求验证。周而复始。

因为用户需求(业务需要)是无限的,所以经过产品经理整理、分析所形成的“产品需求”也是种类各异且数量众多的。因此,对于一名产品经理而言,有效的进行产品需求的管理是非常重要的。在本系列文章中,我将与你分享“优先级判断”、“如何挖掘需求”、“如何定义需求”、“如何验证需求”,这四个方面的相关经验。

对于产品需求优先级的管理,普遍采用 四象限定位法 ,其中以需求的急需性作为横轴,需求的重要性作为纵轴;四个象限分别为:

“四象限定位法”的优点是充分利用了消费者的需求特征层次。其缺点也相当明显,由于仅从需求的重要性和急需性考虑,需求划分的粒度过大,仅适用初步筛选,无法对 产品需求优先级进行量化。

接下来,我将同大家分享 产品需求优先级量化模型 ,在开始之前,先进行一些预备知识的铺垫。首先,我们来定义“重要性”,我们认为,当某个功能可以明确解决用户的某个特定需求或者某个功能可以为用户提供前所未有的服务时,该需求的 重要性为高。 然后,有别于单一时间维度的“急需性”,我们尝试使用“可行性”来替代四象限定位法中的“急需性”。“可行性”即在有限的 资源和时间内 是否可以达成预期目标。

明确了“重要性”和“可行性”的定以后,我们开始使用需求优先级量化模型,模型的使用分为三个步骤:

以某社区电商某个版本的需求为例,来讲解 需求优先级量化模型 的建立:

Step 1 列出采集到的用户需求

将4个主要需求填入表单,形成如下表格。

Step 2 填写“重要性”和“可行性”权重表

为了正确的填写权重表,我们需要对需求(目标)进行逐条分析,评估其重要性及可行性。当我们面对复杂或者难以判断权重的需求时,我们可以使用中位数3来表示该需求的权重。因为有了中位数作为基准,确认其他需求的重要性和可行性也更加容易。下面,我们来逐条分析这四条需求,并完成需求权重表的填写。

“增加独立访客”,可使用电商的黄金公式——销售总额 = 流量 x 转化率 x 客单价,进行分析。流量对销售总额有着重要影响,经过几个版本的推广,流量作为重要因素但非决定性因素存在,其重要性为4;在拥有一定体量的前提下,继续获得新增用户的难度是很高的,其可行性为2。

“提高访客的购买金额”,在流量和转化率趋于稳定的前提下,提高访客的购买金额(客单价)将成为接下来工作的重点,其重要性为5;可行性方面,通过采用精确推荐、捆绑销售等手段可以实现客单价增高的目标,其可行性为4。

“增加页面中商品展示区域”,从已有经验来看用户访问页面深度基本呈正态分布,增加商品的展示区域对网站各方面数据的帮助可能比较有限,其重要性为1。相比需要借助其他渠道才能获取的新用户,完成商品展示区域的扩大其可行性要高一些,这里记为3。

“收录更多的商品”,收录的产品数量是否会对网站产生影响是一个未知数,于是我们将这个需求的重要性和可行性均记为3,用中位数来表示难以判断的情况。

经过以上分析,将分析结果填入表格中,形成如下表格。

请记住这个非常重要的公式 :版本周期内的可用资源数 = 需求数量 x 权重中位数 。以本文中的需求为例,版本周期内的可用资源数 = 4(需求数)x 3(权重中位数)= 12。

接下来,我们计算该版本中四个需求的重要性总和可行性总和,我们会发现,重要性总和:4 + 5 + 1 + 3 = 13;可行性总和:2 + 4 + 3 + 3 = 12;当前版本的重要性总和 > 可行性总和,意味着我们必须对四个需求做出合理的取舍才能保证,在既定的迭代周期内实现版本价值最大化。

然后,按照重要性和可行性的维度对需求进行划分, 我们将需求分为:核心需求,有价值的需求(辅助需求),可忽略的需求 。将权重表中的数据填入可行性-重要性坐标系,完成需求量化。

观察需求分布统计图,我们可以得出以下结论:

最后,“需求优先级量化模型”的使用,有如下几点说明:

如果,你对本文介绍的“需求优先级量化模型”的使用有任何疑问或者对需求管理方面有独到的见解,欢迎在评论区与我互动,谢谢你的阅读。

-EOF-

产品需求管理流程,敏捷开发中的需管理过程_敏捷开发需文档怎么写图1

产品需管理之需收集什么信息

关于需求收集的方法,如何做好需求收集 这篇文章讲解得比较详细,可以参考其内容。用于需求收集的常见手段包括:原型法头脑风暴用户访谈法问卷调查法标杆分析法观察不期而遇的用户各种会议(如用户大会、展览会、学术研讨会等)现场支持和支持团队(运营团队、技术支持团队)谈话客户热线客户满意度调查用户行为分析合作开发一些思考:1)、需求收集应该收集用户真正面临的问题和业务场景,这样才能够捕获用户真正的需求,而不是只盯住用户提出系统需要实现什么样的功能,“需求收集”不是“需求汇总”。2)、用户要的是产品的“价值”,而非产品的“功能”。只有当一个产品功能真正帮客户解决问题,这个功能才具有价值,也才真正有“功能”。3)、需求收集流程要真正发挥作用,必须在组织层面通过组织管理制度及绩效考核制度来保证,将需求收集纳入到各相关部门的绩效考核中。不能指望大家三分钟的热情。4)、需求收集流程的执行情况是一个公司管理是否规范的试金石,也可以衡量一个公司是否真正“以市场为导向、以客户为中心”。5)、需求收集既要避免“什么都要做”的冲动,又要避免“只关注当下需求”,核心根源还是在于产品战略是否清晰。6)、常规的需求收集手段并不能够解决产品创新问题,但如果没有持续的需求积累,创新就无从谈起,创意的灵光源于专业。7)、尊重竞争对手和用户。竞争对手和用户并不像我们想象的那么愚蠢,以自己的标准来度量别人的产品才是真正的愚蠢。很多时候我们从自己的预设立场出 发,否定掉了众多创新机会。对竞争对手,我们应当首先成为其产品忠实用户;对用户,我们应当通过用户社区等互动手段来“倾听用户的心声”。4、客户满意度模型(Kano模型)KANO模型定义了三个层次的顾客需求:基本型需求、期望型需求和兴奋型需求。这三种需求根据绩效指标分类就是基本因素、绩效因素和激励因素。基本型需求:顾客认为产品“必须有”的属性或功能。当其特性不充足(不满足顾客需求)时,顾客很不满意;当其特性充足(满足顾客需求)时,无所谓满意不满意,顾客充其量是满意。期望型需求:耍求提供的产品或服务比较优秀,但并不是“必须”的产品属性或服务行为有些期望型需求连顾客都不太清楚,但是是他们希望得到的。在市场调查中,顾客谈论的通常是期望型需求,期望型需求在产品中实现的越多,顾客就越满意;当没有满意这些需求时,顾客就不满意。兴奋型需求:要求提供给顾客一些完全出乎意料的产品属性或服务行为,使顾客产生惊喜。当其特性不充足时,并且是无关紧要的特性,则顾客无所谓,当产品提供了这类需求中的服务时,顾客就会对产品非常满意,从而提高顾客的忠诚度。一旦每个需求都得到了明确的分类,就能够在需求收集过程对需求进行优先次序排序。关于Kano模型的详情,可以参考kano模型 及 需求入门 - 用Kano模型来确定需求优先级 。

产品需求管理流程,敏捷开发中的需管理过程_敏捷开发需文档怎么写图2

管理归零评审

产品的需求通常都要经历好几轮评审,这是非常重要的过程,可以帮助产品经理将需求梳理的更清晰、更合理、更完善。

需求评审通常包含4轮:

1、 需求版本迭代规划评审

需求迭代版本规划完成后需要进行一次评审,确定产品需求的版本以及上线时间,且每个版本的需求优先级。评审的时候需要对每个版本的需求情况进行简述,说明需求背景、重要程度、解决问题、需求优先级等,然后确定这个需求做不做、放入哪个版本做。

2、 产品需求方案PRD内审

确定需求版本规划后,产品经理要开始产出需求方案PRD文档,完成后要进行需求方案PRD内审,内审即产品团队内部评审,需求负责人将需求方案PRD文档详细讲解一遍,然后评审人员提问以及相关讨论;主要评审人为团队负责人还有产品相关同事,对需求的重要性、合理性、完整性、整体性以及细节交互进行评审。

需求评审时,如果需求问题不大,只是一些小细节调整,那么会后调整完即可,如果需求有些漏洞或逻辑、流程问题等,则需求会被认定为评审不通过,下次还要继续进行需求内审。

3、 产品需求方案PRD技术评审

通过需求内审后,需求方案PRD要和技术经理或技术负责人进行评审讨论,确定从技术的角度考虑需求时,技实现起来没什么问题。有时候技术会希望换一种实现方式,因为涉及到很多技术方案、框架等问题,这时产品经理要和技术经理达成共识。

有些复杂需求或者偏技术性需求在需求方案在设计时,就需要先和技术经理私下讨论,确定方向上实现上是没有问题的,否则在技术评审时,技术负责人说这个需求方案实现不了,那就很尴尬了。

4、 产品需求方案PRD公审评审

需求公审是在技术评审后,需求评审人员比较多(产品经理、项目经理、技术经理、开发人员、测试经理、测试人员、UX、UI),产品经理要提前发起需求公审会议,并发需求方案PRD发出来;技术经理、测试经理要提前分配每个需求对应的开发负责人以及测试负责人,所有评审人员需要提前查看方案进行预审,如果有问题要准备好问题,以便需求评审能高效快速且有质量的完成。

需求评审的注意事项

1、注意控制好每次的评审时间,要控制好会议的节奏

2、评审会议要提前发出来,需求评审前要对需求提前预审

3、产品经理要进行需求自查

4、需求评审的人员要安排好,特别是公审时,具体开发人员不用每个需求都全部参加,通常是参加自己负责得部分即可。

5、每次需求的评审记录要记录清楚,主要是需求评审后的待办事项以及问题

版本需求迭代评审表

下面举例列出一个需求版本迭代评审表,用于某个版本的需求评审时,对版本所有需求以及需求状态的统一管理,仅供参考,可以根据公司情况进行调整。

产品需求管理流程,敏捷开发中的需管理过程_敏捷开发需文档怎么写图3

如何做好需管理的工作

大多产品经理都是从管理需求的工作做起,负责产品的定义,并检验研发出的产品是否符合最初的产品定义。这要求产品经理培养自己一定的需求管理能力。一般来说,产品需求管理包含以下工作内容:

1)需求收集,包括被动和主动的需求收集,其中主动的需求收集要求掌握需求收集的途径和方法,产品创意需要统一纳入到需求收集的范围;

2)需求分析,通过需求分析的层级模型,透彻地分析需求背后的用户问题和痛点,用户的需求场景,必要时还需要通过一些简单的原型确保准确地理解用户需求;

3)需求分发,不是所有需求都要纳入到下一个产品版本,成熟的需求管理团队能够发现高价值的中长期需求,在需求分发环节将其纳入到产品规划;

4)需求实现,该阶段的责任主体是产品开发团队,产品经理需要确保产品开发的各个阶段没有偏离自己的产品概念;

5)需求验证,包括产品经理对产品的验证,还包括产品经理主导的用户验证。

总的来说,产品需求管理能力培养的目标是发现价值需求,形成能够获得市场成功的产品概念,以指引产品研发团队顺利研发出让用户满意的产品。

产品需求管理流程,敏捷开发中的需管理过程_敏捷开发需文档怎么写图4

以上就是关于产品需求管理流程,敏捷开发中的需管理过程_敏捷开发需文档怎么写的全部内容,以及产品需求管理的相关内容,希望能够帮到您。

版权声明:本文来自用户投稿,不代表【尚维培训网】立场,本平台所发表的文章、图片属于原权利人所有,因客观原因,或会存在不当使用的情况,非恶意侵犯原权利人相关权益,敬请相关权利人谅解并与我们联系(邮箱:youzivr@vip.qq.com)我们将及时处理,共同维护良好的网络创作环境。

发表评论

登录后才能评论

评论列表(0条)

    联系我们

    在线咨询: QQ交谈

    邮件:youzivr@vip.qq.com

    工作时间:周一至周五,9:30-18:30,节假日休息