转载： https://www.cnblogs.com/imyalost/p/14948218.html
方法技巧
信息获取
组织架构
每个公司的组织架构都有或多或少的差异，加入新公司的第一周，我个人建议快速熟悉公司大体的组织架构。
做技术的同学大多会在技术部/研发中心/IT部门等一级部门，按照个人的习惯，我会在第一周和自己岗位强相关或者经常打交道的二三级部门同学聊聊，
比如业务研发&基础架构&测试&运维DBA等同学，了解他们的日常工作内容和流程，快速获取和自己的岗位有关的信息，便于日后工作的开展。
流程规范
这里的流程规范包含两方面：公司规范和技术规范。
公司规范主要包括：报销、周报月报、打卡考勤、补贴申请、公司红线等方面。
技术规范主要包括：版本迭代、资源评估、需求&技术方案&用例评审、发布上线、资产申请、会议邀请方面。
业务背景
无论是基础架构、技术支撑、或者一线研发工作，了解业务是必不可少的。
这里的业务背景指的是：目前的核心业务是什么？业务流程从头到尾怎么串起来？各个核心业务的上下游依赖是谁，对应的产品、研发、测试、运维DBA等同学各是谁等方面。
技术框架
做技术的同学，如果不了解公司整体的技术架构和组件，那工作的局限性和发展空间一定不大。
这里列举一些常见的需要了解的方面，供大家参考：
- 技术栈（java、python、golang、PHP、.net）
- 技术架构
- 操作系统：Windows服务器、Linux服务器
- 系统架构：单体式、服务集群、分布式、微服务、SOA......
- 部署方式：自建机房、云服务、虚拟机、容器化......
- 请求链路：user→gateway→web server→app server→DB
- 技术组件：Redis、各种MQ、各种JOB、各种存储组件（mysql、tidb、HDFS、flink）
- 监控告警：cat、jaeger、zabbix、skywalking、Prometheus......
拿到结果
长期规划
进入一家新公司新的部门，一定要了解部门的长期规划是什么。包括但不限于：
- 团队规模：目前多少人，预计本季度、本年度招聘到多少人；
- 通过这点可以粗略判断业务发展情况，组织架构变更多自己的影响以及上升的空间有多大！
- 技术规划：目前是服务集群，要做技术重构、微服务化、容器化；
- 技术迭代变化中，自己能做什么，要解决什么问题，能获得多大的成长，面临的技术挑战！
- 迭代效率：目前是2周一个版本，预计通过多久变为一周一个版本，一周2个版本；
- 迭代的效率提升往往意味着CICD体系构建以及需求吞吐和交付质量的压力，影响会比较大！
短期目标
大多数互联网公司，都会通过OKR或者KPI来制定短期的目标，这里不评价哪个体系更好，或者它们的考核标准是否明确清晰。
从我个人角度来看，无论是OKR还是KPI，它首先是明确了短期要实现的目标，便于统一协调整体向一个方向走。
还是建议大家以中立的态度来看待这些方式，从中汲取和自己有关的部分。
快速落地
前面说了长期规划和短期目标，但职场实际上就是一个赤裸裸的生存法则具现体。
无论是校招的应届生还是社招的有工作经验的同学，对每个同学的考察期和给予的机会都大差不差，融入团队的首要目标，还是要先落地，证明自己的价值，才能有机会看到更多的可能性。
用一句和前同事聊天经常说的话来说就是：谁都不容易，想拿到想要的，你得先快速落地拿到领导想要的结果，证明自己值这些钱，才能想其他的。
解决问题
怎样才能快速落地呢？简单来说就是：解决问题。
你目前处在那个团队&岗位，目前团队面临的问题和困境是什么？你能否解决？交付的质量怎么样？领导安排的工作分工你是否按时保质的达成了领导想要的结果。
解决问题的过程，除了达成自己最初的价值诉求，或多或少还能从中学到一些东西。
沟通态度
躬身入局
我们每个人都或多或少有些路径依赖，即觉得自己过往成功来源于自身的某种特性或者某种做事方式。
但事实上我们过往能够拿到成果一定是在正确的时机、正确的场合做了正确的选择，虽然从日后来看这个选择很成功，但不代表当你遇到类似问题的时候可以不动大脑的复制之前的决定，因为时机变了，场合也变了。
加入新的公司新的团队，过去的工作经验和固有的思维模式，很可能不适配。
所以新人应该尽可能以初入职场的心态，放空自己，“削足适履，躬身入局”，从零开始，快速学习，快速了解团队的人、事、流程和方法等，是自己能够快速适应工作环境。
新人加入最好是能够先僵化式跟随师兄，使自己能够快速把基础工作做好，先拿到结果。经过一定的项目锻炼后，结合过去的经验和持续学习的输入，能够提出现有机制流程和系统方法等方面的优化建议和解决方案。
提问思考
新人集中加入，师兄和TL往往要同时带多个新人，比较难方方面面都能够把信息及时的Push到新人。
建议新人自己主动多去Pull信息、任务和目标。利用好周报、OKR等工具，全面快速拉取信息，而不是等着他人Push过来。
严己宽人
每个公司在不同阶段，制度、流程、系统都会有所变化，很难心无旁骛的只关注自己的领域。
这个时候需要的不是去抱怨某某团队支持做的不好或者工作不到位，而是要积极去思考在现状下如何能够做得更好，甚至更进一步思考我们怎么能够帮助我们的上下游变得更好。
多思考推动，事情才能真的变好，直面我们当前的问题，解决当前的问题，把别人的问题尽可能缩小，尽可能放大自己的问题，让自己的工作能够无懈可击。
所有人都喜欢一个有担当且无BUG的合作方，所有人都不喜欢一边抱怨一边自己做不好的合作方。
积极主动
每个公司在不同阶段，制度、流程、系统都会有所变化，会有很多需要完善的事情，若是你的视野再大一点，看到整个团队的话，那么团队当中需要人做，可是尚未有人做的事，都是你的事情。
好比你们一直苦于没有一个好用的报表工具，那你看到了这点，是否是能够抽空去做一个。之后团队其他人用的都是你写的工具。TL 和团队小伙伴是否会对你高看一眼呢？
一方面是当事情来临或者是问题出现的时候，积极主动地参与其中。
做事情的时候需要积极地反馈，当遇到问题、或者有一些阶段性产出的时候，需要主动地反馈给老板和上级，让他们知道你当前项目推进的风险和成果。
站在老板或 TL的角度来看，其实很放心把事情交给他们去做，能够省下投入在跟进中的精力。
另一方面是当本身发现了一些问题的时候，即便老板或者是其余人没有作出要求，也能积极地去推动它或者是解决它。
好比发现了一些隐藏的bug须要修复、发现了某些问题须要订正，或者是某些功能能够带来很大效率或者稳定性的提高。在这个时候需要主动和上级以及其余人沟通，去推动这些事情落地。
这里面的难点在前者，想要能有这些发现，不是靠灵光一闪就好了，需要背后付出不少努力。
技巧工具
前面讲到了信息获取的方式渠道和长期规划与短期目标。那么从哪里获取这些信息呢？
周报月报
从我工作几年的经历而言，大多数公司都会有日报&周报&月报等各种报的操作。
可能很多同学对写周报是一种完事的敷衍态度，实际上如果你换个角度来看，周报月报是一种很好的了解团队动态的渠道。
这里有个小技巧，可以将部门一些team leader、核心技术同学的邮件单独设一个邮件组，每天花一点时间来了解他们的报告里包含的信息，也许会有出其不意的收获。
会议纪要
开会，是很多人在职场中都要面临的一件事，当然，我自己遇到开会，也很头疼。大多数时候一大群人在会议室争论半天，讨论的就几个人，大多数就是打酱油的。
但有一点需要注意：会议的目的是就一些事达成共识和明确推进事项以及负责人。会议纪要往往能体现这一点（如果加入的公司有这种机制的话）。
了解项目的背景、各方面负责人、目前的进度风险和待办事项，对个人是利大于弊的一件事。
技术文档
做技术的同学，该如何去了解新公司新团队的相关技术和业务呢？文档是一个很重要的渠道（如果有最好，如果没有，可以从你开始做技术沉淀）。
这里的技术文档包括但不限于：技术设计文档、API设计文档、需求文档、用例分析设计文档、业务逻辑文档。
加入新公司，花一些时间熟读这些文档，对后续的工作快速开展有很大帮助，还是那句话：先落地拿到结果，解决问题，再考虑其他。
时间管理
相信很多同学日常的工作时间会被很多事情打断，比如随时被其他同事咨询问题，参加会议，头脑风暴等各种操作，工作时间碎片化，
不仅精力分散，而且该干的事情实际上进度并不理想。该如何解决这个问题呢？我个人工作几年沉淀了下面几点方法，供参考：
- 学会拒绝，界定工作的边界和职责范围；
- 不必要的会议不用参加，事后看会议纪要或者和同事聊聊就好；
- 番茄工作法之类的时间管理方法都可以尝试起来，找到自己适应的节奏；
- 建立工作清单，每天来公司第一件事列出今天/本周要做的事情，分类按重要程度排序，完成打个勾（实际上这一点如果做的好，每周的周报基本素材都是现成的）；
最后
实际上讲了这么多，职场还有很多规则需要大家自己去熟悉适应。打工人打工魂，祝愿大家在卷的道路上能稍微轻松点，掌握一些方法和技巧，轻松的卷，苦中作乐的卷。