如何在重复的工作中获得不断的成长

type

status

date

slug

summary

重复问题的重复解法导致了成长的停滞

很多人都渴望像马斯克一样，造火箭、搞自动驾驶、做人形机器人，做一些前人不曾做过的事情。

世界就是一个草台班子，不是所有人都有这样的机会，大家更多面对的是一个又一个需求，一次又一次重复的运营动作，一个又一个的不需要太多思考和决策的产品设计。

重复的工作，没有新挑战的事情是工作中没有学习成长的主要原因。

重复的工作，意味着这件事你已经做了好多次，每次都使用了同样的解题方法，解题动作甚至都已经固定下来了。比如，对于工程师来讲，虽然换了一个需求，但都是同样的增删改查。

重复 = 问题本身的重复 + 解决问题方法的重复，这两种重复共同导致了成长的停滞。这也是为什么很多人写了很多年的prd，还是在一线写prd，很多程序员写了很多年的增删改查还依旧在写基本的增删改查。

当你一直在“停滞区”时，就无法获得成长的。如果你面对的是一个又一个具有挑战的新问题，恭喜你，你很幸运，即使是被动成长，也代表你在不停的成长。业务蓬勃发展的时候，业务的增长带来了一系列的技术、产品、运营新问题，大家都在解决一个又一个新问题，团队也都在成长，也会给大家带来更大的成长回报和物质回报。业务稳定的时候，大部分人会进入到停滞区，也就是舒适区，会面对更多的重复问题。

即使是在业务增长期，工作内容客观上也是存在重复的。

想在重复的工作中找到成长，就需要打破问题的重复或者解决方法的重复，从第四象限，走向一二三象限。

我有一些不一定成立的想法分享

《如何评断创新性》这篇文章是我早年写的什么是创新。

第一个技巧：面对重复问题，尝试换一种方案来解决，让自己从停滞区走向主动成长区。举例：

之前手写增删改查代码，后来自己写了代码生成工具，模板化自动生成代码；

之前以模板方法为主要的设计模式，这次改为函数式编程，组合替代继承，更优雅更易读；

之前的产品设计以Axure画稿，然后进入ui设计环节，现在开始以figma为产品稿，同时在figma上和UI直接协作

不是所有的重复都值得换一种方式来进行，参考《如何评断创新性》，需要根据更换解决方法之后的长短期收益来评估。即使会涉及到投入度、时间等方面的问题，我认为事情都是可沟通的，更多的在于你对自我的成长要求。

第二个技巧：面对重复问题，标准化、自动化、极简化流程，从自己解决转变为需求方自己解决，一是减少停滞区的停留时间，二是在标准化、自动化的过程本就是从停滞区转向主动成长区。举例：

大部分的互联网startup公司，都有运维工程师这个岗位，在做的大部分事情都是手动运维，包括机器运维、网络运维、服务运维、上下线发布运维等。后来有了devOps，运维转向sre，把运维动作标准化、产品化，使得开发人员可以自行发布，从而实现CI/CD/monitor等，也提升了协作效率和质量。

数据分析师常自称“茶树菇”(查数据的姑娘)，产品运营的数据需求，大多会先提给分析师，由分析师一次又一次的去跑不同维度和指标的数据。需求需要排期，产品运营的数据易得性不能满足，茶树菇也长期处于停滞区做重复的事情。公司经过一定的发展，就有了数据产品，一定程度上满足产品运营简单常规的数据分析，在减少茶树菇停滞区停留时间的前提下，数据效率也得到了巨大的提升。

在互联网领域，类似的case很多，重复动作标准化、自动化、产品化，让重复问题转变为需求方可以低成本快速解决的问题，皆大欢喜。

第三个技巧：面对重复的问题，抽象、提炼，形成新问题，从停滞区走向完全成长区。举例：

深入某个点，对问题本身提出更高的要求。比如同样是增删改查的需求，这次给自己加了隐含条件是P99从原来的600ms到300ms。这种提出更高要求的做法，对于成长型人员来说，是贯穿于整个生涯的，是对自我“高标准严要求”的结果。

抽象问题，找到更高level的问题，从解决一个问题转变为解决一类问题，训练了系统性思考能力。比如，作为产品经理，本次我需要针对当前产品出一个“产品错误信息提示”的优化需求 => 抽象问题，“错误信息提示有多少种方式，我们适合哪种方式”。在解决我们产品错误提示优化这一个小问题的过程中，实际上解决了一类问题。

当你遇到一个问题解决不了的时候，往往是向上一个level的问题没有能解决。如果你能解决掉上一个level的问题，当前的问题就不再是问题。这就是抽象和系统化思考的魅力。

第四个技巧：跟老板聊，主动去承担一些新的需求、解决一些新的问题，从停滞区走向完全成长区。对于希望主动承担一些新问题的人，应该没有老板不喜欢吧。前提是当下手里的事情已经做得很好了。

主动承担更多 ≠ 挑活，挑活 ≠ 有问题。还是那句话，只要好好说话，没什么事情是不能聊的。