[請益] 如何辦一個技術交流會議

看板Soft_Job作者 (Neil)時間10年前 (2016/01/17 21:15), 編輯推噓16(16推 0噓 69→)
留言85則, 18人參與, 最新討論串1/1
哈囉 大家好 最近小弟遇到個個問題 想問問各位高手的看法 我們公司是做SI的 因為我們公司專案很多 所以team也很多 但因為人員流動 以及平時缺乏交流的關係 所以大部分的問題 都是各專案的成員自行解決 但也因為這樣 常常花時間在解決別人解過的問題 像是 專案架構如何設計 某需求該用怎樣的操作流程 遇到某某商務邏輯 則Schema怎麼設計比較好等等... 所以最近想在公司弄個交流會議 讓各專案的設計人員 (不論是老鳥或新人) 都來交流自己遇到的問題和解法 看能不能提供別人解法、經驗 或從別人的建議中得到更好的做法 但通常工程師們 (尤其是越聰明的) 自尊心比常人更高也更自負 我怕到時後一下就變成華山論劍 每個人都認為自己的劍法才是強的 然後會議無法進展這樣 請問各位對於這樣的會議 有甚麼想法或經驗嗎? 或是有什麼推薦的會議流程能夠減少爭執的狀況呢? 謝謝各位大大 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 111.240.59.148 ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1453036545.A.B00.html
推
01/17 21:28, , 1F
打一架 華山不也論劍也是打一架最後贏的是中神通嗎?
01/17 21:28, 1F
→
01/17 21:38, , 2F
不需要減少爭執，要突顯差異才能選出適當的規劃。
01/17 21:38, 2F
→
01/17 21:40, , 3F
最強之劍是不存在的!在不適合的應用情境,憶秋年還是被收了
01/17 21:40, 3F
→
01/17 21:51, , 4F
可是目的不是要選出最強 是要讓其他人知道有這些解法
01/17 21:51, 4F
→
01/17 21:52, , 5F
可以選 或是從別人的建議中得到更好的方向
01/17 21:52, 5F
推
01/17 22:01, , 6F
建立文化~通常這種事不是一次就解決阿...
01/17 22:01, 6F
→
01/17 22:21, , 7F
要不要先從讀書會開始阿?
01/17 22:21, 7F
→
01/17 22:45, , 8F
想問final大 通常這種文化如何培養
01/17 22:45, 8F
推
01/17 22:55, , 9F
專案會長大 每個時期的架構要跟著長 沒有銀子彈可以一
01/17 22:55, 9F
→
01/17 22:55, , 10F
直用的好嗎
01/17 22:55, 10F
→
01/17 23:02, , 11F
銀子彈給得夠多 會議就會一片詳和了
01/17 23:02, 11F
→
01/17 23:10, , 12F
不是要找銀彈 是要share經驗 避免重造一次車輪
01/17 23:10, 12F
→
01/17 23:13, , 13F
為什麼要share? share完還不是被流動率洗掉嗎?
01/17 23:13, 13F
推
01/17 23:13, , 14F
誘因?有加薪嗎?原本手上工作能不能移轉給別人
01/17 23:13, 14F
→
01/17 23:15, , 15F
好處是可以得到薛西弗斯的稱號嗎?
01/17 23:15, 15F
→
01/17 23:15, , 16F
還是工作照做，額外再花精力去搞技術交流。
01/17 23:15, 16F
→
01/17 23:15, , 17F
想從資深的人身上學到什麼 還有不想做白工
01/17 23:15, 17F
→
01/17 23:16, , 18F
負誘因比較明確 工作量不會減少 開會還要佔時間
01/17 23:16, 18F
→
01/17 23:24, , 19F
可是從長遠來看 設計失敗的架構 不是更難開發和維護嗎
01/17 23:24, 19F
→
01/17 23:27, , 20F
重點是你有能力判斷什麼是設計失敗的架構嗎?
01/17 23:27, 20F
→
01/17 23:29, , 21F
如果你有best-practice 那直接拿出來做內訓不就好了
01/17 23:29, 21F
→
01/17 23:29, , 22F
當客戶的出小變更 工程師會發現改不了的 不就有問題嗎
01/17 23:29, 22F
→
01/17 23:29, , 23F
還開什麼交流會呢? 話說交流會就能生出成功的架構嗎?
01/17 23:29, 23F
推
01/17 23:30, , 24F
規定每個禮拜ㄧ人分享阿 上班時間 公司吸收成本
01/17 23:30, 24F
→
01/17 23:30, , 25F
最近問一些前輩技術問 通常給的答案都不是效能最佳化
01/17 23:30, 25F
→
01/17 23:30, , 26F
而是彈性夠高 預先猜測變更的設計呢
01/17 23:30, 26F
→
01/17 23:31, , 27F
但通常都是去問才有 還要剛好問對人 似乎沒有地方分享
01/17 23:31, 27F
推
01/17 23:32, , 28F
這種大拜拜型的交流會議，想得到什麼結論，開nb做自己的事
01/17 23:32, 28F
→
01/17 23:32, , 29F
，玩手機的玩手機，最好不要找我
01/17 23:32, 29F
→
01/17 23:33, , 30F
我也怕變成大拜拜而已 XDD 看來這種作法似乎不太有效
01/17 23:33, 30F
→
01/17 23:34, , 31F
還是用輪值日生方式，大家分享
01/17 23:34, 31F
→
01/17 23:34, , 32F
那你花錢請那些技術前輩來開內訓不就好了嗎?
01/17 23:34, 32F
→
01/17 23:35, , 33F
千萬別叫人輪流present技術啊 備課也是要花時間的
01/17 23:35, 33F
→
01/17 23:36, , 34F
也千萬別叫全部人都來上 採報名制 有興趣才來才有用
01/17 23:36, 34F
→
01/17 23:43, , 35F
同意m大 事實上公司的確有報名式的技術內訓
01/17 23:43, 35F
→
01/17 23:44, , 36F
但這次目的是要 share各自對需求的做法和考慮的觀點
01/17 23:44, 36F
→
01/17 23:45, , 37F
同樣的題目可能會有兩三種答案和原因
01/17 23:45, 37F
→
01/17 23:46, , 38F
不過想問各位大大 若今天遇到沒碰過的商業邏輯
01/17 23:46, 38F
→
01/17 23:47, , 39F
各位會怎麼做呢 (1)找有做過的人問 (2)自己設計看看?
01/17 23:47, 39F
→
01/17 23:47, , 40F
若(1)的話 又是透過甚麼樣的方式交流呢?
01/17 23:47, 40F
→
01/17 23:49, , 41F
想知道前輩的解答 解答的觀點 踩過的地雷 總覺得還是
01/17 23:49, 41F
→
01/17 23:49, , 42F
要有人share
01/17 23:49, 42F
→
01/17 23:50, , 43F
並不是有人share 其他人就能吸收
01/17 23:50, 43F
→
01/17 23:51, , 44F
就算是我沒做過的羅輯 我也不見得會全然信任前輩的解法
01/17 23:51, 44F
→
01/17 23:53, , 45F
但如果合作夥伴裡有人有相關經驗 那確實也挺好的
01/17 23:53, 45F
→
01/17 23:55, , 46F
所以 解法可能是降低流動率 增加團隊成員的(各種)經驗
01/17 23:55, 46F
→
01/17 23:55, , 47F
或是增加有(各種)經驗的團隊成員
01/17 23:55, 47F
→
01/18 00:01, , 48F
討論一個深刻的問題如果沒有相當的投入 應該只會流於膚淺
01/18 00:01, 48F
→
01/18 00:05, , 49F
感謝m大提供的意見 的確有這些問題
01/18 00:05, 49F
→
01/18 00:06, , 50F
我再想用分享平台的方式 不知道能不能解決
01/18 00:06, 50F
→
01/18 00:07, , 51F
減少占用的時間 又讓人有地方找
01/18 00:07, 51F
→
01/18 00:08, , 52F
想一個固定的報告格式 請各專案SD每次結束專案就要交
01/18 00:08, 52F
→
01/18 00:09, , 53F
不知道會不會好一點 XDD
01/18 00:09, 53F
→
01/18 00:25, , 54F
你有權力決定這些事情嗎 再來就是要人花時間準備這些
01/18 00:25, 54F
→
01/18 00:25, , 55F
那案子結案時間會延長 或多補人力嗎
01/18 00:25, 55F
推
01/18 00:29, , 56F
覺得可以先使用slack試試看
01/18 00:29, 56F
→
01/18 00:31, , 57F
一天讓一個人線上分享 但覺得還是要得到主管的支持比較好
01/18 00:31, 57F
→
01/18 00:57, , 58F
覺得這種報告和SD文件不同 記錄想法而非記錄架構本身
01/18 00:57, 58F
→
01/18 00:58, , 59F
對了 我沒有權限決定是否做 但有權限提出這件事
01/18 00:58, 59F
→
01/18 00:58, , 60F
目前主管是同意的
01/18 00:58, 60F
→
01/18 01:00, , 61F
的確會增加專案負擔 但如果人力培養起來不一定虧 XD
01/18 01:00, 61F
→
01/18 01:03, , 62F
應該有碰過超難開發又不具彈性的架構吧
01/18 01:03, 62F
→
01/18 01:03, , 63F
需求變更到需要改架構的時候 多花了多久時間
01/18 01:03, 63F
推
01/18 02:52, , 64F
將技術分享列為考績評比標準 保證大家卯起來分享
01/18 02:52, 64F
推
01/18 08:15, , 65F
這時需要一個夠高階的主管來當主持人
01/18 08:15, 65F
推
01/18 09:41, , 66F
聽課也要佔用工程師自己的開發時間，被逼來只好聽玩手機了
01/18 09:41, 66F
→
01/18 10:52, , 67F
妹子妹子妹子
01/18 10:52, 67F
推
01/18 11:07, , 68F
我覺得樓主的需求實行code review, pair programming之
01/18 11:07, 68F
→
01/18 11:07, , 69F
後順利再來辦同事間的交流比較好。我們以前沒有這種開會
01/18 11:07, 69F
→
01/18 11:07, , 70F
，但是後來漸漸有，是因為pair programming + code revi
01/18 11:07, 70F
→
01/18 11:07, , 71F
ew習慣而演化了
01/18 11:07, 71F
推
01/18 11:47, , 72F
先落實平時的工作日誌跟issue tracking。後面的人遇到類似
01/18 11:47, 72F
→
01/18 11:47, , 73F
的問題，就先去翻前人留下的記錄，並且回饋自己的心得。開
01/18 11:47, 73F
→
01/18 11:47, , 74F
會不必討論細節，只需拋出自己的問題，看誰有處理過給個線
01/18 11:47, 74F
→
01/18 11:47, , 75F
索去找前人留下的記錄即可。
01/18 11:47, 75F
推
01/18 12:27, , 76F
點心訂好吃一點
01/18 12:27, 76F
推
01/18 13:38, , 77F
首先定調這是交流 然後自由參加 參加有點心飲料 甜食有助緩
01/18 13:38, 77F
→
01/18 13:39, , 78F
解氣氛 再高的高手 吵架吵到一半送吃的到嘴邊也是要閉嘴吃
01/18 13:39, 78F
→
01/18 15:20, , 79F
沒誘因 為什麼要技術交流 開個沒結論的會議浪費時間沒人幹
01/18 15:20, 79F
→
01/18 15:22, , 80F
東西訂越好吃反而誘因越小 講的人反而不方便吃...
01/18 15:22, 80F
→
01/18 15:23, , 81F
真要有誘因有講課費用會比較實際 這樣缺錢自然會報名
01/18 15:23, 81F
推
01/18 15:37, , 82F
聽課的也要給出席費,不然幹麼浪費自己的開發時間上課
01/18 15:37, 82F
推
01/18 21:13, , 83F
自己公司的話辦code review就可以了
01/18 21:13, 83F
→
01/18 22:45, , 84F
前面說得對 先從小地方做好做滿 再來談什麼技術交流
01/18 22:45, 84F
→
01/18 22:46, , 85F
code review跟小點心都沒有 談什麼技術交流太遙遠了
01/18 22:46, 85F
‣ 更多 chaung1892 的文章
文章代碼(AID): #1McvG1i0 (Soft_Job)