作者chaung1892 (Neil)
看板Soft_Job
標題[請益] 如何辦一個技術交流會議
時間Sun Jan 17 21:15:43 2016
哈囉 大家好
最近小弟遇到個個問題 想問問各位高手的看法
我們公司是做SI的
因為我們公司專案很多 所以team也很多
但因為人員流動 以及平時缺乏交流的關係
所以大部分的問題 都是各專案的成員自行解決
但也因為這樣 常常花時間在解決別人解過的問題
像是 專案架構如何設計 某需求該用怎樣的操作流程
遇到某某商務邏輯 則Schema怎麼設計比較好等等...
所以最近想在公司弄個交流會議
讓各專案的設計人員 (不論是老鳥或新人)
都來交流自己遇到的問題和解法
看能不能提供別人解法、經驗
或從別人的建議中得到更好的做法
但通常工程師們 (尤其是越聰明的)
自尊心比常人更高也更自負
我怕到時後一下就變成華山論劍
每個人都認為自己的劍法才是強的
然後會議無法進展這樣
請問各位對於這樣的會議
有甚麼想法或經驗嗎?
或是有什麼推薦的會議流程能夠減少爭執的狀況呢?
謝謝各位大大
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 111.240.59.148
※ 文章網址: https://webptt.com/m.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