Entrar Agora 做产品时间一长，人很容易掉进一个思维惯性里：一遇到事情，第一反应就是怀疑软件哪里没写好，或者逻辑上出了差错。可业务跑不通，真的全是产品本身的问题吗？很多时候，我们活儿都花在功能细节上，却忘了往后退一步，看看生意的全貌。
过去半年我反复复盘需求分析和产品设计，踩得最多的一个坑，就是业务诊断做得不够彻底。功能上线了，总有那么些小细节漏掉，或者表面看是满足了需求，实际用起来完全不是那么回事，业务方一上手就皱眉。这时候才慢慢看清，问题往往不在代码，而在最初对业务的理解有没有真正到位。
B端产品天然就是为业务服务的，这谁都知道。可“知道”和“做到”之间，差的就是对业务异常的一次次追问。下面这些思考，算不上高明，但确实是从好几次背锅经历里长出来的。
业务异常，我大致把它分成两类。
第一种，是全链路崩溃。比如交易系统整个挂了，查询、下单、支付全部瘫痪。这种时候，脑子几乎是瞬间从“还有点困”切换到“完了要背锅”的状态。普通人的第一反应肯定是“系统崩了”，但作为产品经理，你得再多想一层：是不是新上线的功能影响到了原有逻辑？或者是不是有人临时改了某个配置，导致整个业务流变了向？这种时刻，最要紧的是快速恢复，不管是修系统还是回滚配置，得把损失降到最低。
第二种更常见，也更容易被忽略——整体业务正常，但个别产品总出小毛病。这时候，产品经理就得沉下心，去还原场景、梳理流程，分析异常到底是怎么出现的，以及修复方案合不合理。今天重点聊的，就是这一种。
业务诊断，其实是个手艺活，贯穿了B端产品从设计到运营的整个生命周期。不管是做新需求，还是做迭代优化，想把问题抽象对，前提一定是先把业务吃透。诊断清楚了，抽象出来的东西才靠谱，最终给出的解决方案才能真正提升效率、辅助管理——这才是B端产品该有的价值。
当业务出异常时，我习惯分两步入手。
第一步，是回到业务现场，把背景摸透。
首先，你得搞清楚业务到底想达成什么目标。这恰恰是最容易被跳过的一步。得问自己：这部分业务究竟要完成什么需求？它在整个业务流里处在哪个节点？这个节点为什么存在？说白了，就是“回归初心”。
举个例子，运营商给用户发短信提醒流量使用情况。这个动作的目标是什么？是告知用户剩余流量，避免在不知情的时候用超了。结果有的运营商只会告诉你“还剩多少MB”，可用户对数字其实不敏感，根本不知道这点流量还能撑多久。而有的运营商多加了一句“剩余流量还能用XX%”，一下子就让用户有了直观感受，这才真正达成了发送短信想达到的业务目标。你看，功能都做了，但有没有贴着业务目标去做，效果天差地别。
其次，把当前的操作流程完整走一遍。这是最“笨”也最管用的一步。很多问题本质上是流程出了问题，不是软件设计或者BUG。业务流程往往涉及多个角色、多个操作环节，如果不亲自去走一遍，你很难发现某个环节的操作其实已经跑偏了。所以，产品经理得化身为一线人员，去观察、去记录，别坐在办公室里想当然。
接着，梳理清楚原本正确的产品逻辑。这里的“正确”不是指绝对真理，而是基于当初那个业务目标，产品设计出来的原始逻辑。这个逻辑可能现在看起来不够合理，但因为要快速上线等原因，当时就那么用了，现在问题慢慢暴露出来。我们得先把这个逻辑脉络理清楚，知道它为什么能跑通，又为什么有缺陷。
最后，比对原逻辑和业务目标的匹配度。既有逻辑能支撑业务正常运行，说明它有一定的稳定性。但漏洞既然出现了，就说明当前的设计不是最优解。走到这一步，我们才算真正拿到了分析问题的入场券。
第二步，是从几个维度拆解问题。
第一个维度，回到用户场景里去。用户场景是个特别好的沟通工具，也是分析问题的抓手。产品经理一定要把自己当成一线销售，或者干脆去一线看运营是怎么操作的。有些问题可能根本就不是软件的问题，而是业务流程本身的问题。比如，销售为了达成自己的目标，会习惯性地用最方便但可能不太规范的操作路径。这可能是因为他对业务的理解有断层，只盯着自己那一亩三分地，也可能是培训没到位。当你亲身走完一遍流程，或者扎进一线观察过，就不会那么容易得出“理所当然”的分析结论。
第二个维度，看清都有哪些角色在参与。业务流程里涉及了哪些角色？每个角色对应的需求是什么？他想达成的个人目标又是什么？这里的目标和整体业务目标不一定完全相同，因为岗位职责不同，关注点自然有差异。把这些角色一个个拆出来看，才能看清他们各自的需求和动作。
第三个维度，搞懂角色之间是怎么协同的。在做产品优化时，我们会在分析完各个角色的目标后，想办法去平衡和协调，让业务更稳定、效率更高，同时还要考虑谁才是业务目标的主要受益者，谁的配合度最高，方案该往哪个方向倾斜。而在排查问题时，各业务角色之间的协同流程往往才是症结所在，而不是软件本身。有些问题，把流程规范一下，可能就豁然开朗了。
想起一个挺典型的例子。有个产品经理手里有个紧急项目，开发排期到了最后一天，他却发现研发那边有个模块根本没动，整个项目有延期的风险。研发的理由是：总经理临时让他去改另一个项目的紧急需求，两边都是急茬，他只能先做领导的那个。产品经理很生气，跟研发吵了一架，又跑去找老板理论。老板让他分析问题出在哪，他说总经理不懂先来后到，不知道研发手头有急活。老板却说，总经理和研发都没错——从研发的角度看，领导施压，他只能先做领导的项目；从总经理的角度，他手上的项目确实也急。那问题到底在哪？下次遇到同样场景，是不是还会爆发冲突？老板最后点了一句：“是流程的问题。”
如果提前有一套流程，能规避这种临时资源调度的风险，比如遇到紧急情况必须走申请、经过多部门审核，那就能提前获得各方支持和协调，不至于让项目延期。与其说这是流程，不如说是一种规范，让各业务方按统一的规范来协作。
搞清楚问题之后，还得想想怎么解决，但不能只盯着功能。
先判断一下问题的深度和广度。不管是业务异常还是产品优化，改进和迭代的价值都得掂量掂量。深度，就是这个问题对整体业务的影响有多大；广度，就是它发生的频率、概率高不高。优化之后，能不能明显提升原有业务的稳定性和效率？最好能把判断依据量化，哪怕只是简单的估算，也比拍脑袋强。
再优先考虑最快的替代方案。软件工程里有个很实在的观点：任何系统的更新优化，成本都是巨大的。所以，能重用的先重用。一是看看能不能优化业务操作流程，别老想着动代码；二是看看能不能用现有系统的其他功能来替代。这条路成本最低，也最稳、最快。
真要动刀重新开发，那就老老实实做可行性分析。从产品角度好好做规划，成本、风险、可行性都得过一遍，心里有数再动手。
说到底，业务诊断考验的，不只是产品设计能力，更是对生意和业务的理解。每一次异常复盘，其实都是在帮我们离真实的业务更近一点。这些，算是我自己工作里的一点记录，如果能给你带来点启发，那就再好不过了。