时间: 2021-07-30 11:24:54 人气: 7 评论: 0
作为一个B端产品经理，笔者将结合自己的工作实践和认知，与大家分享一下自己的B端产品经理的工作流以及每一个流程中具体的思考点和注意点，希望能提供一个真正实用的工作流程，给与大家启发和思考。
看过一些总结B端产品经理工作流程的方法论或指南，总体来说步骤差距不大，但大部分**比较空，告诉步骤点到为止，缺少真正的实用性和启发。笔者作为一个B端产品经理，结合自己的工作实践和认知，与大家分享一下自己的B端产品经理的工作流以及每一个流程中具体的思考点和注意点，希望能提供一个真正实用的工作流程，给与大家启发和思考。
作为一个转行的产品经理，最初看了很多介绍产品经理工作流程的文章及书籍，为了帮助自己能尽快上手，但发小大部分都是介绍的很简单，只给了步骤或者大体方法，自己在实践过程中照做了，但是该踩的坑一个都没少，通过2年产品的工作经历以及自己的工作内容及行业性质，总结了自己的工作流，特别是每个步骤中需要的思考点，特别适用于B端产品经理。
我的整体工作流程：
看起来步骤**比较多，如果是大项目，基本每一步都**需要，小项目或优化类，根据实际需要做删减即可。其实整体工作流程和很多作者总结的工作流大同小异，如下图是另外一位作者写总结的B端工作流，也给了我一些启发，大家也可以去阅读一下。
摘自：人人都是产品经理文章《我的B端产品工作流》
那下面重点为大家详细介绍，在我的每一个工作流步骤中，需要注意的点以及思考方向，这些内容也是自己在一次次项目过程及项目复**中总结出来的，希望给大家在实际工作中有一定启发。
在业务型公司中，大部分业务提出需求其实**相对比较**面，很多没有详细思考就提出，或者仅解决一个临时问题，因此在对业务提出的需求沟通中，产品经理需要了解清楚需求本质，引导业务思考。主要需要收集以下信息，以下内容可以作为【产品需求收集表】来要求业务提交需求时填写，同时也是帮助业务自己对需求进行思考。
在收集需求阶段，若能了解到以上内容，说明该需求是业务仔细思考过的，同时也帮助自己后面对该需求合理性的判断。
这一点在做产品初期没有意识到这个问题的重要性，导致很容易做着做着就变成了需求输出工具，后来做了很多项目复**，才意识到业务很多提出的需求不合理，很临时性，**导致系统功能臃肿，因此当收集完业务的需求后，一定要思考需求的合理性，尽量让每个需求做的都有价值。主要思考点可以围绕一下几点：
需求确定没问题，就可以做初步的立项了，大部分公司不**说非常要求这点，比如项目立项报告之类的，主要是产品自己要做对应的工作计划安排，后续更规范的项目安排**在评审通过，确定上线时间后发出，这个也和各公司团队的习惯有关，根据实际情况做调整即可。该阶段主要确定：
B端产品的需求调研相对C端的**简单一些，主要方式为：访谈+竞品。访谈需要提前列出自己希望获取的关键信息，可根据思考需求合理性阶段得出的结果和疑问点归纳得出，让需求调研访谈更具目的性和有效性。
B端竞品相对比较难获取到，我大部分**看一些第三方开发的ERP软件，去试用借鉴一下。
调研这个自己也还在摸索阶段，还有很多空间可以发挥，欢迎大家补充。
说了这么多终于到产品设计环节了，其实B端产品如果只是说画原型的话，其实很简单，不**花很多时间。主要难点是在于整个产品方案的设计，逻辑的梳理以及各个模块考虑周全。下面是我在整体产品方案涉及中主要**考虑的点，以及**输出的内容，也是自己踩了很多坑总结下来的。
很多总结的产品经理的工作流程中，**说要需要画用例图，流程图，产品功能结构图，产品信息结构图等等。个人认为，这里没必要一定要按部就班每个都要画，更多输出这些图是帮助你梳理逻辑，想清楚即可，不用太苛求形式。我个人在这部分主要**比较常用到以下几种：
1）流程图
流程图是在B端流程产品设计中，最常用的东西。主要帮助理清楚各种关联逻辑。我常用的流程图主要是以下几种：
再这个阶段还需要注意一点就是，不要仅限于你做的这个系统或者功能的流程，还需要考虑到其上游及下游的关联性，是否需要上游支持？下游是否有消费使用你产生的数据？是否需要一起联动修改？等等，都需要在产品设计中考虑完善，避免之后发现了才做临时处理。这点也是我之前做项目留下的刻骨铭心的教训，之前做OMS系统，没有考虑到商品系统以及物流仓储系统的关联性，导致上线后出现了很多问题，那个时候再来临时赶工处理。
2）产品信息结构/产品功能结构图
这两个图，我平时用的不多，主要是在大项目中使用到，大项目中主要通过这两个图，可以总结出你系统功能结构以及系统边界，帮助后续做产品功能设计。
需求清单
通过逻辑的梳理，能确定本期项目需要开发的内容及需求内容。需求内容可以明确罗列出来，帮助开发清晰知道需求点，也方便产品直接对着清单，做后面的产品设计，**非常清晰，这也是我最近做项目中总结出来的。注意，这里说的需求内容不是业务提出的需求点，而是产品通过前面总结，所确认出了本期项目的开发需求清单。
画产品原型
基本上通过上面一系列图及需求清单输出后，就可以开始画原型页面了。大部分B端产品，原型不需要高保真，只需要描述清晰，结构清楚即可，不用去苛求于画的很多交互，重要的是逻辑。
产品原型这里就不多说了，可以去收集一些公共的组件，在画的过程中可以提高很多效率。
画完原型后，一般的工作流程中就是要写PRD了，但实际大部分公司基本不太写PRD文档，主要原因是PRD问题太庞大不利于修改维护，而且开发基本不**仔细看，所以大部分方式是直接采用再axure+批注的方式。需要注意的是，这种方式有时原型页面**比较乱，堆砌了太多东西，很多箭头指来指去，一定要注意排版，让其简洁清晰可读性强。
数据处理方案
如果涉及到数据相关的功能，特别是有历史数据需要初始或者处理的，需要在产品设计阶段就要考虑到数据处理方案，该部分可和开发一同讨论确认。如果涉及到大量数据初始，没有处理好的话，**是非常非常大的坑。
上线后监控方案
这部分很多才开始刚做产品同学很少**想到在产品设计中包含该部分，经过很多次项目复**后发现该部分在产品设计中若能提前想到的话，对后续项目复**，监控，迭代很有作用。主要目的为：监控上线后功能运转正常；可以看业务的使用情况，便于数据统计；也可提前设计数据埋点，避免后续统计数据时没有对应记录。
一般监控分为两部分：第一种为上线后1-2周的跟踪方案，监控没问题后就可以停止了；第二种就是一些关键的信息或者数据可作为日常定时监控进行。一般监控采用钉钉报警。
这部分其实有很大空间可以聊，这里就简单提一下，主要给大家一定启发，思考更为全面。
产品方案设计完成后就进入到评审阶段了，一般我**分为两种，第一做完方案后先和业务简单做个评审，确认一下设计的功能及操作流程，能满足业务需求，还有没有什么补充。确认之后再进行开发测试评审即可，评审通过后，确认开发和测试排期。
我现在的团队工作方式**在评审通过后再进行正式的立项，主要通过项目邮件发出，通知到业务方及涉及到的人员。包含内容为：项目背景，目的，需求内容，最重要是开发测试排期时间以及上线时间。
若有风险或者关联性特别多的项目建议上线时间可以往后推预留1-3天，为未知风险做预留准备。
开发和测试完成后，在正式上线前，一般**预留一天左右的时间做产品验收，这块我主要是看下整体功能以及一些核心逻辑，是否和产品设计一致，若有问题再上线前提前提出和解决。
项目上线后，需要发送上线通知，一般可通过邮件发送，主要包括上线时间（若有延期说明延期原因），上线安排，操作指南等，若功能比较复杂可安排做操作培训。
很多产品经理做项目，觉得上线后就完事了，以前我也是这样的，但其实并没有。上线后1-2周是非常关键的时间，这段时间主要关注点为：
到这里，我的B端产品工作流就结束了，也许看起来很复杂，过程很多，但这些其实都是经过各种坑总结出来了。B端产品工作难点并不是产品功能设计，更多的是业务流程及逻辑的思考和对项目的不断复**改进，才能更好地提升。上面这些点，大家可以看自己的实际工作情况做借鉴，希望能帮助大家在做项目时思考的更为全面。当然还有很多改进和补充的地方，欢迎大家评论一起讨论。
本文由 @youly 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
