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 协议

我来评几句
登录后评论

已发表评论数()

相关站点

热门文章