當我還在科技業帶專案的時候，有一次，新流程上線前，所有準備看起來都差不多了。
時程排好了，分工也分好了，文件、表單、操作步驟已備齊，幾場該開的會議也都開完。照當時的節奏，只要按表往下推，事情似乎就能順順往前走。
但我心裡一直有個感覺：如果專案真的照這樣上線，現場不一定會像紙上看起來那麼順。
後來我發現，這種感覺其實很值得重視。因為很多專案在正式開始前，看起來都很完整。資料有了，流程有了，說明也有了，大家各自回去忙，表面上像是萬事俱備。可是真正一上場，問題卻一個一個冒出來。原本以為來得及的，臨場才發現根本來不及；原本以為都講清楚了，現場才發現每個人理解不一樣；對方說好會配合，到了關鍵時刻卻突然退了一步。
等狀況真的出現，團隊裡常會有人說一句話：如果那時候先想到就好了。
其實很多風險，本來就已經看得到，只是大家忙著往前推時，不太願意先把那些可能出問題的地方講出來。怕影響士氣，怕被覺得太保守，也怕自己像是在潑冷水。於是，明明心裡知道哪裡可能有漏洞，還是照著原計畫往前走。很多原本可以提早修補的地方，最後都變成事後補救，花更多時間和心力去收拾。
那一次在正式啟動前，我沒有急著往下推，而是先做了一件事。我把幾個沒有直接參與這個專案規劃的人找進來，請他們換一個角度看整件事。我不是要他們幫我補內容，也不是要他們來給鼓勵，我只問了一句話：
如果今天你是來挑毛病的，你第一個會挑哪裡？
那場討論一開始其實有點安靜。因為大家平常不太習慣在事情快要上場時，故意從反面去看。可是一旦開始講，很多原本被忽略的地方就慢慢浮現。
有人提醒，第一線人員雖然知道要換流程，但其實還不清楚遇到例外狀況時該找誰；也有人指出，表單版本看似都整理好了，實際上不同單位手上的檔案還不完全一致；還有同事提到，主管雖然都開會聽過，但下面真正會操作的人，未必知道這件事一旦出問題，第一時間該怎麼處理。
那些問題，在當時看起來都不算大，甚至很容易被當成之後再補的小地方。可是我很清楚，這些點如果留到正式上線後才發生，就不只是小問題，而是會讓現場立刻亂起來的源頭。
所以後來，我們沒有硬照原本時程直接上，而是多花了一點時間，把幾個最容易出錯的地方先補起來。包含重新講清楚異常處理窗口、版本文件全部統一、第一線人員再做一次針對例外狀況的說明。表面上看，進度好像慢了一點；但真正上線後，反而比原本預期穩很多。
這也是我後來越來越重視「紅隊演練」的原因。
所謂「紅隊演練」，就是在事情正式上場前，刻意找人從反面看一次。不是為了唱衰，也不是為了找人麻煩，而是要在事情還來得及調整的時候，把那些平常不太想碰的風險先照出來。
它最有價值的地方，不是讓團隊變悲觀，而是讓大家在最想往前衝的時候，還願意留一點空間看風險。因為事情越大、越複雜、牽涉的人越多，越不能只看理想版本。
紅隊演練用在工作現場，不必做得太複雜，重要的是在正式上場前，先把最容易出錯的地方看清楚。
第一，不要找原本就在推這件事的人自己檢查自己。人一旦投入很深，就很自然會替自己的方案解釋，也比較難看見盲點。這種時候，反而要找能理解情境、但不在原本節奏裡的人來看，通常更容易問出關鍵問題。
第二，不要只問有沒有問題，要問最可能怎麼失敗。這兩種問法差很多。前者容易得到客氣答案，後者會逼大家把心裡真正擔心的地方講出來。我後來帶團隊做這件事時，常常直接問：
如果下週正式上線，當天就有狀況，你覺得最可能是哪一個環節出問題？
如果客戶一進來就抱怨，最可能是抱怨哪件事？
如果第一線卡住了，最可能是卡在哪個交接點？
這樣一問，大家通常就不會只停在「應該沒問題吧」，而是會開始把腦中真正擔心的事說出來。哪個環節最可能出現失誤？誰最可能在關鍵時刻接不住？哪一個假設如果錯了，整件事就會變得很麻煩？這些問題一旦被說出來，風險就不再只是模糊的擔心，而是可以處理的項目。
第三，挑出來之後，不是全部重做，而是先補最容易引發混亂的那幾個點。紅隊演練的價值，在於把風險提早看見，讓後面的推進少一點重工、多一點穩定。真正重要的是，看完之後，先抓出那幾個一旦出錯，就會造成大範圍混亂的地方，先補起來。
這也是很多主管最需要調整的地方。因為有些人一聽到風險，就想全部補齊，結果事情越補越多，團隊也越來越動不了。可真正穩的做法，不是把每一個風險都消滅，而是先分清楚：哪些是可以接受的小問題，哪些是如果不先處理，後面一定會放大的關鍵風險。
我常常提醒團隊，越是重要的事情，越不能只問我們準備好了沒，更要問：如果真的出問題，最可能是在哪裡？
很多混亂，不是因為事情太難，而是因為開始時太急著推進，卻沒有先把風險看清楚。
真正穩的團隊，不是只會想怎麼成功，而是會在出發前先看一次：哪裡最容易出錯。當這些地方預先被看見，事情不一定會變簡單，但至少在真的有變數來時，團隊已經先替自己留好了應變的空間。很多時候，願意先找人來挑毛病，正是在替後面的推進，鋪一條更穩的路。
