LaunchCal

在所有審查單位之間協調發布。發布負責人取得自動產生的檢查清單，審查者擁有清楚的佇列，利害關係人則能看到行事曆。

為什麼需要它

靈感來自 Google 的做法：保留真正有用的部分，捨棄只有在那種規模下才行得通的部分。

你會得到什麼

• 依職能團隊設定的發布步驟範本
• 可核准、駁回或核准例外的審查者佇列
• 新聞稿、儀表板與心得文件
• 供利害關係人檢視的發布行事曆與步驟甘特圖

運作方式

1. 1每個單位只需寫一次自己的步驟法務、隱私、資安、客服、行銷：凡是需要檢視發布的單位，都維護一份範本，寫明自己需要什麼、何時需要。寫一次，就適用於之後的每一次發布。
2. 2發布負責人描述這次發布填寫它是什麼、會影響誰、預計何時推出。檢查清單會從適用的範本自動產生，所以不必先了解流程也能照著執行。
3. 3審查者處理自己的佇列每個單位都能看到等待自己處理的步驟，並附上理由核准、駁回或核准例外。發布負責人不必追著任何人跑，就能看著整件事往前推進。

團隊怎麼使用它

• 趕一個已經延誤過一次的期限

  行事曆會顯示哪些步驟正在卡關、卡在誰手上，讓討論聚焦在真正的相依關係，而不是誰忘了回覆。

• 帶領第一次負責發布的人

  他們不需要那些口耳相傳的經驗。檢查清單會告訴他們有哪些要求，例外記錄則會告訴他們哪些項目被豁免及原因。

• 回答「這一季會推出什麼？」

  發布行事曆和步驟甘特圖就是答案，而且永遠是最新的，因為它們就是發布負責人正在使用的同一份資料。

常見問題

我們需要改變現有的發布方式嗎？

不需要。步驟範本描述的就是你們現有的流程：LaunchCal 是存放它的地方，而不是另一套流程。多數團隊會先寫下目前已經在要求的事項，再經過一兩次發布後逐步調整。

某個步驟不適用時該怎麼辦？

由審查者附上理由核准例外。這會記錄在該次發布中，而不是被默默略過，下一個想知道原因的人就能看到答案。

利害關係人沒有席次也能查看發布嗎？

席次是給實際執行工作的人使用的：發布負責人和審查者。公司裡大多數人想看的是行事曆，而查看行事曆不需要席次。

這和我們的問題追蹤系統有什麼關係？

問題追蹤系統管理的是工程工作。LaunchCal 管理的是核准和日期，也就是通常散落在聊天訊息和試算表裡的那一部分。