從 0 到 1 的最後一步：怎樣做一次能指導下一部作品的復盤

真正有用的復盤不是慶功會或究責會，而是把計畫、實際、證據和下一次規則連接起來。它最終應產出三類資產：繼續保留的做法、必須改變的系統、下一個專案開工前要驗證的假設。沒有負責人和觸發時機的「經驗教訓」，很快會被遺忘。

可以分兩次進行：上線後幾天做營運復盤，處理阻斷問題與協作壓力；數週後在銷量、完成情況和回饋相對穩定時做專案復盤。每次提前收集時間軸、預算、版本、缺陷、測試、資料與使用者證據，會議不靠記憶爭論。

讓各職務先獨立寫：原目標、實際結果、最大意外、一個應保留與一個應改變。匿名收集敏感問題能減少權力影響，但結論仍需公開將責任歸屬到流程負責人，而非匿名地消失。

拿出立項時的玩家承諾、範圍、不做清單、預算與成功指標，逐項比較。哪些兌現，哪些主動修改，哪些未經決策悄悄漂移？專案結果不錯也可能過程無法複製；市場結果一般也可能證明了重要假設。

區分產出與成果：拍了 200 分鐘是產出，玩家能理解並願意重玩是成果；做了 12 個結局是產出，結局回收選擇是成果。復盤圍繞成果解釋產出是否值得。

從選題、核心循環、劇本、原型、前期、拍攝、後期、整合、測試、發行到營運逐段檢查。每個問題至少追問：首次可見訊號何時出現，為什麼當時沒處理，哪項流程或誘因讓它繼續，最終造成什麼影響。

避免把系統問題歸結為「某人不細心」。檔案接錯若因為沒有穩定 ID、沒有自動驗證和沒有明確的權威清單，提醒個人只會在下一個專案重演。相反，也不要用「流程問題」模糊實際決策；記錄誰有權在何時改變它。

創作查看選項理解、角色承接、節奏、結局與重玩；製作查看不重複的影片分鐘數、拍攝效率、補拍、重工和資產錯誤；技術查看切換、存檔、效能與工具；商業查看商店轉換、願望清單、退款、評價和支援成本。四者放在同一時間軸，才能看見因果。

例如玩家抱怨分支無效，可能源自劇本太早匯流，也可能是預算刪掉回饋鏡頭、現場漏拍出口，或程式載入錯誤總進同一影片。復盤不能只讓最後接觸問題的職務背鍋。

保留項必須說明適用條件，如「三分鐘垂直切片在技術未知程度高時保留」；停止項要指出替代做法，如「停止在群組聊天確認素材，改用帶校驗值的資產清單」；嘗試項寫成可驗證實驗，如「下一個專案先用五個節點測試直向螢幕選擇版面」。

每項指定負責人、執行時機和完成證據。把「加強溝通」改成「每次定稿由製片發布影響表，四個職務在 24 小時內確認」。越具體，越可能改變下一次行為。

更新節點卡、變數表、分支預算、狀態卡、場記單、編碼預設、測試矩陣和發布清單。範本註明版本、來源專案與使用條件；下一個專案啟動時先質疑它是否仍適用。最佳實務是目前證據下的預設值，不是永恆法律。

封存最終建置版本、原始檔案、授權、存檔樣本、資料字典、儀表板定義和關鍵決策。確保新成員能找到並理解，而不是只有原負責人知道某個雲端硬碟目錄。

列出沒有得到答案的問題：直向螢幕使用者是否更喜歡短選擇？雙播放器在低階裝置是否穩定？某類結局是否促進重玩？按影響與不確定性排序，最高項進入下一個專案的原型，不要直接進入大規模製作。

同時記錄已被證偽的假設，防止團隊換個名字再次投入。證偽不是失敗，它把下一次範圍變得更清晰。

會議結束不等於完成。兩週內發布復盤文件、更新範本與流程、建立負責人可追蹤的行動項目，並在下一個專案立項會上逐項檢查是否採用。若某項決定不再執行，記錄新理由，而不是默默遺忘。

最後保留一頁專案地圖：從一句玩家承諾到成品、最重要的五個決定、最大的三個偏差和下一次首要驗證。它比幾十頁流水帳更能幫助新團隊理解歷史。

下一步：安排兩小時專案復盤會，要求所有人會前提交證據；會議只決定五項最重要的保留、停止或嘗試，並把它們直接寫入下一個專案的範本與開工門檻。