作者chaung1892 (Neil)
看板Soft_Job
标题[请益] 如何办一个技术交流会议
时间Sun Jan 17 21:15:43 2016
哈罗 大家好
最近小弟遇到个个问题 想问问各位高手的看法
我们公司是做SI的
因为我们公司专案很多 所以team也很多
但因为人员流动 以及平时缺乏交流的关系
所以大部分的问题 都是各专案的成员自行解决
但也因为这样 常常花时间在解决别人解过的问题
像是 专案架构如何设计 某需求该用怎样的操作流程
遇到某某商务逻辑 则Schema怎麽设计比较好等等...
所以最近想在公司弄个交流会议
让各专案的设计人员 (不论是老鸟或新人)
都来交流自己遇到的问题和解法
看能不能提供别人解法、经验
或从别人的建议中得到更好的做法
但通常工程师们 (尤其是越聪明的)
自尊心比常人更高也更自负
我怕到时後一下就变成华山论剑
每个人都认为自己的剑法才是强的
然後会议无法进展这样
请问各位对於这样的会议
有甚麽想法或经验吗?
或是有什麽推荐的会议流程能够减少争执的状况呢?
谢谢各位大大
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 111.240.59.148
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1453036545.A.B00.html
1F：推 femlro: 打一架 华山不也论剑也是打一架最後赢的是中神通吗? 01/17 21:28
2F：→ qrtt1: 不需要减少争执，要突显差异才能选出适当的规划。 01/17 21:38
3F：→ qrtt1: 最强之剑是不存在的!在不适合的应用情境,忆秋年还是被收了 01/17 21:40
4F：→ chaung1892: 可是目的不是要选出最强 是要让其他人知道有这些解法 01/17 21:51
5F：→ chaung1892: 可以选 或是从别人的建议中得到更好的方向 01/17 21:52
6F：推 final01: 建立文化~通常这种事不是一次就解决阿... 01/17 22:01
7F：→ death06: 要不要先从读书会开始阿? 01/17 22:21
8F：→ chaung1892: 想问final大 通常这种文化如何培养 01/17 22:45
9F：推 Masakiad: 专案会长大 每个时期的架构要跟着长 没有银子弹可以一 01/17 22:55
10F：→ Masakiad: 直用的好吗 01/17 22:55
11F：→ manaup: 银子弹给得够多 会议就会一片详和了 01/17 23:02
12F：→ chaung1892: 不是要找银弹 是要share经验 避免重造一次车轮 01/17 23:10
13F：→ manaup: 为什麽要share? share完还不是被流动率洗掉吗? 01/17 23:13
14F：推 lichai: 诱因?有加薪吗?原本手上工作能不能移转给别人 01/17 23:13
15F：→ manaup: 好处是可以得到薛西弗斯的称号吗? 01/17 23:15
16F：→ lichai: 还是工作照做，额外再花精力去搞技术交流。 01/17 23:15
17F：→ chaung1892: 想从资深的人身上学到什麽 还有不想做白工 01/17 23:15
18F：→ manaup: 负诱因比较明确 工作量不会减少 开会还要占时间 01/17 23:16
19F：→ chaung1892: 可是从长远来看 设计失败的架构 不是更难开发和维护吗 01/17 23:24
20F：→ manaup: 重点是你有能力判断什麽是设计失败的架构吗? 01/17 23:27
21F：→ manaup: 如果你有best-practice 那直接拿出来做内训不就好了 01/17 23:29
22F：→ chaung1892: 当客户的出小变更 工程师会发现改不了的 不就有问题吗 01/17 23:29
23F：→ manaup: 还开什麽交流会呢? 话说交流会就能生出成功的架构吗? 01/17 23:29
24F：推 GoalBased: 规定每个礼拜ㄧ人分享阿 上班时间 公司吸收成本 01/17 23:30
25F：→ chaung1892: 最近问一些前辈技术问 通常给的答案都不是效能最佳化 01/17 23:30
26F：→ chaung1892: 而是弹性够高 预先猜测变更的设计呢 01/17 23:30
27F：→ chaung1892: 但通常都是去问才有 还要刚好问对人 似乎没有地方分享 01/17 23:31
28F：推 lichai: 这种大拜拜型的交流会议，想得到什麽结论，开nb做自己的事 01/17 23:32
29F：→ lichai: ，玩手机的玩手机，最好不要找我 01/17 23:32
30F：→ chaung1892: 我也怕变成大拜拜而已 XDD 看来这种作法似乎不太有效 01/17 23:33
31F：→ lichai: 还是用轮值日生方式，大家分享 01/17 23:34
32F：→ manaup: 那你花钱请那些技术前辈来开内训不就好了吗? 01/17 23:34
33F：→ manaup: 千万别叫人轮流present技术啊 备课也是要花时间的 01/17 23:35
34F：→ manaup: 也千万别叫全部人都来上 采报名制 有兴趣才来才有用 01/17 23:36
35F：→ chaung1892: 同意m大 事实上公司的确有报名式的技术内训 01/17 23:43
36F：→ chaung1892: 但这次目的是要 share各自对需求的做法和考虑的观点 01/17 23:44
37F：→ chaung1892: 同样的题目可能会有两三种答案和原因 01/17 23:45
38F：→ chaung1892: 不过想问各位大大 若今天遇到没碰过的商业逻辑 01/17 23:46
39F：→ chaung1892: 各位会怎麽做呢 (1)找有做过的人问 (2)自己设计看看? 01/17 23:47
40F：→ chaung1892: 若(1)的话 又是透过甚麽样的方式交流呢? 01/17 23:47
41F：→ chaung1892: 想知道前辈的解答 解答的观点 踩过的地雷 总觉得还是 01/17 23:49
42F：→ chaung1892: 要有人share 01/17 23:49
43F：→ manaup: 并不是有人share 其他人就能吸收 01/17 23:50
44F：→ manaup: 就算是我没做过的罗辑 我也不见得会全然信任前辈的解法 01/17 23:51
45F：→ manaup: 但如果合作夥伴里有人有相关经验 那确实也挺好的 01/17 23:53
46F：→ manaup: 所以 解法可能是降低流动率 增加团队成员的(各种)经验 01/17 23:55
47F：→ manaup: 或是增加有(各种)经验的团队成员 01/17 23:55
48F：→ manaup: 讨论一个深刻的问题如果没有相当的投入 应该只会流於肤浅 01/18 00:01
49F：→ chaung1892: 感谢m大提供的意见 的确有这些问题 01/18 00:05
50F：→ chaung1892: 我再想用分享平台的方式 不知道能不能解决 01/18 00:06
51F：→ chaung1892: 减少占用的时间 又让人有地方找 01/18 00:07
52F：→ chaung1892: 想一个固定的报告格式 请各专案SD每次结束专案就要交 01/18 00:08
53F：→ chaung1892: 不知道会不会好一点 XDD 01/18 00:09
54F：→ GoalBased: 你有权力决定这些事情吗 再来就是要人花时间准备这些 01/18 00:25
55F：→ GoalBased: 那案子结案时间会延长 或多补人力吗 01/18 00:25
56F：推 yyc1217: 觉得可以先使用slack试试看 01/18 00:29
57F：→ yyc1217: 一天让一个人线上分享 但觉得还是要得到主管的支持比较好 01/18 00:31
58F：→ chaung1892: 觉得这种报告和SD文件不同 记录想法而非记录架构本身 01/18 00:57
59F：→ chaung1892: 对了 我没有权限决定是否做 但有权限提出这件事 01/18 00:58
60F：→ chaung1892: 目前主管是同意的 01/18 00:58
61F：→ chaung1892: 的确会增加专案负担 但如果人力培养起来不一定亏 XD 01/18 01:00
62F：→ chaung1892: 应该有碰过超难开发又不具弹性的架构吧 01/18 01:03
63F：→ chaung1892: 需求变更到需要改架构的时候 多花了多久时间 01/18 01:03
64F：推 YahooTaiwan: 将技术分享列为考绩评比标准 保证大家卯起来分享 01/18 02:52
65F：推 cobrasgo: 这时需要一个够高阶的主管来当主持人 01/18 08:15
66F：推 lichai: 听课也要占用工程师自己的开发时间，被逼来只好听玩手机了 01/18 09:41
67F：→ neo5277: 妹子妹子妹子 01/18 10:52
68F：推 Masakiad: 我觉得楼主的需求实行code review, pair programming之 01/18 11:07
69F：→ Masakiad: 後顺利再来办同事间的交流比较好。我们以前没有这种开会 01/18 11:07
70F：→ Masakiad: ，但是後来渐渐有，是因为pair programming + code revi 01/18 11:07
71F：→ Masakiad: ew习惯而演化了 01/18 11:07
72F：推 bobju: 先落实平时的工作日志跟issue tracking。後面的人遇到类似 01/18 11:47
73F：→ bobju: 的问题，就先去翻前人留下的记录，并且回馈自己的心得。开 01/18 11:47
74F：→ bobju: 会不必讨论细节，只需抛出自己的问题，看谁有处理过给个线 01/18 11:47
75F：→ bobju: 索去找前人留下的记录即可。 01/18 11:47
76F：推 v7q4: 点心订好吃一点 01/18 12:27
77F：推 Argos: 首先定调这是交流 然後自由参加 参加有点心饮料 甜食有助缓 01/18 13:38
78F：→ Argos: 解气氛 再高的高手 吵架吵到一半送吃的到嘴边也是要闭嘴吃 01/18 13:39
79F：→ Weky: 没诱因 为什麽要技术交流 开个没结论的会议浪费时间没人干 01/18 15:20
80F：→ Weky: 东西订越好吃反而诱因越小 讲的人反而不方便吃... 01/18 15:22
81F：→ Weky: 真要有诱因有讲课费用会比较实际 这样缺钱自然会报名 01/18 15:23
82F：推 lichai: 听课的也要给出席费,不然干麽浪费自己的开发时间上课 01/18 15:37
83F：推 b510336: 自己公司的话办code review就可以了 01/18 21:13
84F：→ manaup: 前面说得对 先从小地方做好做满 再来谈什麽技术交流 01/18 22:45
85F：→ manaup: code review跟小点心都没有 谈什麽技术交流太遥远了 01/18 22:46