B端SaaS产品工作流程

产品和项目两手都要抓，两手都要硬，方是真B端产品。

产品流程

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

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. 在上线推广阶段切入，主要是客情维护和系统培训。另外，也需要输出产品的用户说明书，为一线实施人员提供弹药。此阶段已上线客户生产环境，需要安排服务经理跟进，并做好出现紧急情况的预案。

作者：道·术 ，邮箱：olivercan.wunban@foxmail.com

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

题图来自Unsplash ，基于 CC0 协议

作者暂无likerid, 赞赏暂由本网站代持，当作者有likerid后会全部转账给作者（我们会尽力而为）。


Support author:
Author's Filecoin address:
Or you can use Likecoin to support author: