时间: 2021-07-30 09:33:56 人气: 0 评论: 0
编辑导语：在我们的职业生涯里，经常**选择跳槽的方式进行岗位的变动或转换，那在面对跳槽后的新工作时，我们应该如何快速上手呢？本文作者分享了关于跳槽后的一些工作方法，我们一起来了解一下。
金三银四已经过去，很多人从原来的旧坑，跳到了新坑，开启了新的“填坑”之旅。
到了新环境，面临的首要问题就是如何快速的了解新工作，快速进入状态，毕竟活不等人，了解的过程越长，后面攒的工作就越多，反正都是自己干，还不如早点开始，所以这里结合自己的经历和思考，写一篇总结帮大家快点上道。
总的来讲，就是一个很朴素的万金油路子——三勤：勤动嘴、勤动脑和勤动手。
道理大家都懂，但到底应该问什么、想什么、写什么，才是我今天写的重点。
缺乏系统的问，没有思路的想，乱无章法的写，都容易走弯路，做无用功，与目标背道而驰，所以除了“勤”，还得有系统的框架来指引我们。
所谓问，其实就是学，做信息的输入。
这时的你对于新公司、新业务/产品就是一个小白，哪怕你曾经做过类似的业务或产品，也需要重新归零，回归小白心态，因为不同的公司、环境、市场地位，对同类产品思考点、要做的事情是不一样的，所以，在信息输入阶段，带入过多的以往经验，反而容易形成枷锁，造成误判。
在问之前，先要知道问什么，所以要先整理问题，而这些问题的设计逻辑，也是有准则的。
在对新公司和新产品一无所知时，过早陷入细节是件很危险的事，容易变成盲人摸象，摸到象腿就以为大象是根柱子，形成错误认知，而这种错误认知**带偏后面每一步工作，所以了解新环境是遵循：
逐步深入，步步为营。接下来要介绍的问题框架，就是遵循这一原则设计的。
不过，很多时候公司不**给那么多时间让你按部就班的学习，而是很早就直接丢给你一些具体问题要处理，这时你就要两条线同时推进：
一边处理具体问题，一边按既定节奏去学，并评估好两条线的优先级，时间虽有先后，但重要性哪个都不低。
这就好像要教你游泳，不**让你从浅水到深水慢慢过渡，而是简单粗暴的直接把你丢到深水区（或者就像小马过河一样，他们以为水不深，而对你来讲很深），这个时候为了活命，只能自己快速学**游泳，扑腾起来了，就活了，沉下去了，就凉了。
这里还有个看似矛盾的地方，就是问题只有很具体别人（或其他信息渠道）才好回答，而很多较宏观的问题**显得很宽泛，所以有时我们需要把宏观问题分解一下，拆解成几个问题拼接起来。
下面就来看具体要问什么。
问题分为两个层面：公司层面和产品层面。
价值观：
我司作为一家非常强调价值观的公司，是每个人进入公司的第一门课。
所以，如果你所在的公司有这些，那就去了解了解，如果你不认同，那就问问自己，这家企业是否真的适合你。当然，给的钱多那也行。
使命愿景：
使命愿景是个slogan，也是立的一个flag，对于业务比较集中的公司，从使命愿景里就能知道它是一家做什么的公司，因为使命愿景是对公司整个发展方向的总结概括。
它与价值观一样，都像是形而上的“玄学”，因此很多人都**嗤之以鼻，但当你进入一家公司并去了解它后，你**发现这些“玄学”真的**潜移默化的影响你，并融入到你的思想中。
业务布局：
只有了解完整的业务布局，才算对公司有比较全面的认识，虽偏居一隅，但也要看看整个前人打下的江山。
如果有内部转岗机制，那日后转岗也好找个方向。
制度规范：
这一点不必多说，人事的、财务的；公司级的、部门级的。都与自己息息相关。
红线要求：
在制度规范中，有一类尤为重要，那就是红线。也许以前的东家强调少，没有养成这种习惯，但到了新公司，这些都是不能碰的，轻则掉层皮，重则卷铺盖。
还有一些是主管的红线，也就是主管的某些要求，这些也要了解，毕竟你的考核主要是主管打。
常用黑话
刚来这家公司的时候，其中一个不适应的点就是各种黑话，作为业内知名的黑话大厂，各种黑话数不胜数。
以前说流程，现在讲链路，以前叫任务，现在叫action，但是入乡随俗，改变不了，就适应它。
而且很多时候这些黑话只是换了个名而已，本就没有标准答案，能让大家都能听懂，词能达意，用哪个词都一样，所以对于这些黑话，不用太较真，只不过是个约定俗成的过程。
工作流程：
工作流程包括“全业务链路的工作流程”和“产品经理岗位的工作流程”。
行业发展至今，大部分环节全行业都是相似的，不过还是**有一些差异，甚至是同一公司，不同业务/产品线都有区别，例如交互设计这个环节，很多中小公司没有这个岗位。所以到了新公司，这些流程环节还是要重新了解，免得产生不必要的麻烦。
在了解工作流程的同时，要着重注意时间节点，无论是你的环节还是他人的环节，以避免产生风险。
作为产品经理，最重要的当然是要了解我们即将面对的产品。主体思路还是和前面一样，从大到小，从粗到细。
而这个思路其实也是我们拆解一个产品的思路，也就是通过这套问题框架，可以用来熟悉、甚至分析任何一个产品，所以，想要产品分析模板的同学也可以用这个。当然，如果要更全面的分析可能还要引入其他维度，看场景是否需要。
产品背景：
即为什么要做这个产品，产生的业务背景是什么，这是首要问题，是产品的初心。
产品定位：
产品定位是个复杂的问题，因为不同视角心智不同，得到的回答也不一样。因此我们要了解得更全面些：
其他的都好理解，这里解释一下“之于部门”和“之于产品体系”的含义。
一般情况下，我们所负责的都是一个比较小的产品（大佬除外），或是一个大产品中的某一模块。当公司业务部门众多，体量庞大时，从公司层面看自己所负责的产品已经看不到了，因为之于整个公司看太小了，所以要从业务部门的层面来看，而如果自己负责的产品之于整个业务部门都太小，就要从产品体系着眼，所以这是一层一层递进的。
核心价值：
了解了前面两点，基本也就能知道产品的核心价值是什么了。
与定位相同，产品的核心价值也是承载着多方面的，所以从不同视角看才能看得全，看得清。
目标用户：
产品是为谁服务的，这是最基本的问题之一。不过我们在了解时，尽量将用户细分一下，而不是获得一个笼统的概念，这样以后才好区别分析，更精准的把握不同细分用户群体的需求。
商业模式：
也就是产品咋挣钱的，或者以后准备咋挣钱，是为了流量，还是为了现金。
业务模型：
先解释一下业务模型是什么：业务模型是一种精准、简练表现业务运转方式的模型。
以前段时间很火爆的社区团购为例，下图所示的是社区团购仓配模式，通过下图，就能很清晰的看出社区团购仓配模式是如何运转的。
图**来源：易齐赚
所以，为了能快速、清晰、准确的理解业务如何运转，最好的方式就是抽象出业务模型，并用图示展现出来。
产品架构：
产品架构是产品的全局视图，了解了产品架构，就了解了产品的内在组成、外部依赖和各个部分的关系，所以这是非常重要上帝视角。
已有规划：
如果一穷二白，那就要自己做新规划了。
发展历程：
了解发展历程是了解产品历史，读史可以明智，知古方能鉴今，了解产品也是一样。
不过这部分信息要看缘分，因为很多产品的发展历史是没有记录的，全凭口口相传，传到最后就成了传说，所以如果有这些记录，那可以好好看看前人趟过的路，如果没有就自己创造新的历史。
核心&主要分支流程：
流程是产品主干，摸清流程就摸清产品骨架了，在没完全搞透核心流程前，你都不能说自己开始了解这款产品了。
产品规则：
很多产品规则随着时间的流逝，已经改过很多版本了，而且你很可能找不到一个人能清晰、完整的介绍全部规则，即使有需求文档的存档也不够，很多信息还是容易丢失；而如果不了解这些规则，稍不留神就**踩坑，所以这是信息量最大、坑最多、影响面最大的部分，需要花长时间、逐步了解。
设计要点：
所谓设计要点，是指产品设计中，容易出问题、需要特别注意的地方。了解设计要点，说直白点就是要了解前人容易踩的坑，用前人崴脚的经验告诉你哪些地方容易被绊到，在后面做产品设计时就能有意识的防范。
同类产品/竞品对比：
这个不用多说了，是产品经理的基本要求和要了解的，不然你后面都没地儿“借鉴”。
在对产品认识不太清晰的情况下，多看看竞品，是非常好的一种补充。
当前主要问题：
这是容易被忽略但又很重要的一点——了解产品当前面临的主要问题，一方面是好对症下药，另一方面很多问题遗留至今是有很多看不到的原因在里面的；尤其是那些看起来很简单却迟迟没有解决的问题，所以了解当前问题也是更深入的了解坑点所在。
问的对象并不一定是某个人，还有很多其他渠道，其实更细节的做法是：
先查再问：
先问网络渠道，当网络渠道找不到的时候，再问具体的人。
当你进入一个新环境时，其实没有那么多人可以依靠，不要理所当然的以为应该有个人来带你，如果真的有，那是你的幸运，但是大部分情况下是没有的，其他人也有很多事情要做，甚至有的信息都不一定完全准确，所以大部分问题需要自己通过各种渠道探索、领悟。
另外，有一个很重要却又容易忽略的角色是值得大家去问的：测试同学。
由于产品迭代了很多版，产品经理换了一茬又一茬，所以很多时候真正了解产品全貌的不是产品经理，也不是开发，而是测试。我之前就是因为找错了人，导致走了很多弯路。
有了信息输入，就要进行信息的加工。
一方面是对输入信息进行理解、整合、吸收；另一方面是要多问自己几个为什么。对于公司层面的问题，我们可能很难得到回答，所以更多的还是聚焦于产品层面的为什么，例如：
每多想一层，对产品的理解就能更透彻。
当信息输入并经过自己的加工后，就要整理输出，通过产出帮助自己进一步巩固。
几个重要的产出物包括：
总览：
根据第一部分产品层面获取的信息，整理成一份完整的文档或文档集，将这些历经千辛万苦收集来的信息记录下来，以便持续更新学习。这是最主要的产出物。
在前文所提及的信息中，一定有很多是缺失的，例如业务模型图、产品规划蓝图、架构图、功能结构图等等，这些都很有可能没有，这就需要自己结合已有信息和个人理解去补充，而补充的结果，其实就属于产出的一部分，通过这些产出，来检验自己是否真的学**了，弄懂了。
所以这份总览其实包含相当多的信息。
词汇表：
将了解信息过程中涉及到的不懂的词汇用一张表格记录下来，查找解释，并用示例帮助自己理解，如下图是词汇表表头及示例。
词汇表示例：
个人FAQ
除了前文中涉及到的，在了解过程中一定还有一些未能包含到前文框架中的问题，对于此类问题可以整理成专门的“个人FAQ”，寻找答案并记录。
业务规则表
业务规则是在熟悉过程中逐渐补充的，所以我们需要用一张专门的表，以功能模块为基础，把不断了解到的业务规则逐条记录到表中，这样就不需要翻曾经若干份需求文档了。
而且这份表可以伴随整个产品生命周期，不断的更新，因为所有的业务规则靠记忆一定是不牢靠的，翻无数份需求文档也很费时费力，最后经常**出现产品经理要去问开发、测试的同学，之前的规则是啥样的。所以，好记性不如烂笔头，用一张表统一记录这些规则，造福自己，造福他人。
业务规则表示例
除了以上列举的重要产出物，其他的按需产出即可。
到这里，关于产品经理如何快速熟悉新工作的总结就说完了。
作者：周翔；公众号：周翔Fly；
本文由 @周翔 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自 Unsplash，基于CC0协议。
