产品出现了问题，真的只是产品的问题吗？你是否想到了业务？
众所周知，B端产品服务于业务。
但回顾最近半年所做需求分析和产品设计过程中，发现一个问题：业务诊断不透彻，做出来的产品投入生产后，总有小细节漏掉或者表面上看起来满足了需求，实际却相差甚远，业务方使用起来并不符合要求。
对于这种情况，作为产品经理在做业务问题诊断的时候，真的诊断清楚了吗？
下面对业务异常之业务诊断作了一个个人的梳理。
一、出现问题
在《软件工程》中提到一个专业化的软件的四个特性中，可依赖性和安全性居于首位。
软件的稳定是保证业务运转的基石，但是总有业务阻断的风险。如电商平台，交易系统等半分钟的宕机就会造成巨大的损失。
笔者遇到的业务异常的情况分为以下几种：
- 交易系统业务全部阻断，查询，下单，支付等功能全部崩溃；
- 产线业务整体正常，总有个别产品异常。
1. 第一种情况
对于一个产品汪来说，这无疑是从睡眼朦胧到瞬间清醒的状态，立刻做好背锅的准备。
常人的第一反应是系统宕机崩溃。但是，从产品汪的角度，还应该考虑，是否是新上线的功能未测试完全导致对原有功能的影响，亦或者是临时动了哪个配置参数，导致产品逻辑变化。出现这种情况，肯定是以最快的速度修复系统问题和或者是还原产品配置。
2. 第二种情况
产线整体业务正常，个别产品由于软件问题，产生异常，这种时候产品经理就要作为一个侦探的角色去还原场景，梳理流程，整体分析此异常出现的原因及修复合理性。
下面就第二种情况作个浅谈。
二、业务诊断
业务诊断能力，贯穿所有B端产品的设计，运营，管理等。
不管系统新增需求还是迭代优化，业务诊断是一个产品经理抽象问题的基础。
全面的业务诊断，抽象出问题，最终提供一个合理有效的产品解决方案；为企业提升运转效率，经营管理辅助，是一个好的B端产品的价值所在。
当出现业务异常时候，我们应该怎么诊断问题呢？
我们可以从下面两个步骤来分析：
1. 业务背景调研
1）理解当前业务“目标”
业务背景调研的第一步，理解当前业务目标：这部分业务要实现一个怎么样的诉求，此业务问题出现在整个业务流转中的哪个节点，这个节点的目标是什么？
换句话说就是回归初心。
举个例子：
短信运营商经常会给用户发送短信提醒用户流量使用情况，目的是为了告知用户剩余流量，提示用户，防止用户在不知情的情况下流量用超。
此短信业务的目标便是告知用户短信使用情况，剩下的流量酌情使用，中国移动在发短信的时候，短信内容显示了还剩多少MB的流量可使用。
对于用户来讲，平时使用APP或者上网，流量用多少是不知道的，用户只知道每个月大概会用多少流量，并不容易知道剩下的这些（比如23643MB）流量会用多久。
相比中国移动，中国联通在发送短信时，加了一句“剩下XX%流量”可使用，这样不仅直观，而且达到了发送短信的业务目标。
2）梳理当前业务的“操作流程”
这一点是最坑爹的，有些问题本质上是流程问题，而不是软件的设计或者BUG。
业务流程涉及到多个业务角色操作，这一步我们应该梳理出当前各业务方现有的操作流程。
3）梳理当前业务“正确”的“产品逻辑”
为了实现以上的目标，梳理原有业务逻辑，和产品设计的“正确”流程。
这里的正确流程不是指绝对正确，是指基于此目的，原有产品逻辑的设计。这个设计现在可能看来不合理，但是因为需要快速上线等各种原因而被一直沿用，此时暴露出了问题，而此刻我们需要理清这个逻辑。
4）分析原有逻辑与业务目标的匹配度
在理清了现有产品逻辑之后，既然业务能正常运转肯定有它的稳定之处。但是也出现了瑕疵，说明当前产品设计不是最完美的解决方案，存在漏洞。
基于此，我们下面进一步分析。
2. 问题分析维度
1）从用户场景进行分析
用户场景在和研发梳理需求的时候，是一种沟通工具，而在分析问题或者产品设计的时候，更是一种思维工具。
产品经理应该设身处地把自己当成一线业务员，或者直接到一线观看操作业务的流程；某些问题可能并不是因为软件问题，是业务流程的问题。
对业务员来说，他会通过最方便但可能不是正确的操作流程来达到他的目的，造成这种情况的原因可能是业务员对这个业务的理解脱节，只关注到了他的节点业务，也可能是业务培训不到位造成。
当产品经理走了一遍全流程，或者进入一线用户场景调研分析后，便不会容易出现想当然的分析结果。
2）从用户角色进行分析
分析业务流程中相关的角色，各个角色对应的需求，他要实现的业务目标。
区别于整体业务目标，这里的目标是角色目标，对应岗位上的职责则不同。
3）分析用户角色之间的协同关系
产品优化方面来说，基于各个角色的业务目标分析，了解他们的诉求之后，在这个角色之间要实现一种协同平衡，实现业务稳定，效率提升，考虑该业务目标的主要受益方是谁，业务需求契合度最高的一方，此时优化方案应该偏向该角色。
对于问题查找来说，可能各个业务角色之间的协同流程都有问题，而不是软件本身的问题，规范流程，或许会豁然开朗。
这里笔者想起一个例子：
一个产品经理，手上有个正在开发的紧急项目，当到最后一天项目计划要完成开发工作的时候，产品经理发现有个研发所开发的模块还没开发完，项目整体出现延期风险。
研发给出的理由是总经理临时让他改一个其他项目的紧急需求，两边都是紧急项目，这个研发选择了先做领导总经理的项目。
这个产品经理气的不行，和研发吵了起来，去找老板理论；老板让这个产品经理分析哪里出了问题。
产品经理说总经理不懂先来后到，不知道研发手上有紧急的项目。
老板说，总经理和研发都没有错，站在研发的角度，迫于领导的压力，先做领导的项目；站在总经理的角度，手上的项目确实紧急。
那到底是哪里出了问题？下次遇到同样场景岂不是还是会出现这种冲突？
老板说，是流程出现了问题。
如果在流程上规避了此种风险，出现临时资源调度的情况，根据提前制定出的流程，当出现这种情况时，申请走相应的流程，需要各部门审核，这样就可以提前获得各方支持协调，而不至于出现项目延期。
现在说来，与其说是流程，不如说是规范，各业务方按照统一规范协同合作。
三、解决方案
1. 问题深度和广度判断
不管是业务异常问题，还是产品优化，都需要判断其是否有改进及迭代的价值。
通过影响的深度和广度来判断，深度即出现该业务异常后对整体生产的影响；广度及出现的频率和概率等。
而优化即是对此问题作出改进后，是否会对原业务稳定性，效率有提升。判断的依据最好可以量化。
2. 考虑最快替代方案
在《软件工程》理论中提到，任何系统，进行更新优化成本都是巨大的。
首先应该想到的是在原有基础上进行复用：其一是从业务的操作流程上进行优化；其二是从现有系统功能中使用其他功能方式替代。
这种方式不仅成本最低，也是最稳定及快速解决问题的最优方式。
3. 重新开发，成本和可行性分析
如果是需要优化该业务流程或者解决业务异常，需从产品角度重新进行可行性分析及规划。
结语
以上就是笔者根据实际工作中所遇到的，对业务诊断的思考，作为个人的一个复盘以及记录。
希望对你有帮助，欢迎指正和讨论。
微信扫一扫 
支付宝扫一扫 
