這些習慣會讓 Lantide 白裝
團隊上了 Lantide，若業務 / 運營仍用舊習慣要數，Plan / Execute 邊界會形同虛設。下面是試點裡最常見的六種反模式。
反模式清單
| # | 反模式 | 為什麼痛 | 改怎麼做 |
|---|---|---|---|
| 1 | 口頭改口徑，Plan 沒批註 | 會議說定了，檔案沒改，Execute 仍跑舊定義 | 改口徑 → 必須 Plan 批註 + Resolve |
| 2 | 催「先 Execute 再說」 | 正式數字基於錯口徑，返工成本更高 | Execute 前確認六項檢查（見 審 Plan） |
| 3 | 拿 Quick 截圖進週會 / 財務 | 無 Plan、無 limitations，追問無落點 | 標註非正式，或升級專案走完 Execute |
| 4 | 只改 Report 文字，口徑其實錯了 | 數字與定義仍不一致 | 口徑錯 → 新 Plan 重跑 |
| 5 | Plan 改了三版，群裡還轉第一版截圖 | 多人依據不同版本決策 | 以專案內最新 Plan / Report 為準；群裡只發連結 |
| 6 | 只改 HTML 上的數字、Report 沒重跑 | 對外口徑與正式分析脫鉤 | 算錯 → 新 Plan；HTML 只改呈現（見 Report 轉 HTML） |
| 7 | Resolve 後從不 Archive | 右側批註面板堆滿已處理卡片，難找 open 項 | Resolve 確認無誤 → Archive；需追蹤歷史用 View changes |
與團隊規範對照
PM：試點與推廣 Step 3 建議的最小規範：
- 對外數字必須來自 Executed Report
- Execute 前 Plan 必有人審
- Quick 結果標「非正式」
業務 / 運營是這三條的 主要執行者 — 你拒絕接受不合規的數字，比事後追問更有效。
你現在可以做的一件事
跟分析師對齊一句話：「我要對外用的數字，請給 Executed Report 連結或 HTML；Quick 截圖我只當參考。」