引言
当我们初次进入职场的时候，必然是怀着好奇和忐忑的心情第一次进入公司的职场，开始自己新的人生。
三分好奇，七分忐忑
好奇新的人生即将起步，忐忑如何和同事相处？能不能胜任接下来的工作？等等...
那么，初入职场，你准备好了么！？
幸运的是,在我入职的第一年中，我得到了leader 的肯定，在我的年终绩效评价的时候，得到了一句
超乎预期的完成了从一个应届生到职场新人的转变。并且在一年的时间内完成职级的晋升。
那么我就来简单以我的故事为基础，为大家做一些建议和分享。
我的故事
入职之后，怀着忐忑的心情，来到了工位，（慌的一匹）在导师的带领下认了一圈同事，真的，我一个都没记的住（羞愧）。
Q 那么第一问题来了，我们如何快速记住身边的同事？
A :
深夜打开工作软件一个个看头像认人。 新入职的时候领导们一般会为你做一个简单的介绍，但如果不是记忆力超群的小伙伴是记不住的。大多数的熟悉都是后续的工作之中逐渐熟悉，是个稳定的方法，但，太慢！时间就是金钱，我的朋友。
如果没有有头像，那么捷径失效，多问问，一般来说，1-2 天就能记住你的同事姓名。（组内人员要是太多就当我没说）
认识完了之后，就是各种熟悉公司环境，常用软件，技术栈，新人培训。
等到全部熟悉完到上手之后，时间已经转头来到了八月。
终于等到可以正式接活了
按照当时的项目规划，我自告奋勇的向领导表示想去一个网关类项目，然后在leader们考虑了之后，转头下礼拜就带着我走向了一个重构的交易类项目。
Q 如果在你提出工作请求和意见的时候得到的不是自己预期的怎么办？
A 虽然大家的诉求不一样，但告诉大家的是，如果遇到类似的情况，请不要不开心，因为你要相信，即使你看不清你自己，你的leader们也会看的明明白白的，身边的人，都是聪明人，相信你的同事和leader们，会把你安放在一个合适的位置让你发光发亮。
最初只是作为一个螺丝钉和同事们一起开发整个交易系统，干着干着，慢慢就发现项目整个项目贡献了最多的代码，为他熬了最深的夜，大家要解决交易相关问题的时候，也会让我来帮忙一起看，水到渠成的成为了这个项目的Owner，去听需求评审，开技术评审，和产品battle，撸代码，跟着前端，QA同学们一起完成需求。
随着时间的推移，已经成为了一个合格的打工人，可能同事们觉得我上一个项目干的不错，随着业务的发展，一个新的工具类项目也交给我来主导。
Q 一个新的项目(微服务)需要注意些什么？
A :
- 系统的设计(整个系统大的架构，包括但不限于调用链路，职责划分)
- 技术栈的选型(各种组件，消息队列，redis，Apollo 的选择)
- 数据库的选择(单独拎出来说主要是真的太核心了，一切的基石)
- 技术方案评审（重中之重，你需要说服你的同事，为什么选择这个技术，和你的同事们battle 起来，说服他们或者被说服）
- 代码的编写（coding coding coding 又到了欢乐的coding时间）
- 代码CR
- 联调（前端介入）&测试(QA介入)
- 上线
一个项目从0到1的步骤，都由我来掌控，在入职不到后一年的时间里，成功的成为了2个项目的Owner，并使我成功晋升。
那么，应届生到项目Owner，或者说一个初入职场的我们，什么样的能力，对我们是最重要呢？
Owner意识，自驱力，沟通
Owner 意识
那么什么是Owner意识？
简单来说就是把交给自己的需求或者是项目当成是自己的来做，让你成为他的主人翁，力求让他有一个好结果。
这个项目做的怎么样，这个需求做的怎么样，其实就是你在整个团队里的招牌。做的越好，承接的需求越多，在同事们的眼里，你就是一个非常优秀的伙伴，一个大家可以依赖的后盾，交给你做的事情大家就都很放心，就类比现在的独角兽企业，在整个行业里独领风骚，大众眼中就是最优秀的，他们的受欢迎程度就会越高，有更好的谁会用坏的呢？
把项目当成你自己的之后，你会发现coding的世界会变得不一样，整个项目的架构，代码书写的风格，易读性，使用的设计模式，别人在你这写代码之后，你都要去确认一下是不是会有问题，是不是和自己的代码风格吻合，是不是会有隐藏的Bug？因为，这个项目的一切都与你息息相关，荣辱与共。
甚至在需求来的时候，你会很明确的知道该不该在我这里做，能不能做，做的时候改动量大不大，会不会影响线上的正常运行？如何用最小的代价完成需求这些都会在短短几秒钟完成。
你会有一种感觉
每一行加入这个项目的代码，你都会充满了掌控力！掌控他们的功能，影响面，以及改动的风险。
这和做一条不思考的咸鱼是double world 。
自驱力
第二点和大家聊的呢，叫自驱力，我们在成长过程中，会逼着自己去做一下对自己有益，但是会跳出舒适圈的事，比如减肥，考研，学习一项新的技能等等这些事。
那换到工作上，自驱力是什么呢？
任何人都不能成为你的卡点。驱动自己，驱动他人帮助你完成你的目标。
卡点：任何阻碍你项目进程前进的事物都可以称之为卡点。（互联网黑话系列）
-
很多初入职场的新人，会受到网上各种参差不齐的鸡汤洗脑，会觉得问别人不好意思，或者支持你自己去解决，可能一个问题，会自己去死磕，磕上一天可能才能解决问题，但这个时候除了百度，你身边最强的资源就是你的同事们，遇到不会的，拿不准的直接问，你要明白，你花一天才能搞定的东西在他们那儿可能只需要几分钟，甚至也会存在一些特异化的东西只有同事才懂。
可能，好吧，确实是会占用他们几分钟的时间，但收益是你手上的需求是可以被快速推进的，而整个项目的推进是整个团队的事情，团队越好，我们就会越好， 说直白点就是团队业绩好，你的绩效和跟着好，直接的提现就是你的年终奖会更多。
请不要害羞，大家都喜欢活泼开朗的人。
-
驱动他人的能力也至关重要，也就是很多人，性格不同，工作习惯不同，想法也不同，所以有的时候你会发现，根本推不动项目，别人不做，没时间（至少跟你说没时间），不认可你的方案，导致整个项目卡住了，那么这时候的方法就是找人寻求帮助。
找谁呢？你的leader
在现在的工作里，你的Leader 除了指导你的工作，和你一起干活，还有一个非常核心的事情就是拍板和帮助你协调资源
当你和同事意见不一的时候，ledaer 可以帮你拍板。
当你推动不了别人工作的时候，就告知你的leader ，他和你对接的人聊，或者直接和对方的领导聊，最终一定会让你的事情推进下去。
切忌，推不动了死磕，导致项目卡死。
项目交给你，是为了看到最终完成的结果，你以任何理由卡主，导致最终结果不行，都是毫无意义的，并且如果因为你的原因导致项目延期，这个责任，我们是担不起的。
沟通
这又是一个很有趣的东西了，在大多数人眼里，程序员们应该算是一个不那么外向的群体，但摆在现实的情况就是，在正常的工作中，你需要和无数的人交流，曾经为了解决一个和兄弟部门联调的问题，一共拉了四五个群，和无数的人沟通，毕竟涉及了好多的系统，系统一多，人就会多，人多，交流就会变得困难。
怎么样在工作上进行沟通呢？一共分为2部分
- 场上因素：场上因素的指的是在沟通进行中，你需要叙述一个完成的故事，也就是这个故事有开头，有中场，有结尾。
-
开头：简单的交代一下背景，遇到问题的现象？涉及的影响？自己的推测？这样别人在帮助你的时候，会知道，哎，我在帮谁解决什么问题，有没有意义，紧不紧急？他们会自觉按照程度来安排帮助你的时间。
例如:2022年6月26日13点12分，页面长时间白屏后才会显示页面，会影响到线上用户的正常使用，等待时间较长会让用户放弃使用，经排查，个人认为是在调用Apollo 组件的时候返回时间过长引起的，麻烦看一下 @xxx 同学
- 中场：这就是你抛出问题，日志，报文，权限等等有关的信息扔出来，配合同事给予能给出的所有信息，信息越多，解决的越快。
更重要的一个是拉齐所有人的认知，对一件事情的理解，讲明白，保证不要因为理解的偏差让中间存在波折，在描述完问题之后，可以写一些简单的总结性话语，让大家确保自己已经拉齐了。
- 日志 xxxxxxxxxxxx costTime 5s xxxxxxxxxxxx
- 权限 只读权限
- 调用服务 Apollo test ip 地址 xxx，xxx，xxx，xxx
- 情况描述，现在的超时指的是我们调用apollo test 的服务时间过长，暂不涉及其他环节，麻烦查看一下apollo test 为什么返回时间这么长？
-
结尾：这儿就是人家已经帮助我们给出了结论，我们需要做的事就是验证是否能解决现在的问题？
解决不了，就去寻找更多的人
解决了,那就是感谢。
@xxx 辛苦了
@xxx 麻烦啦，感谢
毕竟别的同事也是花费了时间帮你解决问题，礼貌是务必的。
-
场下因素：这个大家可以听着玩玩，不做强制要求。
正常来说就是和同事们一起来做一些非工作上的事儿，比如打篮球，跑步，健健身，王者，线下关系越好，大家越熟悉，交流的成本就会越低，做事就会越快，人情，在哪里都存在。
同事:志同道合之人一起共事。
与志同道合之人的交流与沟通，会让人如沐春风。
总结
-
owner 意识
-
自驱力
-
沟通
Owner 意识是在思想上对你的改变，自驱力则是表现在实际行动上，沟通则是人与人之间的信息交换。
三管齐下，未来可期。
本人公众号👇欢迎沟通职场趣事，花式内推一个深耕互联网相关的公众号：你丫才掉发
