今天跟大家分享一下怎么样构建一个学习型的团队。
首先对于计算机行业而言，不明而喻，我们要接受的东西真的太多了。我们接触的信息和变化也太多了。如果只是因循守旧，排斥新东西，那么我们被时代淘汰只是个时间问题。
想当年我大三的时候认识了一个做VB的自有职业的朋友，那是VB开发语言还是很火爆的，我们在喝啤酒的时候，他就跟我说，小蒋，好好学，学好了VB一样，你以后就可以吃香的喝辣的。
时过境迁，我想15年后的今天，应该几乎没有招聘VB的岗位了，别说吃香喝辣，连吃口饭都是问题。
与此同时，在互联网公司里面丰富经验也基本上也往往是低价值的。因为很多时候经验是被旧的产品模式，旧的业务以及旧的技术所积累和沉淀的。但当产品业务和技术发生了天差地别的时候，我们积累那些经验可能完全是无法复用的。
相当年用HTML+CSS的网页制作经验，相信到现在也就是古董了。
比如还有在当前AI时代，原来的产品经验和技术经验可能都是被迭代替换掉的。在AI时代，我们可能就需要用全新的工作方式来面对新的挑战，可能所有产品和技术范式都会被重塑。
聊到这里，大家应该明白，身处计算机行业，构建一个学习型团队对于互联网公司的团队管理来说至关重要。
一方面只有整个团队的知识是迭代是进步的，就能够迎接更好的创新和业务机会。另外一方面，构建学习型团队对每个同学的成长来说也是至关重要的，持续学习的团队可以让每个同学都有接触新技术的机会，可以除了业务之外，能够一个更好学习机会、交流机会，能够迭代和刷新自己的认知和对于技术的了解。
我在面试的时候，不管是校招同学还是社招同学，最后一个问题总会再咨询一个，你平常是怎么样学习新技术的？
从我的经验上面来看，但凡各方面都比较好的同学，往往会对新技术也是非常感兴趣的。反之，如果对学习新技术不感兴趣的同学往往对某一些比较新的技术点的时候，可能同学答的不是很好，或者深度完全不够。这里面体现的就是对于一个技术的兴趣和追求。
那怎么样构建一个学习型团队呢？我认为会有以下几点。
首先，Leader是构建一个学习型团队的核心和灵魂。如果一名Leader没有把重点放在构建学习型的团队上面，团队的同学是没有这个主观能动性的。毕竟在互联网公司最多的事情就是来支持业务上线，也就是我们常见的写代码。就如在早期的时候，基本上在996或者007的这种模式里面，根本没有时间让同学们自己来学习技术，唯有的一点时间就拿来写代码了。
加班到晚上9点，10点再回家，已经疲惫的不可能再拿几本书再去学习新的知识点。相比加过班的同学都深知这一点。
另外对于很多刚刚毕业的同学来说，可能在学习方面很快就会迷失方向。在一个人的思维里面很容易进入一个信息茧房，比如说我学JAVA的，那么我只用JAVA来支持我的业务，在超出我业务范围内的知识我都没有机会去获取，也想不到去获取。或者我们做后端的同学往往没有机会，没有时间去涉及或者了解前端或者客户端相关的知识。同理，做数据的同学往往没有机会去看看后端的架构设计是怎么搞的。而涉略跨方向跨语言甚至跨学科的知识，才能让一位技术同学成长得更快。
我有个前同事兼校友，钉钉总监，微软Azure Identity首席总监，前Office 365首席工程师虞雷就告诉我，程序员最好每半年就学习一门新的技术语言，对自己的编程范式会有质的提高。
反之，时间投入无休止的迭代，会使得我们的技术视野和深度都变得越来越窄。
所以一名Leader要构建一个学习型的团队，就要打造出这种学习成长型的文化，要给团队营造出一个工程师文化的氛围，Leader是团队文化的核心灵魂。李云龙是其打造的“独立团嗷嗷叫的狼性文化”的核心灵魂。
首先，是技术分享。
比如我在团队就定一个规则，两周强制做一次技术分享，做分享的时间纳入到自己的日常工作量上来。与一般的长分享不同，我要求这个技术分享是采用短分享的方式，主要是以某一个同学来起一个自己感兴趣技术主题，收集关键的资料作为主讲人，其他的同学做讨论，然后每两周更换一名同学作为主讲人。
这样既避免了让某一个同学来主导这件事情，花费过多的精力，又能够让其他同学有一个深度参与感。
我之前见过原来的团队组织这种技术分享，一个同学可能要花上一周，两周甚至是一个月的时间来准备PPT，同时在讲解的时候也会挖的特别的深，把很多不常用的长尾的概念也都分析一番，其他同学都不大可能提出具体的问题。这种分享就沦为了一种形式主义。
所以我要求同学们选的主题不要那种特别偏门的，而要求是那种比较新的，比较热门的，比较有实际应用场景的技术主题。
比如我们近期就分享讨论了三个主题，第一个主题是关于Docker的分享，因为我们系统用的就是Docker技术，所以我们在分享这个概念的时候，每个同学都有参与感，在分享期间也频繁提问，也能够加深我们日程发布用到的Docker技术的理解。另外一个技术分享就是AI图生图的技术。这个需求背景是基于我们一个工作台的应用图标变化项目。我们利用AI图生图的方式来对原有的图标做样式和颜色上的重新升级。我们从这个技术里面学习到了很多关于图片处理的一些技术，比如Midjourny。我们还分享了一个关于地球点和点距离和排序的方式，因为我们刚刚做了一个产品功能上线，这个产品就是基于地理位置的一个话题功能，包含“附近”和“同城”，我们设计了一套算法来实现获取当前用户附近的动态内容。
我们这些分享的技术话题都特别的有趣，同时跟我们的工作也息息相关相关，同时也是一个技术前沿性热点内容。
和我之前参与过的技术分享相比非常的枯燥，而我们的短技术分享，每个同学讨论，提问，答疑都非常的热烈。
而这一切就有赖于Leader要构建一个良好的学习型环境，要把技术分享工程师文化写入到我们的团队KPI里面去。
其次，是技术方案Review。
一名技术同学的成长考核，「写一个很好的技术方案」，就是最好的一个标准。技术方案不仅仅是一名程序员解决问题编码能力的体现，更是一名程序员思维方式的体现，也是程序员“技术全局观”的一个投影。
计算机大牛左耳朵耗子就说过，一名程序员80%的精力应该放在写技术方案上，20%才是动手写代码。所以在这里面我们可以看到写好一个技术方案的重要性。到了高手阶段，往往只要你想的清楚，你就能够写的清楚。而想不清楚，也不可能写得出来。因此计算机高手程序员一定不是像黑客那样，坐在屏幕前一通乱敲，反而大部分时间是类似“发呆”一样的组织自己方案。一旦方案清晰了，直接“下笔如有神”。
高手不会像一名初级程序员一样，不管碰到什么问题，上手写代码，然后写着写着发现漏洞百出又重推倒重来。这个就等于一名高手一样，高手过招，是很少直接出剑的，也很少一见面就喊打喊杀，而是面对对手，先做充分缜密的计划、摸索、试探，80%时间在做竞对调研，但是一旦明白了对手底细，就会快速出招，一出就必须要见血，这是同样的概念。
所以我要求团队开发同学在碰到超过三个人日的业务需求上就要准备一份技术方案，技术方案不求宏篇巨论，但求精简清晰。
准备这个技术方案也是同学在构建一个思维的过程，怎么样立体的解决需求。这里面不仅要思考当前的问题，还要思考投入产出比，还要思考核心的解决的架构是什么，里面关键的难点是什么，以及能力复用性。比如用到了什么样的一个技术方案选型，比如在稳定性上面有什么考量，在降级上有怎么考量，能否给其他业务复用，能否具备扩展性。
同时在组织这个技术方案Review的时候，我一般希望尽量所有同学都能够参与，第一个是能够让其他同学可以了解这个技术方案，第二个是给这个技术方案一些自己的思考和建议。这个过程一方面是演讲者自己能够清晰的表达出自己的方案和思考过程，另外一方面也是能够让其他同学来学习这种设计思路或者提出批评建议。
当然这里面还有一个核心的关注点，就是从Leader的角度来关注整个方案的架构是不是合理的，是不是可复用的。会不会踩到一些大坑，会不会使得整个业务出现一个系统性的问题。
所以通过技术Review这样的方式能够锻炼所有团队同学对于系统方案文档产出的一个能力，文档表述的能力以及对于其他同学技术方案的一个理解能力。
最后，是代码review。
归根结底工程师的产出就是代码。虽然我们更看重一名工程师在方案上面的架构设计能力，但最终落到实处的还是代码的能力。因此通过代码Review的方式来学习和提升自己的技能是最具象的。
这也是为什么我在面试P5层级，P6层级和P7同级的同学一定要有代码笔试。一名工程师的动手能力强不强，通过代码笔试完全就能够检测出来。我想这个可能就是诸如谷歌，微软这样的大公司对所有技术职位都要求做算法笔试的一个原因。而且据我所知，像字节跳动这样的公司针对所有层级的程序员都要求写算法代码，这一点我还是非常认同的。
对于代码Review一般采用高层级对低层级进行Review，或者同层级的相互Review。一般来说流程就是在写完程序之后，自测通过了就会把这个代码提交给相关的同学来进行代码Review，然后反复更改确认最后提交发布。
更高阶的工程师一般会从几个角度来看看代码的质量。
比如会关注代码基础规范，代码是不是可复用，之前有没有人写过这段代码，还会关注代码是否优雅，是否有合理的抽象，还会关注代码是否具备了开关和降级能力。对于一些核心主流程的代码还会确认是不是会影响线上稳定的流程。
代码Review对于所有工程师来说来说是一次检查，特别是高阶工程师往往在写代码上面经验非常丰富，通过代码review就能够把自己的经验传达给低阶的开发工程师。对于高级工程师来说，一方面可以学习到其他工程师是怎么样写代码的，另外一方面也能够通过代码Review的方式管把控个系统的稳定性。
作为一个技术团队，从技术分享里面去深挖技术，去讨论技术和学习写代码是最为重要的一个手段。
与此同时，我也特别积极的鼓励同学们参与整个公司的技术分享，积极参与公司举办的各种活动，比如近期的AI大赛。除此之外，我有鼓励团队们在解决日常问题的时候要充分的讨论和相互沟通，比如我们经常就针对于线上发生了抖动、超时的一些根本问题进行深入的分析和探讨。我们团队就有很多同学深入挖掘了诸如大对象导致的FullGC的问题。
我相信只要一个Leader是学习型成长型的Leader，那么整个团队就会是学习型，成长型的团队。
终身学习，我觉得是每一位优秀工程师追求的素养。