以下是今天的分享大纲：
1、团队人员建设
2、技术氛围建设
3、团队微管理
4、二线城市工作体会
考虑到整体时间的有限，我主要从每个部分的几个关键点来进行讨论，更细化及其更多总结性的，也会以文章的形式整理发布。大家有相关问题，一会也可以进行一些沟通，互相学习~
一、团队人员组建
团队建设很核心的关键点是人员组建，尤其是对快速发展阶段的团队和新成立的团队。一线城市拥有更多的人才资源，今天重点来一起探讨下在二线城市组建技术性团队的一些事情。
团队人员组建主体是确认要什么样的人选，然后怎么去找到这些人选，并最后形成一个比较合理的梯队结构。
1、人才标准方面，我们认为的优先级是：软性技能> 技术能力和学习能力> 领域专项技能> 学历
对于排在第一的软性技能，我们会先重点的去评估，包括自驱力和责任心、是否乐于解决问题而不是逃避、是否契合团队的文化、是否具有一定的适应能力（能根据不同发展阶段和业务场景考虑，而不是一味的照搬原有经验），也包括沟通能力等的。当然不是说任何一个人这里的每项都要很好，所以也是综合评估，底线是品格方面。
我们认为一个相对靠谱的人选，至少要在软性技能、技术能力和学习能力方面都有一定的亮点，如果被验证过在某些方面有过亮点，那么在越来越多的方面出现亮点的概率也是越大。
对于大多数的工程性项目，领域专项技能更多是表明在这个领域里切入成本更低、踩坑概率更低，但是技术能力和学习能力强的同学，在一定的时间内也是可以做到，甚至中长期可能做得更好。按照google的文化来衡量，他们认为“好的人才就是能否把一个以前从来没有接触过、或是完全不会的东西，在很短的时间内学会，并且做得很好，这是一个很重要的因素。和学习能力相比，个人经验就显得并没有那么重要”。当然最理想的情况是前三者都好了：）
2、确认了标准之后，怎么找到合适的人选
主要有潜在的三方面的人才：
1）本地技术人才
需要先分析本地人才的组成及其优势，比如多数二线城市传统软件开发的人员比互联网类的多，传统软件开发人员转向互联网领域也是个风口，借助这个风口是有一些空间，可能可以找到一些软性技能、技术能力和学习能力方面还不错的人选。
二线城市的公司相比一线城市会更少，尤其是同类型的公司就更少，在这种情况下，一般都会逐步形成一个个小圈子，这几个公司互相比较熟悉，甚至有比较紧密的关系。在这种情况下，简单粗暴的去挖人明显不是合适的方式，更合理的方式还是努力提高自己的团队，有更多空间和提供更多帮助让靠谱的技术人来更好发挥价值，对外提供有这样的机会，选择权还是在于大家，每个人也都会有自己的标准来衡量，中长期可能会有一些收获，不能求快及其没有原则性的。
同时内部的推荐也是很好的方式，如果环境不错，身边的朋友要做选择，自然也会有所考虑。
2）外地技术人才
北上广深等一线城市，拥有很好的人才资源，尤其在互联网领域，北京具有更大的优势。如何争取这些人才资源，也是一些二线城市的TOP互联网公司一直在紧盯和努力着的。
在发展的第一阶段，能吸引到的最多可能是本地籍贯的人才。有不少在一线城市努力拼搏的人，由于家庭等的因素有在动摇是否回来，但是一直找不到合适的机会。对于多数技术性同学，担心较多的还是能否在技术上继续保持发展并发挥自身的价值。现在一些二线城市也逐步有一些有一定量级的互联网公司，对于公司层面可以尽可能提供双赢的条件，提供更好的发展的路径（无论是技术上纵向还是横向的发展，或者更全方位的发展），及其生活上的保障。双赢的条件对于有部分这样想法的同学会有一定的吸引力，美图通过这样的方式第一阶段也是吸引了一些本地同学回来。
随着北方雾霾等的原因、包括为了下一代的考虑，及其生活成本等各方面的因素考虑，也逐步有一些同学考虑回去二线城市。相比于回到籍贯所在地的方式，大多数人所在地都没有合适的公司，所以一些有这样条件的二线城市也在这些人的考虑范围之内。借此作为管理者也要站在对方的角度想清楚，提供一些确实能满足他们诉求的方案，最终实现双赢会是最长久合理的方式。
同时如果有条件的公司，比如北上广也有研发中心或者分支机构，也可以让部分同学可选择性的在原本工作所在地城市挂职，先来二线城市工作半年或一年。因为有些人想尝试但是担心成本过高，比如社保中断后续没法回头等，所以有条件的话站在对方角度多去思考，也可能能找到一些合适的人才。
美图的架构平台团队作为有一定技术性要求的团队，社招的同学有50%左右的也是从北京回来，这也很有利于前期的一些工作开展。
3）优秀毕业生
从人才的质量来看，在二线城市招聘的实习生的整体质量往往比校招更高一些，但是流失率也可能会比校招更高。所以对于人才有较大渴求，实习生加上校招也是不错的方式，但是怎么让优秀的实习生和校招生能更好的发挥自身价值也是很重要的考虑点。
二、技术氛围建设和人员培养
团队建设另外一个核心要点是怎么一起营造一个更好的技术氛围，及其关注大家的成长。今天重点说下美图在技术氛围建设方面做的一些尝试，及其一些效果。
这方面涉及较多的点，这里重点说下关于技术交流活动的一些想法，主要是实际做过的一些尝试。从当前现有的分享来看，按照参与者群体由少到多是：
1、小组周期性讨论
参与者为某个项目小组成员，可以针对方案设计、问题分析、code review、项目计划等针对性的讨论。是效率最高目标性最强的，也是见效比较好的方式，现在一直很鼓励这样的讨论。每周1-2次比较适合。
讨论和交流比较担心可持续性，这方面也是可持续性最好的，因为足够的轻量和敏捷。
2、部门每周技术交流：
参与者为某个大方向的技术团队，从过去的1年多以来，我们做了三种的尝试，基本上保证了每周持续的在进行。
第一种是部分有经验的同学主动来贡献议题，偏向于实践性的分享和讨论，涉及到现有项目及其原先所熟悉的项目相关的。听众主要受益点是了解到各种最佳实践，这个时期也有部分从传统行业转互联网方面的，所以也侧重分享了较多互联网系统最佳实践方面的。但是这种方式也会面临一个问题，就是容易就是固定的几位讲师，可持续性会面临一些问题。
第二种是团队每个人轮流准备一个议题。在前期多数人会分享他所擅长或做过的领域知识，由于每个人的背景和关注点不一样，所以整体上知识体系偏宽泛一些，听众更多也是广度上了解更多知识。由于是全员性的分享，质量上的保证一般也会相对低一些，但是这样也有好处是锻炼了一些同学的演讲能力，有些同学甚至在之前都没有机会来这样做分享。在后期，有些同学也会分享当前所负责项目的设计和方案，这种也加深了互相之间的交流，大家也了解到团队内各种系统的设计和实现。
第三种是讨论大家都应该关注及其鼓励大家提出一些建议一起来完善的流程、方案等，比如故障的总结、研发流程改善、工具建设等方面。形式上主要是会有先行者先做一些尝试，然后来进行讨论总结，最终确定具体的方案然后更大范围推进落地。
当然现在以上的三种方式也都有在推进，每种方式都有各自的优缺点，所以也是根据目标诉求及其不同阶段来做调整。这方面最近也在进一步的思考，也欢迎大家多多交流讨论。
3、后端技术交流
参与者是整个后端的技术团队，由于涉及到数据团队、运维团队、业务团队、基础研发团队等各种同学，大家口味也不尽相同，所以比较适合的方式是选择制，根据自己的时间安排和兴趣来选择。
分享的内容上尝试过两种方式：
第一种是对于新来的有经验的同学，尤其是有领域性经验的，给大家扩展视野。同时也会针对内部在用的一些基础组件做原理性的剖析和最佳的应用实践方式分享讨论。整体上期望有质量的保证，考虑到可持续性，后来也组织了技术体系性议题。针对后端方面，有系统设计类、基础技术类等，有经验的同学认领相关的议题并提前准备。系统设计类主要是内部的核心业务系统或者基础系统的设计和实现相关，基础技术类包括高可用缓存设计、Redis原理与实践、Nginx原理和实践、消息队列服务等方面。包括后面在大力推进golang语言，也加入了语言系列的议题。
除此之外，部分同学也会去参加国内的一些技术性大会，比如QCon、ArchSummit等，也会把其中的一些不错议题，结合现有的业务，在这里跟大家一起分享。
总体来说，这样的方式比较重，由于听众较多，对于质量也会有一些要求，最担心的可持续性方面。而且要特别注意的是，要定时review，避免沦为形式，如果存在的话哪怕先暂停调整也尽量不要硬着持续，因为这种其实也是挺耗费大家的时间，同时也要避免存在有人情绑架的问题。
4、公司分享活动
公司有专门的培训中心，每两周也会有分享活动。会邀请公司的核心骨干及其外部的大咖，内容也不限于技术方面。从技术层面来看，更主要是了解公司现有技术的发展，及其了解业内的发展趋势，尤其是一些新兴的领域。
5、美图互联网技术沙龙
为了提高厦门地区的技术交流氛围及其加深互相的了解和沟通，美图也组织了美图互联网技术沙龙，主要面向公司外的群体。首期在今年年初在厦门举办，规划每个季度一次，正在做第二期的筹备。对于议题的设置，每期有固定的议题，并会有2-3
