跳出大厂之后，职场人应该如何找到自己的位置，并在心理维度、工作方式等方面做好适应呢？这篇文章里，作者便讲述了自己从大厂跳向其他企业的“软着陆”过程，一起来看一下，或许会对你有所启发。
从字节跳动离职后，我入职了一家央企的全资子公司。虽然公司规模不大，但因为跟控股的央企之间有很深的联系，因此从企业文化、制度和做事方式上，都有比较浓重的央企味道。
再过 10 天就是入职三个月，这段时间见到我的人，都说我比之前在字节看起来更开心。更重要的是，我也比那时更自信，更有勇气去承担起一些具有挑战性的工作。
当然只有我自己知道，从「卷得厉害」的字节到央企，我并没有真的躺平，而是找到了可能更适合我的工作方式。
也想通过这篇文章，给大家分享我的软着陆过程。
对我来说，入职后首要课题是心理上的适应。
老实说，很多互联网大厂人可能都在不知不觉中披上了孔乙己的外衫。
在平台背景、顶级薪水、精英同事等光环的加持下，他们很容易将自己理所当然地锚定在精英的位置上：崇拜互联网的自由，蔑视他们认为的体制所带来的迂腐与沉闷。更不用说，精英是不接受薪资打折的。
于我而言，入职后有一段时间也有这么一点倾向，觉得自己之前做的事情多么多么牛逼，现在在这里做的事情简直太基础了。于是不期望任何成就感，暗示自己就此躺平吧，去生活中找到更多成就感。
但很快我被自己啪啪打脸。
我入职后做的是 APP 重构，最大的难度在于如何解决历史债问题，这比从 0 到 1 做一个系统要复杂太多。那个时候我才开始体会到，在大厂里，你在一个很成熟的平台上做一些事情，看起来很牛逼，但有很多工作是前人为你打下的基础。
而在体制内，能不能很好地解决很多并不合理的历史债，才能真正反映一个人解决问题的能力。
原来这里的工作难度并不比大厂低，甚至可能高出不少。
我开始脱掉这层孔乙己的外衫。
心态上调整好之后，紧接着就是客观条件上的适应。
大厂做业务时，有非常成熟的方法论和基建保障。在字节，经常能看到各个业务线负责人分享各自做业务的方法论，并将这些方法论写在自己的签名文档里。
同时一些基建平台也很完善：项目管理、埋点、AB 测试、知识库等等。有了这些保障，决策会更科学，迭代会更高效。
但千万不要认为：在任何一家公司都有这样的条件。
当我入职后接受 APP 某个模块的重构时，我想要看一些该模块的历史文档，没有；打听埋点的情况，没有文档沉淀，且第三方数据服务商正在切换；历史数据只有浏览和点击；更不用说 AB 测试了。
这是现实。
另一方面，很多功能就不是单纯由数据驱动决策的。他们可能是为了某个战略服务的，尽管数据很惨淡；也可能是某些领导很看重的功能，尽管数据不好，但不能下掉。
这也是现实。
这种种的现实可能跟你在大厂里长期培养出的某些认知冲突，让你觉得「这么做事情简直不可理喻」，但这就是另一个体系下的规则。
如果想要待下去，就得适应它。另一方面，这些现实，恰恰也是我们这些人的机会。
心态和客观条件都适应了，接下来就是日常工作方式的适应。
首先就是汇报。
在字节的时候，我的工作内容基本就是做产品设计、评审、横向沟通，几乎没有什么汇报。
但在这里，每三周一次的汇报成了工作的重要部分。每次汇报都要做 PPT，每次的 PPT 也需要小组内提前讨论两到三轮。
我之前不理解，认为这样的汇报简直就是浪费时间。
但几个月过去了，我开始明白了汇报背后的一些奥妙。这个我们先按住不说，下文会聊。
回到汇报本身，核心关注两个点：1）如何把话说明白；2）如何听懂话。
把话说明白是体制内汇报的一门艺术，一半靠 PPT，一半靠表达。
PPT 的核心在于结构和内容。结构上，需要有点有线。线是主逻辑，点是关键片段。内容上，要看汇报的性质：是详细方案介绍，那就得展开说，是例行汇报，那就放重点内容。
汇报 PPT 的制作是一门大学问，在此不做展开，毕竟我也不精通。
但我知道一点，PPT 做得好，且业务能力过关的人，更容易在体制内获得升职机会。具体原因，大家可以自己品一品。
我想说说 PPT 的表达。
领导在听你讲 PPT 的时候，同时在获取两个信息。视觉上他们在看 PPT，听觉上他们在听你讲。
理想的状态下，讲的内容能帮助领导更好地理解 PPT。所以一方面，你得通过语言引导大家看 PPT 的逻辑，另一方面，PPT 上没有表达的关键细节，得通过语言描述出来。
切记：不要对着 PPT 念。这只会让你的表达变得没有任何意义。
底线是，将 PPT 上的书面语言用自己的话进行口语化表达。
听懂话，是跟听众进行交流的关键。在领导提问的时候，能听懂他们到底想问的是什么，会比你怎么回答重要得多。这里重点建议几个基本操作：
我一直奉行一个原则：当听者听不懂时，首要责任在表达者。
适应了现状，如果你不想躺平的话，那我们再聊聊如何发力。
入职后的两个多月，我学到的最重要的经验是：搞定一件事最好的方法，是一把手下场。在体制内，如果一件事得到了一把手的重视，那基本就成功了一半。
还记得我前面说的么，为什么汇报不是浪费时间，因为汇报本身就是在争取更高层的关注和支持。
埋头做事，不做汇报，在体制内的规则下，推进一件复杂的事情是非常非常困难的。
那如何争取到一把手的支持呢？通过组织架构，推敲高层战略。
某种意义上，组织架构就是顶层战略设计在人力资源层面的映射。
我刚入职的时候，赶上公司组织架构变动，我一个产品经理，所在的部门是商务部，我的老板，是商务部的总监。
我一开始不理解，后来才琢磨出来，产品岗作为商务部下面的一个岗位，说明公司今年的战略重心之一是收入，再去看与商务部并级的横向部门包括哪些，就能知道其他的战略重心是什么。
接着去看商务部下面又分为哪些组，每个组配的资源数量，就大概能一级级拆解出公司战略到部门战略。
为什么战略那么重要，因为跟着公司战略做事情，才能得到最大的资源支持。
有了公司级别的资源倾斜，个人的成长才会更快。
归根到底，不要埋头做事情。
搞清楚你做的事情在公司-部门战略版图中的位置，你才能知道自己该往哪里走，该怎么汇报，后续遇到内部其他机会的时候，应该怎么选择。
前面说不要埋头做事情，并不是说做事情不重要。
相反，对于从互联网大厂去到央企的我来说，做事的效率和质量是我的立身之本。
首先，千万不要躺平。
我并不认为，除了卷和躺平，就没有第三条路。相反我认为，卷和躺平都只是工作状态的两种极端。
一个人，兢兢业业地把自己该做的事情做好，这既不是卷，也不是躺平，这是最基本的职业精神。
虽然很多人知道我来现在这家公司后，都很羡慕我可以躺平了。
当然了，我确实经常没什么事情就准点下班了。
但我知道，该顶起来的时候，那也必须得顶起来。赶材料、赶方案的重要节点，晚上也得加班、周末也得加班。
更重要的是做事情的质量。
互联网人的优势之一，在于见过或经手过很多优秀案例，知道行业里的顶级水平是什么样的。尽管在当前的环境下，因为一些客观现实，无法一下子达到那种水平。
但在日常的工作交付物上，还是应该以顶级水平要求自己。
对产品经理来说，在输出文档的质量上，在产品方案的完备性和准确性上，都应该高标准要求自己。
我入职初期，见过之前的需求文档和开发流程，质量上确实大打折扣，但这并不是我们放弃对自己要求的借口。
反而是我们体现自己能力的机会。
互联网出身的我们，最擅长的是做事，最难的是搞定人。
在大厂做螺丝钉时，我们其实不需要太关心搞定人的问题。一方面大家几乎都很优秀，能很好履行自己岗位的职责；另一方面，残酷的绩效机制和严谨的协作流程，让人成了最确定性的因素。
但在体制里，由于岗位稳定性较高，所以人这个因素的弹性很大。
不是每个人都会为了你 100%努力，他们可以很尽力，也可以选择性躺平。
这时候，人反而成了最不确定的因素之一。
搞定人，就是让你的合作伙伴，能够为你们共同的目标而尽力。
我写此文之前，我、客户和外包同学组成的三人项目小队还在钉钉群里加班聊工作。按理说，他们可以选择不加班，无非整个项目的周期往后倒推一天而已。
但我们有个共同的目标，下周二之前把事情搞定。
有了这个目标，大家就都自觉加班了。
更重要的，我们在群里除了聊工作，还会聊生活，分享自己打球、健身、喝酒的点滴，很有一个 team 的感觉。
这种虚拟 team 的养成，靠的是两点：
最后再说说我想写这篇文章的初心。
互联网大厂人，面对央企这样的工作机会时，往往有两种倾向：
一种是鄙视，他们觉得充满年轻人的互联网才是自由与冒险精神的最佳乐园，他们看不起「体制」这个词，不希望过那种一眼看到头的生活。
一种是追逐，他们担心 35 岁的职业危机，希望找到更安稳的工作环境，或者他们太累了，希望去一个更轻松的环境下，就此躺平。
这两种倾向都是一种隔岸观火，那把火可能好、可能坏，但因为都隔着岸，于是所有的认知可能都来自网络和段子。
而我在真实地经历两种环境之后，我只觉得，这就是两种不同的工作环境，有各自的规则，我们只需要关注一件事：这样的环境，这样的规则，我们如何更好地生存。
一种环境下如鱼得水的人，可能换了环境就举步维艰。
但如果就此形成了鄙视链，或者是抛弃了最基本的职业精神，那都不是我所认可的。
有人问我：现在的状态，是你之前做职业规划时的理想状态么？
我不知道。
我只记得一本书里说过，无论命运把你抛在什么地方，最好的选择都是就地展开搜索，找到可见范围内的最高地。无论我们跳到什么样的职场环境里，最好的选择都是：
找到在这个环境下，最适合自己的工作方法。
这就是我的初心。
专栏作家
大力哥呀，微信公众号：大力哥，人人都是产品经理专栏作家。一个90后产品经理，已经写了6年的公众号，通过输出获得了许多意料外的成长。
本文原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。