如何减少打断提升效率
去年接手一个上线小十年的系统，由于这个系统是出于上下游的中间环节（意味着会跟几乎所有系统打交道），并且存在着大量的历史包袱（意味着很多黑盒，一些奇怪的用法以及机制），导致这个系统的日常工作最为繁重。
我们面向的用户是所有的系统开发者，问题涉及各类调用问题，白名单，权限审批，机制，线上问题排查等等，其中很大一部分需要有实时反馈，这就意味着日常工作中的打断非常多，进而导致团队的效率下降，以及整体产出变少。
对此，经过近一年的优化和改进，我们已经成功地将打断减少了 90% 以上，并且确保服务质量。
以下分享一些过程中的经验
让每个人深切感受到打断
所有人都需要真切感受到被打断、拉群
- 轮值作为接口人，不能让某个人或某几个人单独作为这种打断的受害者，脏活累活得平摊开
- 项目的负责人不能例外
- 产品经理也不能例外，直接在一些接收用户的反馈
跟吃自己的狗粮类似，所有人参与到轮值中，就能覆盖到各类咨询问题的方方面面。
记录，记录，记录
轮值的助手需要记录：
- 用户咨询的问题
- 原因及解决方案
- 如果是操作类，做了哪些操作，操作路径是什么
- 如果是产品问题，应该怎么处理更好
- 耗时
有记录，才有统计，有统计，才能更高效直接地解决问题
我们的项目轮值经过 2 个月左右，基本已经清楚地知道所有打断的来源
统计和分类
分析所有的记录，将相同的问题汇聚计数，得到一张表格
分类：
- 咨询类：哪些问题，出现频次，如何解决
- 操作类：什么操作，操作的链路， 出现频次
二八定律，先处理 20% 的核心问题，解决掉 80% 的打断
处理
1. 文档体系
我们发现，虽然这个系统已经存在了小十年，但是并没有太多的文档，并且文档非最新、含糊不清。
大量的咨询原因是没有文档，或者文档看不懂， 所以我们决定重新构建文档体系，替代掉原先的文档站点。
注意：
- 文档的目的是让所有人可达，所以优先选择所有人员可见的方式
- 文档的编辑成本需要足够低，用户反馈-修改-生效，最好选择所见即所得的方案，例如wiki(而不是需要仓库管理-编辑-review-合并-发布才生效)，低成本，高频率地持续维护
- 文档不要啰嗦，不要歧义，信息量足
- 有目录，有锚点，方便分享
- 重要，容易误操作的地方一定要重点强调
之前有参考一些最佳实践，文档体系由 4 个部分组成
- Tutorials 教程，学习相关，例如quick start/demo等
- How-To Guides， 问题相关，如何解决一个具体的文昌塔
- Explanation， 概念相关，用于深入理解某些概念
- Reference， 引用相关，用于提供更多的参考信息， 例如 API 文档
而具体划分，可能还会涉及
- 产品介绍（能做什么，最新的动态，升级日志等等）
- 使用指南（产品页面功能相关的step-by-step使用指引，保姆式教学）
- 概念说明（概念维度的组织方式）
- 常见问题 FAQ （重点，所有常见问题的解答，包含一些列说明和相关文档的引用）
- 问题反馈
这样，文档就成了一张网，用户不管从什么页面进去，都能够找到相关的概念、背景、用法、DEMO、FAQ， 足够清晰就将用户可能的问题全部在这个阶段解决掉。
并且，在面对咨询的时候，可以通过直接扔文档链接的方式解决，无须废话。
目前大模型已经足够聪明，能够辅助解决问题，所以我们将整个文档站点喂给了大模型，问题咨询的时候直接拉机器人进群，用户发问题的时候机器人协助解答，也拦截了很大一部分问题。
2. 操作的合理性、必要性
对于操作类，我们首先评估合理性，是否有存在的必要？
例如，有一个加调用方 IP 白名单的操作类，每一个调用方都需要找过来加白，而原先的老系统也做了一个快速加白的入口，用户找过来申请加白-打开系统-完成加白，这似乎没毛病，也存在了很多年一直是这么做的。
但是这样做有意义吗？ 无脑加白=没有白名单限制，后来才发现，是 N 年前的安全团队扫描推动加的，但是其实已经不需要了，形同虚设。后来直接给内网网段加白，废弃掉这个流程
同样，还有一些接口权限申请，最早可能有用，但是随着时间流逝，有些权限审批变得不再必要，所以系统上改变，非敏感的不需要审批直接通过，敏感的走自动审批流审批，而不是集中在系统开发这里进行人工审批
3. 自动化及分派
能自动化的绝不手工做，能别人做的绝不自己做
有一些操作是有其存在的合理性的，但是这类操作的操作链路特别长，涉及多套系统。
我们其实是有职能类的人工助手的，但是在这个阶段他们没法做任何协助。
后来我们做了一套系统（3 人、一周），将高频的十个操作整合在一起，配合权限控制、审计，然后将这类操作直接分派给了职能化助手。
这套系统直接在前置步骤拦截了几乎所有的操作类问题， 3 人一周的成本非常划算
4. 其他系统带来的成本
我们发现有几个高频操作是其他系统带来的，他们在文档上直接指引使用者，找到我们系统的开发做一些操作、配置。
实际上这样给我们带来了非常大的工作量，以及困扰。
所以我们最终：
- 写了相关明确的指引文档
- 在产品做了相应的快捷按钮
然后反向推这些系统的维护者改文档说明和入口，直接让用户自助解决问题。
5. FAQ
咨询中很大一部分是接口调用后的返回问题
我们直接在文档中，将所有报错返回进行枚举，并将每种报错的可能原因，排查方式明确，直接让用户通过关键字搜索就能自行排查问题
另外咨询中一部分是关于一些系统的限制配置，我们直接将代码中各类限制放到了文档中。
6. 热点问题置顶
我们发现，总是有一个问题：用户无法识别是自己的问题还是我们系统的问题，所以总是发起咨询。
后来我们将这个做成一个专题，并且置顶，放入用户排查问题的必经链路中。