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

文章图片

一、前言 1. 为何写这系列文章
1亲身经历
产品流程混乱无序
直接对接业务
随时插入新的功能
交接资料为零
进入业务之后 ， 发现流程等各种产品文档缺失严重
产品记录资料中间连续断层
在与众多产品沟通的时候 ， 发现这是一个很普遍的问题 ， 我基于已经趟过的坑 ， 想聊一下 。
2产品流程及文档不规范有什么害处
增加了额外的成本及问题 ， 这些成本包括：
新人对项目的上手时间成本 。
因资料缺失导致的沟通成本 。
研发周期加长导致的进度问题 。
无文本信息 ， 问题反复 ， 理解不一致导致的团队信任成本 。
人员流失导致信息断层的问题 。
特别在业务不断扩张 ， 人员团队扩容 ， 任务复杂度增加 ， 及文档的规范化将发挥巨大作用 。
2. 怎样写这个系列文章
基于这个认知 ， 在我的产品经理职业生涯中 ， 逐步搭建了一套产品流程及规范文档 ， 进行了实践 ， 取得了一定的效果：内部认知语言统一、沟通时间更短、各方效率提高、文档可追溯查询、人员变动流失影响更小、权责清晰等 。
此系列文章将对此套流程及规范做 ， 主要约定公司产品从立项到产品上线的整个过程 ， 产品经理的做事流程 ， 产品经理需要完成哪些事情 ， 需要产生哪些文档以及文档产出的规范 。
本系列文章主要涉及方面包括：
产品需求的收集
产品需求
产品规划
产品原型设计
产品需求的输出文档
产品验收
产品版本命名规则
产品发版二、需求层级 1. 战略性需求
为产品定基调 ， 定方向的需求 ， 比如说 ， 我们要做一个母婴方向的垂直电商平台 。
引起战略性需求的因素可能有两大部分：
一部分是由外部因素引起（如新技术趋势、市场变化、社会交流方式等出现的新机会）
一部分是内部的技术、资源整合再利用 ， 在原有业务方向之外的拓展（比如华为利用他的技术积累往手机方向发展 ， 滴滴利用在出行上的数据积累做无人驾驶汽车）
这会延伸出新增及拓展的两类 ， 新增比如原来做团购 ， 现在增加外卖业务 。 拓展比如本身做外卖业务 ， 配送团队由第三方完成 ， 现在外卖订单量大之后自己做配送 ， 拓展有横向及纵向扩展 ， 纵向是上下游产业链整合 ， 横向是业务多元化 。
此部分参与人员一般是公司最高层 ， 至少是项目的最高层核心人员参与 。
这涉及到商业模式的综合分析 ， 在本文中不做过多扩展 ， 后期将专门写一些文章专门分析 。 本文主要还是集中在产品需求收集、流程及规范上 。
2. 战术需求
战术需求比战略需求低一层级 ， 是对战略的拆分 ， 也即是通常意义说的产品实现路线的每个阶段 。
比如说：做本地生活服务平台 ， 前期商家体量小 ， 尽快的实现业务流转 ， 前期合同可以线下签订 ， 可以只做PC端；后期逐步的实现电子合同 ， 网页适配等 。
3. 战役需求
战役是对战术的再拆分 ， 也就是每一个阶段性的具体实施 。
比如：商家合同电子签如何实现 ， 登录方式如何处理 。 当然 ， 这是简单的区分 ， 实际中短期需求也需要考虑到后期的可扩展性 ， 否则做出来的东西后期改动成本会非常大 。
比如说登录方式 ， 如果不考虑各平台 ， 各渠道账户打通等 ， 后期的对接 ， 用户数据的集中处理将会面临很大的问题 。分页标题#e#
简单说就是公司内部决策高层及各部门具体使用人员 ， 对产品在使用中发现的问题 ， 提出的优化改善策划方案 。
如使用频率最高 ， 部与用户沟通频率最高 ， 都能发现很多需求及问题 。
此部分需求 ， 具体使用部门一般主要集中在对现有产品的优化迭代 ， 在流程的优化、体验的优化 ， 业务线的深化拓展 。
内部客户的需求收集整个流程：
由内部用户填写需求功能收集表 ， 按照一定的周期提交产品经理 ， 并进行沟通讨论 ， 根据商业价值、技术可实现度、优先级、产品路线节奏规划等考虑点判断是否要做 ， 及做的安排 。 短期内不做 ， 或者有其它方法可解决的情况下 ， 与需求提出方沟通其它解决方案（如：在项目的早期 ， 以MVP方式做 ， 则很多分析类的需求 ， 在数据量较小 ， 工作复杂程度较小的时候 ， 是可以通过将相关数据埋点进行导出手动分析 ， 则这个时候做大量的数据分析需求及实用性不大）
如果需求沟通之后确认要做 ， 则将需求放入排期中 ， 并将需求对接清楚 ， 各方通过签字或其它方式进行确认 。
【管理流程及规范上，产品需求管理，收集，管理，优先级——记录需求的优先级】一般来说 ， 如果不是非常紧急的需求及bug修复等 ， 按照一周一次的提交频率进行是一种较好的方式 ， 因为产品进展到一定的程度之后 ， 大概率也是按照一定的固定频率进行更新 。
这样一方面给产品经理可以留下其它时间来完成手上的工作 ， 不至于经常打乱节奏 ， 另一方面可以给需求提出方一定的思考完善时间 ， 补足一些明显的业务逻辑漏洞 。
【管理流程及规范上，产品需求管理，收集，管理，优先级——记录需求的优先级】但这个需要前期进行部门之间的沟通 ， 形成一定的机制 。
其它部门很容易出现的状况是 ， 有一个想法就想立即与产品经理进行沟通 ， 这是人的一种本能 ， 有任何问题及疑问 ， 想法就想立即沟通 。 但产品及业务的工作 ， 是属于较为复杂的知识性工作 ， 这种工作的方式是要进行大量的决策及权衡 ， 不如一些潜意识的行为方式 ， 直觉的判断 。
要克服这一点 ， 只有各部门之间达成一个沟通机制 ， 做一定的固化 。
内部需求收集的整体流程如下：

文章图片

2. 外部客户
外部客户的调研 ， 这要看产品是针对的B端用户还是C端用户 ， B端用户的目标客户群较为清晰 。
B端用户要分决策购买人和使用者 ， 最好的方式是同时满足两者的需求 。
这两者有不同点 ， 比如决策者的依据是对企业好（其它目的不进行讨论）比如员工行为数据可视化、流程线上化 。 这样可以对员工进行 ， 同时数据更为实时 ， 后期商业决策更加有依据 。
实际在做的时候 ， 需要深入业务中调研 ， 也需要对流程进行优化 ， 不能只是简单的将原有的流程完全搬到线上 ， 或者简单的搞高大上的可视化显示 ， 因为这样会增加实际操作人员的成本 ， 并未能提高效率 ， 缩减成本 。
一般B端业务 ， 深入业务 ， 对相关关系人进行足够的沟通 ， 则需求将比较明显能够提炼出来 。
总体来说 ， B、C都采用线上及线下的方式进行调研 。 线上调研一般是调研问卷的方式 ， 以及参考行业相关资料 ， 竞对资料 ， 线下一般采用拜访（预设或不预设问题）邀请用户集中沟通 ， 头脑风暴等方式 。
不同的调研方式适用的阶段 ， 操作的方式都不一样 ， 这一方面要多注意 。 具体的调研方式 ， 大家可以进行网络搜索查看详情 ， 后期我也可以针对不同阶段 ， 不同类型业务采用何种调研方法写文章阐述 。
以下为外部需求收集的流程： 分页标题#e#

文章图片

三、需求收集标准化文档
产品需求收集表：以下为需求收集表的样式 ， 需要说明需求提出方 ， 需求的名称 ， 将需求描述清楚（主要解决为什么做 ， 做什么 ， 怎么做这几个问题 ， 特别是解决为什么及做什么的问题）需求的类型是新增、改进 ， 紧急重要程度（判断排期得重要标准）对接的产品经理 ， 对接的时间（收到需求的时间）
四、需求 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种 ， 分别是：
兴奋型需求—也称魅力型需求：随着满足用户期望程度的增加 ， 用户满意度也会急剧上升 ， 但一旦得到满足 ， 即使表现并不完善 ， 用户表现出的满意状况则也是非常高的 。 反之 ， 即使在期望不满足时 ， 用户也不会因而表现出明显的不满意 。
无差异需求—不论与否 ， 对用户体验无影响 ， 比如现在各平台都有的签到 ， 打卡功能 。
基本型需求—也称为必备型需求、理所当然需求：是用户对企业的产品或服务因素的基本要求 ， 比如现在互联网基本都有的功能 。
反向需求—又称逆向型需求：指引起强烈不满的导致低水平满意的需求 ， 比如将产品流程设计的非常复杂 ， 引起用户反感 。分页标题#e#
针对不同类型的需求 ， 采取不同的措施 。
2.2 四象限法则

文章图片

四象限法则将需求分为：重要且紧急、重要不紧急、不重要但紧急、不重要也不紧急四类 ， 两个选择维度是：紧急和重要 。
第一象限—包含一些紧急而重要的需求 ， 这类需求具有时间的紧迫性和影响的重要性 ， 无法回避也不能拖延 ， 必须首先处理优先解决 ， 比如支付功能出问题 。
第二象限—需求不具有时间上的紧迫性 ， 但它具有重大的影响 ， 需要ｗｂｓ方法分解任务、提前进行规划 ， 按照计划逐步制性 ， 比如数据埋点统计分析 。
第三象限—需求大多是些琐碎的杂事 ， 没有时间的紧迫性 ， 没有任何的重要性 ， 这种需求的提出本身就存在一定问题 ， 没有考虑清楚 ， 可能是头脑发热 ， 也可能是看着别人有就想做 ， 与本身产品没有任何关联性 ， 对这类需求可以放任不管 ， 比如后台标题栏的颜色美观性
第四象限—是那些紧急但不重要的需求 ， 这些事情很紧急但并不重要 ， 比如由于商品图片过大导致的加载慢（可以通过优化压缩上传图片解决）等 ， 可以先采用替代方案执行
2.3 权重衡量
对需求赋予一定的指标 ， 进行量化分析 ， 如工作量大小、对用户价值大小 ， 对公司价值大小、紧迫程度、与核心流程相关性 ， 可以将各指标赋予一定的权重（所有指标项权重相加为1 ， 各指标项确定各自的程度数值 ， 工作量按天计算时间越大 ， 赋值越低）进行加权 ， 得出综合值大的 ， 则优先级高 。
如下图 ， 需求2的综合得分为6.8需求2的综合得分5.6 ， 先做需求2：

文章图片

五、迭代规划 1. 固定任务
任务量固定 ， 时间上可以进行调整 ， 比如一个大的版本上线 ， 新开的功能模块上线 ， 即使采用MVP的方式 ， 也会超出一般迭代的周期 。
这种方式一定是以保证业务、功能需求的完整性 ， 性为主 ， 不能完全按照时间来 。
否则的话 ， 功能逻辑的完整性和链条就会缺失 ， 上线之后会带来极坏的影响 ， 如果功能不完整还不如不上线的好 。
2. 固定周期
当产品进入稳定期之后 ， 业务也较为稳定顺畅 ， 则按照固定周期进行迭代 ， 比如两周时间上新一个版本 ， 则以时间为准 ， 固定时间端 ， 按照优先级并考虑工作量合理安排需求 。
3. 紧急需求
在上一个版本发布之后 ， 发现重ug ， 需要紧急修复上线 ， 这种肯定不能按照常规方式处理 ， 直接将优先级提高 ， 修复上线 。
4. 插入需求的处理
紧急需求与插入需求有些类似 ， 均是常规计划之外的 。 两者又有不同之处 ， 紧急需求是不得不做的 ， 不做将会带来严重影响的 。
插入式需求是计划已经排定 ， 但又有新的需求进来 ， 比如业务部门 ， 上级领导等 。
这个时候从几个方面进行处理：
先不急着拒绝 ， 先分析需求的优先级 ， 如果需求确实优先级高 ， 看需求规模 ， 工作量大小 ， 人力资源 ， 是否能不动本次版本需求的基础上进行增加 。 如果可以则直接增加进去 ， 如果不行 ， 则将优先级低的需求进行删减 。
需求优先级不高 ， 则沟通安排到之后的迭代 ， 并讲明原因六、总结
本文相关词条概念解析：
需求
需求 ， 是指系统必须符合的条件或具备的功能 。 经济学中需求是在一定的时期 ， 在一既定的价格水平下 ， 消费者愿意并且能够购买的商品数量 。 需求显示了随着价钱升降而其它因素不变的情况下（ceterisparibus） ， 某个体在每段时间内所愿意买的某货物的数量 。 在某一价格下 ， 消费者愿意购买的某一货物的总数量称为需求量 。 在不同价格下 ， 需求量会不同 。 需求也就是说价格与需求量的关系 。 若以图像表示 ， 便称为需求曲线 。分页标题#e#

来源：(未知)

【】网址：/a/2020/0708/kd247791.html

标题：管理流程及规范上，产品需求管理，收集，管理，优先级——记录需求的优先级