蘇菲抵達帆影小隊那天，資深工程師盧卡斯很自豪地把她帶到一面貼滿便利貼的牆前：「這是我們這一季的Retro Action Item牆，妳可以看看，我們大概是全公司產出最多改善行動的團隊。」牆上密密麻麻，少說也有四五十張，每一張都寫著具體的行動、負責人、完成日期，大多數還打了勾。
資深資料科學家麥克斯是這面牆最主要的貢獻者——蘇菲翻著紀錄，發現幾乎每兩週的回顧會議，他都會主動提出兩三個新的改善行動，而且執行力很強，通常下次回顧前就真的完成了。「我們團隊最大的優點，就是有問題馬上處理，不會拖。」麥克斯這麼說，語氣裡帶著明顯的驕傲，「妳可以去別的團隊問問，有多少action item最後真的被完成的。」
蘇菲確實去問了，羅盤小隊的凱西聽到帆影小隊的完成率，還忍不住笑說：「那已經是我們望塵莫及的數字了。」這句話蘇菲一開始也覺得沒什麼好懷疑的，直到她真正坐下來，把牆上那些勾選完成的項目，一條一條讀過去。
蘇菲花了一個下午，把最近半年的Action Item跟同一段時間的部署事故紀錄，兩份清單攤開來對照，很快注意到一個規律：跟一個老舊的手動部署腳本有關的事故，出現了六次，而每一次retro的改善行動，幾乎都是同一個方向——「把這次踩到的雷，補寫進部署SOP文件」。半年下來，那份SOP文件已經累積了將近三十條注意事項，長到資淺工程師艾瑪坦言，她從來沒有完整讀完過。
「這個部署腳本，一直沒有人重寫嗎？」蘇菲問資深工程師丹尼爾。
丹尼爾苦笑了一下：「有討論過，其實麥克斯還提過一次『排一個技術債Sprint來重寫』，但那次估算下來要花將近兩週，而且會影響到手邊在趕的功能，最後還是被排到backlog底部，之後就沒再被排進來過。相比之下，眼前這個問題，補一條SOP半小時就能解決，重寫腳本可能要花掉一整個Sprint，還有風險。而且說實話，現在只有我對這個腳本的所有眉角都熟，每次出事，大家還是習慣先叫我，我來手動跑一次，通常比照著SOP更快。」
「所以牆上那些勾，某種程度上，都是你在背後撐著？」蘇菲問。
丹尼爾愣了一下，像是第一次有人這樣問他：「這樣講好像也沒錯，只是我從來沒特別去想過這件事。」
蘇菲把這句話記下來，忽然意識到一件事：正因為丹尼爾每次都能快速救火，團隊寫SOP、補注意事項的行動，才顯得那麼有效率——但也正因為每次都是丹尼爾出手，其他人對這個腳本的掌握，反而一次比一次更弱。工程師奧莉維亞私下跟蘇菲坦承：「老實說，我現在比剛加入的時候，更不敢自己碰那個部署流程了，因為SOP太長，我怕漏看哪一條，出事還是得找丹尼爾。」
資深工程師盧卡斯聽到蘇菲轉述這個發現，第一反應是有點不服氣：「可是我們牆上那些完成的項目，確實都解決了當下的問題，這也是事實吧？」蘇菲點點頭：「每一項單獨看都沒錯，我只是把它們串起來看，才發現它們串成的，是同一條迴圈。」盧卡斯沉默了一下，翻開牆上那疊便利貼，重新看了一遍與部署腳本有關的那幾張，臉色慢慢變了。
蘇菲把這個發現帶回去給艾佛勒。「他們的行動力很強，牆上的紀錄看起來很漂亮，可是同一類事故，還是一直發生。」
「這是一個經典的系統模式。」艾佛勒在白板上畫了兩個環：一個小而快的環，寫著「補SOP→暫時解決→問題再犯」；另一個大而慢的環，寫著「重寫部署腳本→從根本解決」，中間還畫了一條虛線，連到丹尼爾身上。「當一個症狀出現，你有兩個選項：一個是治標，通常又快又容易，另一個是治本，通常又慢又費力。如果每次都選治標，短期內確實比較舒服，但治標的解法，往往還有一個副作用：它會讓真正能治本的能力，越來越萎縮。」
「就像丹尼爾每次都出手，反而讓其他人越來越不敢自己處理？」
「正是。」艾佛勒點頭，「而且最容易被忽略的是，麥克斯這種高執行力的人，往往是這個模式最忠實的推動者——他不是不認真，恰恰相反，他太擅長把眼前的症狀快速壓下去，反而讓整個團隊，一直沒有機會、也沒有動力，去面對那個真正該被解決、卻比較費工的根本問題。」
「那這個迴圈，要怎麼打破？」蘇菲問，「總不能叫麥克斯以後不要那麼積極吧。」
「不是要他變得不積極，」艾佛勒說，「是要讓『治本』這個選項，也被放進同一張牆上，一起被看見、一起被排進行事曆——只要治本的解法永遠只存在backlog最底部，它就永遠贏不了眼前那個半小時就能解決的選項。真正該改變的，不是麥克斯的個性，是團隊排優先順序的方式。」
蘇菲把這張圖抄進筆記本，想著那面貼滿便利貼、看起來無比勤奮的牆——第一次覺得，一個團隊最會反省的樣子，跟它有沒有真正解決問題，可能是兩件完全不同的事。她想起自己剛走進帆影小隊時，盧卡斯那句「我們不太需要外部介入」，此刻聽起來，多了一層不一樣的意思——不是他們真的不需要，而是這個團隊太擅長把每一個症狀處理得漂漂亮亮，讓人連問「需不需要」這個問題的機會，都被悄悄跳過了。
iThome鐵人賽
看影片追技術