【职场经验】无解问题、站队问题、工作生活边界问题

UP主: 崩溃大喵 · 时长: 18:13 · 🔗 B站原视频

发布: 2024-02-02 · 收录: 2024-02-19

标签: 职场经验 · 问题分析 · 职场成长 · 方法论 · 职场人际

开场：这次聊技术支持的“处理与分析”

今天想分享一下我做技术支持的一些经验。我本身不是一个非常优秀的技术支持，所以讲出来的内容大家可以参考一下，但不一定要全听全信，大家自己再分析。

虽然是基础知识，但分享的内容主要是问题的处理与分析，以及一些职场案例。除了相关性比较高的朋友，没进入职场的新人同学，或者做其他行业的，我觉得听一听也会有帮助。

我知道有很多更专业的职业人、以及有管理经验的人士，会更了解怎么处理这些问题。我这也算有点班门弄斧，但为什么还要做？因为我身边有不少同学，专业技能确实很优秀，但处理问题比较糟糕，我觉得这些东西能帮到他们。

直觉处理问题：快，但不专业

不知道正在看视频的同学们，有没有喜欢用直觉去处理问题？大家喜欢用直觉处理问题，是因为它容易，基本不用学。

我不评论直觉处理问题到底对不对，但它不专业。方法是要学、要训练的。

诊断思维：像看病一样处理产品问题

分析问题的过程可以用一个词形容：诊断。跟看病是一个道理，只是看病看的是人身上的问题，我们做支持处理的是产品上的问题，本质都需要一个分析过程。

医生要看报告，分析完如果怀疑还有没发现的问题，会进一步缩小范围，再针对某一块做更进一步的体检、收集更多数据。解决产品问题也是类似的。

我这边画了一个简易流程图（口述版）：

• 第一步：收集数据。比如配置项截图、日志、报告之类的。
• 第二步：分析。能解决就结束。
• 如果解决不了：引入资源。比如叫更多专家，可能是研发团队、更资深的支持、外部供应商、老板、其他部门；或者你觉得自己再多投入精力也能解决，那就投入。
• 然后把问题 narrow down（缩小范围），进一步分析。
• 一直循环这个过程，直到把问题解决。

一般我会按这个逻辑处理问题。

动手之前先问自己三个问题

在走这个逻辑之前，我会先提问自己三个问题。

1）问题理解是否一致

客户给了你一个问题，会带着一组初始数据，但初始数据一般不完整。也许客户只有一句话：某个按钮不能用了。

你一看觉得以前见过，好像是已知问题，就直接告诉客户怎么解决。但这不一定对，本质是凭经验猜的，证据链不完整。你以为的“已知问题”和客户实际遇到的问题，可能不是同一个。

所以先不要着急答复，先跟客户澄清：你遇到的问题，和我理解的这个问题，是不是同一个问题？

2）是否确实没问题

比如软件只能在 Windows10 以上才能用，客户非要装到 Win7、Windows XP 上，这种我也没必要帮你解决，因为软件本身工作正常，这不算问题。

再比如客户发现某个功能能把 PDF 转成 Word，但这不是官方声明支持的功能。他用着用着突然用不了了，来找你提问，这也可以说不是我们的问题：软件工作是正常的，这不在功能范围内。

3）数据是否有效

这很常见：问题发生在昨天，今天来处理。我问现象是什么，让他收集日志、报告、截图，但今天问题没发生，客户把“没发生问题时”的数据给你。你去分析这些数据，里面啥也没有。

所以处理问题之前，一定先初步看一下数据是否对得上。否则隔了一个礼拜才发现数据对不上，客户耽误一个礼拜，这时候就该发火了。

困难问题的“三板斧”：你搞不定时怎么办

刚才说的是一般问题。再说困难问题，也就是你自己处理不了的问题，怎么办。我写得比较粗暴，本质就是你要对接的三方：你、客户、上游（开发团队/供应商团队）以及老板。

三板斧分别是：

1）增加资源：把研发/专家拉进来

解决不了就叫专家进来，一般就是叫研发团队来帮你。

2）降低期望：先把客户预期说清楚

一开始就说清楚：这个问题可能达不到你的预期。我可能只能解决一半，或者给一个 workaround（临时办法），根本解决不了；或者要解决很长时间。

期望先降下来，客户就不会那么急着催。

3）升级问题：我搞不了，让老板看着办

问题实在解决不了，就升级：我不干这个问题，我搞不了，老板你看着办。你也不希望问题掉地上，那要不就把问题给别人处理。

有争议的问题：不一定要“解决”，先界定性质

有争议的问题，其实不一定需要解决，关键在于界定。

1）需求还是缺陷

举例：客户在电脑上用得挺爽，在手机上打开发现无法适配，就提问题说手机上怎么不支持、用不了了。

这对我们可能是新需求，对客户来说就是缺陷、要你立马修好。那就要跟客户解释清楚：这可能要根据产品计划来定，我们会考虑，到时候再说。

2）workaround 还是 solution

客户遇到非常严重的问题，已经阻碍业务运转，每天都在亏钱。那这种问题要解决，但可以分多步。

比如服务器软件有内存泄漏：每隔一天网站就挂，不能访问。那先看看有没有 workaround：改一些配置，让泄漏慢一点，本来每天崩溃，改成一周崩溃一次。这样就有时间了，不至于天天中断。可以在半夜找时间悄悄重启，先把业务跑起来，把问题从高危降到中等，再慢慢解决。

我们跟客户目标是一致的：先让业务能运转。客户可能对 workaround 不满意，但通常能接受。

3）内部问题还是外部问题

比如我开发一个应用，需要数据库支持。数据库也可能出问题，但一开始搞不清楚到底是谁的问题。外部软件的问题很难诊断。

比如采购某知名厂商的云数据库，开工单对方丢个报告说不是他的问题。你又没法证明到底是不是他的问题。你跟客户说是数据库的问题，客户去找云厂商，云厂商又不理客户。客户不是云厂商的爹，但可能是你的爹，所以客户只能来找你，你就卡住了。

这种扯皮的事挺多，做工作真的困难。外企也不是净土，但国内扯皮更多。

无法解决的问题：确实存在

并不是所有问题都能得到解决。常见几类：

1）没有办法重现

问题只发生过一次，我们态度很积极也想解决，但根本不知道问题是什么，收集不到有效信息，确实没办法。

2）系统性缺陷

系统设计时就埋了问题，当时没注意到。等问题暴露时，修复工作量极大，导致现在没办法修掉。可能有临时办法，也可能没有，但短期确实解决不了。

3）外部问题无人配合

还是外部厂商那类问题：你没法证明是他的问题，他也不帮你进一步分析。你是小客户，大体量云厂商不在乎你。

一般来说，只要你证明确实是他们的问题，他们还是会负责任去修，但那往往是你付费的情况下。你要是白嫖了第三方服务，那外部问题没人解决就真没人解决，只能自己担风险。

4）新需求

客户认为是问题，但本质是需求。把这个跟客户解释清楚，说我们会考虑，差不多也就这样。

能把这些“解决不了”的问题清楚分辨并摘出来，工作会少很多烦恼。因为一开始就知道做不下去，就不用花太多心思。

站队问题：两边都有道理时怎么办

站队问题是会出现的。我举一个我自己遭遇过的例子：

一个网页应用在数据量达到一定程度、超大时，在 Firefox 里可以运行，但在 Chrome 里运行不了。Chrome 是主流浏览器，客户觉得这是很严重的问题，一定要解决。

那个功能是产出报告：把所有东西都放到浏览器里，会使用超级大量的内存。Chrome 有内存限制：整个应用不能超过 4G，单个 tab 是 128M，超过 128M tab 就会卡死，报告产不出来。

那到底是客户数据量大导致的问题，还是我们应用设计导致的问题？界限很难界定。客户说要用 Chrome，主流浏览器你们不能不支持；开发说数据量太大，建议拆分，或者用 Firefox。

两边说的都有道理：客户重要功能受影响，开发改动成本又特别大。这时候就会面临站队问题：你到底站谁？

我也没什么答案，我对这种问题很反感，但它确实存在。我只分享一个我听过、觉得还算中肯的答案：你靠谁吃饭，你就站谁。

工作生活边界：问题永远处理不完，要保护自己

最后聊一下我做基础知识时遇到的苦闷：处理问题、处理事情是会上瘾的，你会被别人需要，别人没你就不行。

我当时的想法是：把问题全部处理完，然后好好休息一下。后来发现想错了，问题根本处理不完，只会越处理越多。

问题怎么产生？一种是东西确实做得烂，问题很多；另一种是产品很好用，用的人多也会出现问题。因为所有产品都有缺陷，只是很多时候没被发现。随着用户更深入使用、用户越来越多、用得越来越熟练，缺陷被发现得也越多。

所以你们服务越好，产品被发现的问题也越多。工作做得好，问题不一定会处理完，反而会越来越多。即使有一天问题被处理完了，也意味着你要失去这份工作了。

不要想着把问题处理完，问题是处理不完的。但我也想进步，多拿点年终奖，被老板看中、被提拔，这中间就有矛盾，所以要把握一个度：在负责任的同时也要保护好自己，才能保持对工作的热爱，才能持续发展下去。

最近攒了一点工作知识技能、职场相关的东西做分享，后面可能还会做几集 PPT。有兴趣的同学可以关注一下，谢谢大家。