• 小公司的技术分享怎么搞


    我这个人对分享特别感兴趣,总是爱给人叨叨讲东西。我也一直认为对于每一个搞技术的同学 ,技术分享是应该始终伴随在工作中的,就像吃饭上厕所一样。然而最近我们团队的分享却各种难产,一种“没有分享,地球也照样转”的感觉,这不禁让我开始怀疑人生。
     
    遥想起刚来北京,看到帝都有这么好的分享氛围而激动万分,不辞辛劳不远万里去参加w3ctech组织的各种分享会,那份渴望至今还记忆犹新。第一次见到传说中的周爱民老师,近在咫尺却也不敢上前对话,只能投以深情的目光,那种感觉至今也还萦绕心间。
     
    多年来我从被分享和主动分享中获益良多。这里并不打算阐述分享的种种好处,我相信读者朋友是心知肚明的。例如老王自从爱上分享,变得能言善辩,多年的口吃都治好了。今天想要讲的是我们团队在组织分享中遇到的一些问题,以及我的一些思考。组织分享远不是想象中的那么简单,这中间会面临很多决策,思考的过程像是在做一道道选择题。(我们有20个前端,在创业公司中应该算很多的了)
     
    创业公司要不要搞技术分享
     
    首先,问题的根节点,创业公司要不要搞技术分享。
     
    如果答案是否,那本文就到此结束了...提出这个问题是因为我对此也有点犹豫。创业公司相对更忙一些,做项目是头等大事,能留给做技术分享的时间并不多。而且我们的前端分散在各项目组,时间步调不一致。每次分享都零零散散来不到十个人,这对分享者来说有点泼凉水,毕竟人家吭哧吭哧准备了几个晚上的内容。
     
    以上是负面的因素。既然我们要打造公司的技术氛围,那么分享是一定要搞的。搞技术的人应该都有这样的初心,要保持技术上的持续成长,而不是做了一年项目下来发现什么都没学到,我觉得新手尤其有这样的诉求。如果公司没有提供这样成长的环境,那么优秀的员工迟早会离开。所以分享还是要搞滴,我们需要做的是克服一下负面因素。
     
    分享的时间该如何安排
     
    人到不齐,那肯定是时间安排不合理喽。所以,下一个问题,分享的时间该如何安排。
     
    首先纠结的一个就是:分享是定期搞还是不定期随机搞。如果定期搞,差不多就是一周或两周一次。上面也提到了创业公司的时间充满不稳定性,很难保证每次定期分享都到齐,而且分享者的压力也比较大。我们目前技术比较高能做分享的也就四五个。就算轮着来,每人每月进行一次分享压力还是蛮大,更何况这还是理想情况。
     
    如果是不定期组织呢?我觉得会更不靠谱。人对于学习总是有惰性的,这是本性,凭兴趣能坚持的是少数。如果不定期组织,很可能就会一推再推,最后分享就变成一件可有可无的事情。
     
    综合考虑还是觉得定期分享比较靠谱,至于分享压力的问题,想办法再权衡。
     
    关于分享的时间,还有另一道选择题:上班时间搞还是下班时间搞?之前我们是在上班时间,周五的下午来分享。考虑到尽量不占用大家的下班时间。这样的弊端是,手头有工作的同学可能就不能参加了。
     
    其实我是倾向于下班时间来搞的,之前在奇舞团也是每周一下班开始分享会,每次参加的人都很多。我觉得稍微向上一点的程序员,在占用下班时间和学习知识之间,都会偏向后者。人的本性是贪图舒适,但不能因此就把分享和听讲者的关系本末倒置,不能有“不好意思占用一下大家的时间,请大家参加一下分享会”这样的想法出现,分享不是求人,分享者在无私付出,其他人要想学到东西就必须牺牲一些享乐时间。而且下班时间也更加自由宽松,大家能够安心听讲不被工作打扰。
     
    总的来说,我觉得定期、下班时间分享是比较好的选择。
     
    分享人的选定
     
    接下来就是分享人的选定,小公司不像BAT那样有那么多讲师资源,一人一遍能轮一年。所以分享人的选定我们也面临两个选择:自由申报、强制指定。
     
    之前我们是本着自由申报的原则的,毕竟分享是一个自由开放的事情。
     
    最大的阻力还是人的惰性以及付出回报的不对等。做PPT、准备分享需要耗费一定的精力,这是时间成本。每次来听的就零星几个人,分享者成就感太低,写篇博客还几千PV呢,扯着嗓子讲半天就这点影响范围,太不划算。再有就是程序员的主动性往往很低,性格使然吧。
     
    自由申报的结果就是无人申报。要想定期分享,讲师接不上肯定是很大的问题。
     
    所以我也有考虑是否每次都提前指定好分享人。这种指定当然是大家在会上商量一下,谁好久没分享了,下次该轮谁了,大家的意见达成一致就行,算半强制吧。我觉得有一个共识是所有人需要达成的,分享人是付出劳动的,听讲者是占了便宜的,所以自己也不能老占便宜,也付出一点劳动回馈一下团队。达成这一的共识后,就算是强制到你头上了,你也应该没有怨言。
     
    这么分析下来,我倾向于轮流分享,每次提前商议决定分享人。这样就解决了讲师资源不足的问题,讲师足了,定期分享也就好搞了。
     
    分享内容怎么挑
     
    团队的技术水平参差不齐,分享内容的选择也是需要考虑的一个方面。由分享者自己把控应该是市面上的常规套路吧。这样的缺点是太依赖分享者的个人品味,万一他看走眼了选了一个偏门主题,让听众感觉浪费时间也是不好的。
     
    常见的做法就是提前预告,让大家先对分享内容有个了解,然后再决定参加与否,我觉得这是很好的。另外我还想到的一个办法是,可以成立类似“分享管理委员会”这样一个小组,事先对分享人的主题进行评审,对PPT以及内容进行先验,这样万一发现主题不合适可以进行调整。这样更好地提高了分享质量,保证了上座率。
     
    关于分享内容,我们团队还有这样的尝试,将分享内容进行分类,根据分类将分享会定为不同的级别:
    1. 由讲师编写“教材”,分享前端的基础知识、公司的技术栈,要求新员工必须参加,类似培训会。
    2. 常规的分享,但是要求内容必须是自己实践的原创,能Google到的内容不允许讲。
    3. 技术边缘的广泛讨论,内容形式不限。大概就是聊聊工作近况,聊聊行业话题之类,类似茶话会。
    看上去好像挺规整,但是这个方案一直没能落实。我觉得可能是以下原因吧:
    1. 编写“教材”进行培训,对讲师的要求太高,而且是长期的。我们平时手上都有项目,根本腾不出这么多时间写教材、做培训。而且对于新人,我觉得知道公司的技术栈自己去学就可以了,也没有必要进行手把手的教学,都喂到嘴里了,对丫太好了。
    2. “不允许讲”这4个字是很伤感情的,分享本来是自由开放的事情,有些内容即便网上可以搜到,再分享一下也没什么的,毕竟前端的知识太杂,没有谁能面面俱到。本来讲师就不积极,再加这个限制的结果就是没人肯分享了。
    3. 茶话会倒是挺好,我觉得合并到分享会,作为末尾环节就可以了,也没有单独搞的必要。
    所以,对于分享内容,我觉得还是简单化,没必要这么多限制,还是交给分享者吧。(以前奇舞团的分享搞的那么好,不知他们是否有委员会)
     
    看人家的分享搞得风生水起,着实眼红。到我们这里,要建立起一套大家都满意的分享机制,看上去并不是那么容易。对于分享,你怎么看呢?欢迎探讨。
     
     
    时而干货时而鸡汤,时而严肃时而疯癫。欢迎关注我的公众号:
  • 相关阅读:
    linux指令大全
    strcpy.strcmp.strlen.strcat函数的实现
    推箱子
    头文件string.h里的函数
    SVN 版本控制工具
    Nodejs 学习
    JavaScript基础知识复习
    CSS3 学习小结
    JSP中 JSTL
    JSP中的EL语言
  • 原文地址:https://www.cnblogs.com/lvdabao/p/5502832.html
Copyright © 2020-2023  润新知