圖片來源：ChatGPT 生成
今天聊個非技術的話題，一番趕工後，有個功能大改版準備上線，雖然整體 UX 在內部已經討論和修改過許多次，但我個人仍有點擔心，這個新設計會不會太複雜導致使用者卡住？那要怎麼知道？因此，這幾天我的主要工作是在研究怎麼埋事件，然後送到 Clarity 和 GA 讓 designer 可以做研究分析。
當團隊開始成長，工程師的分工越來越細，但對我來說不確定是好事還是壞事，有人可能喜歡專注在他擅長的事情。但我自己的觀察，當分工越細時，工程師容易像貓一樣，待在舒服的紙箱裡，對於外界的事物不太關心，工作時只是把需求轉成可以用的程式碼就結束了，這程式碼是不是變成有用的產品，就不見得是每個工程師都會在意的事了。
自己從零開始後，雖然很多事情都要自己來，不敢說現在的團隊文化很棒，但我很慶幸目前的團隊是會想讓數據說話的團隊，會關注下面幾種數據的團隊：開發數據
前陣子在社群公開了團隊在 2025 的工程成就，裡面就提到了幾個和開發相關的數據：測試涵蓋率、自動佈署所需要的時間等等。開發相關的數據其實還有很多，在團隊一開始就要求收集所有的數據不切實際，但如果是一個希望進步的團隊，就會開始慢慢增加相關的數據收集，不然怎麼知道是不是真的有進步呢？
目前，測試涵蓋率是我比較在意的數據，因為團隊裡工程師就兩個人，也沒有 QA，測試是團隊大家一起測，也不可能每次改版就跑完整的回歸測試，大多是憑感覺測，因此，單元測試和整合測試，反而是我每次按下 Merge 觸發自動發布到正式環境的底氣。
早期還在用 Eclipse 時，我很喜歡一個套件：Metrics，它可以分析專案的各式數據，其中一個我很喜歡：函式複雜度，它會算出一個數字，並提醒你某個函式太複雜了，然後我就試著去拆解函式，這讓我養成寫小函式的習慣，很可惜我已經沒有使用 Eclipse 了，而這個套件我也沒有找到 Visual Studio Code 上的平替，有點可惜。
這裡有個地方要注意，任何數據的收集，最好是團隊自己認為有用的數據，如果團隊認為是高層要求的數據，那團隊只會為了應付而產生數據。管理者真的想要什麼數據，首先要做的，是要讓團隊相信這數據對團隊是有用的。像是 Metrics，我認為有用，所以我會去算，但如果別的工程師認為沒有，強迫使用是沒有意義的。
工程營運數據
去年農曆年過後，產品上到正式環境，第一件事就是把工程營運的儀表板建起來，雖然 GCP 內建許多儀表板，但各種資源的儀表板散落各地，其實不太好用。以我們的需求建立儀表板才是最適合的，目前儀表板可以一次看到
- API Response Time
- API Error Rate (5xx)
- API Pod CPU Usage
- API Pod Memory Usage
- Database CPU Usage
- Database Memory Usage
- Database Connections
- Database Transactions
- Pending Notifications
- Notification Delay
- Pending Reminder Jobs
這些數據不是好看而已，還有設定警示條件，例如：API Error Rate 超過每秒 5 次，就會發送警示到指定的 Slack 頻道，或是 Notification Delay 超過 10 秒也會發送警示。
除了警示，這些數據也是優化營運環境的根據，例如，依照今年業務成長的預測，需不需要調高資料庫的機器等級？要不要多開幾個 pod 來應付流量，如果沒有上述的數據，其實只能用猜的。
而且這些數據也會反向影響開發，例如，今年打算使用 domain event，更進一步將程式解偶，那是每種不同的 domain event 都有對應一個 pod 實體比較好，還是為了省錢共用一個 pod 實體其實也撐得住，這些數據能幫忙做出決策。
這幾年，devOps 盛行，上面這些數據，感覺反而離開發工程師更遠了，很多開發工程師認為那是 devOps 工程師的事，事實上，這恰恰違反 devOps 的核心精神不是嗎？
產品營運數據
產品上線後，我建立的第二個儀表板是產品營運的數據儀表板，礙於數據的內容不方便公開，就不放上截圖，但可以分享我建立了那些數據儀表板：
- 帳號建立數與實際使用情況 (7 個儀表板)
- 各項功能的使用情況 (每個功能大概都有 3 ~ 4 個儀表板，合計超過 40 個儀表板 )
- 各項功能的使用趨勢 (4 個儀表板)
這些儀表板不是一次就建立完的，是每次新功能上線後，我就會更新儀表板或是建立新的儀表板，像接下來的大改版，對應的儀表板就要大調整了。因為有這些儀表板，我們在 2025 年快結束時，很開心地發布：我們協助客戶完成了百萬小時的班表發布。
這些儀表板本來是要做個專屬的 console 網站，但考量到人力，最後是用 retool 開發的，把需求告訴 ChatGPT，請它產生 SQL Statement (AI 在產生 SQL Statement 的品質上我個人認為蠻不錯的)，然後套用到 retool，拉個圖表元件，完成，數據的內容比用什麼技術完成更重要。
這些數據除了可以知道公司目前產品的營運狀況，其實也會反映回產品的開發，前陣子，團隊在討論某個 UI 選項到底要提供幾個選項給使用者時，與其瞎猜半天，我打開儀表板，直接找到數據，平均使用者只會設定 n 天，搞定，完全不用猜。
相較前兩類數據，工程師比較少關注這類數據，即便這類數據不需要其他人幫忙整理，工程師自己就可以從資料庫挖掘出來 (只要注意 SQL Statement 的效率，別把資料庫打趴就好)。
題外話，為了讓這些數據更容易收集，有時候也會回頭調整 schema，例如在原有的欄位外，加上統計用的額外欄位，像先前我就為了加速比較，加了一個類似 hash 的欄位，不用拿整個 jsonb 來比較，這樣的小調整，讓原本要執行 10 秒的查詢，瞬間就減少到小於 1 秒。
目前，我還會每週將上述數據整理成週報，讓團隊知道目前產品的狀況，若發現異常時，會在 review 時，讓大家討論一下，看要不要進行產品調整。
使用者體驗數據
這是今年的挑戰，經過去年一整年的努力，系統的完整度越來越高，我們始終在功能的彈性與 UX 之間反覆調整，希望降低系統的複雜度，但今年要加入更多的功能，這挑戰就更大了。此時，designer 推薦 Clarity 這個工具，使用後真的覺得很方便。
如何知道使用者體驗的感受？實地訪談，這個我會另外寫一篇，但實地訪談也是有限制的，光是和客戶約時間有時就不是那麼容易，那剩下就是在 UI 埋事件，所以本文的一開始就提到，這幾天我的工作就是埋事件，然後送到 Clarity。
事件基本上也不是亂埋，不然事後整理其實也蠻麻煩的，而且有些分析的雲端系統是以事件數量收費，那會造成不小的開銷，所以在開始埋之前，要先對擔心的事情是什麼 (why)？影響的對象是誰 (who)？然後思考怎麼了解使用者 (how)？最後才是要埋那些事件 (what)？
以下圖為例，我擔心的是新的操作流程會不會太複雜？導致使用者沒有辦法理解最後沒有完成送出的動作，所以在整個流程的幾個關鍵節點，都埋了事件，最後就可以用漏斗圖看，有 28.57 % 的使用者從第一步驟順利到第二步驟，有 75% 的使用者從從第二步驟順利到第三步驟，雖然這是 beta 的測試資料，但或許第一步驟某個環節出了問題，讓使用者卡住了，最後放棄。
使用者行為分析漏斗圖
有了這些數據，我們依然是在猜使用者為什麼卡住了，但至少是有根據的猜測，而不是瞎猜的。相較於產品營運數據，這更是工程師較少接觸的數據，感覺那是 PM 或是 designer 才需要知道的數據，但我不這麼認為，想要做出好的產品，這些數據是很重要的。
文化的建立
我不認為所有的工程師都是冷漠不關心，但如果團隊變成一個冷漠的團隊，我認為負責建立團隊文化的管理者，要負最大責任，例如，常常在討論過程中用「你這是工程師思維」去反對對方的想法，就算對方的想法真的不好，這句話本身是沒有建樹的用語。
又或是工程團隊總是要到開發時，才參與到討論，那自然而然，工程師就會慢慢調整自己的角色，變成只專注在把需求轉成程式碼的工作，需求本身是不是有問題，也不會在意了，表面上看起來團隊效率很好，但可能交付錯的東西最終白忙一場。
前面有提到，要讓團隊去收集並了解這些數據，前提是要讓團隊相信這數據是有用的，目前上面的所有數據，沒有一項是我要求其他人去收集的，都是我覺得有需要或是其他夥伴認為有需要，然後我們就去收集，再來檢討有沒有用。
希望目前的數據文化不會因為團隊變大，分工變細後消失，但誰知道呢？我想我能做的，就是常常地分享數據，讓團隊知道數據的價值，這也是我每周都會發布營運周報的原因了。
小結
冷漠的文化對團隊是很傷的，即便如此，我仍是建議待在這樣團隊的工程師還是養成關注上述數據的習慣，讓自己不是寫程式的工程師，這在 AI 時代看起來會越來越不值錢，要讓自己變成能開發出好產品的工程師，更具跳槽的本錢。
