人人都是产品经理|实践:ToB产品研发完成后还需要做哪些工作


编辑导语:前两篇文章作者带我们完成了产品的研发过程 , 实践:带你一步一步完成ToB产品设计、实践:怎么做好研发阶段的产品工作 , 本文就已经是一次产品迭代流程的尾声了 , 作者详细介绍了ToB产品研发完成后还需要做哪些工作 。

人人都是产品经理|实践:ToB产品研发完成后还需要做哪些工作
本文插图

【人人都是产品经理|实践:ToB产品研发完成后还需要做哪些工作】到了这个阶段 , 产品的一次迭代流程基本上就接近尾声了 。
这个阶段是产品经理比较忙的阶段 , 主要工作内容聚焦在验收测试、市场支持、销售支持方面 。
一般情况下文档量会比较多 , 接下来咱们就捋一捋这个阶段产品的主要工作内容 , 以及完成这些工作内容的一些技巧和要注意的示项 。
当然 , 这个阶段还是以我个人的工作经验为核心描述 , 仅供参考 。
一、产品验收
产品验收是研发团队和产品团队的工作交接过程 , 产品验收标志着产品正式完成研发的相关工作 , 转为后续迭代升级维护阶段 , 也标志着产品部门有了新的武器到市场上冲锋陷阵了(是死是活就看产品自己的能力了) 。
1. 交付物完整性验收
产品研发上线后 , 产品经理首先要对研发提交过来的交付物是否完整进行整体性的检查 。
通常我们会在验收启动前跟研发对一个交付物清单 , 对研发提交的整体成果物达成一致 。
对于ToB类型的产品 , 通常的交付物包括:产品本体:要明确产品版本号 , 模块文件/源代码文件清单(如果有必要的话) , 安装程序等 。 文档手册:包括产品安装手册、测试报告(包含功能测试、压力测试等) 。
拿到产品交付过来的产品后 , 产品这边需要根据成果物清单逐个进行对照检查 , 如果对照过程中出现了任何的问题 , 直接给产品这边的Leader发邮件(注意!一定要发邮件) , 要求他们重新检查后 , 重新发送 。
这个阶段一定要注意:因为交付物是一个整体的概念 , 尽量不要研发一点一点发给你 , 你来替换某个或者某几个文件 , 毕竟你对整体产品包不够了解 , 容易替换出来问题;在完整性验收的阶段 , 一定是研发给你一个整体产品包过来做验收 。
2. 产品安装验收
确认了产品比较完整了 , 产品这边需要协调现场部署人员对产品安装过程进行验收 , 来确认产品安装过程的可执行度 。
这个过程通常会包含两个方面的功能:一个方面是需要现场部署人员熟悉部署流程;一方面也是验证产品整体安装部署的可执行能力 。
过程就比较简单 , 由现场部署工程师按照产品安装手册里面的要求准备测试环境、安装基础的软硬件平台 , 部署软件产品 。
这个过程中如果出现了任何问题 , 就需要提交产品级别的BUG , 由产品研发相关人员做修正;一般情况是安装程序BUG或者文档BUG , 都需要录入到BUG管理系统进行追踪维护 。
3. 产品功能验收
产品安装验收通过后 , 产品部门团队就有了一套用来验收的环境了 。
产品部门就要根据需求对产品的功能进行整体性的试用和体验 。
这个过程中通常会产出以下的内容:
1)产品使用手册:
产品使用手册是产品的重要组成部分 , 产品团队需要按照产品需求、产品原型来一边做功能方面的验收 , 一边切图制作产品使用手册 。
注意 , 产品使用手册通常是给用户应急用的 , 用户一般情况不会看产品使用手册 , 只有出现问题的时候才会使用 。
那么产品使用手册除了常规的操作说明外 , 一定要加上Q&A的部分 , 把验收过程中产品遇到的问题及解决方案都放在里面 。
2)产品BUG:
验收过程中 , 可能会出现产品级别的BUG , 通常我会把产品级别的BUG设置为以下几种:功能BUG:就是功能实现上跟预期不符 , 属于严重BUG , 需要修复后再发布;体验BUG:就是功能上满足需求 , 就是使用过程中会有一点不舒服或者反人类习惯 , 这类的BUG一般情况下会加入到需求池观察 , 如果客户提的多 , 就迭代改进(谁让我们做的是ToB的产品呢?就是有这样的优势) 。


推荐阅读