现在实施的技术交流会

小熊留言问到 screen 是不是窦窦同学的报告,这里说一下我们现在的技术交流会形式:

定期指定一个技术课题交给某人做研究,大概三周后把其研究结果给所有技术人员做报告。

1. 这个技术课题是未来工作中可能会应用,但现在大部分同事还没有接触过的领域

2. 该流程的目的是开拓大家的技术知识面,所以研究工作会交给本来对该方面不太熟悉的人进行——虽然 screen 这个软件窦窦很早以前就用过,但这个做报告的同学是对 screen 一无所知的

3. 该流程的另外一个目的是给每个人上台做演示的机会。增强各个小组之间的交流

4. 三周时间准备是不是有些太短?从研究的角度来看,是有点短;但另一方面这样每个季度也就不过4次集体交流,我觉得周期不能再长了。所以我们不会选太高深的课题。另外,该研究完全可以在上班时间来进行,这是工作任务的一部分。

4. 三周时间是不是有些长?因为在第二周会首先试讲一下,听众是他的leader和我。我们会指出一些问题,帮助他下一次能在众人面前做更好的表演

5. 技术课题是谁提出的?现在还是由我来提出,希望以后这个事情可以交由邮件中心技术委员会来讨论决定。

6. 该活动我们已经进行了两次。第一次是 mysql-proxy,第二次是 screen,下一次是 javascript 混淆工具

7. 上面提到的"邮件中心技术委员会"是个什么机构?我们是一个很官僚的部门,因此成立这个委员会展示我们的行政作风。

hehe,大型 E-Mail 系统是一个涉及面很广的项目,在 N 个方面都需要有技术专家来支撑,需要有一个核心团队来推动提升部门的技术能力

Topic: 技术

评论

提几个建议。

  1. 演讲的目的应该开拓知识面,但是也要以工作优先,以工作中遇到的问题为主,比如 screen 对于基于终端开发的人很重要,这个几乎是必选题目。再比如我们决定很快迁移到 git 上,所以我进行了一次 git 培训。有需求听众也才能听得进去,离得比较远的东西不需要强制培训。
  2. 试讲我认为不太必要,这个要看人,如果他很擅长演讲和培训,就没有必要了,如果他比较内向,或者没有经验,可以考虑试讲一次。总之,多练几次就习惯了。
  3. 不要依靠讲座来增强交流,平时的开发过程中就应该贯彻这一点,多说话没坏处。
  4. 前面说了不必强制培训,所以时间也不必卡的很死,而且比较忙的时候很难实现这一点,工作需要的话,就随时都可以安排,如果有人想秀一下他新发现的或者新实现的技术等等,可以备案,抽时间安排。
  5. 讲座的时候可以加强互动性,比如以一个完整的例子来贯穿,让其他人也上台编写代码练习。
  6. 最后,讲座过程中,如果条件允许的话,所有人都应该带上家伙。一来可以就地练习,加强记忆,二来就没有人走神睡觉了。

多谢建议

另外,很钦佩您写回复也用 ul/li 排版.