当前位置: 首页 » 科技 » 正文 »

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

放大字体  缩小字体 时间:2019-11-14 10:24:24 来源:未知 作者: 匿名    
对于这种情况,作为产品经理在做业务问题诊断的时候,真的诊断清楚了吗?下面对业务异常之业务诊断作了一个个人的梳理。业务诊断能力,贯穿所有b端产品的设计,运营,管理等。3)梳理当前业务“正确”的“产品逻辑

产品有问题。这真的只是一个产品问题吗?你想过生意吗?

众所周知,低端产品为企业服务。

然而,回顾过去六个月所做的需求分析和产品设计过程,发现了一个问题:业务诊断不彻底,成品投产后,总会有小细节缺失或看似满足需求,但实际差距很大,使用时业务方不满足需求。

对于这种情况,作为一名产品经理在做业务问题诊断时,诊断是否真的很明确?

以下是对业务异常的业务诊断的个人回顾。

在软件工程中提到的专业软件的四个特征中,依赖性和安全性是第一个。

软件的稳定性是保证业务运营的基石,但总是存在业务中断的风险。如电子商务平台、交易系统等,半分钟的停机将造成巨大损失。

作者遇到的异常业务情况可分为以下几类:

对于王氏产品来说,这无疑是从睡眼惺忪到一瞬间清醒的状态,随时准备拿起锅。

普通人的第一反应是系统停机和崩溃。但是,从产品王(product Wang)的角度来看,还应该考虑新生产线的未测试功能是否完全影响了原有功能,或者哪个配置参数被临时激活,导致了产品的逻辑变化。如果发生这种情况,必须尽快修复系统问题和/或恢复产品配置。

生产线的整体业务正常,有些产品由于软件问题而出现异常。此时,产品经理应充当侦探,恢复现场,整理流程,分析异常原因和修复的合理性。

让我们谈谈第二个案例。

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

无论新系统需求或迭代优化如何,业务诊断都是产品经理抽象问题的基础。

全面的业务诊断,抽象问题,最终提供合理有效的产品解决方案;一个好的B-end产品的价值在于提高企业的运营效率,辅助运营和管理。

当出现业务异常时,我们应该如何诊断问题?

我们可以从以下两个步骤进行分析:

1)了解当前业务的“目标”

业务背景调查的第一步是了解当前的业务目标:这部分业务应该实现什么样的需求,这个业务问题发生在整个业务流程的哪个节点,这个节点的目标是什么?

换句话说,这意味着回到起点。

例如:

短信运营商经常向用户发送短信,提醒他们使用流量。目的是通知用户剩余流量,提示用户,并防止用户在不知情的情况下使用过量流量。

该短信服务的目标是通知用户短信的使用情况,并酌情使用剩余的流量。当中国移动发送短信时,短信的内容显示还有多少兆的流量可用。

对于用户来说,不知道他们平时在使用应用程序或上网时使用了多少流量。用户只知道他们每月将使用多少流量,不容易知道剩余流量(例如23643mb)将持续多长时间。

与中国移动相比,中国联通在发送短信时增加了“剩余流量的xx%,这不仅直观,而且实现了发送短信的业务目标。

2)梳理当前业务的“运营流程”

这是最严重的一点。有些问题本质上是过程问题,而不是软件设计或缺陷。

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

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

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

这里正确的过程不是指绝对的正确性,而是指基于这一目的的原始产品逻辑的设计。这种设计现在看起来可能不合理,但它已经被用于各种原因,例如需要快速上网。此时,问题已经暴露出来,此时,我们需要澄清这一逻辑。

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

在澄清了现有的产品逻辑之后,因为业务可以正常运行,所以必须有一定的稳定性。然而,也存在一些缺陷,表明目前的产品设计不是最完美的解决方案,存在漏洞。

基于此,我们将在下面做进一步的分析。

1)用户场景分析

用户场景是将需求与研发结合起来的沟通工具,也是分析问题或产品设计的思考工具。

产品经理应该把自己放在第一线销售人员的位置,或者直接去第一线观察操作过程。有些问题可能不是由软件问题引起的,而是由业务流程引起的。

对于销售人员来说,他将通过最方便但可能不正确的操作过程来实现他的目标。原因可能是销售人员对该业务的理解脱节,他只专注于他的节点业务,或者业务培训不到位。

当产品经理经历整个过程或进入一线用户现场进行调查和分析时,将分析结果视为理所当然并不容易。

2)从用户角色分析

分析业务流程中的相关角色、每个角色对应的需求以及他想要实现的业务目标。

与总体业务目标不同,这里的目标是角色目标,而相应职位的职责是不同的。

3)分析用户角色之间的合作关系

在产品优化方面,在分析每个角色的业务目标的基础上,在了解他们的需求之后,应该在角色之间实现协作平衡,以实现业务稳定性和效率提高。考虑到谁是业务目标的主要受益者和业务需求最高的一方,优化方案应该偏向于这一角色。

对于问题发现,可能是各种业务角色之间的协作过程有问题,而不是软件本身有问题。标准化过程可能会突然得到启发。

这里我想到一个例子:

一位产品经理手头有一个正在开发的紧急项目。当项目计划在最后一天完成开发工作时,产品经理发现研发部门开发的模块还没有开发出来,整个项目有延迟的风险。

R&D给出的理由是总经理临时要求他改变其他项目的迫切需求。双方都是紧急项目。这个R&D首先选择了领导总经理的项目。

产品经理很生气,和R&D吵了一架,去找老板的理论。老板要求产品经理分析出了什么问题。

产品经理说总经理不知道先到达,也不知道研发团队有紧急项目。

老板说总经理和R&D没有什么问题,从R&D的角度来看,在领导的压力下,应该先领导这个项目。从总经理的角度来看,手头的项目确实很紧迫。

到底是什么问题?下次你遇到同样的场景时,这种冲突还会发生吗?

老板说这个过程有问题。

如果在过程中避免了这种风险,并且发生了临时资源调度,根据预先开发的过程,当这种情况发生时,应用程序将经过相应的过程,需要各部门的审核,以便提前获得各方的支持和协调,避免项目延误。

现在,与其说这是一个过程,不如说是一个标准。所有业务方按照统一的标准进行合作。

无论是业务异常还是产品优化,都有必要判断它是否具有改进和迭代的价值。

从影响的深度和广度来看,深度是业务异常发生后对整体生产的影响;发生的广度、频率和概率等。

优化是指改进后原有业务的稳定性和效率是否会得到提高。最好量化判断的基础。

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

首先要考虑的是在原有基础上重用:首先,优化业务的操作流程;第二是用其他功能方法取代现有的系统功能。

这种方法不仅成本最低,而且是解决问题最稳定、最快速的方法。

如需优化业务流程或解决业务异常,应从产品角度重新进行可行性分析和规划。

以上是作者根据实际工作对企业诊断的思考,作为个人的复制和记录。

我希望这对你有所帮助。请纠正我并讨论它。

这篇文章最初是由@谢君毅发表的。每个人都是产品经理。未经允许禁止复制。

主题地图来自unsplash,基于cc0协议。

中国一分彩 一定牛彩票网 贵州11选5 山西11选5

 
 

 

 
整站最新
 
栏目最新
 
随机推荐