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

　　1）亲身经历

　　产品流程混乱无序开发直接对接业务随时插入新的开发功能交接资料为零接手的工作未画流程图进入业务之后，发现流程等各种产品文档缺失严重版本更新内容未记录产品记录资料中间连续断层在与众多产品沟通的时候，发现这是一个很普遍的问题，我基于已经趟过的坑，想聊一下。

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

　　增加了额外的成本及问题，这些成本包括：

　　新人对项目的上手时间成本；因资料缺失导致的沟通成本；研发周期加长导致的进度问题；无文本信息，问题反复，理解不一致导致的团队信任成本；人员流失导致信息断层的问题。特别在业务不断扩张，人员团队扩容，任务复杂度增加，管理及文档的规范化将发挥巨大作用。

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

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

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

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

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

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

　　一部分是由外部因素引起（如新技术趋势、市场变化、社会交流方式等出现的新机会）；一部分是内部的技术、资源整合再利用，在原有业务方向之外的拓展（比如华为利用他的技术积累往手机方向发展，滴滴利用在出行上的数据积累做无人驾驶汽车）。这会延伸出新增及拓展的两类，新增比如原来做团购，现在增加外卖业务。拓展比如本身做外卖业务，配送团队由第三方完成，现在外卖订单量大之后自己做配送，拓展有横向及纵向扩展，纵向是上下游产业链整合，横向是业务多元化。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　2.1 KANO模型

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

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

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

　　2.2 四象限法则

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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