当前位置: 首页 >> 汽车
全球简讯:研发团队技术氛围建设
来源:程序员客栈     时间:2023-02-03 23:43:10

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

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


(相关资料图)

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

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

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

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

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

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

见:团队技术理念

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

以身作则:leader自己必须带头,多关注技术细节,对技术有品位,有要求;

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

落地机制:建立制定一套可执行、可落地机制,严格遵守、监督执行,在合适的节点进行监督;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

目的有二:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

上一篇:

下一篇: