#5 更喜歡 Do things right

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

有趣點子

❶ 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 格式也需要確認

  1. 針對下一 Build 進行測試,包含:既有功能測試、新功能測試
  2. 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,自然能做到收斂。

觀看影片與相關文章


訂閱電子報

Start-Up Comedy 是目前嘗試中的寫作計畫,希望分享一些新創有趣的地方,讓 c-level 之外除了鬼故事外有一點陽光。


會不定期分享一些看到的有趣內容、產品使用心得跟同時分享新創生活中的故事。