本文作者从自己的实际工作出发，结合案例对业务异常的情况、预防方案和解决方案进行了梳理分析和总结，供大家一同学习和参考。
由于疫情影响，在延长的假期中抽空回顾了近一年多来的产品工作。收获之于发现了一个比较明显且出现率很高的问题：产品部署上线后，经常会出现未曾预见但又未做处理的异常情况，导致客户使用体验很差，团队也要频繁返工补漏，很是痛苦。
针对这种情况与产品同行们交流后发现，这是一个很常见但又经常被产品经理忽视的非功能性异常处理。
本文将尝试用实际工作中的真实案例，来讲述如何防范和应对此类问题。既是对自身产品工作的复盘总结，也是与产品同行们的一次分享交流。
一、前言
众所周知，一款优秀的产品不仅能够满足用户需求、解决用户刚需，更要在用户体验上保持高度的完整性、连贯性和容错性。此时就需要产品经理们在产品需求确定与设计环节，全面考虑当前产品所面临的各种使用场景与交互逻辑。
也就是说，产品经理除了需要将产品正常逻辑梳理清楚之外，更需要将不属于正常流程、不属于业务范围或不在产品可控范围的情况考虑周全。因此，异常设计是产品设计中不可或缺的重要模块。
需要说明的是，本文不讨论类似于网络中断、服务器出错等“正常”的功能性异常。此处之所以称之为正常，是因为这是产品设计中已经约定俗成的设计模块，大多数产品团队都有一套完整且成熟的处理方案。例如下图所示，各产品都对网络中断进行了异常处理。
同时有关功能性异常的情况说明，网络上也不乏相关的优秀文章，例如在《设计中的异常：超全面的设计异常情况和处理方式汇总》一文中，非常全面的罗列了各种情况，足够充分，本文不再赘述。
相较于“正常”的异常，本文讨论的是极容易被产品团队忽略又非常至关重要的业务异常。说它被忽略大部分是因为业务分析不够透彻，忽视细节纰漏百出。说它重要是由于一旦出现此类型异常，轻则会影响业务重则导致业务链断裂，根本无法满足用户需求。
那么到底什么是业务异常呢？
二、业务异常
2.1 概念说明
在说明什么是业务异常之前，我们首先要明白什么是业务需求？
通俗来说，业务需求是基于企业商业目的的实际业务的需求，大多数来源于企业高层或市场业务部门。与功能需求不同的是，业务需求不仅仅关注要实现什么具体功能，更关注此项功能与业务结合后能满足什么使用场景、带来什么业务价值。
而在业务需求细化过程中，对各个业务逻辑分支的处理，就要考虑到当前业务流程可能出现的各类场景情形，并为之针对性提供解决方案。于是不难得知：
业务异常处理是业务需求逻辑细化过程中，对业务流程异常情形的处理。
2.2 举例分析
几乎所有的互联网产品中都有登录注册模块，一方面要为用户建立虚拟身份，用以记录个人数据；另一方面可以针对用户属性提供个性化服务。除此之外在 ToB 产品中，用户身份可能关联着某些重要的业务，例如用户角色、功能权限等。
那么此时，登录注册模块就不仅要考虑要正常登录/注册流程中的异常，还要考虑其牵扯到的业务逻辑异常。例如下图是销售获客综合体验不错的加推 APP，其登录注册流程就涉及到用户身份的业务，对企业主体或企业员工进行不同的流程分支。
通过初步分析，在此业务逻辑中需要分别梳理以下三部分：
- 功能正常流程：顺利正确注册/登录进入 APP 的流程
- 功能异常流程：如手机号格式错误、网络中断等异常
- 业务异常流程：如已有企业再注册如何处理等异常
首先功能正常流程如上图所示，不再重复展示。而功能异常流程，简单体验后如下图所示：
可以看到加推对常见的手机号格式错误、网络中断与企业名称重复等异常均做了针对性处理，提示明确且体验良好。那么本文强调的业务异常呢？
我们先尝试用一个清单来简单罗列可能出现的情况：
- 注册时加错企业如何处理
- 加入企业后，返回上页再加入另外的企业如何处理
- 加入企业后再注册如何处理
- 加入企业后再登录如何处理
- 已有企业的用户重新注册时如何处理
- 企业管理员长时间未批准如何处理
带着上述问题继续细致体验后发现，注册且提示加入成功后，仍然可以通过返回按钮返回上级重新选择企业并成功加入，但无提示或历史加入记录。同时加入企业成功后等待通过时，不论是注册还是登陆都进入等待同意申请页面，流程合理。最后如果已有企业用户重新注册也不会被阻断，而是会进入选择企业页面(如果只有一家企业，则会直接进入)，流程合理，具备流程连贯性。具体如下图所示：
由此可以看出上述清单中，前五个可能存在的业务异常均已得到妥善的解决。但在体验过程中还发现，加入企业且等待申请通过时再登录，此时无法更换企业。而且如果企业管理员一直不处理请求，用户端也无任何提示。同时在注册流程走完且加入企业申请后，可以一直通过返回按钮返回到首页，且仍然可以走注册流程，重新修改资料并进行其他企业的申请。
相对来说，这些流程似乎不太合理。于是重新梳理清单后如下：
注册时加错企业如何处理加入企业后，返回上页再加入另外的企业如何处理加入企业后再注册如何处理加入企业后再登录如何处理已有企业的用户重新注册时如何处理- 企业管理员长时间未批准如何处理
- 加入企业后再登录想更换企业如何处理
- 加入企业后通过返回按钮可以回到首页是否合理
不难发现，清单中未得到解决的问题，就是本文重点关注的很容易被忽略但用户又有可能会触发的异常情况。如果此类场景未做处理，在流程中断的同时也会降低用户使用体验。
那么如何解决这些异常流程呢？
2.3 优化建议
既然已经发现了场景明确的问题，那么很容易就通过一些简单的预防型提示或主动操作来规避这些问题。
例如可行的优化建议有：企业管理员长时间未批准时，用户可以通过类似“催办提醒”的按钮来提醒或联系企业管理员。系统也可以通过 APP 内消息、短信服务等措施发送至管理员端。其次加错企业可以通过登录后页面中的“重新申请”按钮，自行重新申请。最后回到首页的问题可以通过点击返回按钮提示“是否重新注册”来解决。
具体归纳如下：
企业管理员长时间未批准如何处理
- 用户主动通过类似“提醒管理员”按钮来快速催办
- 用户主动通过类似“联系管理员”按钮来联系企业管理员
- 系统默认 24 小时不处理自动触发推送消息来提醒企业管理员
加入企业后再登录想更换企业如何处理
- 提供类似“重新选取”按钮来切换企业
- 提供类似“等待申请通过时，暂不支持切换企业”相关文案说明
加入企业后通过返回按钮可以回到首页是否合理
- 提供“您已申请成功，是否回到主页”提示框
当然以上优化方案仅为建议可选方案，均存在细节考究。例如主动提醒是否有时间限制？每天允许提醒几次？默认多长时间自动触发等细节，不在本文重点范围，不展开描述。
三、预防方案
从第二节注册登录的真实案例中，我们已经初步了解到业务异常的概念、出现场景及其解决方案。那么在日常产品设计工作中，产品经理们要如何预防此类异常的发生呢？
3.1 业务自查表
关于自查表，产品相关工作者一定不会陌生。它的百度百科定义是：
按照系统工程分析方法，在对一个系统进行科学分析的基础上，找出各种可能存在的风险因素，然后以提问的方式将这些风险因素列成的表格。
其实简单来说，自查表就是一份可能出现风险的产品问题清单。如果有细心的读者可以发现，在本文 2.2 节中已经列出了一个清单，这就是简单的自查表。
值得强调的是，不论是需求分析、交互设计还是业务逻辑方面，自查表既能保证产品设计过程中不遗漏各类细节，也能梳理出详细的业务流程。所以在预防业务异常时，一份完善详细的业务自查表必不可少。
那么在业务繁多尤其在各业务都很复杂的 ToB 产品中，我们如何建立一份完善且合理的业务自查表呢？
首先母庸质疑的是，我们必须深度了解业务需求背后的业务场景。并根据实际的业务场景梳理出当前业务的流程图、状态机图等 UML 图，便于充分理解业务。
关于 UML 图的说明，可查阅本系列的另一篇文章《大话PM | 产品经理必备利器：UML》。如果是一些复杂且专业的核心业务流程，在必要时还需要业务部门配合梳理。
如下图是某项目申请单的核心流程状态机图：
其次在此基础上，按照业务正向流程逐个排查每一个业务状态下，各种操作可能出现的情形，并对可能出现的异常情况做好记录。而且在确保正向已经梳理完毕的同时，也要尝试检查反向流程是否也存在问题。
最后一个非常重要的环节，就是带着吹毛求疵的态度，刻意寻找流程中的漏洞。尤其是一些涉及到商品或金额交易等敏感业务，更要抱着恶意灰产的角色，避免出现被薅羊毛的重大问题。前段时间京东的薅家电事件，可以说是损失重大，最真实的惨痛教训。
当然在整个自查流程中，不要忘记随时做好记录，并最终整理成一份针对性的业务自查表。
整体流程图示如下：
3.2 知识库
相较于自查表，知识库是一种覆盖范围更全面、内容更有组织的知识管理工具，常用于团队、组织或企业。在知识库中，产品团队可以共同储存、分享及管理产品相关文档。那我们如何利用知识库来预防业务异常呢？
从 3.1 节我们已经有了针对某项具体业务的单个自查表，那么如果有多个类似业务的自查表，就完全可以总结归纳出此类业务的共性，将它们相同的业务流程及对应的异常进行常规化处理，并形成对应的知识库。
此时如果再次遇到类似的业务，产品经理只要关注核心业务逻辑异常即可，其他异常可以直接根据知识库进行核查。既减少了工作量提高了效率，也能保证不会对常见的异常进行遗漏。
例如下图所示，A 和 B 同样都是登录功能，但功能对应的业务不同。此时知识库可以采取两者自查表的交集部分，就是登录业务模块的共性自查表。
但要注意的是，知识库是在长期工作中不断丰富、完善和沉淀的产物。产品团队不仅要学会利用知识库，更要利用丰富的产品业务场景来反哺知识库，这样才能发挥出其强大的作用。
3.3 头脑风暴
头脑风暴是敏捷开发中一项很特别也很有趣的会议，它是指：
在正常融洽和不受任何限制的气氛中以会议形式进行讨论、座谈，打破常规，积极思考，畅所欲言，充分发表看法。
也就是说你可以在头脑风暴会议上充分展开想象，对产品进行讨论，并无对错之分。但要注意的是，在此处强调的头脑风暴，并非倡导各个产品团队开展这样的会议，而是要掌握并利用头脑风暴的方法，来从不同的角度更加全面的讨论问题。
例如在产品需求分析会时，整个产品团队中的任一个成员都可以对业务逻辑进行非常规的思考。它的作用在于，不同角色成员对待需求及其背后的业务认知可能不一样，这样看待问题的角度就会不一样。重要的是，这些不一样的观点往往就是异常发生的场景所在。产品经理可以根据不同的意见或建议，对业务逻辑进行优化或补充。
当然不一定非要在需求会运用这样的方法，也可以在设计会、每日站会甚至个人每天自我总结时运用，同样会有意想不到的效果。
四、解决方案
尽管我们在第三节介绍了几种有效的预防方案，但事实上仍然可能存在极个别异常成为漏网之鱼，此时需要我们放平心态去积极解决。
解决问题的首先，一定是根据异常反馈针对性的定位问题，此时业务流程图依然会起到很大的帮助作用。顺利定义问题后，还需要根据异常的影响范围确定其紧急度。
如果此异常已造成重大业务影响，则必须高优先级解决问题，即刻修复、测试、打包并上线；反之如果是影响度较小或者是一些体验上的问题，则完全可以规划到最近的迭代版本中，进行集中优化。
分析并确立好方案后，不论是产品经理个人还是整个产品团队都应该积极总结复盘，找出问题出现的根本原因，并根据实际情况决定是否丰富知识库与自查表，以便未来避免同类问题。
说到这里，如果有拿到 PMP 认证的读者伙伴，很容易明白上文提到的知识库与自查表，其实就是 PMI 所提倡的风险登记册与经验教训登记册。但要知道工具并非解决问题的最佳方案，而是在面对不同场景时，合理的使用正确的方案，才是最佳的解决方案。
所以说产品经理与项目经理，虽然有类别差异之分，但在流程管理和方法论的本质上都是相通的。
总结
至此，本文对于业务异常及其预防和解决方案就已经全部阐述完毕。
需要补充强调的是，本文虽然以简单的登录注册模块为例，但业务异常与产品本身的业务紧密相关，不同的业务可能就带来不同的异常情形。所以产品经理及其团队一定要掌握其分析及处理方法，这样才能在各类业务的处理中得心应手。
此外在很多情况下，业务异常流程可能比正常流程还要多，此时就需要团队评估实现成本与实现价值，看是否有必要处理全部的异常逻辑。在需求紧急的情况下，仍然建议优先关注核心业务逻辑，但不要忘记做好业务异常的预备处理。
