对研发团队里技术分享的一些思考

本文来自: https://www.iteye.com/blog/aoyouzi-2342659

分享目的

做任何事情,要明确目的,才能清晰、顺利实施。目的包括这件事能帮大家带来什么、能给公司带来什么、预期结果是什么、成长又是什么等等。我从公司、团队、个人三个维度,总结了以下五点目的。我会对每一个同事讲述这五点目的,确保大家目标一致:

  1. 学习新知识,完善自我体系
  2. 提升沟通能力、表达能力、自信
  3. 有效提升工程师在专业领域的经验
  4. 解决工程师最常见问题——技术瓶颈
  5. 项目技术推进,如框架、性能、工具等

需要让所有参与人明确分享目的,特别是新人,不要只关注自己付出的代价 , 以及计算别人分享对自己的好处, , 更要关注这样的小 平台,对每个同学软性能力的培养, 以及在这个过程中“教-学”互动带来的收益。当整体目的一致了,才能实施可持久的技术分享。

初期,技术分享并不一定带来显著效果提升,需要大家磨合,不停地完善分享内容。另外,要想实现上面的任何一点也是有挑战的,作为leader,需要思考如何将技术分享转换成目标实现,帮助每一个员工提升自我。

注意事项

很多公司技术分享都难以长期推进,甚至最终不了了之。我还看过其他人发的邮件,讨论如何强制让大家去做分享,等等。。

这里不禁要问,难道我们大家缺少分享精神么?我相信自私只能是少数人,更多的人还是乐于分享和帮助他人的,大家都不去分享,很可能是我们的技术分享平台本身存在问题。我做了有四年多的技术分享,这是我这些年总结的经验。

  1. 内容简单,会失去兴趣
  2. 责任平摊,会降低执行力
  3. 时间仓促,会导致质量不高
  4. 频率较低,会难以深入去实施
  5. 单纯开会,会阻碍实质性成长总结
  6. 选题随意,会达不到较高的成果产出

有效手段

1.队伍划分

在一个事件中,责任如果被群体平摊,最终会弱化责任甚至无责任意识。技术分享采用大家主动去分享的模式,大家心里会想“反正不是我一个人的事,不需要我去推进”,结果很尴尬,每周都不会有人愿意去分享。
可能出现的场景是,技术分享负责人去联系每一个同事:
“同事A,下周你有时间分享想么?”
“同事B,貌似你有两个月没分享了,下周给大家做个分享怎么样?”
“大家有谁想做分享么?可以邮件告诉我,我好给他安排下周的会议室。”
“下周没有人分享,我打算取消下周的分享。”

解决这个问题的办法是,进行队伍划分,把责任集中而非分散。举例,部门有12个同事,可以分成 三个小队A、B、C,每周由一个队伍进行技术分享,并按顺序轮流执行。现在每次技术分享的责任由12分之1变成了3分之1,和之前相比有了更清晰的轮流次 序,大家很难推卸,每个小队也变得更有责任。技术分享负责人基本上不需要再“求”每一个人去分享了!

将一个大团队拆分成几个小团队,责任精准定位到每个小团队,优于将责任集中在整个大团队,更优于将责任完全平摊给每个人。

总结,1/3 > 1 > 1/12

2.专题分享

闻道有先后,术业有专攻。想提升某个领域的技能,不是一天两天就能到达的,技术分享同样如此。

想要提升团队的数据库技能,不是做一两期技术 分享就能搞得定的。我们需要结合我们的工作情况、人员技能真实水平来定制具体计划。详细整理需要分享的数据库知识点、数据库涉及到的数学算法、高级技巧和 原理深入、应用及经验、分布式等,从多个维度规划技术分享,这样大家才能系统地、深入地学会数据库技能。

我的建议是每个季度或者每半年做一次规划,团队需要提升哪些方面,针对这些方面制作专题分享,专题分享需要有规划持续性地去做,并将做过的分享做文档化落地。当一个专题分享系列做完,我们也就积累了一整套完善的资料,并很自然的成为团队资料,供新同事学习和查阅。

我们做过的专题分享有:

  1. 前端专题分享
  2. 数据库专题分享
  3. 网络安全专题分享
  4. 服务器性能专题分享
  5. 框架专题分享等

除了专题分享,还要有其它方面的灵活自由分享。

专题分享和自由分享,各有各的优缺点。过多的专题分享,会乏味;而过多的灵活分享,会得不到成长。团队需要认清两种分享的价值,经常去平衡这两种分享的比重,这样才能让技术分享更加饱满,帮助大家拓宽视野。

专题分享可以强化团队的具体能力,也可以最大化发挥ppt本身的价值,成为技术文档。

3.晚上七点

目前我所在团队每周两次分享,一次是周四的白天上班时间,一次是周二的晚上七点钟。

对于互联网行业,公司层面主要提倡加班,员工层面提倡不加班。这里就不讨论加班与不加班的问题了,我只说两点:
公司希望大家在公司多花时间,多一些产品的产出。
员工希望做事高效且有价值,并有学习、成长时间。

我选择的技术分享时间,便考虑到了这两点。
如果技术分享都是白天工作时间,会让大家每周工作时间减少。
如果技术分享都是晚上休息时间,会让大家抵触去开分享会。

一次白天,一次晚上,很少抱怨,更多积极,引导学习,诱导加班,同事公司,皆大欢喜。

4.六十分钟
5.提前两周

第4点和第5点一起说,主要想表达的就是技术分享必须有内容、有含金量,才能对得起听众,听众的正向反馈也会促使技术分享更好的循环持续下去。

有些人习惯懒散,技术分享的准备会一直拖着,就算有人提醒和催促,也经常是在临近时间节点时候才想起来做。做的ppt,就算内容能讲一个小时,质量也会很差,讲的过程中磕磕绊绊。那么如何帮助大家避免这类问题?说白了就是怎么有效地督促、帮助大家及时去准备技术分享。

首 先明确要求大家提前两周开始准备技术分享,并在分享前一周,把技术分享大纲、或者ppt内容轮廓做完,并邮件发给所有人分享的内容目录。在这种强制要求 下,大家不得不提前一周将技术分享大部分工作做完,然后还能预留一周时间进行修改和完善。不论你懒不懒,分享邮件都要提前一周发,如果你不提前准备,你根 本没办法发邮件。

一旦技术分享邮件发了,内容也准备了一些了。自然惯性,分享者就会利用还有的一周时间去补充和完善,基本上不需要任何人提醒催促了,因为他已经通过邮件把自己放在了公众面前。对分享者而言,每一名群众都是他的监督者。

通过以上手段,能够降低大家技术分享的准备时间风险。

在法律中,合同是保障,时间是规约。对应到工作中,强有力的执行————依赖邮件和时间节点。

6.课前准备

上文提到了专题分享,分享的内容会深入且较难,而自由分享,由于涉猎面广,可能有些概念部分同事还很陌生。

这两种情况下,如果我们直接去听分享会,很有可能只听懂了20%。20%意味着,在一个小时的时间里,48分钟都是在消磨生命。怎么样更好地去听技术分享,连小孩子都知道————课前准备。

每 次我都会去仔细看分享者提前发出来的邮件,对于不会的内容、没听过的关键词,提前去上网查一些资料,带着自己的理解、问题去听,效果会非常非常好!听完分 享会,可以巩固现有的知识体系,正视之前过于浅显的理解,纠正细微的认知误区,解决困扰自己的问题,等等。只有自己准备了,才会有如此多的收获,想想何乐 而不为呢!

技术分享的获益人是分享者,也是听众者,而课前准备是听众者最大化收益的最直接手段。

7.惩罚措施

不过呢,“课前准备”这个想法总是好的,现实总是不满意的。我们强调了很多次课前准备,不过会去执行的人并不多。甚至可以说,有些同事对于听不懂、浪费时间,习以为常。怎么去帮助这些同事,带动他们的主动性和积极性,我给出一个建议。

有奖提问!对,有奖提问!比如某一期技术分享,内容很深,有挑战性。那么我可以告诉分享者,在ppt里面增加一些互动和提问,并告诉所有分享者,这次技术分享会有多个问答环节。答对的同事,有奖励措施。

实施过几次,效果还不错,很多同事会提前抽时间去看一看。

优秀的人知道该做什么,普通人却需要他人帮助。领导可以通过奖惩措施、目标价值等手段,帮助普通人和优秀的人保持行动一致。

补充完善

技术分享只是工作中的一个小事,但是做好却很难,需要大家不断去思考、完善。

抛开技术分享本身,只是去想如何做好技术分享这件事,我本人就得到了很多成长。想想挺有意思,任何事情,只要你花时间多琢磨,一旦琢磨透了,会得到超出这件事本身的成长。

在这里举一些我们技术分享中的故事,给大家作为参考。

帮助他人

如果每一次分享都能得到成长,也许大家会变得更主动。

我会在其他人做技术分享的时候记录笔记,记录大家做分享时候有哪些优点和缺点。在每个人技术分享结束后,会单独和这名同事沟通,从帮助他的角度出发,去表扬优点、指出缺点。

比如

A同事,分享mysql lib库封装,在分享时候说话夹杂着大量的“然后”、“还有”、“嗯”。我会指出他在演讲ppt时候,有太多这类词汇会,显得不专业。很多句子本身就很连 贯,比如ppt有一页内容很清晰地列出了五个点,那么我们不需要每说一点时在前面加个还有,显得多余。现在A同事分享,提升了很多,简洁、清晰。

B同事,在分享linux grep指令详细操作,这个分享需要登录一台服务器,并在服务器上面输入指令做展示。他在分享过程中,11处命令打错,7次输入命令发现不对又删除。这些我都详细的记录在了本子上面,会后和他说了问题,并给出了明确的建议,他在输入指令方面比别人弱,不够熟练,需要加强。

C同事,分享了一个内容丰富的ppt,当时的ppt内容配图很多、很炫。ppt特效也非常丰富,一会文字是横着飞入进来,一会又是图片360度旋转加载进来,一会又是出现一 组晃动的文字。整体感觉就是过于花哨,文字看着头晕。我把问题告诉他,并说好的ppt至少要保持统一。现在做的ppt,依旧很炫,同时底色、字体、动效也都统一,明显好了很多。

我希望让大家明白,技术分享这个平台,不仅仅是分享,也是对自己的锻炼。

拒绝简单

拒绝分享×××的安装、×××入门实战,这类分享没有价值。

分享可以由浅入深,可以分多期,但要保证全面和深入,让大家真正得到提升,也欢迎细分领域的超水平分享。

可以很自豪地讲,我们现在做的每一期技术分享,内容都很高,不论你是高手还是新手,总有收获。

截图是我们分享的https加密机制,各种数学公式的使用,欧拉函数、中国剩余定理,大开眼界。

想要分享牛逼的ppt,你就得努力成为一个牛逼的人。

结果导向

技术落地,结果产出很重要,让大家真实地感受到贡献和价值。
表扬与肯定大家所做出的贡献。

A同事花费了两周时间,做了一期完整的web xss安全专题分享,分享会上大家一起讨论问题、提供方案,最终定制全面的安全防护措施,并在第一时间用在了CC项目中。正巧,绿盟科技股份有限公司对 CC/CS进行专业安全扫描,CC未发现任何xss安全问题,CS发现3处xss高危漏洞。之后,我们也在CS项目中使用此解决方案。

通过这个事,我们肯定了A同事所做的贡献,A同事做的技术分享应用到了项目中,这是最好的证明技术分享的价值。

学会感恩

技术分享,是奉献也是成长,怀着感恩的心看待部门小伙伴。分享会上,我会给大家经常买好吃的、买饮料,这是一个不错的选择。

大家一边吃零食一边听分享,免费学知识、免费吃东西,试问,还有多少人会不愿意去参加分享会呢?

通过让技术分享的氛围更活跃,我还发现额外让团队获得了另外一个成就,整个团队的凝聚力也变得更强!真是得来全不费工夫!

我经常会给大家买85度C的奶茶,还有薯片、瓜子、水果等等,单是买85度C的饮料,就已经花费了好多钱。帮助大家,我乐此不疲。

学会感恩,对同事大方,站在帮助他人的高度看待事情,你才拥有真正的高度。

结束语

技术分享不是最终目的,最终要让大家热爱技术,工作中充满主动。

除了技术分享,我们也主动推进了团队技术博客平台搭建。总之,看到大家主动和成长,技术分享这个平台也就值了!

《对研发团队里技术分享的一些思考》有一个想法

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据