起点学院课程

产品管理流程及规范1:产品需求来源、收集、管理、优先级确定及迭代规划

3 评论 7620 浏览 52 收藏 22 分钟
15天0基础极速入门数据分析,掌握一套数据分析流程和方法,学完就能写一份数据报告!了解一下>>

编辑导语:产品管理流程是很复杂的,稍不注意就会出现差错,然而规范的流程是怎样的?流程不规范有什么危害?需要注意些什么?可能很多人都还不知道,基于此,本文作者总结了那些踩过的坑,为大家详细的罗列出了规范的产品管理流程,希望看后对你能够有所帮助。

一、前言

1. 为何写这系列文章

1)亲身经历

  • 产品流程混乱无序
  • 开发直接对接业务
  • 随时插入新的开发功能
  • 交接资料为零
  • 接手的工作未画流程图
  • 进入业务之后,发现流程等各种产品文档缺失严重
  • 版本更新内容未记录
  • 产品记录资料中间连续断层

在与众多产品沟通的时候,发现这是一个很普遍的问题,我基于已经趟过的坑,想聊一下。

2)产品流程管理及文档不规范有什么害处

增加了额外的成本及问题,这些成本包括:

  • 新人对项目的上手时间成本;
  • 因资料缺失导致的沟通成本;
  • 研发周期加长导致的进度问题;
  • 无文本信息,问题反复,理解不一致导致的团队信任成本;
  • 人员流失导致信息断层的问题。

特别在业务不断扩张,人员团队扩容,任务复杂度增加,管理及文档的规范化将发挥巨大作用。

2. 怎样写这个系列文章

基于这个认知,在我的产品经理职业生涯中,逐步搭建了一套产品流程及规范文档,进行了实践,取得了一定的效果:内部认知语言统一、沟通时间更短、各方效率提高、文档可追溯查询、人员变动流失影响更小、权责清晰等。

此系列文章将对此套管理流程及规范做分享,主要约定公司产品从立项到产品上线的整个过程,产品经理的做事流程,产品经理需要完成哪些事情,需要产生哪些文档以及文档产出的规范。

本系列文章主要涉及方面包括:

  • 产品需求的收集
  • 产品需求管理
  • 产品规划
  • 产品原型设计
  • 产品需求的输出文档
  • 产品验收
  • 产品版本命名规则
  • 产品发版管理

二、需求层级

1. 战略性需求

为产品定基调,定方向的需求,比如说,我们要做一个母婴方向的垂直电商平台。

引起战略性需求的因素可能有两大部分:

  • 一部分是由外部因素引起(如新技术趋势、市场变化、社会交流方式等出现的新机会);
  • 一部分是内部的技术、资源整合再利用,在原有业务方向之外的拓展(比如华为利用他的技术积累往手机方向发展,滴滴利用在出行上的数据积累做无人驾驶汽车)。

这会延伸出新增及拓展的两类,新增比如原来做团购,现在增加外卖业务。拓展比如本身做外卖业务,配送团队由第三方完成,现在外卖订单量大之后自己做配送,拓展有横向及纵向扩展,纵向是上下游产业链整合,横向是业务多元化。

此部分参与人员一般是公司最高层,至少是项目的最高层核心人员参与。

这涉及到商业模式的综合分析,在本文中不做过多扩展,后期将专门写一些文章专门分析。本文主要还是集中在产品需求收集、管理流程及规范上。

2. 战术需求

战术需求比战略需求低一层级,是对战略的拆分,也即是通常意义说的产品实现路线的每个阶段。

比如说:做本地生活服务平台,前期商家体量小,尽快的实现业务流转,前期合同可以线下签订,可以只做PC端;后期逐步的实现电子合同,手机APP,网页适配等。

3. 战役需求

战役是对战术的再拆分,也就是每一个阶段性的具体实施。

比如:商家合同电子签如何实现,登录方式如何处理。当然,这是简单的区分,实际中短期需求也需要考虑到后期的可扩展性,否则做出来的东西后期改动成本会非常大。

比如说登录方式,如果不考虑各平台,各渠道账户打通等,后期的对接,用户数据的集中处理将会面临很大的问题。

二、需求的来源

1. 内部客户

简单说就是公司内部决策高层及各部门具体使用人员,对产品在使用中发现的问题,提出的优化改善运营策划方案。

如运营使用频率最高,客服部与用户沟通频率最高,都能发现很多需求及问题。

此部分需求,具体使用部门一般主要集中在对现有产品的优化迭代,在流程的优化、体验的优化,业务线的深化拓展。

内部客户的需求收集整个流程:

由内部用户填写需求功能收集表,按照一定的周期提交产品经理,并进行沟通讨论,根据商业价值、技术可实现度、优先级、产品路线节奏规划等考虑点判断是否要做,及做的安排。短期内不做,或者有其它方法可解决的情况下,与需求提出方沟通其它解决方案(如:在项目的早期,以MVP方式做,则很多分析类的需求,在数据量较小,工作复杂程度较小的时候,是可以通过将相关数据埋点进行导出手动分析,则这个时候做大量的系统数据分析需求及实用性不大)。

如果需求沟通之后确认要做,则将需求放入排期中,并将需求对接清楚,各方通过签字或其它方式进行确认。

一般来说,如果不是非常紧急的需求及bug修复等,按照一周一次的提交频率进行是一种较好的方式,因为产品进展到一定的程度之后,大概率也是按照一定的固定频率进行更新。

这样一方面给产品经理可以留下其它时间来完成手上的工作,不至于经常打乱节奏,另一方面可以给需求提出方一定的思考完善时间,补足一些明显的业务逻辑漏洞。

但这个需要前期进行部门之间的沟通,形成一定的机制。

其它部门很容易出现的状况是,有一个想法就想立即与产品经理进行沟通,这是人的一种本能,有任何问题及疑问,想法就想立即沟通。但产品及业务的工作,是属于较为复杂的知识性工作,这种工作的方式是要进行大量的决策及权衡,不如一些潜意识的行为方式,直觉的判断。

要克服这一点,只有各部门之间达成一个沟通机制,做一定的固化。

内部需求收集的整体流程如下:

2. 外部客户

外部客户的调研,这要看产品是针对的B端用户还是C端用户,B端用户的目标客户群较为清晰。

B端用户要分决策购买人和使用者,最好的方式是同时满足两者的需求。

这两者有不同点,比如决策者的依据是对企业好(其它目的不进行讨论),比如员工行为数据可视化、流程线上化。这样可以对员工进行监管,同时数据更为实时,后期商业决策更加有依据。

实际在做的时候,需要深入业务中调研,也需要对流程进行优化,不能只是简单的将原有的流程完全搬到线上,或者简单的搞高大上的可视化显示,因为这样会增加实际操作人员的成本,并未能提高效率,缩减成本。

一般B端业务,深入业务,对相关关系人进行足够的沟通,则需求将比较明显能够提炼出来。

C端的用户,业务纵深一般没有B端的程度深,但目标用户的明确性,用户的需求会不这么明显,需求调研所花费的工作将会更多。

总体来说,B、C都采用线上及线下的方式进行调研。线上调研一般是调研问卷的方式,以及参考行业相关资料,竞对资料,线下一般采用拜访(预设或不预设问题),邀请用户集中沟通,头脑风暴等方式。

不同的调研方式适用的阶段,操作的方式都不一样,这一方面要多注意。具体的调研方式,大家可以进行网络搜索查看详情,后期我也可以针对不同阶段,不同类型业务采用何种调研方法写文章阐述。

以下为外部需求收集的流程:

三、需求收集标准化文档

产品需求收集表:以下为需求收集表的样式,需要说明需求提出方,需求的名称,将需求描述清楚(主要解决为什么做,做什么,怎么做这几个问题,特别是解决为什么及做什么的问题),需求的类型是新增、改进,紧急重要程度(判断排期得重要标准),对接的产品经理,对接的时间(收到需求的时间)

四、需求管理

1. 需求池

需求收集之后进入进入正式的需求池进行管理,可以按照一定的时间比如每周一次从各方收集需求,并进行初步沟通之后,放进需求池。并根据需求本身的变动,调整需求池中的相关状态,标注相关的记录,批注。

  • ID——需求的唯一ID号,需求身份标识,增加一个需求ID增加1。
  • 端口——需求所涉及的端口,前端如—安卓、iOS、小程序,后台—平台、供应商、商家,这是对需求做初步划分,如果涉及到多端,一般记为综合或拆分成多条子需求对应到各端口。
  • 模块——需求所涉及到的模块,例如会员管理、用户管理、商品管理等。
  • 需求名称——简单描述需求是做什么的
  • 需求描述——更详细描述需求的相关信息,例如需求提出的背景、需求要达成什么目的、需求的详细说明等。
  • 需求来源——记录需求的来源方,例如产品、市场、运营。
  • 类型——记录当前需求的类型,a、新功能;b、功能优化;c、bug修复。
  • 优先级——记录需求的优先级,a、一般用高中低;b、数字表达;c、需求的优先级是动态的,会随着战略、业务目标的变化而调整。
  • 提出时间——记录需求被提出的时间
  • 提出人——提出这个需求的人及联系方式,有助于在需求详细设计时追踪到原始需求。
  • 状态——需求当前的状态,根据不同的阶段,可以大致分为:a、记录——进入需求池(初始状态);b、论证——需求开始评估论证;c、待设计——论证完成后有价值并决定近期开展后续工作;d、设计中——正在进行详细设计;e、设计完成——原型及UI已经设计完成;f、研发中——已正式安排研发周期;g、已上线——需求正式上线;h、已关闭——针对需求因各种原因提前终止其生命周期;
  • 预计版本——对需求计划上线的版本进行规划,产品部门规划的实现版本往往会超前正在研发版本
  • 实际完成版本——版本上线后,更新需求实现的实际版本号
  • 上线时间——记录版本实际上线的日期
  • 备注——各种情况的补充说明,例如需求关闭的原因,需求优先级变动原因,版本规划变动

2. 需求优先级

需求优先级的分析可以采用KANO模型、四象限法则、权重加权三种方式进行:

2.1 KANO模型

以分析用户需求对用户满意的影响为基础,选择了两个维度:需求实现度、用户满意度。

用这两个维度将需求区分,将需求分为5种,分别是:

  • 兴奋型需求——也称魅力型需求:随着满足用户期望程度的增加,用户满意度也会急剧上升,但一旦得到满足,即使表现并不完善,用户表现出的满意状况则也是非常高的。反之,即使在期望不满足时,用户也不会因而表现出明显的不满意。
  • 期望型需求——也称为意愿型需求:是指顾客的满意状况与需求的满足程度成比例关系的需求,此类需求得到满足或表现良好的话,客户满意度会显著增加,企业提供的产品和服务水平超出顾客期望越多,顾客的满意状况越好。比如说,支付方式,相对来说,是越多越好,这样用户会有更多选择,当没有一种支付或是其中一种没有资金的时候还有别的可供选择,能覆盖更多的用户。
  • 无差异需求——不论提供与否,对用户体验无影响,比如现在各平台都有的签到,打卡功能。
  • 基本型需求——也称为必备型需求、理所当然需求:是用户对企业提供的产品或服务因素的基本要求,比如现在互联网基本都有的客服功能。
  • 反向需求——又称逆向型需求:指引起强烈不满的导致低水平满意的需求,比如将产品流程设计的非常复杂,引起用户反感。

针对不同类型的需求,采取不同的措施。

2.2 四象限法则

四象限法则将需求分为:重要且紧急、重要不紧急、不重要但紧急、不重要也不紧急四类,两个选择维度是:紧急和重要。

  • 第一象限——包含一些紧急而重要的需求,这类需求具有时间的紧迫性和影响的重要性,无法回避也不能拖延,必须首先处理优先解决,比如支付功能出问题。
  • 第二象限——需求不具有时间上的紧迫性,但它具有重大的影响,需要wbs方法分解任务、提前进行规划,按照计划逐步制性,比如数据埋点统计分析。
  • 第三象限——需求大多是些琐碎的杂事,没有时间的紧迫性,没有任何的重要性,这种需求的提出本身就存在一定问题,没有考虑清楚,可能是头脑发热,也可能是看着别人有就想做,与本身产品没有任何关联性,对这类需求可以放任不管,比如后台标题栏的颜色美观性
  • 第四象限——是那些紧急但不重要的需求,这些事情很紧急但并不重要,比如由于商品图片过大导致的加载慢(可以通过优化压缩上传图片解决)等,可以先采用替代方案执行

2.3 权重衡量

对需求赋予一定的指标,进行量化分析,如工作量大小、对用户价值大小,对公司价值大小、紧迫程度、与核心流程相关性,可以将各指标赋予一定的权重(所有指标项权重相加为1,各指标项确定各自的程度数值,工作量按天计算时间越大,赋值越低)进行加权,得出综合值大的,则优先级高。

如下图,需求2的综合得分为6.8》需求2的综合得分5.6,先做需求2:

五、迭代规划

1. 固定任务

任务量固定,时间上可以进行调整,比如一个大的版本上线,新开的功能模块上线,即使采用MVP的方式,也会超出一般迭代的周期。

这种方式一定是以保证业务、功能需求的完整性,系统性为主,不能完全按照时间来。

否则的话,功能逻辑的完整性和链条就会缺失,上线之后会带来极坏的影响,如果功能不完整还不如不上线的好。

2. 固定周期

当产品进入稳定期之后,业务也较为稳定顺畅,则按照固定周期进行迭代,比如两周时间上新一个版本,则以时间为准,固定时间端,按照优先级并考虑工作量合理安排需求。

3. 紧急需求

在上一个版本发布之后,发现重大bug,需要紧急修复上线,这种肯定不能按照常规方式处理,直接将优先级提高,修复上线。

4. 插入需求的处理

紧急需求与插入需求有些类似,均是常规计划之外的。两者又有不同之处,紧急需求是不得不做的,不做将会带来严重影响的。

插入式需求是计划已经排定,但又有新的需求进来,比如业务部门,上级领导等。

这个时候从几个方面进行处理:

  1. 先不急着拒绝,先分析需求的优先级,如果需求确实优先级高,看需求规模,工作量大小,人力资源,是否能不动本次版本需求的基础上进行增加。如果可以则直接增加进去,如果不行,则将优先级低的需求进行删减。
  2. 需求优先级不高,则沟通安排到之后的迭代,并讲明原因

六、总结

本文主要对需求的层级、需求来源、需求收集方法、需求管理池、优先级的确定及需求迭代进行了分析,产品管理流程及规范系列文章地址为:

产品管理流程及规范2——产品规划及相关文档

产品管理流程及规范3:产品原型设计

产品管理流程及规范4:PRD文档撰写

产品管理流程及规范5——版本命名、验收规范、发版管理

 

本文由 @markzou 原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
起点学院课程
评论
评论请登录
  1. 你亲身经历遇到的问题,条条感同身受

    回复
  2. 文章开头的“亲身经历”是我们团队现在最大的痛点,也一直想有所改观,这篇文章对我的帮助很大,感谢作者的无私分享

    回复
    1. 客气了,这是一个系列文章,文章末有这个系列其他文章的传送地址

      回复