源 / Yoguo.us        文 /  余果

一、

今年是2018年，腾讯20周年。我30周岁，刚好在腾讯工作满8年。

我从来没有想过自己会在同一家公司工作8年。因为4年足以读完大学，6年能让小孩读完小学，8年漫长得不可思议。

2010年，我刚大学毕业，加入腾讯。那一天，学生思维的我，不免以学生的尺度定计划：三年的时间，我应该足够从这一所“社会大学”毕业吧。

因此，我追赶时间，以这个截止日为目标，第一年学习高效地完成工作，第二年学习带新人，第三年学习影响力，翻译了一本前端书，和一本设计书。

我一步步从助理UI工程师晋级到高级UI工程师，先是积极响应需求，后来主动找事情做。我低着头，做事情非常“用力”，自信能把交给我的事情都做得很好。

我的博客文章80%都是头三年写的，现在回头看有很多幼稚的想法，但持续想和写才能提高。反过来说，要是现在还觉得好，那才糟糕。

二、

2013年，三年之痒。我开始觉得日常工作毫无挑战，考评时连续“优秀”跟“超出预期”拿到手软，但与此同时，也迎来新的工作挑战。

那时，我的领导问我以后的发展意向，是想继续研究技术深度，还是管理团队。我说如果有机会，尽量管理团队吧。

因为以我的理解，并不存在两种选项。这个问题就像“给你加工资，好不好啊”一样没有意义。学而优则仕，骨干不去领导团队，可能有点不负责任（现在想来很自恋，呵呵）。

虽然给了领导这样的答复，也开始进行正式的管理培训，但我内心还恋恋不舍想保留一点匠人心态。

个人能力要继续提高，我就开辟新的赛道：影响力。

2014年我认真地投入到写作练习中，在“26岁总结”中写下这段文字：

“在很多场景下我们都需要写作，我们要写短小的RTX，长一点的邮件，以及更长一点的分享文章、博客和专栏。关于写作，我觉得最有趣的一个事实是，优秀的写作者跟平庸的写作者所能达到的效果相差百倍以上，比优秀程序员和平庸程序员之间的差别还大。”

“优秀的写作者的RTX就是能让对方明白他的目的，并且像施了魔咒一样去合作。优秀的写作者的邮件能让接受者感兴趣，清晰地知道信息。优秀的写作者写的博客能用一段话击中读者心理，情不自禁点右上角的“分享到朋友圈”……这种效果100个平庸的写作者都达不到。”

“写作者需要的除了文笔，还有逻辑思维、数据分析、麦肯锡金字塔理论、心理学等等几乎所有的知识……”

每个人每天都要阅读微信、朋友圈、新闻、读书、知乎、小视频……关于写作对个人能力的的重要性，我认为怎么强调都不为过。因为广义的写作、演讲和设计，它们有一个共同的关键内核，就是搞清楚你的听众是谁，他们已有哪些信息，缺乏哪些信息，你要以怎么样的顺序来传达你想让对方做的事情。讲得邪乎点，它们都是一种“心理操纵术”。

那怎么才能学好写作（或者演讲，或者设计）呢？

答案无趣但有效：持续写。

反复阅读写出来的文字，毫不吝啬地删除无用的信息，重新再写。

达芬奇说过一句话：“Simplicity is the ultimate form of sophistication（简洁是终极的复杂）”。海明威每天写作之前都会把前一天的稿再改一次。

我也这样做，一开始在自己博客上写水文、在豆瓣写书评，感觉不够。2014年2月，我加入豆瓣专栏计划，需要每周写一篇超过3000字的专栏文章，结束后能获得200元鼓励金。我就像一个缺乏运动的人，强行把自己推入马拉松赛道。

我的前几篇写的很业余，错别字、口水话、病句、缺主语、串主语、一逗到底、唠唠叨叨、层级和顺序不对……那也还是要写。几个月后，20篇文章的专栏完结了，我的文字水平稳定从30分提升到50分，接近及格。

因为专栏内容相对新颖（可能是国内首批系统写“全栈工程师”的思考的专栏），慢慢积累一些读者并每周追看。读者宽容并热情地在评论区给我纠错。

后来，人民邮电出版社的责编在豆瓣上看到了我，就约我写稿。他说我写的东西已经很多，也有一些脉络，可以再整理一下出书。又是一个新的挑战。

先答应再说吧。

写书的过程只能说勉力支撑，因为只有50分的文字水平，却要输出80分的质量。把第一章整理好之后发过去，收到返回的修正稿，变成了另一篇文章。责编很专业，没有吐槽，只是做客观订正。

我羞愧难当，因为痛恨给人添麻烦。我记住修改过的问题种类，文法上字斟句酌，保证同类的不再犯。

因为责编会看出文字上的问题，然后给我修剪枝丫，但保持大树根基稳定就是我自己的责任，对读者的责任。我还买来《麦肯锡教我的写作武器》，更系统地学习写作。

经过好多轮的校对，我终于可以坦然说出，差不多达到基本的标准了。后面的事情我在“我出书了”中也都写了。2015年8月，我的书出版了。我在豆瓣上也慎重给《Web全栈工程师的自我修养》打了4星。

三、

写作成长磕磕碰碰的同时，管理之路也迂回曲折。试着带一段时间团队之后，我在2014年正式成为团队管理者。

当时对于团队管理的职责抱有几个不成熟心态：

1. 管理比写代码更容易掌握，践行起来也更轻松

2. 管理者门槛较低，相较于工程师缺乏核心竞争力，以后跳槽我还是要以工程师身份来定位

3. 我喜欢专注做事情，不适合做管理

4. 在工程师团队中，我要以最强的技术和努力来赢得尊重，我要有能力解决他们都解决不了的问题

因此，从2014-2016虽然也通过努力收获了一些个人成长，但对团队领导来讲其实我是不称职的。

有一个明显不称职的表现就是，每到员工考核期间，我就很纠结痛苦。我不希望有员工拿低于预期的考评，也害怕面对下属沟通面谈，当面对着他说你的绩效低于预期。

我能自律勤奋，但我很难改变自己的观念。最难的是，我甚至不知道自己是否应该改变自己的观念（瞧，这就是为什么改变观念是最难的），还是说退回去做一个还不错的工程师好了。

我在这个观念段位大概停留了两年多，经过断断续续的实践、阅读、观察和自省，我终于升级了。期间纠结和思考过程可以从2014到2016的博客文章中可见一斑。

总之，升级后的我认为：

1. 管理比写代码（或任何一门硬技能）更难于掌握，这是我跟一些技术专家沟通得到的共识。硬技能的学习可以通过读书、培训班，甚至网络视频来学习，然后持续练习，越来越熟练，直到产生一个输出物。这非常简单，只要掌握了学习的方法，几个月就能学习一门硬技能。而管理的学习需要真实观念的转变，这个观念改变可能需要几年时间。

2. 管理的核心观念是“管理者必须善于做有效的决策”。

3. 管理者要注重组织对外的贡献。基于贡献来衡量每个人的绩效。

我开始积极与团队沟通，日常中看到不符合要求的输出，我就会直截了当地说“这不行，达不到基本水准”。

虽然比较严格，但也没有看到团队氛围下降的情况。因为从员工角度来讲，虽然乐于处在一个人际关系融洽的团队中，但更大的述求是加入一个充满专业人士的团队。每人都能从其他人身上学到特定知识，每人表现都是专业的。

我不再担心员工考核，因为它是一个有效的管理工具。有些无法用言语传达到的信息，可以通过绩效考核来传达。而且平时对于低绩效的员工就要做好预期管理，言行一致员工就不会困惑。

四、

2017年，我慢慢成为一个资深的管理者。又一次对工作驾轻就熟时，再次迎来新的挑战——转换岗位，领导腾讯微云UX设计团队。

我喜欢这个挑战，一方面它确实是一个“很大挑战”，受虐症的我无法拒绝。另一方面我一直处于产品流程中偏后的位置，但也对前置的思考很感兴趣。

因此，我梳理了自己面临的挑战：

1. 之前领导的团队都是工程师，而现在的团队由交互设计师和视觉设计师组成。虽然管理的基本法是相通的，但新团队的成员还需要更多熟悉

2. 自己的设计专业能力不够，尤其是在视觉上，无法给到“怎么做”的建议

3. 新的UX设计团队面临比以前更复杂的外部关系

4. 如何帮助下属专业晋升

但我也有我的优势：

1. 能轻松地理解版本管理、多平台特性、开发挑战等“工程”难题，然后管理好风险

2. 参加了三年多设计部的管理会，对设计的“味道”有感觉。或者说品味远远高出实现能力

3. 在UI方案上，我有用户同理心，不只是从“好看”来评判设计

4. 我的演讲呈现能力和写作能力可以提升团队

唔，也不全是坏消息嘛。那就开始做吧！

前半年仍然是勉力支撑（哭），但因为团队都在看着自己，不自信也要自信起来。

工作之余多体验各种APP，收集UI、运营、营收、品牌等方面的案例，进一步提升“产品力”。老婆平时在使用新的APP，或者被活动吸引付费时，我就会在边上观察她的行为。看到精彩处，我还会请求暂停，截图发给我。

总之，我希望自己的专业成长能快速补上权限扩大带来的差距。

慢慢地，有一些“腾讯微云用户体验不错”的口碑了，在自己能影响的范围内，使用我能调用的资源，慢慢地补齐漏洞，提升体验。

但仍然能力有限，有时候会出现仓促出的方案不合理的情况。这时更加如履薄冰，不是怕外部批评我，而是怕连累授权给我的上司，和被我能力所限的团队。加上腾讯微云也是一个有历史包袱的产品，所以仍然离自己心中的理想产品差很多。

团队成长上的挑战同样很大。

我仔细观察每一个人的优缺点，用人所长。于此同时我还要横向去看部门其他设计师的输出，不希望相对独立的产品导致了封闭的专业氛围。这将是接下来花半年到一年重点要解决的。

我对现在这个挑战，还远远没到驾轻就熟的状态，可能还需要两年以上时间来消化，所以有时工作会觉得比前几年加起来还累。

我时常以山本耀司的话给自己打鸡血：

我从不相信什么懒洋洋的自由，我向往的自由是通过勤奋和努力实现更广阔的人生，那样的自由才是珍贵的、有价值的。我相信一万小时定律，我从来不相信天上掉馅饼的灵感和坐等的成就。做一个自由又自律的人，靠势必实现的决心认真地活着。

勤奋和努力只是基础，以大多数人的努力程度之低，还根本谈不上拼天赋。

疲劳和兴奋交替，成就和挫折并存，曲折前行，比轻松混日子更有趣。

五、

回头看，这八年来，我从来都只是“短暂地胜任”自己的工作。每当我觉得能够驾轻就熟地处理目前的日常，就会迎来新的挑战。

想到这一点，我突然悟到一种“佛性”的工作哲学：

每当你能胜任当前的工作，就会迎来更高难度的挑战。

每一个能胜任当前工作岗位的人，都会被提拔。继续胜任，那就继续提拔，直到不能胜任。

因此，不用特别在意自己的头衔、权限和职级，外部的认可是你能力的反馈。你没有被提拔，大概率是因为还不胜任当前工作。如果完全胜任还没有被安排更有挑战的工作，要么自己找事情做，要么跳槽转岗。

反过来说，自知自己能力还达不到岗位要求也不用担心，不胜任是常态，以胜任为目标就好啦。

对于职场马拉松来说，心态放松，保持作息，持续养成好的习惯，学习好的方法和观念，这才是最重要的。

-END-

原文链接：https://yuguo.us/weblog/

转载声明：本文选自「 余果博客 」，点击阅读原文即可关注

本次送书

本次送书活动由博文视点介绍赞助！

博文视点-品牌商标

目前微服务的现状是概念多于实践，管理和架构人员往往不知道如何落地微服务，《微服务架构实战》从软件工程的角度切入，融入了作者多年的管理及架构经验，内容完全基于实际经验所得，直击痛处。通过阅读本书，开发人员能够实现微服务的快速落地。

《微服务架构实战》共12章，分为概念篇、开发篇、运维篇和实战篇。概念篇详细阐述微服务的由来和设计要点。开发篇介绍Spring Boot、Docker和Spring Cloud应用于微服务的案例，并且附有源代码。运维篇从测试、快速开发、质量管理、自动化运维和监控的角度介绍微服务涉及的知识点。实战篇将企业级开发中涉及的内容尽可能详细地列出。

《微服务架构实战》不但适合初学者，而且对于团队的管理者及技术选型的架构师也有着非常大的参考意义。

觉得书不错的，扫描下边二维码，直接购买哦！

扫描下文进行抽奖哦！

点击图片查看更多推荐内容

↓↓↓

创业公司技术总监，去上市公司面试，结果凉了！

无所不能的RPC消息协议是如何设计的？

最坏的不是面试被拒，而是根本没有面试机会！

从分布式之的角度告诉你前后端分离架构的必要性！