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