研发团队技术氛围建设

​

很多研发同学希望自己团队有很强的技术氛围，这点我个人是比较认可的。

因为大家现阶段都是技术人，技术是我们吃饭的手艺，搞好技术，塑造技术氛围，对研发团队还是非常重要的。

技术氛围好的团队，普遍可以发挥出更强的战斗力和生产力，能够对业务和组织做出更大的贡献。

如果研发团队过于偏重对业务方面的关注，而忽略了对技术方面的要求，就有可能造成工程师们缺乏自身对技术的追求，每天将精力放在堆砌不够优雅的业务代码上，自身技术得不到成长，系统也不能很好的服务业务。

长此以往，这样的技术团队，战斗力和凝聚力会每况愈下，研发同学难以得到成就感和满足感，也难以对业务形成很好的支持。

通过技术氛围打造，提升团队技术氛围，可以让团队中越来越多的人愿意学习、钻研、交流、分享技术，形成一个良性循环。

我们常说，技术服务于业务，技术如果想要和业务很好的结合，技术自身就需要创新，技术就需要帮助业务做创新。

但切忌矫枉过正，不要走到技术自嗨。

见：团队技术理念

打造技术氛围，首先需要leader遵循3点原则：

1. 以身作则：leader自己必须带头，多关注技术细节，对技术有品位，有要求；

2. 文化导向：必须引导团队成员更多的关注技术，提升技术要求，有技术追求，对做得好的同学给予奖励；

3. 落地机制：建立制定一套可执行、可落地机制，严格遵守、监督执行，在合适的节点进行监督；

一些常见的监督节点如下。

首先是技术方案阶段，书写技术方案是工程师日常工作中做的最多的事情了，技术方案的质量关乎到最终技术的落地效果，一定要重视，对技术方案的质量提高要求。

从常识上看，技术方案写到100分，而落地往往会打折扣，如果执行不力会大打折扣，所以尽量提高技术方案的质量，保证执行者对于方案有深刻的共识理解。

好的技术方案不应该仅满足于完成日常开发需求，更应该是可以引发思考的。对于需求或业务本质有好的表现，对现状及未来扩展有很好的预判，通过架构上的扩展留白，实现对未来需求的迭代和扩展保有余地。

好的技术方案，内容中应该评估出架构中的那些关键的技术点或者技术环节，比如是读写流量高的模块，还是效率卡点模块，或者稳定性风险较大的模块，或者容易误操作的模块。有了这种识别能力，你才能在方案落地中，对这些部分进行加强和做好兜底设计。

为了提高方案编写质量，可以制定技术方案模版wiki，所有技术方案以此为框架编写，将关键信息展示出来，当然抄好模板只是60分，想要做到100分，需要case by case的体现出相关技术的关键设计。

有了方案模板，leader必须审核，给与确认，所有干系同学必须参与评审，参与提出问题，评估问题，对方案全貌和细节做到心中有数，讨论和交流要充分。

技术双周会做通晒、抽查，那些做到好的方案要表扬、推广，不合格的要提要求、促改进。

每个季度进行一定的评优激励，给与物质奖励。

对于团队内公用或共性的部分，通过推广规范或者编写技术组件方式实现固化。比如制定设计和编码标准的统一规范，这为日后的底层技术能力平迁提供非常重要的基础，比如日志打印标准，关键通信协议字段透传定义，中间件交互组件等。

这些规范与组件能让团队技术标准得到统一，也可以促进大家有更好的编码习惯。如果规范或组件需要迭代，需要经过组委会的评估，批准后，才可以将改造内容merge到主干。

为了提升编码质量落地效果，可以将这些要求以okr的方式写在自己的规划里面，牵引大家思考和遵守。

在cr或评审时，遵守相关要求，做严格检查。复杂模块设计及改造，要多人交叉cr。

代码提交人要有开放心态，能够接受不一样的意见，听得进去意见，充分讨论，成年人，不要意气用事，目的是做的更好。

团队要提倡工具文化，工具是流程、规范、标准的固化，既可以提高效率，又可以塑造习惯，所以要做好工具很重要。

日常的提效工具、检查工具、辅助工具都可以，鼓励大家做分享、做共建。

好的工具要做定时分享，提升个人和团队影响力，也可以让更多人了解工具，使用工具。

对于工具贡献者，做季度评优，给与一定的物质奖励。

业务是发展的，每个阶段业务的发展、目标和挑战都不一样，所以系统负责人需要阶段性的进行技术的规划。

对于不同规模系统和业务可以做季度、半年的技术规划。

leader做好阶段性的过程管理，比如周维度，月维度的跟踪，防止技术方案的跑偏或者不落地。

这个机制，有利于促进技术同学做技术思考，避免埋头陷入惯性的状态。

技术迭代、升级、规划，要和立项一样做整体评审，更大优先级别的项目，需要更大的老板参加（主要是要资源、做同步、拉共识）。

项目立项之后，做好落地阶段拆分，拆解成小需求，确定好工作优先级。

在承接业务需求之外，建立技术需求类别，每周、或每个月，跟踪各个系统业务业务需求及技术需求数量占比。

阶段性组织模块串讲，可以是模块维度，系统维度，业务维度等。

目的有二：

1. 一是考核owner对业务或模块的理解与认知程度，对负责业务和技术的思考；

2. 二是充分交流，让更多人对于系统有更好的了解，防止重复造轮子。

技术分享的关键原则在于质量，而不是数量。

良好的技术文化塑造是建立在有质量的分享和交流之上的，以前试过轮流分享，最后发现这种大锅饭似的组织方式，并不利于技术氛围的达成。

质量的评估方式，要求分享内容有一定的创新性，包括不限于技术组件或者技术思想，比如有一定的先进性的技术，对团队协作有帮助的协作方式等，关键在于要有营养。

之前很多人重复的分享线程池、数据库索引，往往没啥效果。如果分享如何做饭，这种就更应该慎重了。

为了不让分享议题和分享过程跑偏，需要制定一些原则，面向分享者和旁听者。

比如分享会阶段性看一些关键信息，比如选取素材的方向、技术内容的先进性、分享人的表达能力等。

旁听同学提的问题，也要框在一定范围内，比如是否对分享素材的质量有认可，对分享的内容有了解，对分享人的表达能力满意等。

通过将所有人框在一定范围内，就可以避免大家思维跑偏了，过于发散不会有好的效果，树立阶段性的聚焦目标，有助于刻意练习。

鼓励写小作文，统计大家每周、每个月、季度、年度写多少篇文章。写得多的，质量好的小作文作者要给予奖励。

可以通过留作业的方式，push大家做分享、做总结、做沉淀。也更利于成员养成知识沉淀到文字的好习惯。

其他的方式，包括更高阶的技术专利、开源等手段。

总之，每件事情要有目标、有标准、有执行、有落地、有奖励。

不断推进团队向着良性循环的角度发展。让所有研发同学爱上技术分享、爱上技术交流、爱上技术沉淀，最终形成好的团队技术氛围。