都说产品经理的工作杂，运营的也好不到哪里去。作者从产品转运营2年，也是经历了痛苦的零碎工作。这篇文章，就是她的个人心得总结，希望饿可以帮到大家。

不知不觉，在这个岗位已经两年了，近期还有一些新的感悟分享。

今天聊聊，做运营的最大迷思！

一、如何从琐碎里抽身？

面对琐碎，其实是运营类工作产出的一部分，但很难度量，很难出系统性的业绩，怎么办？

相信一直做着运营岗位的同学就有这种感触：

• 自己一天到晚打杂，忙着解决琐碎的事情，没什么系统性的产出。
• 感觉运营的门槛好低啊！好像随便一个实习生也可以做？
• 那我们的价值在哪里？前途在哪里？

而我这种做了十多年产品的老人，转做运营后，随着新鲜感和激情的消退，陆续也感受到了这种困惑。

比如某一次，发现某个和 OKR 指标不直接关联的数据指标波动很厉害，得需要人快速归因。正好数据团队的人都很忙，我也比较感兴趣，就花了不止俩小时的工作量进去，找到了隐秘的原因。

又比如，干了这份工作之后，每天都有其他部门找过来，抛出疑似系统的 bug 或者是操作人员的失误问题，要我们帮忙找到原因和解法。所以在每周工作的日常中，总有几个线上 oncall 要有人负责盯着——因为如果没有人去催相关团队的产品和研发，可能没人会及时给出答复，最终影响的是客户的体验和利益。

二、这类工作有多重要吗？

从根源上看，是重要的，我们是在替客户、替业务部门解决真实存在的问题。

但从打工人视角来看，好像又不那么重要。它们通常和 OKR 不直接相关。功利地说，在写总结的时候，这些工作量充其量只能写一句话：日常针对 xx 产品 xx 模块的 xx 数据指标波动归因，引导xx、xx等团队做日常优化；通过客户反馈发现产品bug x 起，完成修复。

就感觉是很稀松平常的日常，产出不了惊天动地的业绩。

在很多团队负责人眼里，这些事情不值得花精力，但有人需要来完成它们——这就是为什么运营岗位需要低门槛招聘一些人来完成这些日常“低价值”工作。

如果不幸在工作中，我们需要投入大量精力处理这类事情，是不是前途就完了？

其实没那么悲观，我对这些事情是这么看的：

运营，首先是商业经营中必要的一个保障环节，不管是核心目标的达成、还是客户体验的保障，都是属于运营的职能范围（operation），这是拿了钱就得干的活。

其次，从打工人的视角，如何去平衡日常产出和核心产出呢？

有两点心得：

1. 二八原则

不管琐碎的事情有多少，我们每天都要盯着自己的 OKR，把 OKR 相关的事情当作优先级最高去投入精力。比如每天有固定两个小时一定是搞这些事情。当有各种琐碎的事情来找我们，我们处理起来自然可以不那么及时。在有余力的情况下，我们可以选择自己感兴趣的“琐碎”的事情来处理，因为“感兴趣”，所以不枯燥，可能通过这些事情的处理，还能发现一些意料之外的新信息。比如我有一段时间很喜欢帮忙排查 bug，是因为我想借此机会熟悉一下平台的产品架构、研发实现逻辑，为后续做其他工作打好基础。

2. 从琐碎里抽身思考

如何找到本质的、规模化、自动化的解法？这可能就是立项和做出业绩的新机会。

琐碎不可怕，可怕的是琐碎的事情让我们变成无法思考的工具人，像每天推着石头上山的西西弗斯。

在琐碎之余，我们每天哪怕抽 10 分钟思考：我要怎么摆脱这些琐碎的事情？（除了甩锅），说不定有意料之外的收获。我这里举两个类型的解法：

1）自动化、规模化的解法尝试：

比如说我自己遇到的数据归因临时需求，之后我把它扩展成了一个“自动化归因数据能力建设”的专项，陆续把手工归因的逻辑做成自动化的能力，以后这事儿就不需要我了，节约我这种比较贵的人力（😊）。还能更快的把问题原因呈现出来，给需求方自己拿去解决，这不就皆大欢喜？

2）找到本质解法：

很多时候，表面上看到的问题，不是本质问题。多问几个为什么，我们才能摆脱“治标不治本”的圈圈。

比如反复出现的系统 bug、人员操作失误问题，相比于零星出现的问题，这类问题很值得警惕，它预示着系统设计或者操作人员的流程方面一定存在某种大的缺陷。针对聚类的现象，我们完全可以通过数据佐证影响量级，一旦发现这是个巨大的问题洼地，就可能需要对此场景推翻设计，这不又有大的项目做了吗？

其实，琐碎才是世界的真相，抽象是人为的归纳。运营的琐碎工作，有价值，只要我们善于把琐碎变成一种杠杆、一类桥梁，一样可以做出好的业绩。