如何评价技术分享的价值

评价一个技术分享的好坏,最简单有效的方式是在场听众的人数。

目前的现状是什么样?

首先分享一般是在周例会上,参与的人包括了各个项目的技术,技术方向包括但不限于iOS、Android、Java、C++、PHP。这时候分享会有三种类型。

第一种是分享通用技能,比如Git、HTTPS、算法。通用技术分享可以认为是对所有技术同学都有用的,或者说对工作是有帮助的。但既然是通用技能,就一定会出现有人没有掌握,有人已经掌握,而掌握的人也存在程度不同的情况。

第二种是分享专业技能,比如Swift、如何使用Android Studio、Yac实现原理。这种分享的特点是专业性强,面向人群主要为某一特定的技术方向,明显的缺点是受限于知识结构。对其它技术方向的同学的帮助不是显而易见的,或者干脆就不感兴趣。而同一方向的同学出由于技术程度不同也会出现分享效果不好,收获不大的问题。

第三种是分享工作项目,比如图像搜索、商业广告系统。这种分享可以帮助整个团队互相了解彼此的工作,但是由于技术性不强,所以很难突显个人的技术水平,对其他同学的技术成长帮助也十分有限。

那么现在我们认识到,不管是这三种分享的哪一种,都会受限于专业背景、知识结构以及实用性等问题,对分享和被分享的同学都不是十分有利的。

那么我们应该怎么做?

首先要做的是打破周例会上分享这种分享形式(或者是团队内部的指定性分享),采用一种更为开放的分享开式 — 自由分享模式,让分享同学自由的发起分享。为什么要这么做?我们都知道,作一次分享首先要明确的是听众是谁,至少应该知道他们的技术层次,这使我们能够更好的规划分享的方向。二是他们为什么要来听你讲,他们想从次分享中得到什么?是单纯的来捧场,还是要学习技术?

通过以上两点,可以分析出自由分享模式的一些优势。

一,分享者能够更有针对性的准备主题,也可以根据听众的背景来准备内容。反过来说,分享者准备了一个主题,来听分享的同学中必定是一些对主题感兴趣的同学,准备内容时也可以更好把握技术深度。

二,对听众来说,花了宝贵的时间来听分享,当然要听自己感兴趣的或者对自己有帮助的主题。有谁愿意花大把的时间过来,只为帮助你证明你的技术实力,而一无所获呢?

三,由于分享主题与听众专业背景的契合,在分享过程中也会产生更多的交流,使得双方都会有学习的空间,听众也可以从中学到更有价的内容,最终听众的收获与评价能够更加客观的证明一次分享的价值。

四,操作非常简单,报名、点名、现场照片,这里就不展开了。

对分享的双方,都是一种更市场化的行为。

对于分享者,出于对自己负责的态度,希望提高自己的技术,希望提高自己的技术影响力,那么一定选择更受欢迎的主题。这个主题有可能是自己熟悉的,会驱动自己更深入的学习。例如,只讲一个开源类库的用法是不是很浅,讲类库实现的原理是否更深入、更有价值。也可能是自己不熟的,会驱动自己去接触新技术。例如,讲PHP是不是过时了,是不是接触一下能代表未来的node.js。不管是哪种,对自身的技术都很有帮助。

对于听众,出于对自己负责的态度,可以自由的选择自己感兴趣的,或者对自己有帮助的技术分享。能从分享得到更多的收益,会促进参与的主观意愿。无论对个人的成长,还是对公司业务的发展,都会产生更加长远的影响。

采用自由分享模式,你可能还有一些顾虑,下面让我们来消除这些顾虑

分享的同学硬拉来认识的同学怎么办?对于这种情况完全不用担心,这种情况可以说是十分公平的。首先上面提到过,没人会花费的宝贵的时间来听一个没有收获的分享,那么被迫的同学会来一次,会来两次吗?会因为给面子而次次来吗?我想很少人这么大方的投入自己的时间吧。其次,就算是去硬拉来同学听分享,那有的人邀请到的人多,有的人邀请到的人少,而邀请到更多的人,或都说认识更多技术同学的人,也可以证明是更有技术有影响力的人吧。能邀请到10个人,那能邀请到100个人吗?能邀请到1000个人恐怕可以当VP了吧。

你可能会问,如果很多分享听众人数都差不多,那还是没有办法评价分享的价值。这里先要搞清楚评价分享的作用是什么,为什么要对分享作评价。最主要的想法是希望区分出一个人的技术层次,也就是说并不需要按照一个严格有序的队列对所有人进行排序,只要能区分出哪些同学的分享非常优秀,哪些分享一般,就算达到目的了。从这点出发,只需要给听众人数按范围划分就可以了。当然,分享次数多的同学还是值得肯定的,刚开始技术影响力小,层次低的时候,通过不断的分享来锻练自己,提高自己的分享能力,以达到更高的层次,所以分享数量更多的同学,从自身的提升和他人的评价中,都可以在同层次中脱颖而出。

最后

采用自由分享模式,通过在场听众的人数来判断一次分享的价值,是非常简单有效的方式。讲者提高技术,提高影响力。听者收获知识。所有人都可以客观的评价一次分享价值,可以说是一种双赢。

如果你还有什么疑问,或者有不同的观点,可以随时联系我(联系方式请自行挖掘)。

Written on January 30, 2016