关于内部分享的，所想所做
一家之言
虽然，大多人奋斗的最终目的都是财务自由。
但是，越来越多的年轻人，更不仅限于此，能“站着”把钱挣了，为什么要“坐“着呢？
甚至，随着成本不同，宁可少赚一些，也要“站着”。
回到“正”题，
以前工作的时候，特别羡慕那些有内部分享的公司；但是，一直也没有加入到过这样的团队。
既然没有，那就自己来，
以前我没得选，现在我想做个分享。
付诸行动
真正要做这个东西，不是那么简单的。
在公司，做任何东西，都是看成本与收益的，很多事情不可能像想象的那么简单；而且，既然做就做好，不要形式化表面化。
成本与收益
分享涉及到的人员的成本收益以及主程的成本收益都要考虑到。
管理者
做任何活动，当然都要经过管理者的把关与认同。
需要做的就是证明，分享这件事收益是大于成本的，对于收益比高的东西，管理者是很难不去赞同你做的。
成本：
- 功能进度上的影响
- 管理上的时间支出
- 激励及鼓励项支出（可选项）
其中，功能进度上的影响，可以由调整内部分享的时间来进行把控及限制。
但是，做分享，一定程度上会耽误功能开发进度
收益，由以下几个方面：
- 培养良好的技术氛围
- 扩宽团队视野
- 提高团队技术
当然，还会有很多隐性收益。
参加者
参加分享的人，主要可以分为两种，分享的人 和 听的人。
对于分享的人，
成本：
- 花费时间筹备，影响功能进度（中等）
收益：
- 锻炼对已获得知识的总结、提炼能力
- 锻炼表达能力，沟通能力
- 检验并优化实现功能
对于其他人，
成本：
- 花费时间参加，影响功能进度（轻微）
收益：
- 获取新的知识，对当前项目加深理解
- 锻炼表达能力，沟通能力
流程与规范
把内部分享当做一个玩法，
有三个职业：
- 守卫者（1人）
- 分享的负责人，前期可由主程担任，之后期望团队各个成员轮值
- 职责：
- 分享前，与分享者沟通协调分享主题，确立大纲及大概时间
- 分享期，沟通协调 会议室，确保使用工具（分享材料、工具等），把控分享流程及时间
- 分享后，统计整理反馈给分享者，整理分享内容存档
- 分享者（n人）
- 职责：确定分享内容，并准备好分享材料，流程大纲以PPT效果最好，辅助以 XMind、代码片段截图、效果视频等。
- 聆听者（n人）
- 职责：对分享者分享内容吸收讨论，做好反馈，帮助分享者更进一步。
分享期的流程为：
- 准备
- 所有人准备好 笔/本
- 分享者准备好分享材料提前交付守卫者
- 守卫者联系好会议室等
- 开始
- 守卫者 明确分享流程及规则
- 分享者 进行分享
- 期间非重大问题，先记录下来，禁止打断
- 分享者 进行答疑
- 守卫者把控方向及时间，避免跑偏及超时
- 对于大争论，可暂时记录，并约定好下次讨论时间
- 结束
- 守卫者收集聆听者的反馈，整理给分享者
- 守卫者将分享材料、答疑期间重要问题 等，收档存储
重点与难点
时间
不止是内部分享，还有很多会议，难以开展，主要问题就是时间。
由于时间无法确定，导致效率低下，阻碍功能开发进度（开会一开一下午，谁受得了呀）。
但是，很多时候，并不是真的需要花费那么多时间。
内部分享会议主要由两部分组成： 分享时间 + 答疑时间。
分享时间能做好预估，答疑时间，也可以做限制，对于大的问题，讨论大概，并存档延后处理，不一定非要一次解决完所有问题。
所以，保证每次分享的时间，让大家都明确要花多少时间来做这件事，保证分享高效的进行，是很重要的一点。
目前，由于近期项目组业务繁忙，暂定的时间是 双周一次，每次根据内容把控在1-2小时。
分享内容
分享的还有一个大的问题，就是不知道分享什么。
感觉分享难的，大家听不懂；分享简单的，又觉得不值得。
但是，其实分享方向很多的，大方向来讲，可以分为三种：
- 模块功能的实现方法
- 模块功能的优化方向
- 外延分享
对已实现模块功能进行剖析，也便于CodeReview，也便于发现一些模块的性能瓶颈等。
优化方向的讨论，便于发现不同的角度及方案。
外延分享也是必须的，不能仅限于当前业务，但是一定要与业务有所关联，并且不能太深。
流程
很多人觉得，分享应该是大家都轻轻松松的去进行，目的是让大家都理解，没必要有太多规矩，让大家拘谨。
首先，我是很认同这个目的，让大家有所收获，理解分享者的内容。
但是，无规矩不成方圆，为了我们分享的高效执行，还是要有一些基本的规矩的，比如分享者先分享再答疑，可以避免很多问题，再如，把控分享时间，也可以避免插科打诨等影响分享的收益。
这里，我自己本人的观点就是，高效的收益来源于完善且准确执行的制度。
反馈与存档
反馈是对于分享者的另一份收益，也要保障好。
分享会议，最难的还是做分享的人，为了激励大家对担任分享者的积极性，一定要保障好分享者利益。
存档是对于整个分享的一个总结，每个团队，都应该有自己的底蕴与积淀，这些分享日志就可以作为积淀的一部分。
磕磕绊绊
到目前为止，也实施了一段时间，过程也是磕磕绊绊。
此处也列一些遇到的问题，有些有解决，有些没有解决，都可以讨论一下。
时间冲突
有时会出现，准备开分享会的时候，人员不齐的情况。
由于分享希望让所有成员都有所收获，并且团队人员不是很多，所以，就会推迟分享时间。
最主要的问题，还是在于会议室不足（需要大的且有投影仪的会议室），所以无法准确预估会议室空缺时间，之后解决方法就是分析各团队占用的时间，找个相对冷门时间开分享会议，降低冲突概率。
功能冲突
还有一个问题就是，分享者时间和功能研发冲突了。
尽管已经提前2个周进行沟通，但是业务繁忙的时候，的确没有时间去整理（大家对分享质量要求还是很上心的）。
这个解决方案，目前也是延迟分享，但是，不能影响之后的分享进行。
比如，分享时间表：
- 第一期，时间：第一周
- 第二期，时间：第三周
- 第三期，时间：第五周
- …
第一期时间延迟，首先改为第二周开始
第一期时间再次延迟，将第一期时间放在第二期之后
- 第二期，时间：第三周
- 第一期，时间：第五周
- 第三期，时间：第七周
- …
所以，需要提前通知两期分享者准备，需要提前一个月告诉分享者时间，开始准备分享。
最后
很多团队，尤其是游戏团队，感觉都不重视这方面。
一是现在很多都在抢时间上线，哪有时间管你自己提升。
二是都想着上线后，就开始做；赚钱后，就开始做；等等…
其实，现在年轻人，不像以前了；
相对于提升工作的幸福感，可能比工资上收入多那么一点更重要
（毕竟，多那些钱，也改变不了什么，为什么要在工作中委屈自己呢）
最后的最后，一切这些都离不开管理者的支持，没有管理者支持与理解，设计再好再多，也是枉然。