# 1 on 1 with Ray

## 2024-12-17 年度 1 on 1

開始時間: 16:11
結束時間: 18:20 + 12/18 20 min

- 工作表現與成就
- 你目前的團隊中有哪些角色？你過去一年在團隊中主要擔任的角色？
- 開發者: 依據需求完成任務，交付可以運作的功能，也負責非開發的維運、測試、需求分析等任務
- 專案領導: 提供 Member 對於任務項目的看法作為參考，提供建議，和 Member 一起訂定每次任務或 Pair 的 milestone，確保時間效益
- 技術貢獻者: 持續將學到的新知識與技能分享給 Member，讓 Member 持續學習，提升大家的任務品質與速度
- > Mars: 看的出來你過去一年其實這些角色都扮演的很好，像上次跟 CL team 講解 CF 的功能和架構時，也是臨危受命一個人完成了這件事，並且還有預先寫一些資料還有讓他們可以先想一下問題，這部分的領導能力我很肯定
- > Mars: 那上述角色我覺得還可以再多加一個 DevOps，因為你也會去設定一些 Datadog 相關的監控，並且每天也都會去注意那些 alert 和 errors，甚至晚上下班後也會第一時間發現問題就馬上通報和處理，這也是我覺得你非常難能可貴的地方，儘管那些專案可能不是你負責或經手過的，也都會一起幫忙解決，這個團隊貢獻精神非常好
- 重點列舉你過去一年參與的重要milestones, 你在這些milestones中主要職責/任務?
- 對齊manager對team member過去一年的貢獻
- CF Bot setting Crop Image
- 在第一次接觸 CF 前端下，獨立開發前端功能，習慣並了解 CF 前端架構，並準時交付，有 bug 也能迅速修正
- CF Webchat Answer Source
- 在急迫的時間內獨自完成 CF 前端和後端，也和 FusionKB API 對接合作，在遇到無法解決的問題時迅速向前端尋求協助，確保任務準時完成
- CF Permission
- 規劃開發整套 ChatFusion 的 Permission 管理機制
- 事先設計好規則，讓支援的 Member 可以快速上工來支援任務
- 事先準備測試資料與環境讓大家測試，讓團隊不需要準備任何資料即可快速進行測試
- 事後也和 Member 一起檢討該架構還可以改進的地方
- CF Email Notification
- 除了完成前端開發，也包括設定 AWS SES 服務，並附上完整的操作流程紀錄以及跟教會後端如何建立與使用該服務
- CF Conversation List with location
- 開發前端，完成比過往更好的 UI 實作成果，並和後端合作對接與事先提供 QA 測試資料，減少了 QA 很多測試時間
- Site Comapnion
- 下半年最大型任務，完成包括 smart generation、related question、answer sources、new answer flow 等許多功能
- 中間也有獨立開發和前端雨後端
- 和其他後端 Member 一起開發，為 Member 解說自己清楚的功能，也從 Member 了解以前沒碰過的部分
- 中間為了解決 QA 測試的問題以及讓前端不會每次都需要爬 code 確認 API，擬定了 API 文件架構，讓其他後端有一致的規格去寫 API 文件，期間也寫了大量的 ChatFusion API 文件
- 為了讓測試更方便，自己實際架設網站模擬使用情境，降低測試複雜度、建立 mcok 資料節省 Apify 和 OpenAI 成本，並透過 Demo 更清楚確認功能是否符合需求
- > Mars: 好，這個格式看起來很像履歷 XD，但也很感謝你能夠這麼快就掌握新的專案架構和功能，並且快速的獨立開發完這些任務，並且也能帶同組的成員一起進行開發還有給予很多有用的建議， code review 也很細心
- Data Retention 算嗎? 雖然沒有做完，但也是投入了大量時間，中間也順便優化了 SW 報表查詢速度
- > Mars: 那這個我覺得是算的，只是後續做其他專案之後，那這個功能目前先暫時停滯，比較可惜沒有後續持續精進這個功能，但是你初期的研究也是非常令人讚賞，尤其是一開始這個功能是為了 SOC2 所以要做的，那你也研究了 SOC2 的內容，雖然目前這個計劃好像也是暫時停止的狀態，不過你投入的精力大家也是有感受到的！
- 你覺得你對專案知識與使用技術的掌握度？
- 檢視成員在跨/新專案的參與度
- Cerebro、TSM、Widget、Falcon
- 如果遇到需要 operation，可以透過排查程式碼確認問題
- 整體架構還算清楚，Click 的業務比較熟，電話的業務就還好
- 查報表如果有人一起應該可以更快解決
- 如果突然有新需求也還是可以快速切換回來開發
- Widget 應該是在公司中非常熟的
- > Mars: 沒錯，你的 widget 比我還熟非常多，感覺我那邊的熟稔度遠遠不及你，那其他專案也是一樣能夠很快速掌握細節，而不是單單只是大概瞭解功能流程，掌握度非常好
- ChatFusion
- 現在主力專案，整體算熟悉
- 很少開發前端的 webchat bot，對 Webchat bot 程式算是最不熟的部分，但業務邏輯還是知道
- FusionKB 在下半年碰比較多有熟悉很多
- 如果時間充足，應該都可以獨自完成前端到後端整套新功能 (不含前端 webchat bot 機制)
- OpenAI API 有比以前更了解，未來還是可以透過 side project 在更近一步提升
- > Mars: 沒錯，Fusion-KB 這塊只有初期做 SSQ 的時候帶你們跑了一段時間，後來的 site companion 你們就已經完全可以自己規劃進度跟分配任務了，也讓我感到輕鬆許多，那相對的我就有更多心力去
- 不過這次在做 Lead Capture 的時候在 request validation 感覺到比較麻煩，因為還要考量到向下相容，所以有一些檢查就沒有寫到很嚴謹，code review 的時候就會被提出來，或是在開發的時候會為了迎合 ETA，所以用比較快速的做法，那在跟組員討論的時候會想說要有一些未來的擴充性
- > Mars: 那當然以商業的角度來看，ETA 很重要，因為程式寫的好，但功能還沒完成其實無法上線，那業務就無法推廣，相對的，如果程式架構還可以，但是功能完成，那就可以被大家使用，就是有價值的，那這就是一種妥協，雖然會感覺好像程式一直沒寫好，但其實你在相同的時間內，其實也是越做越好，像是以前有人會為了快速完成功能然後不寫測試，那現在我們這邊是沒有這個問題，就算是很趕也會有測試，而且像你現在邊開發也會邊想很多使用情境讓程式品質越來越好，其實不一定是要架構很好容易開發跟維護才是程式品質好的唯一指標，能夠滿足更多情境都能穩定使用也是，那接下來就是持續精進，然後在相同的時間內能夠做到更長遠的設計
- 反思一下跟去年訂出來的目標所需要的能力還離多遠？達成？還差一些？
- 去年訂下的目標很廣泛，包括了前端、後端、SRE 等都要有成長
- 前端
- Overview:
- 比起去年整體有進步，算是勉強達標
- 實績
- 以前只能切版出接近的畫面，現在成長到可以根據設計稿切出設計師滿意的畫面
- 在開發期間透過和設計師與QA的溝通，提早在開發時找出可潛在的 UX 問題，提早反映問題並解決
- > Mars: 不錯喔，尤其像你這幾次做了前端的畫面，只有被設計師挑出一個 4 pixel 的問題，Natalie 也覺得你都有照著設計稿在切，很棒，那這個其實就非常好，因為我們有時候後端寫程式的對於調前端畫面其實是覺得滿煩的，那你願意不厭其煩的調整，這樣子給你個讚
- 後端
- Overview:
- 整體是有進步，但感覺只達標 60 %，因為今年下班進修方向偏向 SRE，主要是靠上班時間的經驗累積，達標率比較不理想，如果要達標可能需要投入更多時間在 Design Pattern、重構等方面
- > Mars: 那 Design pattern 這方面其實不用太刻意，因為我們平常寫程式的時候就有默默的在使用了，像我們現在用 adapter 然後在 usecase 注入，其實就是轉接器模式跟策略模式合併使用了，只是因為現在功能和資料來源比較單一，所以沒有感受到這種切換或是注入帶來的好處，但其實你已經是在用了，也要小心常常人們在學到新的東西就會想要運用在工作上，那這樣反而容易導致程式變來變去或是有那種 over design，可以先多瞭解一點之後再來進行
- 實績
- 有了更多在乾淨架構、符合最佳規範等各式經驗，這中間也持續透過實作、code review、設計討論、進修有了更多開發上的進步
- > Mars: 很好，那也希望大家可以多激盪一些新的想法，那目前你是我們這組裡面無論經驗或是能力都是比較頂尖的，那這部分就請你再多麻煩一點帶領其他組員
- SRE
- Overview:
- 整體進步算比較多，體感達成有 70%，下班花了很多時間研究 AWS、k8s、Terraform，中間也透過和 Mars Pair 練習，並再教學給 Member，因為這個 Scope 範圍很大，儘管還不夠深入，但也還有很大的進步空間
- > Mars: 很好，像跟其他組員 one on one 的時候，我也有提到在信賴程度的方面，其實除了專案有問題的時候可以放心交給對方處理，另一方面還有當一個新的技術或是專案來臨時，我第一時間會想交給誰處理，像今天你都有自己私下研究，那不管今天新的任務是你已知範疇或是你沒接觸過的東西，我都會覺得很放心，因為你會自己去研究，那還有另一個方面是你碰的東西也很廣，所以交給你的話能夠更快完成，我也會期許其他組員能夠跟你一樣多觸類旁通
- 實績
- 從 0 自學 k8s，現在能夠做到基本的維運和任務 (e.g. 確認狀態、排查Log、更改資源設定、自己執行 command)，也試著在過程跟 Member 說明了一些概念，讓 Member 能夠有入門概念
- > Mars: 很好！而且你也有想要分享，那最近任務比較忙，TSM 小聚如果沒辦法分享，其實也可以在 Tech Seminar 分享，因為在場的人比較多，可以講更多基礎介紹的部分，然後之後可能 TSM 小聚可以改成 brown bag，讓參加的人是對這個主題更有興趣，並且已經在 tech seminar 有瞭解一些基本的人，或是如果想要在 seminar 分享前先讓組員聽並且給一些回饋也是可以的
- 在去年一整年中，這些面向中你有那些成長 ? 具體的例子有那些 ?
- 理解力
- 理解一個大型需求並思考更多情境
- 在建置 CF 的權限機制時，根據手上有限的需求情報，依過往經驗和網路上的知識，從零建置出整套權限管理機制，並反覆推敲出許多不同角色與權限的排列組合，列出可能發生的潛在問題，提早解決以避免未來安全性問題
- 在開發 CF 的 Site Companion 新對話流程時，雖然還不能在英文會議中立刻理解，但在會後思考以及和 Member 的討論後，迅速理解整套新需求
- > Mars: 很好，因為有時候大家可能會覺得理解力跟對專案熟悉度有關，那你這邊有一個很重要的關鍵就是對未知題目的理解，代表你不是只有在自己熟悉的專案才能夠理解並且思考解決方案，而是不管在任何專案都可以辦到這件事
- 解決問題
- 解決 FusionKB 有時卡住無法 training，透過研讀資料和實驗，找出 OOM 問題，調整資源以避免核心功能異常
- 解決 CF 聊天變慢的問題，至少提升約 20 % 的速度
- 透過 AWS、Terraform、Trello 交叉比對，找出公司 wiki 的錯誤資訊，解決 Member 反映一直無法使用 Tool 連線 Staging DB 的問題
- > Mars: 很好，而且我記得 FusionKB 和 CF 聊天變慢還是在你剛進入專案的時候就解決的，很快就想到問題點，並且瞭解實際執行內容然後解決，這點我給予高度評價
- 獨立運作
- 能夠因應公司需求或是安排，可以自己獨立完成前端、後端或Server 維運的的各種工作
- 也會抽空自己主動進行 enhancement、文件撰寫、確認 QA 測試順暢度等任務外的項目，無需 Leader 安排即可自己判斷要做哪些高價值的項目
- > Mars: 其實下面這點也是我很讚賞你的原因，因為就像寫自動化測試的很討厭寫測試案例，那我們開發的工程師也比較排斥寫文件，當然一方面是時間很趕，那一方面是我們其實習慣用程式當文件，而不是真的寫一份能讓使用者和開發者看得懂的文件，那你這部分就做的很好
- 影響力
- 花許多時間研究 Datadog Monitor，並分享、說明、解答任何開發部門 Member 在使用 Datadog 的問題，讓大家能夠設定更好品質的 Monitor
- 將過往收到的 code review comment 也傳遞給其他 Member，讓 Member 也能收到自己以前收到的寶貴 code review comment 的相關經驗
- 常向 Member 分享對當前任務的時程和品質的衡量點，讓 Member 也開始能自己試著評估如何在時間和品質做取捨
- 在 Leader 忙碌時，向 Member 提出我們可以先做的事，讓大家嘗試在沒有 Leader 的狀況思考可以做什麼，並分工合作完成
- 將自己學到的東西，整理好分享給 Member，讓Member 學到更多，也是著像 Mars 鼓勵我多分享一樣鼓勵 Member
- > Mars: 那你有提到一個很好的點，因為其實我之前也有在 one on one 的時候跟其他組員提過，如果今天別人的 PR 有 with comments 的時候就要去看一下別人留了什麼，不是自己 r+ thanks 就可以了，可以從中學習，那你會主動傳遞給其他 member 我覺得很好，然後 datadog 的設定你在 seminar 有分享，然後 Glenn 平常私下問你你也都會回答，這點非常好，那目前你也是 TSM 分享王，我感覺非常開心，還會主動調配任務讓同儕執行，非常好！
- 溝通
- 向 QA 解說功能和注意事項，也常和 QA 討論如何寫文件、使用工具讓測試更順暢，也讓 QA 理解有些問題原因以及優先度的問題
- 和 Member 解說在 CF 處理過的功能，快速讓 Member 了解前因後果，提升專案熟悉度並讓 Member 的開發更順利
- > Mars: 那跟 QA 溝通這點也是幫了大忙，終究很多時間要查明原因在前端或後端也是需要花時間的，你願意投資時間在幫忙釐清甚至解決問題，我覺得很棒，而且你手上負責的任務還能準時甚至提早完成，高度評價，然後有時候組員忘記的一些 CF 的功能你也會快速幫他們恢復記憶讓他們開發順利我覺得很好，那上面有提過跟其他組介紹專案這點也是一個很好的溝通
- 領導
- 主動從零開始制定 CF API 文件規格，向大家說明 API 文件，讓後端可以有依據可以快速上手撰寫文件，讓前端和 QA 有 API 文件可以確認規格以及注意事項
- 在 Leader 忙碌時，帶領 Member 提出我們應該要做什麼，並和制定今日目標，確保大家有共同目標
- > Mars: 那你也會主動發起組內的會議，並且帶大家專注任務內容跟執行，這點的確就是很高的領導力
- 團隊合作
- 在設計或需求會議中思考並提出特殊案例，讓 Member 思考在這些特殊案例下還需要什麼解決方法
- 提供完整的規格和文件
- 在 CF 的 Permission、Site Comapnion、Impression 可以和前後端分工合作，提供完善的文件、測試資料等
- 減少其他人的工作量
- 一些 Conversation 等功能改成讓後端做，讓前端在工作量大時，不需要多很多額外工作
- 在進行前端任務時，還可以額外幫後端設定好 AWS Mail 服務，並提供文件以及說明設定方式
- 提供建議或指導
- 在以 Pair 方式進行任務時，中間持續提供建議或是假設，幫大家解決更多問題，也能讓大家在對一些問題可以更深入思考，未來相關問題也能更快解決
- > Mars: 那也很感謝有想到在開發的時候能夠多從後端來著手進行一些判斷處理，讓前端執行更輕鬆，尤其是在 chatbot 那邊感覺前端很複雜，所以你願意多花時間讓她們那邊比較輕鬆這點我覺得非常好，從團隊的角度來著手進行，也制訂了 API 文件格式和前後端溝通的規格，很好！！
- 可信任的
- 平常
- 一直持續優化 CF 的 Monitor，提升 Alert 可靠性，讓大家不會被 falsy alert 影響
- 檢查 Datadog 和 Teams 服務，通知大家要升級設定確保 Monitor 正常
- 多次在發現問題後，和 Team Member 一起 SWAT 解決問題，可以彈性負責程式修正、查詢、紀錄、操作等不同 part
- QA 測試遇到問題或是測試困難時，以提供資料、文件、方法、甚至是自己實做一個測試環境 (架網站來 Trainng 和 測試 site comapnion bot)，讓 QA 測試更容易，同時也降低了一些Apify、OpenAI 的費用
- > Mars: 那我的確是非常信賴你的工作能力，無論是開發/維運或是查 bug 各方面我都不會太擔心，那相對的可能會讓你覺得我好像比較冷落你，都是問別人工作內容居多，但其實是因為我太放心了
- 晚上下班後解決臨時問題
- 和 Team Leaders 排查 Cerebro Campaign 設定異常的造成沒電話的問題
- 找出問題客戶網站因為 CF Webchat 擋住頁面影響客戶網站功能，讓同仁更快解決問題
- 今年多次在晚上 SW 有疑似異常時，回報給相關人員，數次減小影響規模
- 有過在晚上人手不足時，臨時和 River 電話視訊協助處理 Samurai 的問題
- > Mars: 這點大家有目共賭，一方面也是晚上有時候發生問題都是非常晚的時候，那你願意犧牲自己睡眠時間來處理這點非常感謝
- Performance
- 全部都有在公司訂製的 ETA 內完成
- 通常可以在拿到需求後就開始設計與開發，有些項目提前知道需求後即可提早開始，這些項目通常會比 ETA 早數天或是品質更好
- 除少數項目受限於時間，通常可以在完成項目之餘，額外撰寫文件、協助QA測試、進行 enhancement、修正沒被安排的 bug，盡可能讓 Performance 最大化
- > Mars: 很好，尤其像有些升級套件這種有風險但是對使用者功能無感好像比較沒什麼 KPI 的 enhancement 你是最積極處理的，甚至在非 CF 專案的時候你連前端的套件都有升級
- 未來的題目
- 想一下你覺得公司內部有哪些問題需要被解決？
- 這題是指公司/部門的問題? 還是自己在公司的問題?
- > Mars: 你目前觀察到我們 RD 部門面臨的問題然後有什麼方面會影響到你，並且你覺得有什麼應對的方法，譬如說像我現在比較專心在做 PO 的角色，你就會轉換一下變成帶大家討論任務並且分配這樣
- 開發/合作上問題
- 團隊風格，譬如說一些用字遣詞上的調整
- > Mars: 因為團隊每個人的個性不同，那我們就盡量求個最大化大家能接受的說話方式，像之前有一次會議上會覺得問題發生的時候不要指名道姓，專心針對問題來做描述，除非是要表揚誰做的好的時候，那有些人可能會覺得她本身不介意，所以別人直接說她做的不好對她來說只是一個提醒，那對某些人來說是責備，所以我們就做一些改善，像我也是漸漸會收斂有一些玩笑不要開，因為其實現在公司專案比較緊，那大家在忙碌的時候比較容易將不開心的情緒放大，當然我們自己本身也會如此，所以就多互相體諒，那相對的，如果別人說了什麼會讓你覺得不開心的，也可以提出來說希望對方怎麼講會比較好
- 成員組成，缺少 PM
- > Mars: 那這部分其實之前公司是也有找過，當然我也有想過說如果 PM 難找，還是我們可以多找開發人員，因為目前把 Leader 抽去做 PM 其實相對的就少了一些開發能量，如果專案在趕的情況下，一種是找人協助釐清規格，或是協助開發，或是你有什麼想法呢？還有你對 PM 的期待任務內容是什麼呢？
- 對 PM 的需求至少要能夠規劃規格，流程圖，至於查找 bug 那些可以先不用
- > Mars: 那如果以後公司會需要找 PM 的時候，也可以瞭解大家對 PM 的想法，這樣也比較容易讓公司瞭解要找到什麼程度的 PM
- 個人風格，讓每個人保留自己一些空間
- > Mars: 那這部分我覺得很好，因為平常會想要 ORID 或是什麼其實也是參考別人使用的一些討論事情的風格，看能不能找出問題點並且聚焦在解決比較重要的問題，那當然這不是唯一解，如果你平常有看到一些其他的方法來面對和解決問題，那也可以在主導會議的期間請大家試用看看那個方法
- 你可以多扮演哪些職責來幫助自己/團隊成長？
- 對團隊的提升
- **領導**: 更主動決定一些事情
- 覺得過往太顧慮主管，擔心自己的決定和主管想要的不同，造成其他 Team 認為只要主管不在我們就無法做事或給時程，應該可以透過確實回報給主管決策依據，並透過每月 1 on 1 和主管確認作法是否妥當
- > Mars: 那這部分一方面也是歸因於我之前管的比較緊，還有有的時候會想說這個 sprint 先讓你們專心衝刺相關任務，後續任務的內容先不透漏太多，導致有時候你們比較不容易回答別人其他任務的問題，像是在衝刺 SSQ 的時候我就比較少提 site companion 的東西，那相對的也導致別人在詢問 site companion 的任務內容時你們比較不容易回答，那你有注意到這個問題想要改善我覺得很好！
- **影響力**: 持續分享自己進修學到的東西，除了驗證自己的學習效果，也能讓 Member 學習，同時也激發 Member 分享的動機
- > Mars: 我覺得這個很好，一方面能提升大家的水準，另一方面其實有時候做一個領頭羊不一定是要最厲害的，而是要讓別人覺得你是最厲害的，如果你會的東西都沒講，那其實別人不會瞭解你有多強
- **溝通**: 多和 Ops team 溝通，了解他們的痛點，向 Leader 反映，如果能自己解決就優先用空擋時間解決，提升 Ops 對我們的信心
- > Mars: 那也希望你不要太累，自己默默在家加班做完，如果 Ops 有什麼問題跟你說的話，也可以跟我講，我會再跟 Chris 確認任務優先順序
- 因為像 Ops team 對使用者回報的一些問題我們這邊都沒處理的話，那他們對我們也會沒有信心
- > Mars: 沒錯，因為他們是面對使用者的，就像我們如果打客服電話結果問題都沒解決我們也會不開心，那他們也是會遇到一樣的事情，那因為目前專案在趕，所以當然是希望先以專案任務為主，那像之前批次上傳跟現在批次停用就我們這邊後端能很快先解決的我們就先解決(不到 30min)
- 對自己的提升
- 持續學習更深入的知識與技能，讓自己有更穩固扎實的實力
- > Mars: 這個我對你有信心

總體戰力值
- 理解力: 4.3
- 之前既有專案熟稔度高
- 新的 CF 跟 Fusion-KB 也很瞭解
- 能理解更廣泛的問題而非單只針對專案任務
- 可以更好:
- 快速思考更有彈性的架構
- 解決問題: 4.5
- 前端/後端/DevOps 皆能自行處理
- 可以更好:
- DevOps 部分，目前較多是自己摸索，之後在實際專案中來驗證能力
- 獨立運作: 4.5
- 獨立思考解決任務的能力強
- 可以更好:
- 卡關的時候能夠及早求助，避免花太多時間在自己一個人思考
- 影響力: 3.8
- 在組內具有領導開發的風範，會開啟和組織會議並帶組員進行開發
- 可以更好:
- 多分享，多制訂一些改善開發流程的工具或是方法讓大家遵從並且流程更順暢
- 溝通: 4.2
- 跟同組的開發成員和 QA 溝通順暢且細心
- 可以更好:
- 團隊外溝通能力，多顧及別人心情
- 領導: 4.3
- 同組內開發的領導人物
- 組內分享最多次內容也最多元的人
- 可以更好:
- 跨組會議的主持
- 有議題時能夠更帶領討論議題
- 團隊合作: 4
- 會分配任務，訂立規格，調整任務執行優先度加快進行
- 可以更好:
- 跟別組合作模式的調整，提早溝通瞭解彼此需求
- 可信任的: 4.6
- 任何新需求及過往專案內容都可放心交付
- 查找 Bug 修復速度快
- 常常監控服務是否正常運作
- 可以更好:
- 各方面能力再更精進
- Performance: 4.5
- 任務準時或是更早交付
- 跟 QA 合作測試及查找 Bug
- Enhancement 效能加強或是套件升級
- 可以更好:
- 功能 Design 的架構以及未來擴充性，讓之後開發任務時間可以縮短

- 上述的所有能力，有哪些是你覺得今年是有成長的
- 解決問題
- 累積 CF 和 Fusion KB 的開發、設計、修正 bug 和維運的經驗後，在面臨不同情境的問題時，增加了解決問題的效率
- 領導
- 當主管在忙時，Member 不確定當前要做什麼，提出大家可以先進行的項目，或是 Member 有想法時，統整意見整理出讓大家認可的進行方式，避免主管不在時，大家會游移不定
- 團隊合作
- 和以往分開開發不同的是，多了很多 pair 的開發、大家聚在一起整合測試，是過往比較沒有的經驗，也了解了些其他工程師的做事風格，進而知道可以採用的合作方式

- 未來的題目
- 上述的所有能力，選三項是你明年會想要比較專注成長的
- 獨立運作
- 更了解商業邏輯，未來有些功能或是 bug 的排查可以先自己進行，節省團隊所需投入的資源
- 加強 Devops/SRE，當有系統狀況時，可以優先自己確認問題，不需依賴主管才能處理
- 領導
- 如果主管在忙，Member 不確定任務方向時，可以帶領 Member 一起協作或是給予建議
- 想出更彈性的方式或回報流程，讓 Member 可以更接受自己的建議，也確保主管可以接受結果
- 影響力
- 提升自己的知識與技能，並能在會議或 pair 時提出系統性的建議，更有根據地說服他人接受
- 其他人今年有什麼地方讓妳感到有幫助妳成長？
- Mars
- 除了分享很多各式知識，也指導了很多開發與設計的知識或或技能，也會怕我們有太大壓力，盡可能優化開發任務的安排與時程
- Tobey
- 很細心學習，對於程式會仔細去鑽研，了解更多知識，並找出大家思考上的盲點
- Tzu
- 進步很多，對於 AI 的 Domain Knowledge 非常熟練，會分享 AI 領域的知識，現在是使用 OpenAI 的高手了
- 你可以多扮演哪些職責來幫助自己/團隊成長？
- 技術貢獻者
- 增進自己的技能，為團隊提供技術
- 領導
- 為團隊提供決策參考依據，加強工作效率

---

## 2024-12-?? (之前寫的)

開始時間:
結束時間:

### 最近一個月主要的工作內容

- 主要工作內容
- [site companion new answer flow](https://trello.com/c/pkpW1Ydf)
- 只有CF 部分是自己開發，FKB 主要都是和組員協作，最後大家一起整合測試
- Enhancement

### 目前合作模式? 對開發有幫助嗎? 有什麼地方變好? 有什麼可以改善的嗎? 有什麼地方需要我幫忙？

- 合作模式
- 11 月因為有重大核心功能，幾乎全部都是 Backend 一起協作進行 (Live share，而非一人寫其他人看)，只有一小部分是獨自進行
- 感覺大家自己的開發習慣或思考方式會影響協作順不順利，也發現一些現象：
- 優點
- 可以讓不清楚專案的人不需要花太多時間了解架構或業務
- 可以讓大家練習去說明對於架構的想法
- 缺點
- 有些寫法大家想法不同，會花非常多時間說服或被說服，拉長了作業時間
- 大家好像沒有看 Error Message 習慣? 直接丟 chatgpt? 這樣中間學習到的東西或機會就變少了
- 有些人個性比較急，想到什麼寫什麼
- 有些人因為不夠瞭解，會堅持要看到輸出 (e.g. dd()) 才能繼續
- 大家對於時間和品質的衡量點不同，在認為某些東西應該要做好，某些東西先應付的意見有所差距
- Live Share 協作只適合在這次重要功能的協作的案例，未來要協作可能還是一人寫一人看比較好
- 每天開始前，給大家一個今日目標 (e.g. 今天第一版、今天上 staging 等...)，可能下班前比較能有個階段性成果
- 以上是個人的 feedback (自己的部分就不確定了)
- 到 12 月現在還是常聽到有人說我們 Backend 在做事、Pair 或開會不能被打擾，但無論其他 Team、QA、需求方來問問題我們也沒有拒絕回答或拒絕提供協助，但不知道為什麼在公司被越描越黑? 被描述成一個不願意溝通的 Team，如果只是因為有人曾經在 "想到什麼問什麼"，多次在 "幾分鐘內一直打擾別人"，而被我們要求先整理好再來問，Leader 能否協助解決這個現象? 如果只是誤會那澄清一下也許就可以解決?
- 開發幫助
- 有了一些以前沒有的長時間多人 pair 做事的經驗
- 變好的地方
- 需要改善的地方
- 需要有方法或流程解決多人對設計或開發意見不同時的狀況
- 需要我幫忙的地方

#### 順利、滿意、進步或做的不錯的地方？

- 順利的地方
- 算是有重啟了 TSM 的分享會，希望可以保持持續進行
- 滿意的地方
- 進步或覺得不錯的地方

#### 不順利的地方，有什麼我能幫的忙嗎？

- 不順利的地方

#### 會想要做更多哪方面的功能？目前做的東西，與自己發展的部份，有無落差？

- 想要做更多哪方面功能？
- 沒有特別想做的
- 目前做的東西與自己發展目標有無落差
- 好像還好

#### 這個月會想要加強自己什麼部分的能力呢？

- 這個月感覺有加強的部分
- 持續下班後或假日進修的 AWS, Devops 有更精進了
- 下個月想要加強的部分
- 複習 k8s
- 會分配一些時間比例到開發，但還沒想要怎麼進行

#### 有什麼可以增加自己工作士氣的方法呢？

- 增加工作士氣的方法
- 加薪、獎金、升遷
- 能有更多決定權 (e.g. 在既有 ETA 下，安排自己的任務順序、進行方式、上線時間等...)
- 感到士氣低落的原因
- 總覺得團隊隔閡還是在加深，現在會議中非任務相關的事越來越不想發言

#### 其他想討論的部份

- 想討論的部分

#### Follow up 上次的 Action Items

- 後端先開發的項目你就跟其他後端開發人員先一起寫簡易的 AC，讓前端後續進來的時候，不用再從頭開始
- 這次變化的大規模比較大，到最後一開始寫的沒有用到，時間緊迫也沒有時間補充非常詳細的文件
- Retro meeting 的時候主動提問文件歸檔/追蹤/維護的問題
- 印象好像以前有問過? 有點忘了，不過最近沒 Retro 會議
- 至少抽空確保 API 文件

#### 這個月的 Action Items

#### Retro

## 2024-11-11

開始時間: 16:20
結束時間: 18:05

### 最近一個月主要的工作內容

- 主要工作內容
- ChatFusion answer rating settings
- Create or update site companion bot
- Site companion answer with answer sources
- Enhancement
- Improving Datadog Monitors
- > Mars: 感謝你幾乎一個人就包辦了 TSM、ChatFusion 的所有設定
- Bot list api improvement

### 目前合作模式? 對開發有幫助嗎? 有什麼地方變好? 有什麼可以改善的嗎? 有什麼地方需要我幫忙？

- 合作模式
- 有獨自開發、Pair 開發、討論等方式，但比例應該可以再調整一下，還是希望保有一些獨自開發的時間
- > Mars: 之後大家對彼此任務比較熟之後，應該就可以多一點獨自開發了，但這次的這個 site companion 回答的這個功能可能還是希望先用 pair，但主要可能會是子瑩來帶你們瞭解下跟 OpenAI 的互動，當然也可以你多一點主導把 node.js 程式改到 PHP 的部分
- Bonus 題目: 如果重來一次，會選擇讓 CL 團隊獨自做完 Intent Detetion 或是跟這次一樣他們做同步 Intent 和 Named Entity，然後我們實作 OpenAI？
- 可以 CL 指派一個人和 CF 後端 pair 開發
- > Mars: 你這個想法也很好，因為他們當初會想做的一個原因最主要也是想要碰 OpenAI 的部分，只是我覺得我們這邊還是要有除了我之外的人能夠對這塊更熟，所以才履次決定讓我們這邊做，當然我也有提說他們可以找人一起 Pair 做，只是後續可能他們也有很多事要忙，所以就沒有派人來 pair
- > Mars: 一方面也是子瑩當初說對 OpenAI 很有興趣，所以我也更傾向於我們這邊要有人能夠獨自處理這塊，如果以後還是遇到相同的困境，我也會再提出來請大家一起思考然後做個決定，共同承擔，那這次也辛苦你們了，在很趕的 ETA 下你跟 Tobey 也是拼命加班趕功能，非常感謝
- 開發幫助
- 每週的會議時間太長，影響開發時程。會議應該著重在設計或 pair，但花費太多時間在 sync、retro、workshop 或討論跟近期任務無關的東西
- > Mars: 那我們一開始的確花了很多時間在 Sync 跟 retro，那因為團隊感覺還有很多不流暢需要磨合的地方，所以 Coomy 跟 River 也很熱心的帶我們做了一些 team building，那其實我們慢慢的感覺磨合的更好，像今天就不用開 release retro meeting，之後如果也都能這麼順暢的話，我們就變成可以減少一些 retro 或是同步的時間，那之後看後續任務的複雜度跟時間，看能不能我跟 Coomy 這邊多一點時間確認一些需求，然後再讓你們一起跟 Chris 討論加強AC 就好
- 變好的地方
- 現在 Release 比以前快
- > Mars: 喔，哪邊感受最明顯呢？
- 禮拜一早上，因為上週確認完，所以就知道只要上 tag 就好
- > Mars: 好的，那也感謝大家都很努力的在前一週就先把 release branch 都準備好，也寫好卡片跟注意事項，在我週一早上開會的時候大家就很順利的把 release 都完成，也配合 QA 測試完，讚！
- 需要改善的地方
- 會議太多或是目的不明
- 希望一週的會議時間不要太多太長，也希望非週五的 workshop 應該是自由參加
- > Mars: 那這次的確有一些 workshop 是比較突然加進來想要讓大家團隊在平時任務執行的時候能夠更互相體諒(e.g. Coomy 老闆娘)，還有建立一個高效團隊的共識，那的確這些會佔用到原先決定要 retro 的時間，反而導致要 retro 的內容沒有被討論到，但之後應該可以先以 retro 為主，看這種 workshop 能不能在中午的時候用 brown bag 來呈現，因為有一些東西的確是挺適合大家一起玩的，像 Coomy 的老闆娘感覺也可以讓其他組一起體驗一下
- 感覺有時候這些 workshop 幫助不大，因為很多事情我們知道要怎麼做比較好，但是不是我們能控制的
- > Mars: 的確，就像減肥或是心靈成長，我也知道我要生活作息正常，控制飲食，運動，但我就是做不到，或是加班太忙影響到作息，但這類 workshop 應該很久才會一次，那也是可以在這個時間聽聽大家的內心一些想法，雖然好像會跟平常 seminar 講的內容有重疊，但慢慢的凝聚共識，內化成平時的行為時，就不用再多花時間來做這些
- 如果會議壓縮開發時間造成進度 delay 進而又要加班，這樣又會被要求 Retro，會是惡性循環。
- > Mars: 可以認同，藉由這次機會我也來思考下有什麼會議是我們真的必需的，雖然以 sprint 來說，跟 PO (chris) 討論需求並且列 AC 然後指定時間交付是正常的流程，但因為我們整體功能也有一個比較明確的 ETA，所以會導致我們在不確定細節的情況下要花時間來確認並且開發壓力很大，那在這種情況下，你覺得有什麼方法會比較好，像是可以節省會議或是討論時間的？
- 限制會議時間，並且不要臨時變更會議目的
- > Mars: 那現在我們有以下會議，那有哪些會議覺得是可以濃縮或是刪減的？
- > 週一 sync meeting, release retro meeting
- > 週二 User story meeting, Retro meeting
- > 週三 Requirement meeting
- > 週五 Release meeting
- 像是 Retro 的應該要限制在半小時內結束，然後 User story 跟 sync meeting 感覺也可以合在一起，大部分會議應該可以在 30 分鐘內解決，但會因為不相關的問題或是不確定的事情導致會議超過一個小時甚至一個半小時
- > Mars: 好的，你的建議很明確，那之後我會更嚴格執行確認大家會議前先填好相關資料，像 Sync meeting 如果平常已經有先記錄，那應該就會很快同步完，還有 Retro 其實這幾次也是等到會議開始大家才填寫，也佔了很多時間，之後我再多注意這塊，那就像你說的，如果我們真的都有把記錄先寫好，就可以大幅縮短等待時間，那有些會議就可以合併了
- 在沒有任何說明下，會議目的突然被變更 (e.g. Retro 變 workshop)
- > Mars: 這個的確有點讓人措手不及，雖然我覺得過程跟結果是有趣跟有意義的，但好像真的我們原先要 Retro 的東西好像就被跳過了，之後可能就請有要更改會議內容的人，先確認本次 Retro 的內容是否有先帶過確認沒問題，這樣如果有人手上有比較緊急的任務，就可以先離席去趕工
- 團隊風氣
- 最近團隊對於 "團隊"、"Devops 精神" 等東西有點狂熱，多了非常多 Retro 和 workshop，討論形式的 workshop 有點太多，覺得對自己沒幫助，而且會覺得這些會議或 workshop 一直強迫我接受一些想法、限制個人的思考方式，而且有時用字不妥，像是一直在指責我們 (e.g. 角色扮演結束時，說我們在老闆和需求方眼中就是這種不合作的工程師)
- > Mars: 我覺得可能先想大家做的事情其實沒有要指責的意思，都是從好的地方開始著想，像那個角色扮演就是讓我們知道平時要多溝通，不用給自己太大壓力，因為我們還在摸索的階段，當然我們會想要先以比較高的水準來要求自己，但這是一個過程，但最主要的就是把產品顧好，像你平常看到 Samurai 跳很多錯誤通知，你會去看內容，發現有沒見過的錯誤就會主動跟該 team 的人說，這個其實就是很好的實踐了團隊的這個概念，反而像有時候如果有人認同這些理念，但是遇到事情卻覺得不關我的事的時候，那這樣是真的好的嗎？感覺你已經有那種成功不必在我，但是有我就會更成功的精神在，那目前雖然團隊人數不多，可是要統整大家的想法還是很難，那 Kos 也是會希望大家用比較正向的情緒來面對問題，像是什麼東西不好，就可以轉念想成怎樣讓它更好，有 bug 發生不是想是誰導致的，而是先修理再來想怎麼避免以後再度發生
- 希望給點私人空間，希望不要在未經同意就在個人座位上張貼東西
- > Mars: 好的，那這個我再跟 Kos 說一下，雖然之前是希望大家都能夠有共識，但是在一些行動上還是要跟每個成員溝通
- 以前工作都不需要特別強調團隊合作就能與他人合作，但不知道為什麼最近都要特別強調團隊合作、溝通、自省，像是我們從未這麼做一樣
- > Mars: 我覺得之前可能因為有時候在開發專案的時候大家想法有一些落差，導致 QA 測試還有跟上面溝通的時候發現大家想法不同，所以需要多溝通，然後因為又是走 Agile，所以會希望團隊之間更加強這一塊，那你平常也都會很積極的接觸一些技術相關的知識跟補強自己的不足，所以可能會覺得自省是一件很自然的事情，但團隊裡面各色各樣的人都有，所以現在做這些，應該是要讓大家都能夠站在差不多的水準，盡量找到一個平衡點
- 需要我幫忙的地方

#### 順利、滿意、進步或做的不錯的地方？

- 順利的地方
- 滿意的地方
- 進步或覺得不錯的地方
- > Mars: 你一直都有持續做的好的地方，就是無時無刻關心伺服器的狀態，然後 Code review 也都很仔細，現在你對 PHP 執行 node.js 的這塊也更熟悉了

#### 不順利的地方，有什麼我能幫的忙嗎？

- 不順利的地方
- 團隊某些功能卡太久，一直被追問，但是功能不是我做的，也不知明確進度
- > Mars: 哪個功能？
- Related questions
- > Mars: 那這是我的問題，我 Code 寫好了但是還沒拆 commit 跟發 PR，然後因為還沒到 milestone 所以就慢慢拖下去，而是先去跟你們討論接下來功能細節，之後我會任務完成就趕快督促自己發 PR，我自我反省

#### 會想要做更多哪方面的功能？目前做的東西，與自己發展的部份，有無落差？

- 想要做更多哪方面功能？
- 目前沒有
- > Mars: 之後會有一些重要事項，看你對哪個會比較有興趣
- > ChatFusion production 要搬到 private VPC
- > Amazon RDS Proxy，目前已經針對寫入的做了，但 replica 的還沒
- > 把一些 node.js 的 code 拉到 laravel (組 prompt, embedding, vector search)，讓 node.js 的專心做跟 LLM 串接就好
- > 前端 build 好的 snippet code 放到 CDN
- > 假設上面四個任務同時要開始，你會想要先做哪一個
- 1 or 4 搬 VPC 或 CDN 會比較有興趣
- > Mars: 好的，第 4 個任務搬到 CDN 的會比較急，那剛好前端也想要碰這塊，就大家一起速速弄
- 目前做的東西與自己發展目標有無落差
- 還好，但感覺又要調整一下發展方向，因為最近工作幾乎是純後端，沒有前端也沒有太多 Devops，但今年進修方向都是 Devops 為主，很難在工作中看見成效，而且現在前端架構太複雜，和我想要偏應用的前端不太一樣，今年 Devops 收尾後會再思考一下各方面技能的投資比例
- > Mars: 那後端開發方面可能會想往什麼方向學習呢？
- 可能會朝資料結構、演算法、Design Pattern 的部分進行
- > Mars: 那 DevOps 的確平常比較少碰到，但先準備好你的武器，之後一些搬移 VPC 或是 SOC2 的時候就可以有多一個戰力來實作跟討論
- 外面有一些相關的課程，但不確定實不實用
- > Mars: 之後如果有要做 SOC2，應該就會找 AWS 的 TAM，到時候看能不能請他們那邊來做個培訓之類，會更貼近我們實際應用來做講解，感覺更實用

#### 這個月會想要加強自己什麼部分的能力呢？

- 這個月感覺有加強的部分
- 一些 k8s、有了解更多 AWS Service
- > Mars: 感覺我們週五下班前的實作好像要準備繼續開始了，之前在趕專案都犧牲掉了
- 下個月想要加強的部分
- 應該繼續 AWS Service，一樣預計今年底收尾
- > Mars: 加油
- 可能補一下開發相關的東西，還沒決定進行方式
- > Mars: 有開發相關的也可以找我或其他成員一起來個讀書會
- 有想過一個月兩次的 TSM 小聚，準備比較小的東西來分享

#### 有什麼可以增加自己工作士氣的方法呢？

- 增加工作士氣的方法
- 沒特別想法
- 感到士氣低落的原因
- 漸漸習慣了

#### 其他想討論的部份

- 想討論的部分
- Member 對於事情的決定權可到多少?
- 如果 Leader 請假，被問時程或架構，Member 是可以自己決定時程怎麼安排嗎? 如果是 Leader 沒請假，在公開會議或私底下，Member可以給自己安排的時程? 會問這個是因為有人覺得我們 CF 後端只要 Mars 不在就會整個停擺，無法給時程、架構、功能等，主要是不確定權責歸屬，不敢貿然給答覆
- > Mars: 主要是一開始你們對 ChatFusion 和 FusionKB 都還很不熟，尤其是 Fusion-KB 是近期功能才開始碰的，那它複雜的點是在 Laravel 串 node.js 串 OpenAI，所以很多時候我已經有解法了，我會覺得直接帶著你們討論比較快，那像最近子瑩做完 intent detection，那其他額外相關功能就是她決定時程我也覺得 ok，那像你們對目前很多功能也都瞭解了之後，我覺得他們直接問你們，你們是可以決定時間沒有問題了，如果一開始就是放你們不管，讓你們自己去討論跟決定時程的話，其實會花太多時間在看 code，然後估時間也會太樂觀或太保守，所以才一開始我管比較多

#### Follow up 上次的 Action Items

- 後端先開發的項目你就跟其他後端開發人員先一起寫簡易的 AC，讓前端後續進來的時候，不用再從頭開始
- 好像現在都是大家一起寫，頂多我偶爾先開好 Loop，簡單寫一點東西
- > Mars: 那這樣也很好，避免都同一個人在寫，現在大家都會維護文件這點其實 Yuris 也是讚譽有加，而且大家一起寫文件，也多少還避免了之前有人沒看 AC，只憑開會的時候的印象就開發功能
- Retro meeting 的時候主動提問文件歸檔/追蹤/維護的問題
- > Mars: 很好，感覺大家的文件也歸檔的越來越有條理了

#### 這個月的 Action Items
- 之後開會會要求大家先寫好內容，那如果你發現有人寫的內容不太容易理解，主動詢問一下對方內容是什麼，並且在聽的過程中，看能不能也寫一版自己覺得容易理解的方式
- 你有想好本季 tech seminar 分享的內容嗎？
- schedule monitor + datadog 設定經驗

#### Retro
- 思考會議如何加速跟精簡
- 瞭解會議和workshop的用意，並降低負面情緒
- 看別人預先寫好的會議內容並且詢問不清楚的地方