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

一、前言

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. 插入需求的处理

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

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

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

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

六、总结

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

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

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

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

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

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

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