#5 更喜歡 Do things right
10 min read
這週回顧前一陣子大功能的上線,覺得如果可以有更多功課可以做的更深入。
有趣點子
❶ 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
文內也有詳盡的分享每天上版歷險記:
- 開始部署以及發布 release note
- PM, QA 做最後驗收,看有沒有任何 Hotfix
- 準備下一個 Build,包含:merge 前的 dependency 檢查
danger 除了同一個 repo 外,前後端之間的搭配、data 格式也需要確認
- 針對下一 Build 進行測試,包含:既有功能測試、新功能測試
- 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 路線大概是技術人員心裡最柔軟的一塊(X)
這篇文章提到即便往主管職走,還是有下列這些方法可以維繫著自己的技術能力:
- 確保自己的程式技能:做一些與功能並非直接相關的開發,但可以提昇團隊生產力的工具、清理技術債、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,自然能做到收斂。