需求改了五次，專案沒有垮；真正懸在一線的是：改完之後，「現在承諾了什麼」全世界只剩一個人背得出來。

一場記憶力表演

昨天結尾問：設計的「為什麼」靠原作者，那需求的「改成怎樣」靠誰？

今天的答案坐在會議桌的另一頭，職稱是 PM。案例照例經過去識別化與合併改寫。

某個系統整合案有一張核心的申請表單。三個月裡，這張表單的需求口頭改了五次：

開工不久的定期會議
→ 客戶部門主管：申請單要加一個「加急」選項

幾週後的通訊軟體
→ 客戶窗口丟來一句：加急改成三個等級好了

專案中期，某次 Demo 散場的走廊
→ 另一位主管：三級太複雜，一般跟加急兩種就好

再一次定期會議
→ 加急件要多走一關主管簽核

驗收前兩週的訊息
→ 窗口：簽核那關先拿掉，上線後再說

五次變更，三種場合，來自三個不同的人，沒有一次留下正式紀錄。工程團隊照著「最後聽到的版本」一路改，Ticket 只記了要做什麼，沒記為什麼、更沒記它取代了哪一版。

然後是驗收會。客戶方來了一位前面幾次會議都沒參加的高階主管，翻了兩下系統，皺眉：

「怎麼只有兩個等級？當初不是說好三個？這跟當初講的不一樣。」

會議室安靜下來。三個月、五次口頭變更、零份文件——這種時刻，通常就是專案開始翻車的聲音。

然後 PM 開口了。第幾週的定期會議上誰提出加急、第幾週窗口在訊息裡改成三級、Demo 散場的走廊上是哪位主管說改回兩種、哪次會議加了簽核、驗收前哪一天又拿掉——時間、場合、人、原話，一路背到底，中間還翻出兩張通訊軟體的對話截圖。

客戶方的人互相看了看，點頭：確實是這樣沒錯。驗收繼續。

會後聚餐，大家舉杯：

「還好 PM 都記得。」

聽起來熟悉嗎？Day 01 那句「還好有他在」，換了一個職稱，又出現了。

當時團隊怎麼理解這件事

照例，每一句單獨聽都有道理。

我們是敏捷團隊，擁抱變化，需求本來就會改；每次改都開變更單太官僚，客戶會覺得我們難搞；PM 本來就該掌握需求，這是他的工作；有不確定的問 PM，比翻文件快；而且你看，驗收不是過了嗎？

合在一起，這些說法剛好繞開一個問題：

需求改了五次之後，「現在的承諾」是哪一版？除了 PM，誰答得出來？

答案在驗收會上已經演過了：客戶高層記得的是第二版，工程團隊做的是第五版，合約附件寫的是第零版。每個人手上都有一份「自己最後聽到的版本」，而沒有任何一個地方，存放著所有人公認的當前版本。

缺席的不是會議記錄，是「當前版本」

先說清楚：這個團隊不是沒有紀錄。會議有零散筆記，通訊軟體的對話調得出來，Ticket 一張沒少。資訊都在，散落在五個地方——而五個地方加起來，回答不了一個問題：所以現在到底要做什麼？

這件事在兩套方法裡，原本都有安排。

瀑布的做法 Day 02 走過一遍：需求凍結成 Baseline，要改就走 Change——重新估算、重新承諾，驗收拿 Baseline 加上所有已核准 Change 的總和來對。這套流程常被罵官僚，但它保證了一件事：任何時刻，「目前答應了什麼」等於一個可以翻出來的東西，不是一段可以爭論的記憶。

敏捷把這件事做得更輕，但沒有做掉。Backlog 本身就是當前版本：需求改了，改的是那張卡，卡上永遠是最新的共識。變更的成本被降到很低——低到不需要委員會——但「所有人看著同一份當前版本」這條底線，一天都沒有放掉。

兩套方法的共同承諾是：任何人、任何時刻，查得到「我們現在承諾了什麼」，而不必問某一個人。

這個團隊兩邊都沒有。於是 Change Management 退化成另一種東西：記憶力競賽。驗收會上，客戶的記憶對上 PM 的記憶，比誰記得多、記得細、手上剛好有截圖。那天 PM 贏了。但一場需要「贏」的驗收，本身就是流程壞掉的證據。

還有一層 Day 05 講過的帳：五次變更，沒有一次經過報價。這不只是態度問題，是根本報不了——報價的前提是知道「從什麼改成什麼」，而這裡連「從什麼」都沒有一個確定的版本。沒有紀錄，連報價都無從報起。

大神腦袋裡藏了什麼

系列走到現在，大神一直坐在工程師的位子上：補需求的、記介面的、通靈驗收的、留著設計原委的。今天的大神換了張名片，職稱是 PM。血脈壓制，不分職能。

看看他替全團隊代管了什麼：

真正的需求現況
→ 五次變更疊加後的最新版本，全專案只有他一人完整持有

真正的變更史
→ 每一次改動的時間、場合、提出的人、原話

真正的出處
→ 哪句話是誰說的，出現「當初不是這樣」時可以對質

真正的權重
→ 哪些改動客戶其實不會追問，可以先放著不動

Baseline、Change Record、每筆變更的來龍去脈——變更管理該有的 Artifact 一樣都不缺，全部存放在同一顆腦袋，每天口頭提供查詢服務。他不是在管理變更紀錄，他本人就是變更紀錄——一份會累、會記錯、會休假、會離職的紀錄。

而那場表演能成立，需要三件事同時為真：他記得對、對方信得過、他人在場。

背錯一個日期，整套時間軸的可信度當場歸零；對方高層若堅持「我不記得有那次走廊對話」，記憶對記憶、口說無憑，最後比的是信任存量而不是事實。至於第三件——他不在場的時候會怎樣——今天先不推演，這個系列遲早要正面回答它。

這次到底誰在吸收代價？

老規矩。五次變更全數照做，交期沒動，也沒加人。那三個月的變更混亂，這筆帳記在哪裡？

Scope       □   五次變更照單全收，一項沒少
Time        □   驗收如期舉行
Cost        □   帳面上一毛都沒加
Quality     □   這次沒被扣到，純屬幸運
Risk        □   「他記錯一次會怎樣」，沒有人想過
人          ■   PM 的記憶，外加全天候的人肉查詢服務   ← 還是這格

值得注意的是這次的吸收方式。前幾天的人肉緩衝，至少還分攤在幾位資深工程師身上；這次更集中——整個專案的承諾現況，由一個人獨家代管。吸收的人越集中，平常越省事，出事越徹底。

需求的每一次口頭變更，都是往同一顆腦袋裡存進一筆別人取不出來的款。

如果沒有大神，應該留下什麼

Day 01 就說過：缺的是 Change 的紀錄，不是「變更管理委員會」。今天把這句話補完整。

要讓變更史離開 PM 的腦袋，最小配備是兩個東西。

第一，每次變更，四行紀錄：誰提出、改了什麼、代價誰付、誰同意。第三行直接接 Day 05 的報價單——報完價，把結果抄進來，報價單從此有了歸檔的地方。

第二，一份所有人可查的「當前版本」。可以是需求清單、可以是 Backlog、可以是一頁 wiki，形式不拘，規則只有一條：變更核准之後，先改它，再開工。紀錄是歷史，當前版本是狀態；只有歷史，每個人得自己在腦中疊加出現況；只有狀態，出爭議時無從對質。兩個都要，而兩個加起來，不超過十分鐘的工。

還有一件事值得說破：這不是為了防客戶，也不是為了留證據吵架——雖然那天它確實救得了場。真正的目的，是讓「這跟當初講的不一樣」這句話出現時，所有人的反應不是屏住呼吸看 PM 表演，而是翻開來看。

紀錄在，這句話是一次五分鐘的查證。紀錄不在，這句話是一場賭上專案的比賽。

今日 Artifact｜最小 Change Record

四行，會議還沒散就能填完：

□ 誰提出：＿＿＿＿在＿＿＿＿（會議／訊息／走廊）提出
□ 改了什麼：從＿＿＿＿改成＿＿＿＿
□ 代價誰付：本變更以＿＿＿＿支付（接 Day 05 的報價單）
□ 誰同意：＿＿＿＿於＿＿＿＿（日期）點頭

填完之後做一件事：把「當前版本」那份文件改掉。順序不能反——先改當前版本，再動手做。

第二行如果寫不出「從什麼」，恭喜你提早發現問題：你們連上一版承諾是什麼都沒有共識。這格填不出來的團隊，缺的不是這張表，是 Day 02 的那條 Baseline。

今日一句

需求一直改不是問題；改完之後，「現在是哪一版」只有一個人答得出來，才是問題。

到今天為止，第二部已經連看五個現場：需求靠腦補、介面靠交情、完成靠通靈、決策靠原作者、變更靠記憶。你可能會問：洞這麼多，這些團隊平常怎麼都沒感覺？

因為補洞的人都在，而且都很好用。這些洞要現形，通常得等一個特別的時刻——一個什麼都還不知道的人，走進辦公室。

明天：新人加入後——為什麼大家都知道，只有我不知道？