上個季度，我接手了一個“敏捷”項目。之所以給“敏捷”打上引號，是因為在項目初期，我們的狀態是：用着最敏捷的理念，進行着最混亂的折騰。 這是一個社交類App，市場窗口期很短，要求我們快速迭代，快速驗證。理論上，我們應該每天都在“開發-測試-反饋-優化”的正向循環中。但現實是，我們團隊大部分的精力，都耗在了“開發”與“測試”之間那段泥濘的道路上。 混亂的序章：當“
每個季度末，我們團隊都會做一次覆盤。通常，我們聊的是線上Bug、項目延期、或是某個新技術帶來的收益。但上個季度，我把一個看似“雞毛蒜皮”的話題放到了會議桌上：我們的內測App是怎麼交到產品和測試手上的？ 起初，大家覺得這沒什麼可聊的。“不就是用釘釘/飛書發個文件嗎？” 但當我把我們團隊一個月的“隱性時間消耗”估算出來後，會議室沉默了。 我們是如何“默許”
我一直覺得，一次真正有效的 應用內測，應該像一場安排周到但不打擾彼此的聚會。週五晚上，我們準備把新版本灰度給三十來位種子用户。大家各自關掉工位燈，Slack 裏只剩“上線吧？”這一句。我把安裝包打好，寫完 Changelog，開始思考最麻煩的那一步：app內測分發要怎樣發，才能既不打擾人、又能收回有用的反饋？ 以往我會把鏈接甩進羣裏，附上一句“隨便用用”。結果一晚上只收回“
