产品经理方法论:业务异常诊断及优化

产品出现了问题,真的只是产品的问题吗?你是否想到了业务?

产品经理方法论:业务异常诊断及优化

众所周知,B端产品服务于业务。

但回顾最近半年所做需求分析和产品设计过程中,发现一个问题:业务诊断不透彻,做出来的产品投入生产后,总有小细节漏掉或者表面上看起来满足了需求,实际却相差甚远,业务方使用起来并不符合要求。

对于这种情况,作为产品经理在做业务问题诊断的时候,真的诊断清楚了吗?

下面对业务异常之业务诊断作了一个个人的梳理。

产品经理方法论:业务异常诊断及优化

一、出现问题

在《软件工程》中提到一个专业化的软件的四个特性中,可依赖性和安全性居于首位。

软件的稳定是保证业务运转的基石,但是总有业务阻断的风险。如电商平台,交易系统等半分钟的宕机就会造成巨大的损失。

笔者遇到的业务异常的情况分为以下几种:

交易系统业务全部阻断,查询,下单,支付等功能全部崩溃;

产线业务整体正常,总有个别产品异常。

1. 第一种情况

对于一个产品汪来说,这无疑是从睡眼朦胧到瞬间清醒的状态,立刻做好背锅的准备。

常人的第一反应是系统宕机崩溃。但是,从产品汪的角度,还应该考虑,是否是新上线的功能未测试完全导致对原有功能的影响,亦或者是临时动了哪个配置参数,导致产品逻辑变化。出现这种情况,肯定是以最快的速度修复系统问题和或者是还原产品配置。

2. 第二种情况

产线整体业务正常,个别产品由于软件问题,产生异常,这种时候产品经理就要作为一个侦探的角色去还原场景,梳理流程,整体分析此异常出现的原因及修复合理性。

下面就第二种情况作个浅谈。

二、业务诊断

业务诊断能力,贯穿所有B端产品的设计,运营,管理等。

不管系统新增需求还是迭代优化,业务诊断是一个产品经理抽象问题的基础。

全面的业务诊断,抽象出问题,最终提供一个合理有效的产品解决方案;为企业提升运转效率,经营管理辅助,是一个好的B端产品的价值所在。

当出现业务异常时候,我们应该怎么诊断问题呢?

我们可以从下面两个步骤来分析:

1. 业务背景调研

1)理解当前业务“目标”

业务背景调研的第一步,理解当前业务目标:这部分业务要实现一个怎么样的诉求,此业务问题出现在整个业务流转中的哪个节点,这个节点的目标是什么?

换句话说就是回归初心。

举个例子:

短信运营商经常会给用户发送短信提醒用户流量使用情况,目的是为了告知用户剩余流量,提示用户,防止用户在不知情的情况下流量用超。

此短信业务的目标便是告知用户短信使用情况,剩下的流量酌情使用,中国移动在发短信的时候,短信内容显示了还剩多少MB的流量可使用。

对于用户来讲,平时使用APP或者上网,流量用多少是不知道的,用户只知道每个月大概会用多少流量,并不容易知道剩下的这些(比如23643MB)流量会用多久。

相比中国移动,中国联通在发送短信时,加了一句“剩下XX%流量”可使用,这样不仅直观,而且达到了发送短信的业务目标。

2)梳理当前业务的“操作流程”

这一点是最坑爹的,有些问题本质上是流程问题,而不是软件的设计或者BUG。

业务流程涉及到多个业务角色操作,这一步我们应该梳理出当前各业务方现有的操作流程。

3)梳理当前业务“正确”的“产品逻辑”

为了实现以上的目标,梳理原有业务逻辑,和产品设计的“正确”流程。

这里的正确流程不是指绝对正确,是指基于此目的,原有产品逻辑的设计。这个设计现在可能看来不合理,但是因为需要快速上线等各种原因而被一直沿用,此时暴露出了问题,而此刻我们需要理清这个逻辑。

4)分析原有逻辑与业务目标的匹配度

在理清了现有产品逻辑之后,既然业务能正常运转肯定有它的稳定之处。但是也出现了瑕疵,说明当前产品设计不是最完美的解决方案,存在漏洞。

基于此,我们下面进一步分析。

2. 问题分析维度

1)从用户场景进行分析

用户场景在和研发梳理需求的时候,是一种沟通工具,而在分析问题或者产品设计的时候,更是一种思维工具。

产品经理应该设身处地把自己当成一线业务员,或者直接到一线观看操作业务的流程;某些问题可能并不是因为软件问题,是业务流程的问题。

对业务员来说,他会通过最方便但可能不是正确的操作流程来达到他的目的,造成这种情况的原因可能是业务员对这个业务的理解脱节,只关注到了他的节点业务,也可能是业务培训不到位造成。

当产品经理走了一遍全流程,或者进入一线用户场景调研分析后,便不会容易出现想当然的分析结果。

2)从用户角色进行分析

分析业务流程中相关的角色,各个角色对应的需求,他要实现的业务目标。

区别于整体业务目标,这里的目标是角色目标,对应岗位上的职责则不同。

3)分析用户角色之间的协同关系

产品优化方面来说,基于各个角色的业务目标分析,了解他们的诉求之后,在这个角色之间要实现一种协同平衡,实现业务稳定,效率提升,考虑该业务目标的主要受益方是谁,业务需求契合度最高的一方,此时优化方案应该偏向该角色。

对于问题查找来说,可能各个业务角色之间的协同流程都有问题,而不是软件本身的问题,规范流程,或许会豁然开朗。

这里笔者想起一个例子:

一个产品经理,手上有个正在开发的紧急项目,当到最后一天项目计划要完成开发工作的时候,产品经理发现有个研发所开发的模块还没开发完,项目整体出现延期风险。

研发给出的理由是总经理临时让他改一个其他项目的紧急需求,两边都是紧急项目,这个研发选择了先做领导总经理的项目。

这个产品经理气的不行,和研发吵了起来,去找老板理论;老板让这个产品经理分析哪里出了问题。

产品经理说总经理不懂先来后到,不知道研发手上有紧急的项目。

老板说,总经理和研发都没有错,站在研发的角度,迫于领导的压力,先做领导的项目;站在总经理的角度,手上的项目确实紧急。

那到底是哪里出了问题?下次遇到同样场景岂不是还是会出现这种冲突?

老板说,是流程出现了问题。

如果在流程上规避了此种风险,出现临时资源调度的情况,根据提前制定出的流程,当出现这种情况时,申请走相应的流程,需要各部门审核,这样就可以提前获得各方支持协调,而不至于出现项目延期。

现在说来,与其说是流程,不如说是规范,各业务方按照统一规范协同合作。

三、解决方案

1. 问题深度和广度判断

不管是业务异常问题,还是产品优化,都需要判断其是否有改进及迭代的价值。

通过影响的深度和广度来判断,深度即出现该业务异常后对整体生产的影响;广度及出现的频率和概率等。

而优化即是对此问题作出改进后,是否会对原业务稳定性,效率有提升。判断的依据最好可以量化。

2. 考虑最快替代方案

在《软件工程》理论中提到,任何系统,进行更新优化成本都是巨大的。

首先应该想到的是在原有基础上进行复用:其一是从业务的操作流程上进行优化;其二是从现有系统功能中使用其他功能方式替代。

这种方式不仅成本最低,也是最稳定及快速解决问题的最优方式。

3. 重新开发,成本和可行性分析

如果是需要优化该业务流程或者解决业务异常,需从产品角度重新进行可行性分析及规划。

结语

以上就是笔者根据实际工作中所遇到的,对业务诊断的思考,作为个人的一个复盘以及记录。

希望对你有帮助,欢迎指正和讨论。

本文由 @谢君翊 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

本文来自网络,不代表新锐科技自媒体博客平台立场,转载请注明出处: https://www.chaoqi.net/ganhuo/2019/1012/259765.html

作者:

这家伙太懒了,什么都没有留下!

发表评论

联系我们

联系我们

0898-88881688

在线咨询: QQ交谈

邮箱: email@wangzhan.com

工作时间:周一至周五,9:00-17:30,节假日休息

关注微信
微信扫一扫关注我们

微信扫一扫关注我们

关注微博
返回顶部