现在就与君和客服交流

400-039-7699
APP开发 · 小程序开发 · 网站 · 电商 · 微信 · 系统定制 · 网络营销
在线咨询
提交成功
B端产品的后续优化,如何落地?
05.23 / 2020

在面向B端的产品中,部分软件公司对于产品的研发,是想要建立一套行业解决方案。

因为是想解决行业的问题,软件的研发周期,需求收集都耗时较长。

尤其是在产品研发后,一些需求的传递就没有ToC迅捷,某项产品功能在初始研发时是满足市场需求的;但经过一定周期再来分析时,这个需求可能就“淘汰”了。

此时,为了做好产品功能优化,更好地服务于客户就要在产品部分功能落地后进行调整,而我们提出『产品改进』这一产品,用于对B端产品改进需求、实际开发调整的管理。

一、产品改进业务

1. 产品改进是什么

产品改进是指在产品上线后,用户反馈的一些改进建议,或是灰度测试暴露的“小问题”,需要单独拎出时间来进行讨论、研究以来对产品进行改进调整优化的产品使用需求。

其中部分改进需求甚至会延展为一个新的独立项目。将这些需求进行评判、开发、以及后期的上线版本控制。

2. 需求管理是什么

整个需求的管理是非常广泛的。其中包括原始需求、分析需求、必要需求等等。划分的类别根据不同的标准划分五花八门,具体的不再赘述。

在《人人都是产品经理》上有各种大牛解答。但是,在这些划分的背后都围绕一个目的:产品的开发方向,产品要实现哪些功能。

3. 二者异同点

产品改进是整个后期产品线调整的总概,需求管理仅是其中之一。

二者都是对实际产品业务需求的管理,只是产品改进更偏向于产品投入线下后的使用改进,而需求管理则是产品落地前后都具备的。

4. 为什么要有产品改进

在敏捷开发的模式下,产品的开发工作也是存在“蜜月期”的。

在产品开发完成的前一周,直到产品落地的后一周,在这期间项目组成员方便跟进产品调整,“改得及,改得快”。

但是过了这个“蜜月期”,若是开发成员手头又开展了其他工作,就可能产生两个问题:

  1. 之前业务代码会看起来“生疏“——消耗一定时间成本去熟悉。
  2. 一些业务概念也不如初始开发时那么清晰——盲目地直接更改可能产生新业务缺陷。

额外一点,在公司层面,核算人工成本时,难以界定其ROI。

而且某些需求是零散的。例如:

部分客户提出来A业务要增加一个功能,B功能模块希望整合到C里。而『产品改进』主要功能就是,将零散的需求收集在一起,进行统一查看,将这些产品业务方面的调整单独罗列出来,作为一定工作时间内的开发工作。既是某次『产品迭代』的内容,也是个人待办的列表。

二、落地方法

了解了产品改进的业务以及来源情况,下面就是『产品改进』的相关落地方法。

整个『产品改进』业务分三个部分进行考虑:

  1. 事前讨论
  2. 事中监督
  3. 事后反馈

遵循如下流程:

涉及到角色:需求提出者、产品人员、开发人员、测试人员。

1. 事前讨论

可以具有一个需求池,一些用户反馈的需求,或产品经理“拍脑袋”想到的内容,统统丢在这个池子里,这一部分可以叫做『需求管理』。

然后,定期定员召开需求评审会,也就是所谓“事前讨论”,在实际动手前,大家坐在一起商讨评审三方面信息:

  1. 哪些需求可以满足 (What)
  2. 这些需求交由谁处理 (Who)
  3. 初步地规划怎样处理 (How)

所谓定期,可以是每月或每段周期内的某个固定时间点,例如每月的1号,也可以是每次版本迭代后。

定员:一般是相关产品线的负责人,需求的提出者,相关技术人员。

2. 事中监督

产品改进这个模块,最终落地到工作上其实是对产品功能的新开发或是调整。所以,产品改进落实下来就是功能改进的管理。

当一个需求被判定为需要满足后,就要对这个实际需求进行细分化地处理。一个需求在经过分析设计后,可能拆分为N种实际落地的功能,这一点我在《服务于敏捷开发的项目文档》中提到过。

为了更好地了解某个开发的进度,可以用『功能管理』将其管理起来。注意这里的管理的基本都是单一的功能点,若是一个需求可以作为一个模块或项目,那应该是进入到一个新项目中。

功能管理:用于管理某次产品迭代时要增加或修改的功能。其主要作用就是监控相关需求实际执行的完成进度。主要三类角色参与:产品人员、开发人员、测试人员。可以利用看板的形式来进行管理,各个状态和相关人员的工作。

其中一个功能的状态变化情况如下:

3. 事后反馈

当一个需求被满足后,需要将其反馈出去。主要是两种:

  1. 信息通知需求提出者
  2. 版本公告

在『功能管理』的【产品确认】时就可以通过通讯类工具通知原始需求提出者,以来达到正向反馈。然后在『产品迭代』进行【确认发布】操作时,可以和公告进行关联,以此来告知公司内部其他成员此次版本的内容,以及明确的真正的上线时间。

正向的整体流程大致为下:

正向里『产品迭代』是最后建立的,对于要迭代的内容,是手动从『功能管理』中挑拣的。

而要是想用『敏捷』的方式管理,操作流程是反向的。

首先确立好某次『产品迭代』时限,然后拉出需求池判定需求,将相关需求分派下去。

创建『功能』工作项时和『产品迭代』进行关联(相当于把这些工作项归并到某个冲刺里),然后再在『产品迭代』的确认发布时,将未完成的『功能』工作项进行移动到下一『产品迭代』。

三、总结

产品改进实际运用的也是敏捷开发的模式,定时定量,将一次『产品迭代』作为一个冲刺,监督其过程,明确其结果。

不同公司的具体开发流程会有差异,以上愚论仅作参考。任何东西都有个性化的一面,就像加勒比海盗里说的那样:

法典只不过是一些指导,它并不是必须遵守的规定。