内部分享这件事

关于内部分享的,所想所做


一家之言

虽然,大多人奋斗的最终目的都是财务自由。

但是,越来越多的年轻人,更不仅限于此,能“站着”把钱挣了,为什么要“坐“着呢?

甚至,随着成本不同,宁可少赚一些,也要“站着”。


回到“正”题,

以前工作的时候,特别羡慕那些有内部分享的公司;但是,一直也没有加入到过这样的团队。

既然没有,那就自己来,

以前我没得选,现在我想做个分享。




付诸行动

真正要做这个东西,不是那么简单的。

在公司,做任何东西,都是看成本与收益的,很多事情不可能像想象的那么简单;而且,既然做就做好,不要形式化表面化。


成本与收益

分享涉及到的人员的成本收益以及主程的成本收益都要考虑到。

管理者

做任何活动,当然都要经过管理者的把关与认同。

需要做的就是证明,分享这件事收益是大于成本的,对于收益比高的东西,管理者是很难不去赞同你做的。

成本:

  • 功能进度上的影响
  • 管理上的时间支出
  • 激励及鼓励项支出(可选项)

其中,功能进度上的影响,可以由调整内部分享的时间来进行把控及限制。

但是,做分享,一定程度上会耽误功能开发进度

收益,由以下几个方面:

  • 培养良好的技术氛围
  • 扩宽团队视野
  • 提高团队技术

当然,还会有很多隐性收益。

参加者

参加分享的人,主要可以分为两种,分享的人 和 听的人。

对于分享的人,

成本:

  • 花费时间筹备,影响功能进度(中等)

收益:

  • 锻炼对已获得知识的总结、提炼能力
  • 锻炼表达能力,沟通能力
  • 检验并优化实现功能

对于其他人,

成本:

  • 花费时间参加,影响功能进度(轻微)

收益:

  • 获取新的知识,对当前项目加深理解
  • 锻炼表达能力,沟通能力



流程与规范

把内部分享当做一个玩法,

有三个职业:

  • 守卫者(1人)
    • 分享的负责人,前期可由主程担任,之后期望团队各个成员轮值
    • 职责:
      • 分享前,与分享者沟通协调分享主题,确立大纲及大概时间
      • 分享期,沟通协调 会议室,确保使用工具(分享材料、工具等),把控分享流程及时间
      • 分享后,统计整理反馈给分享者,整理分享内容存档
  • 分享者(n人)
    • 职责:确定分享内容,并准备好分享材料,流程大纲以PPT效果最好,辅助以 XMind、代码片段截图、效果视频等。
  • 聆听者(n人)
    • 职责:对分享者分享内容吸收讨论,做好反馈,帮助分享者更进一步。

分享期的流程为:

  • 准备
    • 所有人准备好 笔/本
    • 分享者准备好分享材料提前交付守卫者
    • 守卫者联系好会议室等
  • 开始
    • 守卫者 明确分享流程及规则
    • 分享者 进行分享
      • 期间非重大问题,先记录下来,禁止打断
    • 分享者 进行答疑
      • 守卫者把控方向及时间,避免跑偏及超时
      • 对于大争论,可暂时记录,并约定好下次讨论时间
  • 结束
    • 守卫者收集聆听者的反馈,整理给分享者
    • 守卫者将分享材料、答疑期间重要问题 等,收档存储



重点与难点

时间

不止是内部分享,还有很多会议,难以开展,主要问题就是时间。

由于时间无法确定,导致效率低下,阻碍功能开发进度(开会一开一下午,谁受得了呀)。

但是,很多时候,并不是真的需要花费那么多时间。

内部分享会议主要由两部分组成: 分享时间 + 答疑时间。

分享时间能做好预估,答疑时间,也可以做限制,对于大的问题,讨论大概,并存档延后处理,不一定非要一次解决完所有问题。

所以,保证每次分享的时间,让大家都明确要花多少时间来做这件事,保证分享高效的进行,是很重要的一点。

目前,由于近期项目组业务繁忙,暂定的时间是 双周一次,每次根据内容把控在1-2小时。

分享内容

分享的还有一个大的问题,就是不知道分享什么。

感觉分享难的,大家听不懂;分享简单的,又觉得不值得。

但是,其实分享方向很多的,大方向来讲,可以分为三种:

  • 模块功能的实现方法
  • 模块功能的优化方向
  • 外延分享

对已实现模块功能进行剖析,也便于CodeReview,也便于发现一些模块的性能瓶颈等。

优化方向的讨论,便于发现不同的角度及方案。

外延分享也是必须的,不能仅限于当前业务,但是一定要与业务有所关联,并且不能太深。

流程

很多人觉得,分享应该是大家都轻轻松松的去进行,目的是让大家都理解,没必要有太多规矩,让大家拘谨。

首先,我是很认同这个目的,让大家有所收获,理解分享者的内容。

但是,无规矩不成方圆,为了我们分享的高效执行,还是要有一些基本的规矩的,比如分享者先分享再答疑,可以避免很多问题,再如,把控分享时间,也可以避免插科打诨等影响分享的收益。

这里,我自己本人的观点就是,高效的收益来源于完善且准确执行的制度。

反馈与存档

反馈是对于分享者的另一份收益,也要保障好。

分享会议,最难的还是做分享的人,为了激励大家对担任分享者的积极性,一定要保障好分享者利益。

存档是对于整个分享的一个总结,每个团队,都应该有自己的底蕴与积淀,这些分享日志就可以作为积淀的一部分。




磕磕绊绊

到目前为止,也实施了一段时间,过程也是磕磕绊绊。

此处也列一些遇到的问题,有些有解决,有些没有解决,都可以讨论一下。

时间冲突

有时会出现,准备开分享会的时候,人员不齐的情况。

由于分享希望让所有成员都有所收获,并且团队人员不是很多,所以,就会推迟分享时间。

最主要的问题,还是在于会议室不足(需要大的且有投影仪的会议室),所以无法准确预估会议室空缺时间,之后解决方法就是分析各团队占用的时间,找个相对冷门时间开分享会议,降低冲突概率。

功能冲突

还有一个问题就是,分享者时间和功能研发冲突了。

尽管已经提前2个周进行沟通,但是业务繁忙的时候,的确没有时间去整理(大家对分享质量要求还是很上心的)。

这个解决方案,目前也是延迟分享,但是,不能影响之后的分享进行。

比如,分享时间表:

  • 第一期,时间:第一周
  • 第二期,时间:第三周
  • 第三期,时间:第五周

第一期时间延迟,首先改为第二周开始

第一期时间再次延迟,将第一期时间放在第二期之后

  • 第二期,时间:第三周
  • 第一期,时间:第五周
  • 第三期,时间:第七周

所以,需要提前通知两期分享者准备,需要提前一个月告诉分享者时间,开始准备分享。




最后

很多团队,尤其是游戏团队,感觉都不重视这方面。

一是现在很多都在抢时间上线,哪有时间管你自己提升。

二是都想着上线后,就开始做;赚钱后,就开始做;等等…

其实,现在年轻人,不像以前了;

相对于提升工作的幸福感,可能比工资上收入多那么一点更重要

(毕竟,多那些钱,也改变不了什么,为什么要在工作中委屈自己呢)

最后的最后,一切这些都离不开管理者的支持,没有管理者支持与理解,设计再好再多,也是枉然。