关于软件公司如何进行知识分享的一些讨论
关于软件公司如何进行知识分享的一些讨论
Jerry Wang
发布于 2019-06-01 22:30:14
发布于 2019-06-01 22:30:14
问题搜集
- 你认为知识分享对你的工作是否带来了帮助？如果是，麻烦列举一些具体的点.如果觉得没有帮助，麻烦列举一些原因，比如是内容太浅，还是讲的东西和自己工作关联不大，等等。
- 你希望将来继续按照现在这个形式（即每次由一位或几位同事给其他同事分享自己最近项目上用到的技术或者设计）来进行这个知识分享么？ 如果不希望，你是否有其他的建议?
在这里插入图片描述
同事A
- 我参加了三个分享,由于关联性不强，对目前的工作没有什么实际上的辅助。但是在设计，或者考虑问题的时候是有帮助的。比如某个分享上提到的一些数据库设计问题，以及了解到的smart template。
- 我觉得这个形式蛮好的，如果能在分享之前将ppt大纲分享出来就更好了，能够提前了解大概这个分享的主题，以及技术点。
或者我们可以将分享分类一下，如UI5，微服务, CRM…
以及 不太确定每一次是否都是由领导邀请组里的同事进行分享呢？
同事B
- 然后我觉得这种方式和形式都挺好的，也对我去理解其他组的项目有直接帮助，同时也开了下眼界.
- 同时我有点觉得不是很好的方式，一是我们每次大概是1.5小时，会不会太长？同时我记得好几次都只有十几个人参加，这样会不会效果没法达到最佳，虽然每次都有分享记录。
同事C
- 参加这个分享我觉得有帮助的地方，就是能够和其他团队的同事切磋，了解其他团队的同事所做的东西，他们的技术架构大概是怎么样，扩展知识面，更加了解本公司的产品。
- 我认为可以继续保持这个形式。改进方面，看以后，我们能不能列一些主题，一起做一做，自己实际操作过后，印象会更深刻。
同事D
- 这个分享给我的工作是带来了帮助的，因为当时我把手上正在做的luckydraw的案例提出来, 大家都给了很多很好的建议,包括压力测试和数据的备份都是我们后面确实付诸行动去做的; 更重要的是这次的深入探讨让我了解到作为资深架构师的你们是如何来看待同一个问题, 因为我们组没有一个明确的架构师可以给我们指路, 所以更多的时候都是我们几个自己尝试各种可能, 这个知识分享就像是我们的一个资源后盾一样, 觉得任何问题都可以去和你们讨论. 此后团队给我们分享了几个项目组正在做的事情, 我也觉得很有意义, 让我大致了解到其他同事现在所在做的事情, 用到的技术, 他们在设计之初进行的尝试, 以及最后架构成型的思路. 我都觉得对我而言产生了潜移默化的帮助.
- 我认为这个方案去进行知识分享是一个可取的方法. 我仔细想了一下, 首先我们的知识分享讨论是1-2个月做一次, 每次都是一个项目组来分享, 但这并不代表其他项目组就没有可以分享的东西, 比如我们组前面才完成的rules engine service的设计和实现, 其实我们就可以把代码开放给大家, 包括我们的一些总结和资料, 我们可以有一个共享文件夹, 大家把自己最新的东西都放上去, 如果大家都对某一个东西很感兴趣, 或者有很多疑问, 我们就可以用一次小组讨论的方式来进行(当然这样子肯定会占用一些大家的时间, 甚至是私人时间). 我现在这个觉得觉得看别人的代码很有用, 在做rule engine的时候我们就是参考了组内一位大牛之前的代码, 才看的时候并不知道他的一些设计理由, 越到后面, 特别是自己开始写了以后越来越体会到他设计其中的一写巧妙的地方, 设计模式简直是在他的代码中活灵活现. 然后就借鉴到自己的代码中来了.
在这里插入图片描述
同事D
我觉得还是有帮助的，上次参加的Hybris技术分享， 还是了解了很多相关的知识。由于后面工作比较忙了，分享老是与重要会议冲突就没有怎么参加。就参加那次而言，觉得很好的就是事先提供有资料去了解整个SAP Hybris，这样在听的过程中不至于听不懂。后续还是希望有这个分享。但是有如下的建议: (1) 分享之前能够预先提供一些阅读资料，这样有个背景准备。
(2) 分享之前可以提供一些问题，让我们带着问题去阅读相关材料。 (3) 分享能不能尽量放在周二或周三，尽量提前两三周发出来，这样可以有一个时间上的安排。
同事E
1.这个知识分享帮助大家储备软件设计相关的案例，扩展知识广度和深度，很有意义，这些都有助于提高对日常工作的理解，从而提高工作效率。
2.现在的运行模式融合了各个团队之所长,希望可以继续保持；另，如果有时间的话，请考虑一下是否可以再加入一些基本软件工程的基础概念, 这样可以温故而知新，概念+真实案例，效果会不会更好些呢？
这个group对你的工作有帮助么？如果有，请列出一些具体的点
- 能了解其他组的同事在做什么，开阔了眼界
- 帮助我们解决了一些实际的设计问题
- 这个知识分享成为了团队的Architect资源池，遇到设计上的问题可以提出来和大家讨论
- 帮助大家储备软件设计相关的案例，扩展知识广度和深度，有助于提高大家对日常工作的理解
你觉得这个知识分享的形式到目前，还存在哪些问题？
- 每次分享之前没有只有个主题和大纲，缺乏具体的相关材料。这样如果听的同事对该主题一点基础都没有的话，分享上听起来很吃力，接收效果也不会太好。
- 每次分享1.5～2小时的时间会不会太长？1小时之后大家的注意力很难像刚开始一样保持集中
- 有些主题是讲述一些概念，缺乏动手环节
- 分享安排的时间总是和团队其他重要会议有冲突导致无法参加
你的建议？
- 每次分享之后先将详细材料放到共享文件夹下，组员事先自行阅读了解分享主题的背景知识。分享的演讲者可以有意识地提一些问题，让大家带着问题去阅读相关材料。
- 增加分享前/后的动手环节
- 分享尽量安排在周二/周三，会议安排提前三周发出来。
- 今年分享所使用的主题是否能设计成一个系列，如UI5，微服务, 自动化测试等等，通过一个系列的若干个分享，深入进去把一些问题彻底搞透，让每个组员都真正参与进去，而不是像去年的分享那样一个人讲，其他成员只是简单地旁听。
在这里插入图片描述
本文参与?腾讯云自媒体分享计划，分享自作者个人站点/博客。
原始发表：2018年12月22日，如有侵权请联系 cloudcommunity@tencent.com 删除
评论
登录后参与评论
推荐阅读
目录