自我成长与团队管理——一些总结

本文章来源于：https://github.com/Zeb-D/my-review ，请star 强力支持，你的支持，就是我的动力。

文章目录

• • @[toc]
  • • 背景
    • 自身成长
    • • 学好技术
      • 学好英语
    • 团队成长
    • • 团队建设
      • 团队文化建设

背景

最近身边的同事私下向我交流心声，

在学习方面，如没时间学习、不知道怎么找资源学习、不知道怎么学习、平时接触的技术能力没锻炼、以前掌握的技术变成不熟悉了；

在工作方面，如经常性开会，方案一直评审没时间专心敲代码；业务方面相似度高如就是一些CRUD；跨部门协同效率低；协调各方面的资源很累，如何提高自己业务上的产出，如何提高领导对自己的看法以至于可以负责更多的业务；甚至是在工作压力下还能一如既往的疯狂输出；etc…

在职业上，大家都有颗DayDayUp的心，奈何有心无力伐天，怎么从中级猿到高级秃头猿，怎么更好的锻炼好自己的业务能力，怎么成武技术上和业务上的架构师；etc…

在家庭或者业余方面，如何划出更多的时间to live to life,工作与生活交叉更协调，如何认识业界各种大佬，甚至抱各种大中小腿；etc…

为什么会有这些担心或者浮躁之举，一是沉迷业务不能自拔，常常迷失了自我；二是年龄也大了，压力也大了，年龄不是25就是30，精力输出不再是毕业时那小清新可比；三是想问下自己，路在何方；

这些交流，在我看来大抵分为两种：一是关于成长方面的技能提升，二是团队方面的技能提升；接下来专门分别来细讲这两块；

自身成长

在自身成长方面：

• 学习方面还是协调家庭方面，抗压方面，这些都可以归结为自我管理，可以说是自己能主观的去做到；
• 技能方面还是业务设计甚至说架构设计，这些都可以归结于个人的专业性；
• 跨部门协调还是组织资源这些可简单理解为沟通协调；
• 至于怎么校验成长的结果，这个比较好说，想提高自己在领导层或者业界的看法，结果导向可以说第一维度；如你的工资比我高xxK，那么大家就认为你比我牛；你快速完高质量成各种任务，那么你可以负责的更多，输出更多；

上面这些可以说，个人在公司或者生活上，个人的单兵作战能力，

在如今社会方面，历史往往表明，如“三个臭皮匠顶个诸葛亮”，在群体之间，个人作用远小于群体的作用如1<<N；当然排除某些方面极个别人会 一个顶几的情况；

自身成长也有部分和团队有一些关系，交叉的方面不多；

现在我结合自身的成长和身边的一些朋友的交流，可以分为两部分，学好技术和学好英语；

学好技术

在我看来，知识网络的搭建就是在造楼房：基础也就是地基的承载力，决定了你能把楼造多高；广度就像是把房子造大、造宽；深度就是楼房的高度。因此，如果你想要提升自己的水平，那这三个方面的发展缺一不可。

• 第一，学习必须靠自觉。

虽说工作经历和项目经验是实践技术、提升技术的一个重要手段，但不可能所有的工作经历和项目都能持续地提升我们的技术。所以，我们要想提升自己的技术水平，就必须打消仅仅通过工作经历来提升的念头，要靠业余时间主动地持续学习和积累来提升。
比如，你可以针对项目中用到的技术，全面阅读官方文档，做各种 Demo 来论证其技术特性。在这个过程中，你一定还会产生许多技术疑问，那就继续展开学习。

• 第二，不要吝啬分享。

刚毕业那会，我花了很多时间和精力在 CSDN 回答问题，积极写博客、上传自己实践代码至github。这些经历对我的技术成长，帮助非常大。
很多知识点我们自认为完全掌握了，但其实并不是那么回事儿。当我们要说出来教别人的时候，就必须 100% 了解每一个细节。因此，分享不仅是帮助自己进一步理清每一个知识点、锻炼自己的表达能力，更是一种强迫自己学习的手段，因为你要保证按时交付。
当然了，分享的过程也需要些正向激励，让自己保持分享的激情。

• 第三，不要停留在舒适区。

利用业余时间多学习几门不同类型的编程语言，比如 Java、Python 和 Go。
有些时候，我们因为恐惧跳出舒适区而不愿意学习和引入合适的新技术来解决问题，虽然省去了前期的学习转型成本，但是后期却会投入更多的时间来弥补技术上的短板。

• 第四，打好基础很重要。

这里的“基础”是指，和编程语言无关的那部分知识，包括硬件基础、操作系统原理、TCP/IP、HTTP、数据结构和算法、安全基础、设计模式、数据库原理等。学习基础知识是比较枯燥的过程，需要大块的时间来系统阅读相关书籍，并要尝试把学到的知识付诸实践。只有实践过的技术才能映入脑子里，否则只是书本上的知识。
比如，学习 TCP/IP 的时候，我们可以使用 Wireshark 来观察网络数据。又比如，学习设计模式的时候，我们可以结合身边的业务案例来思考下，是否有对应的适用场景，如果没有能否模拟一个场景，然后使用所有设计模式和自己熟悉的语言开发一个实际的 Demo。
这些看似和我们日常业务开发关系不大的基础知识，是我们是否能够深入理解技术的最重要的基石。

• 第五，想办法积累技术深度。

对开发者而言，技术深度体现在从一个框架、组件或 SDK 的使用者转变为开发者。
虽然不建议大家重复去造轮子、造框架，但我们完全可以阅读各种框架的源码去了解其实现，并亲手实现一些框架的原型。比如，你可以尝试把 MVC、RPC、ORM、IoC、AOP 等框架，都实现一个最基本功能点原型。在实现的过程中，你一定会遇到很多问题和难点，然后再继续研究一下 Spring、Hibernate、Dubbo 等框架是如何实现的。
当把自己的小框架实现出来的那一刻，你收获的不仅是满满的成就感，更是在技术深度积累上的更进一步。在这个过程中，你肯定会遇到不少问题、解决不少问题。有了这些积累，之后再去学习甚至二次开发那些流行的开源框架，就会更容易了。
除了实现一些框架外，我还建议你选择一个中间件（比如 Redis、RocketMQ）来练手学习网络知识，大部分架构师都掌握一个以上中间件。
我们可以先实现它的客户端，用 Netty 实现 TCP 通信层的功能，之后参照官方文档实现协议封装、客户端连接池等功能。在实现的过程中，你可以对自己实现的客户端进行压测，分析和官方实现的性能差距。这样一来，你不仅可以对 TCP/IP 网络有更深入的了解，还可以获得很多网络方面的优化经验。
然后，再尝试实现服务端，进一步加深对网络的认识。最后，尝试把服务端扩展为支持高可用的集群，来加深对分布式通信技术的理解。
在实现这样一个分布式 C/S 中间件的过程中，你对技术的理解肯定会深入了许多。在这个过程中，你会发现，技术深度的“下探”和基础知识的积累息息相关。基础知识不扎实，往深了走往往会步履维艰。

这时，你可以再回过头来，重新系统学习一些基础理论。

• 第六，扩大技术广度也重要。

除了之前提到的多学几门编程语言之外，在技术广度的拓展上，我们还可以在两个方面下功夫。
第一，阅读大量的技术书籍。新出来的各种技术图书（不只是编程相关的），一般我都会买。几年来，我买了 100 多本技术图书或者电子书，大概有三分之一是完整看过的，还有三分之一只翻了一个大概，还有三分之一只看了目录。业余时间看纸质书或代码实践，上班途中看Kindle；
广泛的阅读，让我能够了解目前各种技术的主流框架和平台。这样的好处是，在整体看技术方案的时候，我可以知道大家都在做什么，不至于只能理解方案中的一部分。对于看不完的、又比较有价值的书，我会做好标签，等空闲的时候再看。
第二，在开发程序的时候，我们会直接使用运维搭建的数据库（比如 Elasticsearch、MySQL）、中间件（比如 RabbitMQ、ZooKeeper）、容器云（比如 Kubernetes）。但，如果我们只会使用这些组件而不会搭建的话，对它们的理解很可能只是停留在 API 或客户端层面。因此，我建议你去尝试下从头搭建和配置这些组件，在遇到性能问题的时候自己着手分析一下。把实现技术的前后打通，遇到问题时我们就不至于手足无措了。

学好英语

为啥要单独说英语的学习方法呢，这是因为学好英语对做技术的同学非常重要：

• 国外的社区环境比较好，许多技术问题只有通过英文关键字才能在 Google 或 Stackoverflow 上搜到答案；
• 可以第一时间学习各种新技术、阅读第一手资料，中文翻译资料往往至少有半年左右的延迟；
• 参与或研究各种开源项目，和老外沟通需要使用英语来提问，以及阅读别人的答复。

所以说，学好英语可以整体拓宽个人视野。

不过，对于上班族来说，我们可能没有太多的大块时间投入英语学习，那如何利用碎片时间、相对休闲地学习英语呢？

还有一个问题是，学好英语需要大量的练习和训练，但不在外企工作就连个英语环境都没有，那如何解决这样的矛盾呢？

接下来，我将从读、听、写和说四个方面，和你分享一下我学习英语的方法。

• 读方面

读对于我们这些搞技术的人来说是最重要的，并且也是最容易掌握的。我建议你这么学：

先从阅读身边的技术文档开始，有英语文档的一定要选择阅读英语文档。

一来，贴近实际工作，是我们真正用得到的知识，比较容易有兴趣去读；

二来，这些文档中大部分词汇，我们日常基本都接触过，难度不会太大。

技术书籍的常用词汇量不大，有了一些基础后，你可以正式或非正式地参与翻译一些英语书籍或文档。从我的经验来看，翻译过一本书之后，你在日常阅读任何技术资料时基本都不需要查字典了。

看一些英语新闻或短语，比如 ChinaDaily。

第一，贴近日常生活，都是我们身边发生的事儿，不会很枯燥；

第二，可以进一步积累词汇量。在这个过程中，你肯定需要大量查字典打断阅读，让你感觉很痛苦。

但一般来说，一个单词最多查三次也就记住了，所以随着时间推移，你慢慢可以摆脱字典，词汇量也可以上一个台阶了。

技术方面阅读能力的培养，通常只需要三个月左右的时间，但生活方面资料的阅读可能需要一年甚至更长的时间。

• 听方面

读需要积累词汇量，听力的训练需要通过时间来磨耳朵。每个人都可以选择适合自己的材料来磨耳朵，比如我是通过看美剧来训练听力的。

我就以看美剧为例，说说练听力的几个关键点。

量变到质变的过程，需要 1000 小时的量。如果一部美剧是 100 小时，那么看前 9 部的时候可能都很痛苦，直到某一天你突然觉得一下子都可以听懂了。

需要确保看美剧时没有中文字幕，否则很难忍住不看，看了字幕就无法起到训练听力的效果。

在美剧的选择上，可以先选择对话比较少，也可以选择自己感兴趣的题材，这样不容易放弃。如果第一次听下来，听懂率低于 30%，连理解剧情都困难，那么可以先带着中文字幕看一遍，然后再脱离字幕看。

看美剧不在乎看的多少，而是要找适合的素材反复训练。有人说，反复看 100 遍同一个感兴趣的美剧，英语的听说能力可以接近母语是英语的人的水平。

如果看美剧不适合你的话，你可以选择其他方式。

总而言之，选择自己喜欢的材料和内容，从简单开始，不断听。如果你有一定词汇量的话，查字典其实不是必须的，很多时候不借助字典，同一个单词出现 10 遍后我们也就知道它的意思了。

一定要记住，在积累 1000 小时之前，别轻易放弃。

• 写方面

如果有外企经历，那么平时写英语邮件和文档基本就可以让你的工作英语过关；如果没有外企经历也没关系，你可以尝试通过下面的方式锻炼写作：

每天写英语日记。日记是自己看的，没人会嘲笑你，可以从简单的开始。

在保持写作的同时，需要确保自己能有持续的一定量的阅读。因为，写作要实现从正确到准确到优雅，离不开阅读的积累。

写程序的时候使用英语注释，或者尝试写英语博客，总之利用好一切写的机会，来提升自己的英语表达。

再和你分享一个小技巧。当你要通过查词典知道中文的英语翻译时，尽量不要直接用找到的英文单词，最好先在英语例句中确认这个翻译的准确性再使用，以免闹笑话。

• 说方面

训练说英语的机会是最少的，毕竟身边说英语的人少，很难自己主动练习。

这里我和你分享两个方法吧。

第一是，买外教的 1-1 对话课程来训练。这些课程一般按小时计费，由母语是英语的人在线和你聊一些话题，帮助你训练对话能力。

买不买课程不重要，只要能有母语是英语的人来帮你提升就可以。同时，大量的听力训练也可以帮助你提升说的能力，很多英语短句经过反复强化会成为脱口而出的下意识反应。所以，你会发现在听力达到质变的时候，说的能力也会上一个台阶。

第二，大胆说，不要担心有语法错误、单词发音问题、表达不流畅问题而被嘲笑。其实，你可以反过来想想，老外说中文时出现这些问题，你会嘲笑他吗。

这里有一个技巧是，尽量选用简单的表达和词汇去说，先尝试把内容说出来，甚至是只说几个关键字，而不是憋着在脑子里尝试整理一个完整的句子。灵活运用有限的单词，尽可能地流畅、准确表达，才是聪明的做法。

• 总结

最后我想说，如果你感觉学得很累、进步很慢，也不要放弃，坚持下来就会越来越好。
学习一定是一个日积月累、量变到质变的过程，希望我分享的学习方法能对你有启发。不过，每个人的情况都不同，一定要找到适合自己的学习方式，才更容易坚持下去。

持续学习很重要，不一定要短时间突击学习，而最好是慢慢学、持续积累，积累越多学习就会越轻松。

如果学习遇到瓶颈感觉怎么都学不会，也不要沮丧，这其实还是因为积累不够。

你一定也有过这样的经验：一本去年觉得很难啃的书，到今年再看会觉得恰到好处，明年就会觉得比较简单，就是这个道理。

团队成长

在团队方面，如何建设一个步伐一致、目标一致、有血有肉的团队，不同团队的规模要求的也是不一样的；这不但涉及到领头羊的建设能力，也涉及到组员自我奉献，怎么提高自己团队的荣誉感；

我亲身经历过不同团队建设、也带过团队，比如成为团队的一员，DayDayUp的员工就会多方面体会自己TL为什么会下达这样的要求或指令，为什么主管会向TL下达这样的要求，自己有没有办法比他做的更好，我要怎么做怎么锻炼对我以后的职业生涯更好发展；

也就是每个人不可能一出来就是TL或管理层，都会一段过渡期间；在身为成员大多数是少说多做，这里的做不单单是说做任务一样去做，而是要带责任感去做，更多的是换位思考，甚至是在有些时候要颠覆性的思考；

后面经历过管理团队这些事情，简单总结下为几个点：一是团队建设，这包括组建团队，建设团队文化，给定团队目标，监督团队目标实现；

可能有些小团队如小组没有权利去招人，但是后面这些是有这些共性的；建设团队文化这个是优先级不高，最终执行的督促的是小TL；

团队建设

这里不讲团队文化建设，团队文化在不同规模的共性是不一样的，先放到后面总结；

从组建团队、设定团队目标、协助团队实现目标到团队目标实现，我先简单总结下：

• 第一选人，组建团队第一必须要选人，选人是真的非常懂脑子的问题，连各界的伟人也碰到这样的难题。但看透本质，其实也没有那么复杂，如果让我只选一个条件，我会选择“相互欣赏”。展开来说就是先要对脾气，TA 站在你面前的时候，你想和 TA 交往。另外你认为 TA 身上有很多值得学习的地方，当然更重要的是你认为 TA 一定能够帮助团队解决一些关键难题，把事情交给 TA 你是放心的。如果非要上升到方法论的层次，选对人，基本就解决了团队管理中的 80% 的问题，其他的部分就相对简单了。我是将其总结为：对公司忠诚，敢做事儿，能成事儿。
• 第二是给团队设定高远的目标，我坚信一句话，那就是“取乎其上，得乎其中，取乎其中，得乎其下，取乎其下，无所得也”。这是啥意思呢？高三班主任让我们选高校目标，至今一直能记起“想去读清华北大的，那么中国排名前十的大学能进；想读排名前十的大学，那么就能进一流院校；想进一流院校那么只能进二流院校…”，为什么会和这个有相似的意思呢？因为完成这个目标的过程，会挖掘各种潜力去完成自己设定的目标，但现实往往残酷的，所以我虽然选了排名前十的高校，我却只能进一流院校；而且之所以有目标，就是为了激发人的想象力和斗志，如果目标很一般，即使完成了，也没什么意思，对不对？
• 第三是给高远的目标设定实现路径，这一条可以防止把目标定得太虚无缥缈，最后真变成梦幻泡影。如果想尽各种办法，也推演不出来目标的实现路径，那说明目标确实不合理，我们就要往回倒一倒，调一调。
• 第四就是督促实现路径上各项事务的实现，这个就没有上面所说的那么宏观和充满想象力，到这儿就开始考验一个团队负责人的微观综合管理能力。各种的催促，各种的会议，各种的激励，基本都是在这个阶段产生的。为什么很多团队负责人的脾气都不好，也都是被这里面各种各样的细节折磨所导致的。

简单总结来说就是：
第一，先把 80% 的精力放在团队选人上；
第二，给团队设定高远的目标；
第三，和团队一起设定实现目标的路径；
最后，督促路径的实现，形成闭环。

团队文化建设

可能大家会问我，为什么需要这些，上面的这些不是可以吗？其实不是的，历史往往表明，人是非常复杂的，如果上纲上条能达成你期望团队的样子，我认为这极难的，一个团队工作的时候经常不说话不沟通，那么离解散团队就不远了；团队文化的建设，让大家工作起来有血有肉，让大家一起认可团队，更甚者对自己团队有一股荣誉；

当然这些建设是为了团队更持久更高效的完成目标；

在团队文化建设，不同团队规模也是不一样，不同层级的团队文化建设的目标也是不一样；

如小组新人入职，分配导师、入职当天一起像平时吃午饭，好点的小组会有一个季度有几次的组内聚餐；

如果是几十人的团队，季度的聚餐，周末组织个活动；

公司层次的话，内推有奖励、年度旅游、体检、生日会、周年庆…

当然有人会吐槽，啥啥形象工程，但涉及到自己，我个人保证，自己的心决定有所波动；

我接触的团队，或者我管理的团队，大抵是程序员同界人；难道这是业内共性吗？

其实拴住一个团队下组员的心，其实建设大家都需要的精神需求，如中高级程序员需要提升技术能力，高级的想完成各种设计；

团队内的一些对外活动可设置几名生活委员，也可以轮流担当，当然是非必须的；

这些其实可以做成一个分享文化，分享不单单是某某技术原理的分享，也可以是某某框架、组建的中高级规范避坑使用，更可以分享自己怎么带团队；

管理一个不同业务小组集合成的团队，这分享需求比较实在，更好的培养好一个团队之间的不同业务线的沟通协调；

分享的作用有好多，如在个人方面能促进成长，团队之间成员多了一次相互惺惺相惜的机会，成员之间有共性的沟通交流相互，有一起头脑风暴聚在一起分享后的讨论；

面对分享，我们必须抛弃个人单身作战式的分享，为什么？一年下来就那么几个人分享，其他的要么说没时间、要么不会时间管理…

当然这些是现实存在的，如果要打破这种僵局，那么必须是业务小组为单位式，有分享指标或甚者主管可以考虑把团队内分享作为团队贡献的kpi指标；

在团队里，不同层次的员工，面对分享的需求也是不一样的：

• 对TL级别的话，可能存在如何更好地使自己业务小组完成业务目标，如何使得产品迭代越来越好，组员更容易管理；
• 对组员来说的话，技术分享最喜欢的，架构设计也是最想听的；

如果要想建设一个良性循环的分享文化，必须边实践边反思改进分享的制度流程：

• 首先确定团队周边的分享点，再根据这些点细化成不同分享主题，某某技术入门使用、某某技术原理实现、某某技术规范使用等等，可以说不同点分成的主题越发的深入；
• 接下来按季度进行各个业务小组分享的排期，不可确定具体分享主题，由业务组TL确定分享点，对参与分享的业务组可适量给予资源奖励如KPI的团队奉献等；
• 把握各个分享排期，每次分享后通知下个分享业务组，该业务组需要发出具体分享安排，不可推三到四，如排期在某星期内都没进行正常的分享，视为弃权(有适量的惩罚)，那么这次分享取消，轮到下个业务小组，该业务小组可提前、可按排期执行；
• 团队内一个月最多分享两次，且一周内不能出现两次团队内的分享；
• 业务派出的分享代表如必须可先组内先分享，避免团队内分享期间节奏不好；
• 每次分享要有提问时间，分享人必须合格回答提问人的问题，回答当前主题的提问合格率需要大于1/3；
• 每个季度归档TOP N的分享及整理；

注：这里没包括业务小组内的分享

谢谢大家看完本文，可以一起私下沟通交流做朋友：1406721322@qq.com

本文章来源于：https://github.com/Zeb-D/my-review ，请star 强力支持，你的支持，就是我的动力。