這週回顧前一陣子大功能的上線，覺得如果可以有更多功課可以做的更深入。

有趣點子

❶ PostHog 開源產品數據分析工具

最近在研究產品數據的技術方案，從 server side tracking 到 client side tracking，從現成方案到自幹一套，想來想去覺得應該要先來看看現有的工具到底都怎麼做這一條龍的 data pipeline，因此剛好看到這個開源的 PostHog 工具，因為是開發人員導向，對於工程背景的人來說也比較好研究起。

試玩看看

❷ Workspace 打造你的工作空間

在推特上看到推友分享的電子報，與一般 Instagram 上的 desktop setup 有所不同，Workspace 電子報會介紹一點關於工作空間的背景與使用設備，這對於工作空間控來說也太推坑了吧。

試逛看看

❸ RefactorJS

目前資料量還不多，但覺得很有趣的題目。前陣子開始清理自己的筆記，發現一大堆 Snippet 應該換一種管理方式，後來轉用 Webstorm 跟 Raycast，隨手將覺得寫得好的程式碼存進 Github Gist 之中，不久剛好就在 Product Hunt 看到這個點子（吸引力法則？）貼一則醜扣，發揮群眾智慧得到更好的重構，未來如果可以先有測試就更完美了！

試玩看看

讀了一些

❶ 在 CI/CD 之前先從 Release Management 看需求

最近從一個大功能成功下莊（菸）從工程的角度看 CI/CD 都會覺得是一直上版一直爽（並不是），但其實真的要理解的是 release management 才發現這些技術是為了解決什麼問題，以下是三篇文章的重點整理。

在第一篇 產品上線管理：寫給 PM 的基本名詞解釋與工作流程. 前陣子在 PTT 看到關於 Release 週期的討論，底下推文從一天 n… | by Anne Hsiao | 3PM LAB 產品三眼怪實驗室 | Medium 中，雖然對於工程師來說可能非常日常，但其實是非常需要跟其他部門溝通的重點：

• Deployment
• Release
• Phased Rollout、Staged Rollout
• Full Rollout、Rollout to All
• Product Launch
• Rollback
• Hotfix

文內也有詳盡的分享每天上版歷險記：

1. 開始部署以及發布 release note
2. PM, QA 做最後驗收，看有沒有任何 Hotfix
3. 準備下一個 Build，包含：merge 前的 dependency 檢查

danger 除了同一個 repo 外，前後端之間的搭配、data 格式也需要確認

4. 針對下一 Build 進行測試，包含：既有功能測試、新功能測試
5. Final Check 測試狀況，決定是否要繼續 release，還是 revert 部分功能。

到了第二篇，產品上線規劃：分階段釋出網路產品的實作流程與工具 | 3PM LAB 產品三眼怪實驗室 開始更詳細的介紹如何做分階段釋出這件事，從工作的顆粒度開始分起 release 的含義，剛好在團隊內也是採用 Github 非常有感：

• Tickets (Issues) : 可以被內驗證的最小單位 e.g. code review, QA 測試。
• Epic (Milestone) : 可以被「對外」驗證的最小單位 e.g. 可以被使用者驗證、商業驗證的釋出。

其中，當一個個 Milestone 被完成後，接著就會需要決定怎麼 release：

• Alpha 內部測試：在正式環境由內部人員來操作確認沒有問題

note Alpha 也可以讓特定精熟使用者以資料刪除為前提來進行，可以收到更多使用者端的回饋，而不只是功能的問題。

• Beta 公開測試：由一小群使用者來使用進行測試

note Beta 也可以透過風險告知 e.g. Chrome 實驗性功能的做法來對功能進行公開測試。

• A/B 測試：隨機使用者測試，針對不同使用者釋出不同功能，來觀察功能是否有成效。

對於上述的規劃進行排程以及預期要驗證的目標，也可以被好好記錄下來：

caution 會想自己有遇到的狀況：Change Log vs Release Note 差異在於 Change Log 更接近技術端讓測試跟工程知道這次有哪些內容，Release Note 則是商業端，讓大家知道這次會「影響到哪些行為」。

以上的不同測試，可以透過 Feature Flag - 開關特定功能讓特定使用者使用的方式來進行實作，在第三篇文章 產品上線規劃：Beta Release、Feature Flags 實作經驗與工具分享 | by Anne Hsiao | 3PM LAB 產品三眼怪實驗室 | Medium 有詳細描述：

Feature Flag 很適合用在有一個大型 Epic 需要上線，怕會有出錯的狀態、又或者想讓使用者慢慢適應，以及一個不確定的解法中。核心精神就在於：

能不能在影響最小的情況下，就儘早收到回饋，儘早調整。

所以可以透過收集鐵粉、曾經的訪談者或者就是這次新功能的核心 TA 透過 Feture Flag 來讓他們進行測試（並給予回饋）。

caution 曾經踩過關於移除功能的坑，有時上一個功能代表一個功能的消失，也許有些功能用量很少，但使用的人可能是非常喜歡的使用者，文內建議要強制更換新版前：一定要寄送通知、給予寬限期、細心處理 Data Migration 並且分階段的慢慢改版，盡可能減少使用者的痛點。

閱讀系列文章

❷ 管理工作怎麼兼顧技術 QAQ

有幸前主管耳提面命一句話：「自己不必是技術最強的那個人。」每當在思考類似的議題時，都會不停地透過這句話來驅趕心魔，相信要走 IC 路線還是 Manage 路線大概是技術人員心裡最柔軟的一塊（Ｘ）

這篇文章提到即便往主管職走，還是有下列這些方法可以維繫著自己的技術能力：

• 確保自己的程式技能：做一些與功能並非直接相關的開發，但可以提昇團隊生產力的工具、清理技術債、code review 、打造 POC ...
• 協助增加團隊知識交流：整理大家的經驗來確保自己吸收到大家的經驗，像是：寫文件、Pair Programming 或者技術分享會 ...

閱讀文章

❸ 若有幸重來一個大功能

除了前者提到的 Release Management 外，更前期對於功能要有更好的 MVP 思維，才有辦法思考更好的 Release 規劃，於是重新研讀了 Heptabase 的一張關於 MVP 的寶藏地圖 找了對應的 YC 資料來閱讀，有幾個重點覺得是現在的自己可以多把握的：

Launch Quickly !

• Get some initial user : 對於已經有既有產品的服務來說這是一個時常忘記的問題，哪怕是一個新的大功能也應如此看待，找到這個功能的一群初期使用者與他們對話，然後迭代。
• Launch something bad, quickly : 有時快速釋出害怕的是搞砸一切，但你得釋出才有辦法得到使用者好的建議，並找出問題解決他們。
• Build an MVP extremely fast : 在釋出前任何事情都有可能改變，所以我們需要定義清楚來避免發散（並非鉅細彌遺的規格書）透過訂出時間、寫下預計功能在兩者相輔之下：cut off your spec，自然能做到收斂。

觀看影片與相關文章