只賭你控得住的:三層受控性 + retro 把失敗串回目標階層
計畫從來不缺野心,缺的是誠實。
最常見的錯法:把「等客戶回覆」、「等審核通過」這類事項列進 KVM——目標指標——然後月底 retro 發現沒達,寫一行「外部因素」帶過。下個月同樣的事再出現。
問題不在執行力,在規劃時沒切清楚一個問題:這件事我控得住嗎?
三層受控性
我把計畫裡的每個 item 都標三個等級:
① 自己可控——純自己執行,不依賴外部。寫 code、整文件、內部 setup 都是。這種項目 100% commit,沒達到就是真失誤。
② 需對方配合——我能推進,但節奏依賴對方。跑 walk-through、推客戶簽名、跨團隊對齊都是。這種可以押,但要留 buffer,retro 時要分清是「我沒推」還是「對方卡」。
③ 純等對方——我的推進力是零。等簽核、等付款、等政府補助都是。這種列成 side bet,不進 KVM。
這條線的重要性在:把③算進 KVM,計畫永遠跟現實對不上——不是因為你不夠努力,是因為你把自己控不住的事當成了自己的責任欄。
計分也要誠實
規劃時切清楚可控性,計分時還有另一個陷阱:文字平權是自我欺騙。
所有軸取平均——達成 70%。聽起來及格,但如果這 70% 全來自「全自控、repo 內、不依賴任何人」的軸,而真正攸關生存的軸這個月是 0,那個 70% 只是在灌水。
正確做法是按處境加權:你今天最重要的事是什麼?把那個軸的權重拉高。然後並列兩個分數——處境加權分 vs 文字平權分——讓自己看到差距。
同時強制自己問一個問題:這次達成的是不是全是「easy-axis pass」?全自控、沒有市場動作、repo 內就能解決的——那個 pass 是真的推進了,還是在安慰自己?
retro 不只是重排
Sprint 沒達標,最常見的處理是把 items 挪到下週。這是不夠的。
目標分層是有結構的:Company Vision / Mission → Product Goal(有指標的)→ Sprint Goal → Daily。往下拆是規劃;往上問是 retro 的另一半任務。
Sprint 未達 → Product Goal 的假設還對嗎? → Vision / Mission 的方向還對嗎?
連續低頭執行最危險的失效,是方向早就偏了卻沒人抬頭。retro chain 的意義是把「執行沒做到」自動升級成「方向是否還值得做」的審問。
Sprint 只是切片,Product Goal 才是容器。Sprint 分數看起來 OK,但 Product Goal 沒有在動——這時要 diagnose:是 timing slip,還是整個 PG hypothesis 從來沒啟動過?
教訓的三層斷點
就算 retro 問出了真正的問題,得出了真正的改善結論,那也只是半途。
結論往往死在三層斷點的任何一層:
記錄了——寫進 retro dashboard、記在某個 doc。
進規則了——被加進 CLAUDE.md 或任何會在下次執行前被讀到的規範。
行為改了——下個 Sprint 真的做不同的事。
三層缺一,教訓就不算落地。最常見的斷法:記錄了但沒進規則。下次 retro 來,同樣的結論又被提出來,大家點頭,再記錄一次。
這就是為什麼每場 retro 的第一步不是檢討這週,而是先 audit 上週的 synthesis 有沒有過三層:grep CLAUDE.md 確認有沒有進去,看 plan + daily 確認有沒有行為改變,標 pass / partial / fail。
skip ≠ 沒問題;dark ≠ 對齊
兩個最容易被默讀成「沒事」的狀態:
一是 retro 跨人補充時有人 skip——「沒什麼要補充的」。Skip 不代表沒問題,代表跨人 evidence = 0。沉默不能被當成綠燈,要顯式問:後續在哪個時間點補?月底結案前?下個 daily?
二是 deadline 當天某人 dark——沒有任何狀態更新。Dark 不代表做完了,代表其他人在這一天無法判斷狀態。cross-owner 的工作,一人 dark 就可能斷鏈整週。
解法都一樣:把「沒檢查」和「檢查過沒事」嚴格區分。往安全那邊倒——fail-closed,不是 fail-silent。
defer 也是同樣的道理。決定今天不做了,當天就要寫明:原因是什麼、新 deadline 是什麼、或者直接 abandon。隱性的自我 defer——daily 不寫、retro 才發現整個軸從頭到尾沒動——是計畫和現實永遠對不上的根本原因。
具體到 code:核准是狀態機的一格
這套思維在 code 裡也能開花。
我在 104-apply-agent 沒有把申請流程寫成一個跑完的腳本,而是把每個 job 壓成一張 SQLite queue,用 status 欄當顯式狀態機:queued → drafted → approved → submitted → replied / rejected,加上兩條逃生支線 skipped 和 needsQA。
人工核准——HITL——不是流程外的審查,是狀態機裡 drafted → approved 這一格的狀態轉移。沒推進就不會 apply。needsQA 是 fail-closed 的具體形:機器代答不了的缺口,不硬投,退人工。
這跟規劃的邏輯是同一個:把「需要人做決定的節點」設計成顯式的停頓,而不是隱性地跳過或默認通過。
計畫可控才 commit,分數按處境算,retro 往上問方向,教訓確認三層落地,沉默顯式處理——五件事合在一起,才算把失敗真的教給你什麼。
單做任何一件,都只是儀式。
這套方法論實作在 claude-team-ops — 帶你跑 Scrum 的教練 Agent；底層的組織設計論述見把公司開成一個 git repo。