B端SaaS产品工作流程

作者：道·术 （转载已取得授权）

产品研发流程大体分为：立项阶段、设计阶段、开发阶段、测试阶段、上线阶段、运营阶段。

1. 立项阶段

主要分为需求搜集和PMO（或产品委员会）立项。需求搜集阶段可以很长，包括如下内容：

如果是从0到1或者彻底重构的产品，要先进行BRD的输出。包括整体行业的分析，到竞争对手分析，再到roadmap和对应资源匹配。用BRD进行宣讲，才能向上申请资源进行立项。

然后，可能是MRD的输出或者拆解执行。MRD在很多公司会以年度规划的形式提前进行输出，主要是产品roadmap和进度计划。到了某个立项阶段，会根据市场、战略、竞品、技术、渠道等情况，调整版本实现的功能模块以及优先级。当然，还有最重要的项目里程碑计划。

最终输出物基本是立项报告，然后邀请PMO或产品委员会进行立项评审。

2. 设计阶段

主要分为需求池和PRD两大块：

基于立项阶段的MRD、上版本遗留问题和运营反馈的问题，列出概要清单。

然后召集项目成员，进行概要评审。这个评审一般是可行性、优先级以及成本的评审。评审通过的功能，细化成功能清单。

也存在研发业务背景较弱，概要已经要很细，功能清单要更细，以评估合适的工作量。上述的一个概要，需要拆成：

• 列表显示（实体的相关信息、列表需要显示的字段、数据规模以及分页）
• 查询（哪几个条件，条件对应的类型）
• 高级查询（哪几个条件，条件对应的类型）
• 新增（表单录入字段，校验规则）
• 编辑（只读信息、可编辑信息、校验规则）
• 启用（规则）
• 停用（规则）
• 删除（规则）

3. PRD阶段

主要输出物是原型和需求规格说明书，部分小版本甚至不输出需求规格说明书，业务流程、页面流程、交互说明和异常处理都会在原型上体现。

B端比较重视文档，在部分敏捷开发的C端，原型也是以逐个拆解的线框图为主。

这样有以下好处：

1. 一目了然，开发、UI设计不容易遗漏页面
2. UI设计、研发实现工作量评估更加到位
3. UI设计师可以设计更好的UE效果，有更大的发挥空间
4. 节省产品经理自己的时间，高保真原型性价比太低

绘制原型之前要进行整体的业务建模，力求梳理清楚全部的业务流程和必要信息。

在绘制草图时，要多和UI设计师交流，找到更合适的呈现形式。

在原型评审的时候，先介绍这些流程，再看具体的原型页面。原型评审结束，前端研发可以开始部分页面的UI开发，UI设计师准备视觉界面的输出。

需求规格说明书，需要拆分各业务领域进行输出。一个产品一个需求规格说明书，整个文档会非常的大。加上大量的修订和批注，产品人员维护起来很痛苦。编写需求规格说明书期间，要保持和架构师（开发经理）的沟通，在文档中完善业务逻辑。为了保障文档质量，目前文档是基于用例的形式编写的：

这样能更好的和测试进行沟通，减轻测试用例输出的工作，更专注于自动化测试。

需求规格输出完成，需要进行需求评审。由于内部项目动辄3个月，这个会议至少需要1-2小时。拿着几十上百页的文档过，开始还好，半小时后大家就注意力涣散了。

目前使用PPT进行需求评审，只关注业务流程和关键因素，反馈效果很好：

具体文档可以回去后进行查看，配合项目管理工具登记具体的问题，产品人员进行修复。

4. 开发计划阶段

主要是进行项目的计划排期，不展开讲。内部有开发经理角色，可以将这个任务交给开发经理。

5. 概要设计

如果不是第一个大版本，基本是业务时序图、数据结构的设计。由研发输出，测试、产品进行评审。

6. 编码实现阶段

该阶段事情最为繁杂的，包括但不限于：

1. 原型、交互形式的改动
2. 用户需求规格的补充
3. 追踪推进进度，进行阶段性的测试验收。
   如客户管理的列表查询和新增编辑功能今天都能完成，要早上找到对应研发人员询问进度情况。
   进度理想的情况下，下午让研发先自测，然后去进行检查。
   进度不理想要找出差距，寻找追赶的办法。

7. 测试验证阶段

主要有以下工作：

1. 把握测试环境的部署和更新节奏
2. 守好需求验证的关卡。
   根据主业务流程，编写需求验证清单，对产品进行需求测试。
   如果连主业务流程都跑不通，没必要让测试人员进行测试。
3. 修复前期遗漏的业务逻辑。
   不排除经过原型评审、需求评审、编码实现，还有部分逻辑不在需求规格说明中。
   例如某个异常情况，需求规格没写处理逻辑，研发按照自己的想法做了。
   还是需要产品确认，并在需求规格中补充的。

8. 发布运营

发布运营阶段很重要，工作也比较零散：

1. 演示环境的搭建，准备数据的初始化
2. 针对营销线的方案宣讲，输出解决方案和功能模块清单
3. 针对实施、客服的系统实操培训，输出用户操作说明书
4. APP上架文案和相关事项追踪
5. EDM的设计
6. APP更新机制策略的评估，是灰度发布、提示更新还是强制更新
7. 用户的反馈进入需求池，为后续迭代做准备
8. 支撑验证客户项目，包括方案讲解、需求调研等

项目流程

B端客户一般有定制化诉求，会以项目交付的形式进行落地。并且公司内部要求每个版本有验证客户，完善产品到实施的知识转移。工作流程如下：

整个大流程里面，产品经理可能会在涉及以下工作：

1. 在意向阶段介入，协助售前一起完善解决方案（一般是大客户）。
2. 在投标阶段初期切入，替代售前进行解决方案的讲解，以及产品的演示（行业龙头客户）。
3. 在投标阶段后期切入，负责客户POC功能的调研和规划落地。
   需要协调各方资源，在实施开发环境进行功能改造，并追踪整体进度（此时未立项，替代项目经理）。
4. 在项目立项阶段切入，作为公司的产品部代表出席立项会，维护客情。
5. 在蓝图规划阶段切入，支撑需求调研工作。
   如出差客户现场，主导调研并输出部分PRD。
   提供最新产品原型、PRD和组件库，赋能实施人员。
   最后，还可能参与蓝图方案的输出。
6. 在系统建设阶段切入，可标准化的功能将由产品部实现。
   此时需要分配任务跟踪进度，确保标准功能分批实现，满足客户诉求和各项目上线节点。
   同时关注客户测试环境，确认稳定可靠。
7. 在上线推广阶段切入，主要是客情维护和系统培训。
   另外，也需要输出产品的用户说明书，为一线实施人员提供弹药。
   此阶段已上线客户生产环境，需要安排服务经理跟进，并做好出现紧急情况的预案。
   
   
   
   

视频号推荐

最后也欢迎有问题的小伙伴加微信：yw5201a1 沟通交流。

更多干货可关注微信公众号：产品刘

想学习更多关于产品、职场、心理、认知等干货，可长按右边二维码，关注我们。

RECOMMEND

推荐阅读

再分享个竞品分析报告

最全的B端产品经理干货知识（2）

线下实战2.0

二面面试官都会问啥？

点击“阅读原文”