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

一、序言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 四象限法则

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

第一象限——包含一些紧急而主要的需求，这类需求具有韶光的紧迫性和影响的主要性，无法回避也不能拖延，必须首先处理优先办理，比如支付功能出问题。
第二象限——需求不具有韶光上的紧迫性，但它具有重大的影响，须要ｗｂｓ方法分解任务、提提高行方案，按照操持逐步制性，比如数据埋点统计剖析。
第三象限——需求大多是些噜苏的杂事，没有韶光的紧迫性，没有任何的主要性，这种需求的提出本身就存在一定问题，没有考虑清楚，可能是头脑发热，也可能是看着别人有就想做，与本身产品没有任何关联性，对这类需求可以放任不管，比如后台标题栏的颜色都雅性第四象限——是那些紧急但不主要的需求，这些事情很紧急但并不主要，比如由于商品图片过大导致的加载慢（可以通过优化压缩上传图片办理）等，可以先采取替代方案实行

2.3 权重衡量

对需求授予一定的指标，进行量化剖析，如事情量大小、对用户代价大小，对公司代价大小、紧迫程度、与核心流程干系性，可以将各指标授予一定的权重（所有指标项权重相加为1，各指标项确定各自的程度数值，事情量按天打算韶光越大，赋值越低）进行加权，得出综合值大的，则优先级高。

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

五、迭代方案1. 固界说务

任务量固定，韶光上可以进行调度，比如一个大的版本上线，新开的功能模块上线，纵然采取MVP的办法，也会超出一样平常迭代的周期。

这种办法一定因此担保业务、功能需求的完全性，系统性为主，不能完备按照韶光来。

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

2. 固定周期

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

3. 紧急需求

在上一个版本发布之后，创造重大bug，须要紧急修复上线，这种肯定不能按照常规办法处理，直接将优先级提高，修复上线。

4. 插入需求的处理

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

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

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

先不急着谢绝，先剖析需求的优先级，如果需求确实优先级高，看需求规模，事情量大小，人力资源，是否能不动本次版本需求的根本上进行增加。
如果可以则直接增加进去，如果弗成，则将优先级低的需求进行删减。
需求优先级不高，则沟通安排到之后的迭代，并讲明缘故原由

六、总结

本文紧张对需求的层级、需求来源、需求网络方法、需求管理池、优先级的确定及需求迭代进行了剖析，产品管理流程及规范系列文章地址为：

产品管理流程及规范2——产品方案及干系文档

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

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

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

本文由 @markzou 原创发布于大家都是产品经理，未经作者容许，禁止转载。

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