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