del

极客时间专栏/geek/职场求生攻略/职场情商篇/17 | 升职：看着周围的人都升职了，我什么时候才能升职？.md

@@ -0,0 +1,135 @@
+<audio id="audio" title="17 | 升职：看着周围的人都升职了，我什么时候才能升职？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/ae/ce/aef2d76e201b45yy81499455135e3dce.mp3"></audio>
+
+你好，我是臧萌。今天我们来聊聊升职那些事儿。
+
+升职加薪，人人心向往之。但是升职之路，怎么才能走得顺呢？大家都在同一个公司混，为啥别人升职我没有，我真的比别人差吗？要是差的话，又差在哪里呢？今天这篇文章我们就来聊聊升职这档子事儿。
+
+但我讲的不是咋升到很高的层次，我就讲如何从萌新升到临界级别。临界级别我之前的文章中有提到过，简单来说就是指在公司里只要专心把事情做好，就可以升到的级别。临界级别我们都能达到，但是有人到的快，有人到的慢，还有人到了临界级别后，憋很多年也没升职。
+
+## 升职的逻辑
+
+那你可能要问了，这到底是为啥呢？其实，升职这事大有学问。首先呢，我们来聊聊升职的逻辑。每家公司的风格都有不同，我给出了你升职逻辑的四个共同点。
+
+### 1.先做到，再升职
+
+说到升职，可能很多朋友会有一个问题：我本职工作做得很好啊，可为什么升职没有我呢？
+
+这就要说到升职的第一个逻辑了，那就是先能做到下一级别的事情，才会升职到下一个级别。简单来说，你要先证明自己具备下个级别的能力，才能升职到下个级别。而不是去指望公司先给你升职，再自己努力达到下一个级别的要求。
+
+所以，当前的工作做得好，只能说明自己能力对得上当前的级别。当前的工作越做越好，加薪的几率越大。但是这并不是说当前的工作做好了，就理所当然地可以升职了。
+
+公司给员工升职加薪，不是因为他之前做得多好，而是因为相信他以后能够做得更好。公司是为未来买单。简单来说，公司花钱肯定是有明确的目的。俗话说得好，不见兔子不撒鹰。你之前做的工作，公司给了你工资，给了你奖金，这就是两清了。只有你已经证明自己可以做得更多，做得更好的时候，公司才会相信你未来也可以延续这个势头，然后考虑给你升职加薪。
+
+如果你任性地想着，公司不给我升职，我为啥要做得更多？那你就完全想错了。因为公司和经理不会这么想。因为你的表现还没达到下一个级别，如果给你升了职，结果你还是达不到下一个职级的要求，那怎么办？
+
+毕竟一个职级应该做到什么，做得好不好，都是比较主观的事情。升职升上去了，再降下来的话阻力就会很大。这就好像奖金一样。奖金的规定可以模糊，但如果是罚金，那一定要规定得很严格，否则没人觉得自己应该被罚钱。升职的决定权掌握在公司和经理手里，那么公司和经理自然想让升职这件事情的主动权掌握在自己手里，而不是你手里。
+
+大多数时候，很多公司对于那些无法证明自己能力的老员工，不会给他们升职，而是宁可招聘新的更高级别的员工。因为员工如果表现没有到下一个级别，给他们升职就会是一个错误的示范。会让更多的人觉得混着就应该得到升职。公司可不想让员工有这种念头。
+
+### 2.稳定输出
+
+你可能又要问了，下一个级别的同事能做到的事情，我也能做到呀，为啥我还没升职呢？
+
+这里就要说到稳定输出了。在职场，稳定的输出是黄金一般的品质。
+
+我们来举个视频App的例子。比如说有这样两个视频App，一个App在打开视频的时候，有99.99%的概率会最多缓冲3s，后面就会顺畅播放视频。另一个App有80%的概率视频一秒不卡，还有20%的概率每一帧都卡，卡到忧伤。如果只能选一个App，你会选择哪个App？我想大部分没有自虐倾向的人都会选择第一个App。这就是稳定的魅力。
+
+工作中也是一样。稳定输出，结果可期。不求有惊喜，但求没惊吓。如果做一个事情这次用一天，下次用五天，再下次用一个小时。试想一下，如果你是经理，你敢给这样的员工重要的事情吗？万一下次用一个星期都搞不定呢？所以不如去选择一个，每次都能两天搞定事情的员工。
+
+级别越高，对稳定输出的要求也越高。这里稳定输出的内容，也可能不仅限于具体的某个工作。也包括一些日常琐碎的事情，比如不会漏掉客户发来的邮件和消息、每天都会查看系统dashboard、每次都记得将发布流程按规定走完、每次写完代码都会记得增加UT、每次遇到问题都会记得给系统增加新的报警规则等等。
+
+稳定代表可靠。所有的经理都喜欢稳定发挥的人。而经理喜欢的人，有更大的升职机会。
+
+结合前面说的“先做到，再升职”的逻辑，稳定发挥意味着你能够在连续的几件事情上，都发挥出下一个级别的能力，达到下一个级别的水准。这样才能让经理对你放心，你才会有更大的升职概率。时而行时而不行，就好像一盏灯一会儿明，一会暗，只会伤眼睛，起不到太大的照明作用。你只有稳定地发出光，才能当灯用。
+
+### 3.不仅要绝活，更要靠全面
+
+我们玩技术的，都更喜欢靠技术出位。也就是说，要靠自己技术好，博得大家的认可。这点没问题，但是光技术好是远远不够的，还要足够全面，这样才是全面的好。别人都会的，自己也要会。然后再去说别人不会的我也会。而不是别人都会的，我觉得没意思，我就要整点别人都不会只有我会的。
+
+我再来举个例子帮你理解一下绝活与全面的关系。假设一个人在工作中需要使用ABC三种技术：有两个选择，一个选择是自己的A和C技术都达到平均水平，B技术略突出；一个是自己A和C技术基本无法完成工作，B技术超牛，各种犄角旮旯的东西都会。
+
+在实际工作中，前者会更受经理喜欢。毕竟工作中用到的技术是全面的，只会B技术，基本无法独立地去完成任何一项工作。即使偶尔有机会靠B技术，亮出自己的绝活，也无法让人认可他的综合能力。
+
+所以我建议你不要沉迷于只靠绝活。工作中用到的技术，你一定都要学会，就算是硬着头皮学，也得让自己能达到可以独立完成工作的程度。毕竟公司雇佣一个员工，是为了让员工完成工作，不是来技惊四座的。
+
+### 4.资历老
+
+在能力差不多的情况下，肯定是资历更老的同事更容易升职。这是人之常情。就好像我们前面提到的，程序员的日常工作还包含了交流和沟通，资历老的同事在一个公司里认识的人更多，这也是能力之一。
+
+同时，资历老的同事通常有更多公司相关的经验积累，比如熟悉各种明坑案渠，各种系统怎么用，哪个同事对某个系统最精通等等。升职资历老的同事，一方面是对这种软能力和技能的认可，同时也是对资历的认可。
+
+## 程序员的三个阶段
+
+每个公司的职级划分都不同，对于每个职级的能力要求也都不同。我根据我的经历和理解，将程序员的能力划分为下面三个阶段。
+
+### 1.写代码
+
+这个阶段的工作就是能够按照设计，完成代码的编写和bugfix。这个阶段要锻炼出熟练的编码手感，养成良好的编码习惯。按照我的理解，这个阶段要达成的主要成就有以下五个。
+
+- 能够完成具体功能的代码，保证代码质量。
+- 有阅读代码的能力。
+- 开始理解和掌握基本的设计模式。
+- 不再闷头就开始写代码，而是开始在class和package层级，思考和实践高内聚、低耦合的代码。
+- 建立自己学习技术的体系，培养学习技术的习惯。
+
+这个阶段的成长点集中在写代码。经过这个阶段的成长，一个明显的感觉就是写代码不再是问题了。这个阶段一般会需要3到5年的经验积累。紧接着，就会进入下个阶段。
+
+### 2.能掌握
+
+这个阶段，除了要承担代码编写的任务之外，还能够理解整个系统的设计，针对系统的新功能，能够给出和现有系统连贯的设计，并能够承担新系统的设计，理解这些设计背后的目的。按照我的理解，这个阶段要达成的成就有如下六个。
+
+- 接到需求，能够快读准确的给出可行性，难点，系统集成点，给出设计和工作量估计。
+- 可以将一个系统的设计划分为高内聚，低耦合的模块，并给出工作量估计。
+- 补全自己计算机底层知识的短板。有一个自己是在做系统设计而不是瞎做系统设计的底气。
+- 锻炼自己快速掌握一门技术的能力，包括技术的总体设计，优缺点，使用场景等。
+- 熟练掌握这个系统，能够快速排错。
+- 能主导搞定系统里的一个项目。带领低级别的同事做项目，自己能发挥主导作用。
+
+经过这个阶段的成长，最明显的感觉就是自己清楚系统的方方面面，各种细节，系统能力的边界等，知道自己能稳稳地搞定这个系统。这个阶段一般需要3到8年的经验积累。这时候，就会很自然地想到这个系统的明天会怎样，也就很自然地进入下个阶段。
+
+### 3.能hold住
+
+这个阶段的意思就是能够own一个系统，系统各种大大小小的事情都能搞定。换句话说就是有ownership。说起这个系统，第一个想到的就是你。而且你的稳定发挥也不会让人失望，只要是这个系统的问题，找你马上能够快速直接的解决。按照我的理解，这个阶段要达成的成就有这四个。
+
+- 逐渐掌握系统的全貌，设计新的功能时，可以通篇考虑。
+- 可以对系统进行重构和升级，解决系统的技术债。
+- 开始积淀起自己在相关领域的业务知识，理解领域中的难点，易出错的点和痛点。
+- 可以顺畅地和上下游相关同事沟通交流，并开始培养自己的影响力。
+
+经过这个阶段的成长，最明显的感觉就是对这个系统有了feel，不仅对系统当前清楚，能清楚地知道系统解决的问题，基于此，对系统的未来有自己的想法，可以让系统发展到一个更高的层面。这个阶段一般需要8年以上的经验积累。
+
+能够own一个业务系统，基本上就可以顺利升到临界级别了。这时候，已经站在半山腰了，怎么继续向上爬，需要根据自己的特点来拿捏了。
+
+## 到底我能不能升职？
+
+那到底我能不能升职呢？那我们就得从经理的视角来看看升职这件事了。首先，经理是否愿意本组的人升职？答案是肯定的。经理肯定想争取到更多升职的名额，这样，自己的队伍相当于是壮大了，也就相当于自己有了更多的资源。给自己的手下争取更多的升职机会，是符合经理的利益的。所以，首先弄清这一点，别没事儿就老觉得经理在想着法地不给自己升职。
+
+但是公司肯定是有自己的预算的，每个经理能争取到的升职名额也是有限的。所以如何分配升职名额呢？如果我们是一个经理，我们会尽量避免给哪些人升职呢？
+
+首先，不符合文中开头说的升职的逻辑的人，大概率不会升职。这个是硬性指标。
+
+其次，和经理彼此不对付的人，也基本和升职没太大关系。每个人都有自己的好恶。经理也不是圣人，他为什么要给一个自己不喜欢的人升职呢？让他做更重要的事情，然后继续和自己对着干么？这点我们在经理那节也说过，这里不再细说。
+
+还有就是，经理不会给离职可能性大的人升职。如果好不容易争取来的升职机会，刚给一个员工升职，没多久他就走了，这会让经理很头疼。这样一方面是浪费了升职的机会，另一方面也是对自己的考核不利。因为这代表自己辛苦培养的人才流失了。
+
+同时，对于离职可能性大的人来说，升职之后去找工作更容易，这更加增加了离职的可能性。但是对于员工来说，一直升不上去，就会越来越难在外面找合适自己的工作。所以还是那句话，遇到不对付的经理，如果确实非常不对付，那么可以考虑换个组了。
+
+<img src="https://static001.geekbang.org/resource/image/38/b7/38c3079503a90df6838c2251d83174b7.jpg" alt="">
+
+## 总结
+
+升职是职场永恒的话题。职场永远不缺辛苦工作，却多年无法升职的故事，也从来不缺有人火箭速度升职的传说。有人喜欢富贵险中求，有人喜欢步步为营。本文给出了升职的一些总结和思考，但现实总会更复杂些。
+
+升职不是游戏里的打怪升级，不能像游戏里一样砍怪就加经验，经验到了就能升。升职背后的各种利益考量，各方势力的角力，都会影响最终的升职结果。一时的得失，难免让人心态失衡。而关于升职，最重要的一点就是不要让自己的心态失衡，影响到自己的发挥。升不升职，都要有自己的职业规划。
+
+有次我在一个老同事群里讨论升职之类的事情，有个同事说了一句话，我印象深刻，记忆至今。他说：“从足够长的时间跨度来看，公司对我们是公平的。”
+
+其中滋味，各自体会。
+
+最后，祝你在升职的路上，守得云开见月明；祝你在升职的路上，柳暗花明又一村。
+
+## 思考题
+
+关于升职，你有什么故事吗？有过没想到我竟然没升职，或者我竟然升职了的疑问吗？
+
+欢迎在评论区和我交流。也欢迎把这篇文章分享给你的朋友或者同事，一起交流一下。

极客时间专栏/geek/职场求生攻略/职场情商篇/18 | 职场政治：我只想好好干活，职场政治和我有什么关系？.md

@@ -0,0 +1,95 @@
+<audio id="audio" title="18 | 职场政治：我只想好好干活，职场政治和我有什么关系？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/9e/40/9ebeeyyc751f2b27c3500bcd7df75d40.mp3"></audio>
+
+你好，我是臧萌。今天我们来聊聊职场政治那些事儿。
+
+不过我首先得强调一点，这篇文章并不是教你怎么搞职场政治。毕竟在职场政治这个大舞台上，我们程序员不是主角。这篇文章的目的就是为了能让你理解职场政治的必要性，理解职场政治的基本要素——站队。这样你才能在职场政治这个舞台剧上，扮演好自己的绿叶角色。
+
+## 为什么我说一定会有职场政治？
+
+也许你也曾经天真如我，觉得自己靠自己的双手干活在公司谁都不亏欠，觉得自己全凭勤劳和真本事吃饭，觉得公司全靠和自己一样的写代码的人来养活。以至于像我这样想了太久，在公司里感觉腰杆子比铝合金电线杆子都硬气了。如果你是这样的人，那么我建议你仔细品品我下面说的这个故事。
+
+### 人少总是小而美
+
+这是一个电商网站的故事。一开始，有一个“草台班子”，只有创始人单干，卖定制化小商品，比如T恤、杯子等等。所有的事情，包括产品研发、产品代工生产、进货、库存、编写电商商城代码、服务器维护、发货、售后、营销等等都是创始人一个人来包办。
+
+老天有眼，商品的路数对了，卖得很不错，订单量越来越大。这时候创始人一个人就忙不过来了。怎么办呢？招人呀。按照工作职责划分，很自然地，创始人又招了三个人，一个人负责生产，一个人负责营销，一个人负责售后。程序员太贵招不起，所以创始人自己继续负责商城的开发和服务器维护等，同时总管新来的三个人。
+
+这时候，其实问题已经来了。因为人多了起来，赚的钱怎么分就是个问题。之前只有创始人一个人，赚多少都是自己的。现在有了三个手下，虽然他们现在还不管人，只是拿工资。但是年底奖金怎么分？加薪怎么给？谁多谁少？这些问题就开始接二连三地蹦出来了。
+
+当然，这时候人还不多，大家也都很辛苦。所以大家对创始人的奖金和加薪方案，也可能没有什么抱怨。毕竟公司发展得好，对大家都有好处，每个人到手的钱，差的那仨核桃俩枣也没多少。或者创始人如果足够有魅力，还可以让大家忘记心里那一丢丢对利益的纠结，继续拧成一股绳，奔向更美好的明天。
+
+故事讲到到这里，你能够明显看出，当公司只有一个人时，所有赚的钱亏的钱都是创始人自己的，这个毫无争议。公司接着发展下去，会从一个人发展到非常扁平的两层结构。
+
+这个两层结构时期人还非常少，虽然已经要开始为各自的付出来分配利益，为各自的失误承担责任。但是由于公司规模不大，每个人为公司做的贡献和每个人的工作失误造成的损失都非常明显。这时候要做到奖惩分明，并不是特别难。
+
+### 人多就会有“江湖”
+
+但是，公司会继续发展。进一步往下发展的话，之前做产品的部分就会变成产品部和库管部，分别各有十几号人。营销部和售后部也都成立了，也都是好几个人的规模。同时，公司也终于有了商城研发组。创始人终于可以专心地管理公司了。
+
+这时候，公司变成了三层结构，公司的人也越来越多，想做到奖惩分明已经非常难了。
+
+比如说，产品是直接面向用户的，所以产品设计做得不好的话，对销量会有直接的影响。营销可以扩大销路，增加销量。但是产品的销量有多少是要归在产品设计上，又有多少要归在营销上呢？
+
+营销需要经费，那么接下来的营销经费，是应该增加还是减少呢？售后不是利润部门，但是会影响回头客。有多少客人是因为售后不好而流失的，又有多少新客是因为优质的售后才获得的增长呢？因为售后原因增加的客户和营销带来的新客户，又应该如何区分？这些问题的出现，让公司很难做到奖惩分明。
+
+更不用说，公司除了奖惩分明之外，还有更高级更复杂的利益。比如大到某个部门的存留，小到某个项目是继续还是取消。举个例子，库管部负责商品进库、发货、清点等工作。这个工作并不是公司的核心竞争力，而且随着公司规模的扩大，可能交由更专业的公司来负责会更好。这时候，这个部门留是不留？这个部门的老大怎么证明自己部门的价值？是更安全、更快速、还是更省钱？
+
+所有这些大大小小的事情背后，都是赤裸裸的利益。没有这些，你可能都没机会干活，没机会赚辛苦钱，也没机会升职加薪。
+
+你想想看，如果不是商城部门的老大能搞定关系，给出各种让人信服的数据，背上各个方面给的KPI，这个部门可能就被取代，下面的程序员可能就散了。如果不是老大能做出正确的决策，展示出让公司满意信服的成果，整个部门的加薪升职可能都要缩水。
+
+而这整个过程，都是政治的运作。
+
+## 一般公司里的那些职场政治
+
+当然，在一般的公司里，对于我们这些最基层的程序员来说，日常能亲身体会到的，并不是上面例子中说的整个部门不要了这种大动作。我来给你说两个个比较常见的例子。
+
+### 为啥要改组？
+
+在成规模的公司里，大大小小的改组（Reorg）可谓屡见不鲜。比如我们熟悉的腾讯和华为，最近几年都有调整自己的事业群（Business Group）。这种公司层面的改组，肯定会一层层地传递给下面的部门。有时候，一个小的部门，也会随着发展而改组。正所谓，分久必合，合久必分。很多时候改组就是分分合合。
+
+下面我来说说我对改组的拙见。随着公司的发展，内部外部环境的变化，公司改组是难免的。公司通过重新划分地盘，打破老的利益格局，重新规定各自的权利和责任。改组搞得对了，可以激发组织的活力，可以让做事情更顺畅自然。
+
+我之前面对重组，只关心两件事，一是我的工作还有吗？二是我换老板了吗？最多再关心一下我老板换老板了没。现在我更愿意去理解这次改组的目的，想要解决的问题是什么。进而我能去理解，这次重组给自己所在的组带走了哪些老的负担，带来了哪些新的责任，又伴随着哪些新的机会。
+
+### 不改组行不行？
+
+我来给你说个柯达公司的故事。柯达公司原本是做相机胶卷的。后来，随着数码相机的普及，柯达公司的胶卷业务已经没有了存在感。但很多人可能不知道，数码相机其实是柯达最先发明的。但是柯达却将这个未来的潮流束之高阁。
+
+这个也不难理解，一个靠胶卷生存的公司，不待见一个可以淘汰胶卷的发明，这也是很自然的。但是如果当时柯达公司能够改组一下，将数码相机的研发制造从胶卷业务中独立出来，柯达公司或许会走上一条完全不一样的道路。
+
+当然，这也是一个久远的例子，现在数码相机也被手机淘汰了。所以说啊同学们，公司不改组行吗？不打破老的利益格局行吗？当然不行。不变就意味着被淘汰呀。
+
+### 用谁的系统？
+
+在公司里，除了改组，用谁的系统这件事儿也会经常出现。公司大了，系统多了，功能难免会有重叠。更不用说还有鹅厂这种鼓励内部竞争的公司。这时候，用谁的系统这个问题，除了功能等因素之外，还有更多非技术的考量。比如从两者所在组织的角度看，这种合作是否互惠互利？合作是否会动了别人的蛋糕，让别人不爽？合作带来的地盘交叉，以后是否能分得清？在对方系统上做的投资，是否会被好好维护？这些考量都是有政治意味的。
+
+## 面对职场政治，程序员应该做什么？
+
+前面说了这么多，其实目的是阐述职场政治的必然性和必要性。当然，我们是程序员，是基层做实际工作的员工。这篇文章不是鼓励你去搞政治。那么了解这些之后，我们程序员应该做什么呢？
+
+### 尊重职场政治
+
+我觉得首先要做的，就是尊重职场政治。职场政治远不止我这里列出来的这些正能量的事情，也有很多算计，可能看上去并不那么让人舒服。但是，从屁股决定脑袋的角度来说，我们还是要尊重自己组织作出的各种决策，尽自己的力量去支持。
+
+你要知道，每一份工作背后的一系列利益逻辑都是各路老大搞定的。你不要动不动就想着，此处不留爷，自有留爷处。你这样想的话，到哪都没有你的工作。
+
+### 懂得组织的利益所在
+
+一个公司，往大了说，大家是一个整体。往小了说，大家是一个个利益小团体。我们作为程序员，要懂得自己所在的组织的利益所在，不要做违背组织利益的事情。当然，这里也并不是鼓励大家去花太多的时间，思考职场政治。毕竟我们是干活的人，不是搞职场政治的人。大部分情况下，你只要配合经理做好自己的工作就好了。
+
+同时呢，我们还要能理解和自己合作的各个组，以及各个部门的利益所在。这样在大家合作的时候，能够泾渭分明。不要打破大家合作的约定和默契。
+
+## 总结
+
+俗话说，有人的地方就有江湖。那么在职场这个江湖里，它背后的逻辑就是利益。支配利益的方式就是靠政治。游戏的主角就是各路老大们，我们做好配角就是了。别替老大们操心，别想太多没用的，别说太多没用的，更别做太多没用的。
+
+大家在一起玩儿，一定要有游戏规则。这个游戏的规则的制定，不需要我们操心。实际上职场政治也远比我这里举的例子复杂难懂，我们也很难参与进去。就好像你在路上开车一样，你不用参与，也无法参与制定各个路口的红绿灯的规则，我们只要学会看红绿灯，按照红灯停绿灯行的规则走就行了。当然，职场上的政治，没有红绿灯那么简单直接。看不懂的时候，别乱动，问经理该怎么做。毕竟全公司最不希望你犯错的人，除了你，就是你的经理。
+
+<img src="https://static001.geekbang.org/resource/image/fe/c0/fe98b8ea3a7a1f74bacf485a4a0f1fc0.png" alt="">
+
+## 思考题
+
+关于职场政治，你有什么故事吗？有没有因为这个迷茫过，又有没有因为这个吃过亏呢？
+
+欢迎在评论区和我交流。也欢迎把这篇文章分享给你的朋友或者同事，一起交流一下。

极客时间专栏/geek/职场求生攻略/职场情商篇/19 | 职场政治：面对公司自上而下的技术更新，我该怎么办？.md

@@ -0,0 +1,117 @@
+<audio id="audio" title="19 | 职场政治：面对公司自上而下的技术更新，我该怎么办？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/5d/f0/5db5c134d7588d70353bede2158ab3f0.mp3"></audio>
+
+你好，我是臧萌。今天我们接着继续聊聊职场政治。
+
+在上一节中，我们聊了聊职场政治的必然性。在这一节里，咱们接着这事再讲讲我们程序员会遇到的一种特殊职场政治，那就是公司自上而下的技术更新。
+
+这种技术更新，大都是伴随着技术方向的变化，或者发展策略上的变化。这种变化可能是整个公司层面的，也可能是部门或者小组层面的。变革的目的就是为了更上一个台阶，而打破现有的模式和利益关系。
+
+## 电商软件研发部的困境
+
+光说技术变革几个字还是比较抽象，咱们回到上节课里我提到过的那家电商公司。公司里有个软件研发部，它开始的职责是自己研发电商网站。但是随着公司的发展，软件研发部的老大要做一个非常关键的决定了：是继续自己研发电商网站，还是将自己的销售系统和当时已经发展起来的天猫、京东等电商巨头平台对接呢？
+
+### 自研还是对接平台
+
+两种选择，各有利弊。站在部门内部的角度想，如果走自己研发电商网站之路，自己部门可以把控着公司的网站，能够让自己的部门在公司中有举足轻重的地位。但是就电商发展形势而言，电商巨头已经形成，配套的支付、搜索、移动端多平台支持、购物体验等等，都是自己这个小的电商公司无法做到的。尤其是让自己研发的电商网站获取流量，将是个越来越难的事情。
+
+所以说，自研之路，也许能保证自己部门在公司的地位，但是长期来看，无法保证自己的部门能够为公司的发展发挥应有的作用。
+
+这时候，从有利于公司长远发展的角度出发，也从自己生存的角度出发，软件研发部老大决定壮士断腕。研发部保留了自己研发的电商网站中，最基本的企业展示和主页功能。与此同时，研发部在各个电商巨头平台上建立旗舰店，将购物功能都导流到各个电商巨头网站。
+
+### 程序员如何应对变化，重整旗鼓
+
+随之而来，软件研发部本身也要经历一轮大的变化。原来是做自己的一套电商系统，现在变成了做一套对接各个电商平台的内部ERP系统。一开始研发部老大跟兄弟姐妹们画的饼都不见了。从这种变化本身来看，其实这就是动了程序员的“蛋糕”。之前程序员的那些付出，写的那些代码，做的那些系统，都白费了。瞬间自己为公司创造的价值归了“零”，心里肯定是不好接受的。
+
+面对这种变化，程序员应该怎么办呢？如果你从外部来看，当然很容易就能说：“这有什么的，不就是写代码嘛。公司的变化怕啥，继续拿工资写代码呗。”其实这是一种站着说话不腰疼的说法。如果深入到程序员的内心，公司的变化给程序员内心造成的影响，是无法简单用一句继续拿工资写代码就能带过的。
+
+因为程序员是一种既需要经济利益刺激，又需要荣誉感的工作。看着自己做的系统跑起来，服务千千万万的用户，这种感觉是程序员特别重要的一个追求。
+
+但是说了那么多，还是一句话，技术更新是必然的。我们程序员应该做的，就是收拾心情，理解公司或者部门做出这种变化的原因，然后重新燃起自己的斗志。公司做出这种变化的时候，公司层级或者部门层级肯定有大会。但是大会更多的是单向的交流，很多问题也不适合在这种大会上提。
+
+这就是发挥一对一会议作用的时候了。在一对一会议上，我们可以把自己关心的各个点都和经理聊一聊。比如公司的发展方向、自己以后的发展路径如何与公司的发展路径切合、公司是否有资源安排跟大家做这种方向的转换，比如安排培训等等。对未来的方向清楚了，对变化的原因理解了，自然自己心里的疙瘩也就容易解开了。
+
+## 业界那些技术驱动型更新
+
+刚刚的电商例子是业务直接导致的技术更新。有些更新呢，则是更倾向于技术本身的升级换代。从公司的角度来说，公司更倾向于使用统一的、可以支撑公司未来多年发展的技术架构。这样也有利于公司内部形成技术合力。接下来我们来聊聊业界有名的那些技术更新。
+
+### 亚马逊的SOA
+
+亚马逊全面转向SOA，可能是最有名的一次变化了。简单来说，就是亚马逊提供一套SOA框架，公司内部所有的组与组之间的业务交互，都必须通过service调用来进行。强调一下，这是一个全公司层面的变化。没有任何讨价还价的余地，搞得定就搞，搞不定就换人搞。
+
+后面的事情你应该都耳熟能详了，亚马逊成功地从一个单纯的电商公司，变成了稳坐云计算头把交椅的老大。提供的AWS服务据说有几百个。可以说亚马逊公司全面转向SOA转变是它后来成为霸主的一个基础。
+
+### 阿里巴巴公司的去IOE
+
+很多年前，阿里巴巴在国内掀起了声势浩大的去IOE浪潮。IOE代表的分别是IBM小型机、Oracle数据库和EMC的存储设备。去IOE的大背景是IOE这些传统公司所提供的产品，已经跟不上互联网公司的发展了。
+
+一方面，这些产品很贵，而其主打的特性是可靠。另一方面，随着互联网公司的飞速发展，数据急速膨胀，对这些产品的要求正好是反过来的：产品一定要便宜，才能够在可控的成本下，撑得起急速膨胀的数据。互联网公司可以用自己的技术解决可靠性问题。
+
+这就是去IOE的大背景。通过自研底层这些产品，阿里巴巴靠自己的技术实力支撑起了自己的电商帝国。几年前看到的新闻是阿里系除了核心支付，其他部门都已经淘汰了Oracle数据库。而最近两年更是宣布全面替代了Oracle数据库。
+
+### 编程语言的更换
+
+很多公司也会随着规模的发展，选择更适合公司的语言。比如京东从.Net平台转变到了Java平台就是一个比较成功的例子。相信京东是看中了Java的生态全、工具全、Linux运维更成熟等原因，才做出这么大的变化。
+
+当然，也有很多公司从Java语言转变到别的语言。这都是根据公司的发展作出的选择，不涉及语言本身的优劣。
+
+### 云计算
+
+云计算可以算是最近十年最大最成功的一次技术变革。很多公司的基础设施都已经云化。现在看来，需要机器就上云去申请，已经是很自然的动作了。其实倒退个七八年，很多公司都是自己拥有或租用机房，有一个部门专门做运维，管理一堆物理机。
+
+随着人才的流动和技术的发展，以及各种各样云计算平台的出现，让云计算带来的便利得到了越来越多公司的认可。大家纷纷放弃了自建物理机房，转投各大云计算平台之上。公司摆脱了物理机对业务的束缚，并且享受着云平台带来的各种监控、运维、组网、安全、扩容等便利且高附加值的功能。
+
+## 程序员应该如何应对
+
+那么我们在面临公司技术更新的时候，究竟应该怎么办呢？我有三点经验和你分享。
+
+### 1.改变都是取舍的艺术
+
+首先，我们要意识到，没有完美的改变。我们程序员不能抓住新技术的缺陷，就将新东西一棒子打死，说这玩意就是瞎搞。
+
+如果有一种完美的变化，那这种变化大概率会自然而然地发生，不会遇到太大的阻力。而需要自上而下推动的变化，都是会涉及利益再分配的。改变很少会是完美的，新的方案也很少能完胜老的方案。每一种变化的背后，都伴随着新的问题。
+
+比如前面说的电商平台的话题，放弃了自己开发电商网站，那么随之而来的就是用户体验和页面设计会收到电商平台的限制，商品描述等也会受到电商平台的规范的约束。
+
+SOA也并非适合所有的场景。如果仅仅是交换数据，本来就是拷贝一个文件的事情，现在非要走服务调用，结果肯定会带来非常大的额外开销。
+
+IOE更是一条艰辛的道路。尤其是淘汰Oracle这个数据库的标杆产品。相信这条路阿里走得肯定很艰辛。其中Oracle数据库里各种高级的功能特性，要么就不能使用了，要么就需要在新的产品上支持。
+
+编程语言也一样，每种语言都有人在用，每种语言也都有人在骂。
+
+云计算就更是一言难尽了。物理机提供了天然的资源隔离，而云计算里的资源隔离一直被诟病。
+
+从责任上来说，作出决策的是老大们。我们程序员负责的是执行。我们改变不了我们老大已经做完的决定，但我们可以调整我们的心态，不要去抵触新技术，要看到新技术带来的新可能性。
+
+### 2.看清趋势，做好准备
+
+随着技术的发展，很多专业技能会被淘汰，甚至很多工种都会被淘汰。这时候，我们程序员一定要看清趋势，做好准备。下面我举几个例子。
+
+之前很多软件公司都有专门的人工测试。就是让测试人员来模拟用户的操作，走完整个流程，检验是否有问题。现在测试都是靠测试框架，很少有人工测试的岗位了。原来人工测试的岗位算是被行业淘汰了。所以如果你是一个人工测试工程师，那么肯定越早转测试开发越好。
+
+云计算带来的变化就更多了，可以说淘汰了很多公司的底层运维和机房运维职位。很多新公司里压根就没有这些职位，直接就是上云的，申请机器，线上运维这些工作软件工程师就能搞定。
+
+### 3.或进或退，积极应对
+
+当然，并不是说只要是变化，就一定能取得成功。失败的变化也是不胜枚举的。比如最近很火的“中台化”趋势，就是几家欢喜几家愁。还有很多微服务改造，如果不能结合实际情况实施，可能就会导致服务划分的不合理、熔断降级等落实不到位的问题，最终造成延迟增加，依赖复杂，排查错误不便等问题。
+
+虽然决策是老大做出的，但是作为一个程序员，自然对事情也有自己的看法。如果你觉得老大搞的这个事情不靠谱，那么不妨退一步海阔天空，换个组或者换个部门。这也是一种积极应对。
+
+当然，你可以觉得不靠谱，并且继续在现在的组工作。但是这时候就一定要积极地履行自己的责任，尽全力完成自己的工作。没准你做着做着，就觉得这件事情靠谱了。
+
+最危险的是自己觉得不靠谱，行动上也不积极，在老大看来就是尸位素餐，消极应对。这样即使你的判断是正确的，这件事情最后确实是不靠谱，搞不成。但是真的论起责任来，没准你就会因为工作态度有问题，变成背锅侠。
+
+所以说，程序员面对这种事情的时候，越是觉得不靠谱，越是要积极应对，努力工作，让自己的表现找不到瑕疵。要不然，就明哲保身，退到一边。
+
+## 总结
+
+这节课我们讨论了和程序员关系最紧密的职场政治之一，就是从上而下的技术更新。我之所以称之为职场政治，就是因为它除了跟技术有关，很多时候更是跟利益有关。无论是关于成就感这种虚的利益，还是自己的升职加薪、职业发展这种实实在在的利益，都有可能被技术更新打乱。
+
+从我们程序员的角度来说，有时候这种变化可以推着我们朝着更代表发展趋势的方向前进，有些时候不靠谱的变化又有可能让自己白费劲。所以我们还是回到利益这个点来看问题。老大作出决定，背负这个决定的责任。我们作为程序员，也要果断作出自己的决定，是全力以赴，还是明哲保身。
+
+<img src="https://static001.geekbang.org/resource/image/e4/yy/e423a35dea9bffd634267f37yy1fa1yy.jpg" alt="">
+
+## 思考题
+
+技术变革可以说是程序员职业生涯里逃不过的事情。你在工作中都遇到过哪些自上而下推动的技术变革呢？你是如何应对的，结果又是如何呢？
+
+今天的课程就结束了，希望可以帮助到你，也希望你在下方的留言区和我参与讨论，同时欢迎你把这节课分享给你的朋友或者同事，一起交流一下。

极客时间专栏/geek/职场求生攻略/职场情商篇/20 | 沟通技巧：如何跟自己的同事请教问题？.md

@@ -0,0 +1,121 @@
+<audio id="audio" title="20 | 沟通技巧：如何跟自己的同事请教问题？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/02/44/02c8217fc0216875fe970f9903e95744.mp3"></audio>
+
+你好，我是臧萌。今天我来和你聊聊沟通技巧这件事。
+
+我们在日常的工作中，和同事的互相交流必不可少。一方面，我们要大胆主动地和同事多多沟通交流。另一方面我们也要意识到，沟通也是有技巧的，如果沟通不得要领，会降低沟通的效率、浪费大家的时间、甚至可能会引起别人的反感。所以在这一节里，我想跟你分享一下我关于交流沟通的一些小技巧。
+
+我把沟通分成三类，分别是输出式沟通、请教式沟通、和向上沟通。这三个方向，面向的受众和沟通目的各有不同，具体的技巧各有不同。
+
+## 输出式沟通
+
+首先我们来谈谈输出式沟通。所谓的输出式沟通，就是把自己知识输出给别的同事。这里说的不是分享会这种集中式的输出，而是通过简单随意的沟通来进行的输出。这种沟通方式，非常考验技巧和方式。毕竟弄不好就会让人觉得你是在臭显摆。不信我们来转换到被输出的一方，看下面这样一个场景。
+
+### 好心也可能办坏事
+
+你工作中遇到一个问题，正在埋头研究着怎么解决，看得正起劲儿，想深入研究一下。忽然一个同事跑过来说，这个啊，你这么弄这么弄之后，再这么弄就好了。你不得不恋恋不舍地把注意力转移到这个同事身上，还不得不装作非常感激地回应这同事的“指导”。然后你说：“哦，知道了，我一会儿试试看。”然后想赶紧抽身，继续自己研究。看你没动作，同事还以为你不会，直接说我帮你弄吧，接过你的键盘鼠标刷刷刷帮你改好了。
+
+这时候，你的学习的劲头也没了大半，想着那就不妨跟这位同事多请教请教好了。当你真的就这个问题深入问下去的时候，发现同事也只会点皮毛，深入的内容并不是很懂。
+
+你想想，在这种情况下，你作为被输入知识的一方，是不是感觉有点不爽？你不仅仅是想解决一个问题，而是想借机学得更深入一点。自己学得好好的，结果被人“一顿操作猛如狗”，学习的劲头被搅和没了。站在那个热心助人的同事的角度看，好像也有点冤。自己花了时间帮你搞定了问题，最后还没落到好。
+
+想输出内容，也是要讲究方式方法的。
+
+### 看准时机，点到为止
+
+其实我曾经有一段时间，就是上面例子里说到的那个“有个同事”。自己一瓶子不满半瓶子咣当，就喜欢到处掺合着给人指点问题。这种行为，别人可能嘴上不说，但是心里还是不欢迎的。每个人都有自己的学习习惯和解决问题的方式，除非一个人的事情已经阻碍到你做事情的进度了。默认情况下，各人做各人的事情就好，一个人是不需要别人来主动指点的。更不要说例子中这种轻率地过去指点江山，甚至抢过鼠标键盘就开始操作的行为。
+
+当然，并不是说热心不对。只不过当我们主动提供帮助时，要讲究时机和力度。下面我们再来看这么一个例子。
+
+你抓耳挠腮地在看一个问题，口中情不自禁地念叨着“这破service的破接口，咋就调用不成功”之类的话。在你打算休息一下，喝口水换个心情的时候，遇到了组里的同事。同事说，那个service是挺烂的，我当时搞了半天也没成，最后一看是少传了TOKEN参数，你回去可以试试看。
+
+这样一来，你是不是感觉上要舒服得多？首先，同事并没有打断你工作的过程，而是在你已经暂停工作的时候，通过闲聊的方式分享了自己的经验。其次，同事把解决问题的主动权交给了你，你可以选择自己去试试看，也可以在自己搞不定的时候，选择去向这个同事请教。因为同事既然主动跟你说了这个话，自然表示他是愿意就这个事情提供帮助的。
+
+正所谓，观棋不语真君子。别人正在思考的时候，别东一榔头西一棒子地打断别人。别人空闲下来的时候，可以找机会说出自己的见解，表示自己愿意提供帮助。
+
+就我自己来说，我现在已经很少主动去掺合别人解决问题了。主动掺合也是多听多想，除非是我非常确定自己在这块儿吃得很透彻，否则我很少会去主动说什么。子曾经曰过：人之患，在好为人师。古人的话是有大道理的。
+
+好了，那如果你确实搞不定，需要主动寻求别人的帮助，那么应该怎么操作呢？我们来接着看。
+
+## 请教式沟通
+
+向同事请教各种问题，可以说是非常常见的一种沟通了。你会问问题吗？
+
+### 摆正态度：没人有责任帮你
+
+首先，大家是同事关系，不是师徒关系或者师生关系。所以从责任上来讲，我们周围的同事，是没有责任帮助我们，回答我们的问题的。
+
+当然，日常同事们会互帮互助。但是上面的道理是不变的。我们不能把别人的帮忙想成理所当然。不能认为这个事情我不会，那么你会你就应该教我，教到我会为止。这里是公司，不是学校。虽然大家一般都会友善地回答同事提出的问题，但是如果问的问题不对，不但很难得到想要的答案，还可能会慢慢地成为同事们拒绝帮助的对象。
+
+那接下来我们就来看看问问题的正确姿势。
+
+### 问问题的正确姿势
+
+既然同事之间都是纯友情帮忙，那么我们就尽量少去麻烦别的同事。在向同事寻求帮助之前，先做好准备工作。比如说，先去看一下组内相关的文档，先去看一下源代码，尝试自己找到问题的答案。如果是一些开源软件的用法，那么就自己去开源网站上看相关的文档，自己学起来。如果在这个过程中，遇到了非常具体的问题，那么就可以考虑拿这些具体的问题去问相关的同事了。
+
+最不受欢迎的问题就是：XXX怎么搞。记住，工作是自己的，问题也是自己的，一个XXX怎么搞的问题，基本就是把自己的工作扔给别人去做了。问别人问题，要尽量具体，而不是非常笼统地问一个问题。
+
+当然，很多时候，如果懂的同事帮忙指点一下，可能几分钟就能搞定了。自己看，可能要几个小时甚至一天。但是这个过程是很难避免的。以一个当前的工作为契机，自己慢慢熟悉起工作中涉及的各个模块，最后收获的是以后可以自己解决问题的能力。如果靠同事指点，解决问题是快，但是收获也小的多。
+
+所以说，问问题的本质，不是让别人帮你解决问题，而是**要学会自己解决问题**。如果问题解决了，自己还是一脸茫然，下次遇到类似或者相关的问题，还是不会，那么你就不是在问问题，你是在让别人帮你来做你自己的工作。
+
+在完成工作的这条路上，路要自己走，在路口不知道怎么走的时候，可以问别人。但是一般情况下，不能让别人领着你一路走到终点。举个简单的例子，你分到的工作任务是用HBase做一个缓存，那么下面三个问题，就非常不适合问同事：
+
+1. HBase是什么；
+1. HBase怎么用；
+1. HBase的客户端有那么多API，我应该用哪个。
+
+因为这三个问题，你靠搜索公开资料就可以自己搞定，完全不需要问别人。但是下面这三个问题，就可以问问周围的同事：
+
+1. 我们公司的HBase集群配置在哪里可以找到；
+1. 我研究了一下HBase，感觉HBase做缓存可能会有些问题，比如内存命中失败的时候，加载数据可能会很慢；
+1. HBase的可用性能满足我们对缓存的要求吗？
+
+在这三个问题里，第一个问题属于常识性的问题。这个问有经验的同事没问题，他们可能会直接给你一个文档链接，然后剩下的事情你自己就可以搞定了。
+
+而下面的两个问题，都是比较有建设性的问题。其实这已经部分脱离了单纯的请教式沟通，而是更多地向探索式的双向沟通发展。从我个人的角度来看，我是比较欢迎这种问题的。因为和大家一起讨论这种问题，大家都能够得到能力和认知的提升。
+
+### 写在后面的三个小技巧
+
+首先要重点说一下的是，千万不要相同的问题问了一遍又一遍。这不叫问问题，这叫把别人当工具人使唤。如果问别人问题，别人也愿意回答，那就一次性问清楚问明白，然后自己好好总结，牢牢记住。一遍遍地问相同或相似的问题，是对别人的不尊重。
+
+然后是积极总结归纳。如果你向别人请教问题，收获了很多，那么不妨总结出一个文档发出来。这样一方面，归纳的过程能加深巩固你自己收获的知识，另一方面你整理出的文档可以帮助更多的人解决问题。这样做也能表达对帮你一把的同事的尊重。
+
+最后一点就是，如果你确实是个超级大萌新，什么都不懂，每天不得不到处请教同事各种问题，那么不妨和经理反映一下自己的实际情况，让经理指派人来帮你完成工作热身。毕竟大家都很忙，对于每天都要完成自己的工作的同事们，很难说能够挤出足够的时间来帮助你。
+
+## 向上沟通
+
+向上沟通，就是指和经理沟通。向上沟通有三个主要目的，分别是汇报工作、申请资源、请求帮忙做决策。总的来说，这三种目的的沟通，都需要提前准备好足够的信息，而且跟经理沟通，要仔细负责，不能信口胡来。下面我来展开说一下。
+
+汇报工作时，先交代两个重点：成果和问题。工作成果是指那些已经落实了的成果，没落实的、没实际验证的不要想当然地乱说。问题是指现在遇到的感觉需要经理帮忙协调的，以及需要经理调动资源解决的事情。至于自己就能解决的问题，不需要说太多。
+
+比如说之前提到的用HBase做缓存的工作。如果要就这个工作向经理汇报，那么下面几个内容是要给出来的：测试环境是否可用、生产环境是否可用、外部依赖是否解决。我们自己是否提供了jar client、还是通过 service API访问、或者说都支持。要是支持的话，性能指标数据又分别是什么。至于细节的技术问题，没必要说，经理不是帮你解决技术问题的。
+
+然后是申请资源。这时候，要整理清楚前因后果，你要想明白申请了资源能做到哪些事情、申请不到又会影响哪些事情、为什么资源不是要得更多或者更少。简言之，就是要证明这个资源用得值。
+
+还是拿HBase做缓存的例子。在测试环境下，你可以整理出数据量、缓存命中率、HBase内存、性能指标的统计数据。然后根据这些数据，以及整体对性能指标的要求，提出生产环境需要的机器资源和配置。
+
+最后是请求帮忙做决策。自己不能做决定的事情，就需要经理帮忙了。这种情况很多，比如遇到了新的情况，或者遇到需要对外部作出承诺的事情等等，所有自己吃不准的，不知道如何处理的，都可以找经理帮忙做决策。
+
+当然，我们找经理做决策，不是去把包袱扔给经理，而是和经理一块协调解决问题。所以在找经理之前，我们也要整理好足够多的信息才行。
+
+比如用HBase做缓存的例子，就像我们前面提到过的，如果在实测的时候，发现HBase不是很适合做缓存，比如因为缓存不命中，会导致P99在1秒以上，比如HBase在生产上有2%的时间会有3%的数据不可用。收集好这些数据，可以让经理做决策，我们是否继续用HBase做缓存，还是另外寻找其它解决方案。当然，如果你已经有别的缓存解决方案的数据，也要一并提供给经理。
+
+总结一下，和经理沟通，不是让经理帮你干活。要带着足够的信息来，不要只带着问题来。
+
+## 总结
+
+好了，讲到这里，这节课也就接近尾声了。这一节中，我们聊了聊沟通的技巧。虽然我们是按照三种不同的角度来说的，但是你发现没有，其实底层的逻辑就是一个词：尊重。
+
+输出式沟通时，对别人要有尊重，不“好为人师”。做到真的是在帮助别人，而不是显摆自己。
+
+请教式沟通时，要自己做出足够多的努力，而不是把手一甩，就直接让别人帮自己干活。同时，也要尊重别人为了帮你而付出的时间，不要拿别人的时间精力不当回事儿。最好是能提出有建设性的问题，这样双方都可以有进步。长期来看，这种请教式的沟通才是一个良性问问题的方式。
+
+和上级沟通时，要准备好足够的数据，说的事情要有理有据，对自己的话负责，不要说一些模棱两可和想当然的东西。这是对上级的尊重。
+
+<img src="https://static001.geekbang.org/resource/image/2e/d5/2e61eb1ce1a3b601590c85f6b978aed5.jpg" alt="">
+
+## 思考题
+
+沟通是必要的，沟通的技巧也是要掌握的。你在工作中，都遇到过哪些让你感觉很膈应的沟通？又遇到过那些让你如沐春风的沟通？
+
+今天的课程就结束了，希望可以帮助到你，也希望你在下方的留言区和我参与讨论，同时欢迎你把这节课分享给你的朋友或者同事，一起交流一下。

极客时间专栏/geek/职场求生攻略/职场情商篇/21 | 答疑篇：想升职，我该准备些什么？.md

@@ -0,0 +1,88 @@
+<audio id="audio" title="21 | 答疑篇：想升职，我该准备些什么？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/1e/ab/1edbe865526d2ddfe8086987ff532fab.mp3"></audio>
+
+你好，我是臧萌。转眼之间，咱们第三个模块也结束了。这个模块不大，我们讲了升职、职场政治、和同事沟通这三个点。别看第三个模块不大，但对于满眼都是技术的程序员来说，尤其容易忽视这些问题，导致踩坑。所以我们更要去注意人与人之间的关系，培养好自己的职场情商，做好自己的绿叶角色。下面我就针对这个模块的热点问题做个详细解答。
+
+## “会表现”就容易升职吗？
+
+首先是升职，有同学说，要想升职，还是要会表现。如果是只会默默干活的人，升职机会就少。
+
+很多时候事实就是这样的。
+
+与其默默干活，看别人升职加薪，不如我来给你分享两个容易上手的表现技巧。
+
+会表现，一方面就是多说、多露面、多交流。就好像之前说过的那样，交流沟通可以让人与人之间，组织与组织之间的合作更顺畅，及时消除彼此之间对事情理解的不同。多露面多交流，既能够在经理面前混个脸熟，还能在不怎么交流的大群体里，显得你是个稀缺交流人才，那么你升职更快也就是合理的。
+
+另一方面，会表现还包含和经理沟通顺畅，想经理所想，急经理所急，尽自己最大的努力来帮助经理。这种情况下，经理自然也会更照顾这个人，优先给这个人升职。
+
+那我们反过来再想想，经理安排一件事情给手下，接下来为什么这么做、这么做好不好、怎么做才能更好，这些都是经理希望自己的手下来多花心思来思考的。如果一个人只是自顾自地干活，在经理看来，那也只是手下生硬地干好了交代的活儿而已，没有融入到这个团队，这个公司。对比“会表现”的同事，自然是差了一节。
+
+从利益的角度来说，会表现的人是经理想留下的，因为这种人才的替换成本更高。而只会让干啥就干啥的人，他们可能得不到升职后会选择离职，但这种人随时可以通过招聘找到，从管理者的角度来看，替换成本没那么高。
+
+咱们这个专栏怎么说的来着？“会工作也是个技术活儿”。
+
+## 想升职，该准备些什么？
+
+还有同学提供了很多有助于自己升职的小技巧，比如来自 **@🛠️🛠️🛠️人和尚** 的分享。
+
+- 在公司多做分享，不管有没有人听。
+- 多画图。
+- 体系化思考，总结的能力，形成自己的方法论。
+- 要有自己落地的action，有case支撑。
+
+我解读一下他的话，就是要养成分享的习惯，锻炼自己做分享的能力。没有人听不重要，自己的能力得到锻炼了，随着自己的成长和做的事情越来越有料，以后不会缺少听众的。
+
+而且关于这一点，还有一个很重要的隐含因素，就是要增加自己的曝光率，让更多的人知道自己的名字，知道自己干了什么。如果想给一个人升职，结果大家看到这个人的名字，都感觉很陌生，完全没有任何印象，那么作为升职评审的人，很可能会保守地倾向于否定。但是如果对这个人有印象，知道他分享过什么知识，参与过什么项目，那么名字背后的内容就丰富形象很多，给他通过或者不通过，也会更有据可循。
+
+多画图，也是一个锻炼自己表达能力的方式。正所谓，一图胜千言，能把事情用图展示清楚，让人能马上明白这个事情的要点，是一个非常高级的能力。
+
+第三点，在我看来，就是要能吃透自己的系统，建立自己对系统的认识。
+
+第四点就是要有料，对于自己做出的成绩，要总结归纳得光鲜亮丽，让别人一目了然，无法否定。
+
+还有来自**@ecanfly** 的分享。
+
+提前收集数据，做出成果前后有对比。晋升材料尽早准备，多演练多演练多演练。关键还是日常积累，体系化思考，体系化呈现结果。
+
+简单来说，就是要能突出自己的成绩，要好好准备自己的晋升。这点也很重要，程序员不要抹不开面子。事情做都做了，好好拿出来说说，展示一下自己的成绩，没什么不可以的。升职是自己的事情，自己肯定要多操心。其实有时候，经理真的不一定能记住你一年到头做了哪些事情，所以，务必记得自己做出的成绩，而且要想办法如实突出自己的成绩。
+
+## 技术业务两手抓
+
+关于技术升级，有些同学表示一般都没问题。 更多的应该关注于业务线的升级。
+
+是的，我在文中将业务线的升级，和技术本身的升级换代，都简称为技术升级了。比如电商决定放弃自研电商网站，转向对接电商平台，其实就是一次业务升级。比如携程之前的模式被称作鼠标+水泥，也就是PC端+呼叫中心。后来为了迎接移动互联网的挑战，推出了大拇指+水泥战略，也就是要靠手机App+呼叫中心。公司类似的这种变化，对所有技术人员都是一次机遇和挑战。
+
+再补充一点，新技术一般都更好更先进。但是好的并不代表就是适合的，还是要结合自己的业务、组织架构、实际技术能力等现实情况来具体分析。就好比你手里一天的生活费有100块钱，如果附近有个高级购物中心开业了，基本跟自己没啥关系；如果自己不能吃辣，就算附近开了个好吃的川菜馆，也跟自己没啥关系。如果你硬要上，就要有问题了。
+
+## 你真的会沟通吗？
+
+沟通技巧，我没有将它放在第一篇中，而是放在了职场情商篇中。原因是沟通是工作要求的基本素质，而沟通的技巧，则更关乎情商。
+
+俗话说，三岁学说话，一生学闭嘴。话不是说越多就越好，如果技巧有大问题，那么沟通的结果可能是负面的。当然，大家都是社会人，不会有人愣头青一样地直接跟你说：你别来找我了，你说的这些都是废话，对事情毫无帮助。（不会吧不会吧不会吧，不会真的有人这么说吧。）这么说是过分了一点，但是对方心里的意思可能就是这个意思。
+
+这里呢，我给一个指标供你参考。这个指标就是你找人沟通，和别人找你沟通的次数比例。如果每次都是你主动找别人沟通，但是别人极少主动过来找你沟通，那可能就说明，别人和你沟通下来，感觉收获不大。
+
+如果每次和你沟通完，都有“与君一席话，胜读十本书”的收获感，别人肯定逮住机会就找你聊聊。当然，这个指标也是受到各种因素影响的，比如因为彼此的职责和级别不同等。但是站在基层一线程序员的角度，这个指标还是有参考意义的。
+
+当然，不是说没人过来找咱，咱就放弃了，而是应该主动解决自己的短板。你可以从认真对待和总结与别人的每次沟通开始。记住沟通的核心：尊重。和你沟通，是否有收获？如果没有收获，自己应该如何改进？只要思想不滑坡，办法总比问题多。
+
+## 毕业生需要什么样的帮助？
+
+有同学问，有些刚毕业的同事，希望得到全方位立体式帮助。对于这些同事，工作中应该如何带呢。
+
+这里，我的建议是，对于刚毕业的同事，还是要多宽容一点。毕竟大家都是从开始什么都不会这样一路过来的。提示他们可以自己尝试着解决。遇到真的问题再大家一起讨论。
+
+很多刚毕业的同事并不是能力不行，导致一个事情搞不定，而是他们自信心不足，怕自己搞会弄出问题。这时候他们需要的不是一个帮他们的人，而是一个给他们信心的人，让他们可以放心大胆去自己搞。你需要做的是告诉他们：“有问题不怕，遇到问题来找我”。
+
+## 总结
+
+和机器打交道，靠技术。和人打交道，靠情商。咱们程序员，如果不想被贴上低情商的标签，首先得重视情商，要能清楚的意识到情商在工作中的重要作用。
+
+打开IDE，程序员就是一个没得感情的代码生成器。但放下键盘鼠标，我们程序员作为芸芸社畜里的一员，也要频繁的和人打交道。人和人的关系，就要靠情商来支撑了。
+
+情商不是阿谀奉承、放彩虹屁，不是阴险狡诈、两面三刀。对于程序员来说，情商可以充当人与人之间关系的debugger。与人交流的时候，可以设置一个断点，好好想想该怎么说话。人与人之间相处时的那些事儿，也可以用调试程序的态度来复盘。在尊重彼此的利益的前提下，我们要用好这个debugger，把人与人之间相处时的那些事儿整明白。
+
+培养自己的情商，可以让自己与同事和上下级更好的相处，更高效的工作，更好的收获自己的利益。
+
+以上就是答疑篇的内容，不知道有没有解决你的困惑呢？
+
+欢迎你在评论区与我交流一下你的想法，也欢迎把这篇文章分享给你的朋友或者你的同事，一起来交流一下。