普通短链
活码系统
随机短链
跳转微信小程序
更多
产品经理方法论：业务异常诊断及优化
更新时间：2024-10-27 02:20:19 作者：爱短链
产品有问题，真的只是产品问题吗？你想过生意吗？
众所周知，B端产品服务于业务。
然而，回顾过去六个月的需求分析和产品设计过程，我们发现了一个问题：业务诊断不彻底。
产品投入生产后，总有小细节遗漏或表面上看起来满足需求，但实际上相差甚远，业务方不符合要求。
在这种情况下，作为一名产品经理，在诊断业务问题时，诊断真的清楚吗？ 以下是对业务异常业务诊断的个人梳理。
一、有问题 可靠性和安全性在软件工程中提到的专业软件的四个特点中排名第一。
软件的稳定性是确保业务运行的基石，但总有业务阻断的风险。
例如，电子商务平台、交易系统等半分钟的停机将造成巨大损失。
笔者遇到的业务异常情况分为以下几种: 所有交易系统业务都被阻断，查询、订单、支付等功能崩溃； 整体生产线业务正常，个别产品总有异常。
1. 第一种情况 对于一个产品王来说，这无疑是从朦胧的睡眼到瞬间清醒的状态，马上准备背锅。
普通人的第一反应是系统停机和崩溃。
然而，从产品王的角度来看，我们还应该考虑新的在线功能是否完全导致对原始功能的影响，或临时移动哪个配置参数，导致产品逻辑的变化。
在这种情况下，必须尽快修复系统问题或恢复产品配置。
2. 第二种情况 生产线的整体业务正常。
由于软件问题，个别产品出现异常。
此时，产品经理应探角色恢复场景，梳理过程，分析异常原因和修复合理性。
以下是第二种情况的简要讨论。
二、业务诊断 业务诊断能力贯穿于所有B端产品的设计、运营和管理。
业务诊断是产品经理抽象问题的基础，无论是系统的新需求还是迭代优化。
综合业务诊断，抽象问题，最终提供合理有效的产品解决方案；提高企业运营效率，管理协助，是B端产品的良好价值。
业务异常时，应如何诊断问题？ 我们可以分析以下两个步骤： 1. 业务背景研究 1)了解当前业务的目标 业务背景研究的第一步是了解当前的业务目标：这部分业务需要实现什么样的需求，哪个节点出现在整个业务流通中，这个节点的目标是什么？ 换句话说，回归初心。
举个例子： 短信运营商经常向用户发送短信，提醒用户流量的使用，目的是告知用户剩余流量，提醒用户，防止用户在不知情的情况下使用多流量。
该短信业务的目标是告知用户短信的使用情况，并酌情使用剩余流量。
当中国移动发送短信时，短信内容显示还剩多少MB可使用流量。
对于用户来说，平时使用APP或者在网上，不知道用多少流量，用户只知道每个月用多少流量，不容易知道剩下的(比如23643MB）流量会持续多久？ 与中国移动相比，中国联通在发短信时加了一句剩下的XX可以使用%流量，仅直观，而且达到发送短信的业务目标。
2)梳理当前业务的操作流程 这是最糟糕的。
有些问题本质上是过程问题，而不是软件设计或BUG。
业务流程涉及多个业务角色的操作。
在这一步中，我们应该梳理各业务方现有的操作流程。
3)梳理当前业务正确的产品逻辑 梳理原有的业务逻辑和产品设计的正确流程，实现上述目标。
这里的正确过程并不意味着绝对正确，而是指基于此目的的原始产品逻辑的设计。
这种设计现在可能看起来不合理，但由于需要快速启动和其他原因，它已经被使用，此时暴露了问题，现在我们需要澄清这个逻辑。
4)分析原逻辑与业务目标的匹配度 在澄清了现有的产品逻辑后，由于业务可以正常运行，必须有其稳定性。
但也存在缺陷，表明当前的产品设计不是最完美的解决方案，存在漏洞。
基于此，我们将在下面进一步分析。
2. 问题分析维度 1)分析用户场景 在分析问题或产品设计时，用户场景是一种沟通工具。
产品经理应将自己视为一线销售人员，或直接前往一线观看运营业务流程；有些问题可能不是因为软件问题，而是因为业务流程问题。
对于销售人员来说，他会通过最方便但可能不正确的操作流程来实现自己的目标。
造成这种情况的原因可能是销售人员对业务的理解脱节，只关注他的节点业务，或者业务培训不到位。
当产品经理完成整个过程或进入一线用户场景调查分析时，不容易出现理所当然的分析结果。
2)分析用户角色 分析业务流程中的相关角色，每个角色对应的需求，以及他想要实现的业务目标。
与整体业务目标不同，这里的目标是角色目标，相应岗位的职责也不同。
3)分析用户角色之间的协同关系 在产品优化方面，在分析每个角色的业务目标后，了解其需求，实现协调平衡，实现业务稳定，提高效率，考虑业务目标的主要受益者，业务需求合作度最高，优化方案应偏向角色。
对于问题搜索，各业务角色之间的协同流程可能存在问题，而不是软件本身的问题。
规范流程可能会突然开明。
笔者想起了一个例子： 产品经理手中有一个正在开发的紧急项目。
当项目计划在最后一天完成开发工作时，产品经理发现研发开发的模块尚未开发，整个项目存在延迟风险。
R&D给出的理由是总经理暂时要求他改变其他项目的紧急需求，双方都是紧急项目。
这个R&D选择了先做领导总经理的项目。
产品经理很生气，与研发争吵，去找老板理论；老板让产品经理分析问题。
产品经理说总经理不知道先来后来，不知道R&D有紧急项目。
老板说总经理和R&D没有错。
从R&D的角度来看，在领导的压力下，先做领导项目；从总经理的角度来看，手头的项目真的很紧急。
到底出了什么问题？下次遇到同样的场景还会有这样的冲突吗？ 老板说过程有问题。
如果在过程中避免这种风险，出现临时资源调度，根据提前制定的过程，当出现这种情况时，申请采取相应的过程，需要各部门审核，以便提前得到各方的支持和协调，不延长项目。
现在，与其说是流程，不如说是规范，各业务方按照统一规范合作。
三、解决方案 1. 判断问题的深度和广度 无论是业务异常还是产品优化，都需要判断是否有改进和迭代的价值。
从影响的深度和广度来看，深度是业务异常后对整体生产的影响；广度、频率和概率等。
优化是指在改进这一问题后，是否会提高原有业务的稳定性和效率。
最好量化判断依据。
2. 考虑最快的替代方案 软件工程理论中提到，任何系统更新优化的成本都是巨大的。
首先要考虑的是在原有的基础上重用:一是优化业务操作流程；二是用其他功能替换现有系统功能。
这种方法不仅成本最低，而且是解决问题最稳定、最快的方法。
3. 重新开发、成本和可行性分析 如果需要优化业务流程或解决业务异常，需要从产品的角度进行可行性分析和规划。
结语 以上是笔者根据实际工作对业务诊断的思考，作为个人的复习和记录。
希望对您有所帮助，欢迎指正和讨论。
特别说明：本网站的主要目的是收集与互联网运营相关的干货知识，为运营伙伴提供便利。
本网站收集的公共内容来自互联网或用户的贡献，这并不意味着本网站同意其观点，也不对网站内容的真实性负责。
如有侵权行为，请联系网站管理员删除，。
然而，回顾过去六个月的需求分析和产品设计过程，我们发现了一个问题：业务诊断不彻底。
产品投入生产后，总有小细节遗漏或表面上看起来满足需求，但实际上相差甚远，业务方不符合要求。
在这种情况下，作为一名产品经理，在诊断业务问题时，诊断真的清楚吗？ 以下是对业务异常业务诊断的个人梳理。
一、有问题 可靠性和安全性在软件工程中提到的专业软件的四个特点中排名第一。
软件的稳定性是确保业务运行的基石，但总有业务阻断的风险。
例如，电子商务平台、交易系统等半分钟的停机将造成巨大损失。
笔者遇到的业务异常情况分为以下几种: 所有交易系统业务都被阻断，查询、订单、支付等功能崩溃； 整体生产线业务正常，个别产品总有异常。
1. 第一种情况 对于一个产品王来说，这无疑是从朦胧的睡眼到瞬间清醒的状态，马上准备背锅。
普通人的第一反应是系统停机和崩溃。
然而，从产品王的角度来看，我们还应该考虑新的在线功能是否完全导致对原始功能的影响，或临时移动哪个配置参数，导致产品逻辑的变化。
在这种情况下，必须尽快修复系统问题或恢复产品配置。
2. 第二种情况 生产线的整体业务正常。
由于软件问题，个别产品出现异常。
此时，产品经理应探角色恢复场景，梳理过程，分析异常原因和修复合理性。
以下是第二种情况的简要讨论。
二、业务诊断 业务诊断能力贯穿于所有B端产品的设计、运营和管理。
业务诊断是产品经理抽象问题的基础，无论是系统的新需求还是迭代优化。
综合业务诊断，抽象问题，最终提供合理有效的产品解决方案；提高企业运营效率，管理协助，是B端产品的良好价值。
业务异常时，应如何诊断问题？ 我们可以分析以下两个步骤： 1. 业务背景研究 1)了解当前业务的目标 业务背景研究的第一步是了解当前的业务目标：这部分业务需要实现什么样的需求，哪个节点出现在整个业务流通中，这个节点的目标是什么？ 换句话说，回归初心。
举个例子： 短信运营商经常向用户发送短信，提醒用户流量的使用，目的是告知用户剩余流量，提醒用户，防止用户在不知情的情况下使用多流量。
该短信业务的目标是告知用户短信的使用情况，并酌情使用剩余流量。
当中国移动发送短信时，短信内容显示还剩多少MB可使用流量。
对于用户来说，平时使用APP或者在网上，不知道用多少流量，用户只知道每个月用多少流量，不容易知道剩下的(比如23643MB）流量会持续多久？ 与中国移动相比，中国联通在发短信时加了一句剩下的XX可以使用%流量，仅直观，而且达到发送短信的业务目标。
2)梳理当前业务的操作流程 这是最糟糕的。
有些问题本质上是过程问题，而不是软件设计或BUG。
业务流程涉及多个业务角色的操作。
在这一步中，我们应该梳理各业务方现有的操作流程。
3)梳理当前业务正确的产品逻辑 梳理原有的业务逻辑和产品设计的正确流程，实现上述目标。
这里的正确过程并不意味着绝对正确，而是指基于此目的的原始产品逻辑的设计。
这种设计现在可能看起来不合理，但由于需要快速启动和其他原因，它已经被使用，此时暴露了问题，现在我们需要澄清这个逻辑。
4)分析原逻辑与业务目标的匹配度 在澄清了现有的产品逻辑后，由于业务可以正常运行，必须有其稳定性。
但也存在缺陷，表明当前的产品设计不是最完美的解决方案，存在漏洞。
基于此，我们将在下面进一步分析。
2. 问题分析维度 1)分析用户场景 在分析问题或产品设计时，用户场景是一种沟通工具。
产品经理应将自己视为一线销售人员，或直接前往一线观看运营业务流程；有些问题可能不是因为软件问题，而是因为业务流程问题。
对于销售人员来说，他会通过最方便但可能不正确的操作流程来实现自己的目标。
造成这种情况的原因可能是销售人员对业务的理解脱节，只关注他的节点业务，或者业务培训不到位。
当产品经理完成整个过程或进入一线用户场景调查分析时，不容易出现理所当然的分析结果。
2)分析用户角色 分析业务流程中的相关角色，每个角色对应的需求，以及他想要实现的业务目标。
与整体业务目标不同，这里的目标是角色目标，相应岗位的职责也不同。
3)分析用户角色之间的协同关系 在产品优化方面，在分析每个角色的业务目标后，了解其需求，实现协调平衡，实现业务稳定，提高效率，考虑业务目标的主要受益者，业务需求合作度最高，优化方案应偏向角色。
对于问题搜索，各业务角色之间的协同流程可能存在问题，而不是软件本身的问题。
规范流程可能会突然开明。
笔者想起了一个例子： 产品经理手中有一个正在开发的紧急项目。
当项目计划在最后一天完成开发工作时，产品经理发现研发开发的模块尚未开发，整个项目存在延迟风险。
R&D给出的理由是总经理暂时要求他改变其他项目的紧急需求，双方都是紧急项目。
这个R&D选择了先做领导总经理的项目。
产品经理很生气，与研发争吵，去找老板理论；老板让产品经理分析问题。
产品经理说总经理不知道先来后来，不知道R&D有紧急项目。
老板说总经理和R&D没有错。
从R&D的角度来看，在领导的压力下，先做领导项目；从总经理的角度来看，手头的项目真的很紧急。
到底出了什么问题？下次遇到同样的场景还会有这样的冲突吗？ 老板说过程有问题。
如果在过程中避免这种风险，出现临时资源调度，根据提前制定的过程，当出现这种情况时，申请采取相应的过程，需要各部门审核，以便提前得到各方的支持和协调，不延长项目。
现在，与其说是流程，不如说是规范，各业务方按照统一规范合作。
三、解决方案 1. 判断问题的深度和广度 无论是业务异常还是产品优化，都需要判断是否有改进和迭代的价值。
从影响的深度和广度来看，深度是业务异常后对整体生产的影响；广度、频率和概率等。
优化是指在改进这一问题后，是否会提高原有业务的稳定性和效率。
最好量化判断依据。
2. 考虑最快的替代方案 软件工程理论中提到，任何系统更新优化的成本都是巨大的。
首先要考虑的是在原有的基础上重用:一是优化业务操作流程；二是用其他功能替换现有系统功能。
这种方法不仅成本最低，而且是解决问题最稳定、最快的方法。
3. 重新开发、成本和可行性分析 如果需要优化业务流程或解决业务异常，需要从产品的角度进行可行性分析和规划。
结语 以上是笔者根据实际工作对业务诊断的思考，作为个人的复习和记录。
希望对您有所帮助，欢迎指正和讨论。
特别说明：本网站的主要目的是收集与互联网运营相关的干货知识，为运营伙伴提供便利。
本网站收集的公共内容来自互联网或用户的贡献，这并不意味着本网站同意其观点，也不对网站内容的真实性负责。
如有侵权行为，请联系网站管理员删除，。
相关搜索
