溫水煮青蛙，有時慢慢來反而快

還記得 2015 年時我在面試中，面試的主管問我：「你打算怎麼展開加入我們後的前三個月？」

我告訴他：「第一個月我會先觀察，先了解狀況，讓我在第二個月可以開始動手做些改變。」他聽完後點點頭表示認可。因為我們都很清楚，只有掌握現況，循序漸進的推動改變，成功率遠高於一開始就大刀闊斧地推進。

沒多久，我到新公司任職，我剛到的第一週。團隊成員跟我抱怨了很多工作流程以及跨部門溝通的問題，他們的說法是「這不對，需要盡快調整」。而在我到職之前，才剛離開一位技術能力很傑出的工程師，他進來一個禮拜發現苗頭不對，很快地就退場了，辦公室的白板還留著他當時建議的方案。

而這些工程師們認為對的做法，在 PM 的口中卻有另一種觀點。他們認為這些需求都是有歷史背景的，不能隨意否認或修改。如果真的要改動，那得經過跨部門討論，還得業務主管的許可才能調整，不是說改就改的。

在差不多的時間點，我還聽過幾個部門提出的重大改革計畫，每個計劃都要投入大量的資源與時間，都會大幅改變目前的工作流程與資源配置，最後，沒有一項計畫真的被落實執行。

聊過一輪後我大致知道問題在哪了，我只跟團隊們說：「這些事急不得，得慢慢來。」那時團隊成員們覺得有些納悶，怎麼我不是要來帶動改革的，還要慢慢來嗎？但我只要他們有點耐性看我怎麼做。

改變，從一些小事開始

我接手部門的第一個禮拜，我去找了業務總經理談，希望能解決專案沒有優先順序的問題，我想先建立專案管理的觀念，過程雖然被洗臉說「你們以前從來沒有準時過，談順序壓時程沒意義」，但她在我的說服下還是先接受了我的提議，跟我一起把專案順序壓出來了。

而回過頭，我跟團隊溝通的事情是，我們得立刻配置資源到這幾個核心專案上，確保每個專案能準時交付。然而因為當時大家手上都卡著現有的短期任務，而且每天來的緊急單子很多，很難靜下心來處理專案工作。此時我又做了兩個決定，第一，將資源集中到重要的專案上，第二，將窗口限縮到其中一人。

將窗口限縮到一人身上，並不單純只是為了統一溝通管道而已，這還是一個我用來調整業務部門工作習慣的「小事」。

當我將窗口限縮，當下業務部門的主管們有些反彈，因為他們覺得以前都可以想找誰就找誰，為何現在要限制在一個人身上？我跟每位主管逐一溝通原因，也跟他們道歉造成他們一些不方便，但他們聽完我的說法後大多可以理解。而在往後的日子裡，這個單一窗口確實帶來的蠻大的效益。

不只資訊落差減少了，回應時效跟專業性也提高了。業務部門在兩個禮拜後便適應了有事找這個唯一窗口的流程。

在差不多的時間，我也跟業務總經理提議讓我列席業務週會，因為我想在現場了解大家的需求，以及我們可以改進的地方。總經理很爽快的答應讓我列席會議。隔週一我帶著兩位 PM 一同參與，並在現場聽他們抱怨，抱怨研發的資源太少，專案進度緩慢，抱怨系統不穩定經常出錯，抱怨我們都不在意業績達成狀況。

我在現場聽，也現場回應大家的抱怨。在會議將結束時，我跟總經理提議下週給我半小時左右的時間，我來報告一下研發這邊的狀況。包含大家最在意的專案、問題，還有我們的招募進度，跟研發資源的使用狀況，若有認知上的差異，那我們就盡快調整。總經理同意了。

隔週，我準備了目前團隊的重要專案進度，以及例行性處理 bug / 需求的狀況，還有一些由業務部門主管們提出的需求。我報告完，總經理問了幾個需求的問題，他很納悶為何要做那幾個需求，此時提需求的幾位主管紛紛表達他們的想法，但總經理最後認為不應該做那幾個需求，而是將資源集中在最關鍵的專案上。

就這樣，我沒有花時間逐一說服各業務主管，而是藉由透通資訊，讓總經理自己來做這件事。他說，比我說有力道。

而在我的報告中我有帶到了另一個問題。那時公司的業務系統會自動分派客戶名單給業務，讓業務可以透過電話系統來進行客戶開發。而名單的品質有好有壞，好的名單有限，所以每個業務都只能分配到少量個優質名單。但有業務會走系統的漏洞，謊稱名單的電話號碼有問題，要我們再派一筆給他。

但其實原先的名單是沒問題的，這些業務只是取巧，想透過這種方式多騙一筆名單。但研發成員也沒有去查核這件事，所以當業務有反應時，窗口就會請工程師手動再派一筆給他。而這個問題，後來被我們發現了。在會議中，我並沒有直接說這是舞弊行為，畢竟這是業務部門內的醜事。我用了另一個比較有技巧的說法。

我說：「這陣子業務團隊反應好名單 pool 中經常有無效名單，過去比較沒碰過這樣的狀況，所以我們整理了這幾個月來的數字，發現最近一個月的無效名單數量大約是更之前六個月的總和。我想這件事需要跟行銷部門討論一下才行。」

業務總經理其實也分管行銷部門，他已經聽過行銷部門那邊的報告。他其實已經知道問題出在哪。他當著大家的面先修理幾個業務主管，並要他們警告業務以後不准再這樣，而有舞弊行為的幾位業務必須懲處。

順著他的話，我又提出了另一個建議，那就是要不要調整一下業務部門提需求的流程？因為有些緊急需求研發團隊其實無法當下判斷這件事到底是業務的個人需求，還是業務部門整體的需求，也怕我們做出錯誤的判斷，照顧了個人的需求，卻損害了業務部門整體的權益。

所以，往後緊急性的需求是否由業務副總監同意後才提出，而一般需求則由我們在每週的業務週會中提出確認。由於剛剛才出現名單的舞弊事件，所以我這個提議很容易的就過關了。

就這樣，我在到職的第一個月，陸續完成了幾件小事：

1. 讓總經理同意專案要排優先順序，讓資源的投入更集中。
2. 將需求溝通的窗口單一化，讓工程師可以專注工作。
3. 參與業務部門週會並爭取到報告時間，讓資訊正確傳遞。
4. 調整緊急性需求的提出程序，讓窗口的溝通對象從數十個減少到數個。

這些事情，或許都是最佳實務中我們認為對的事，但公司當時已經有習慣的做法了，過去的做法問題也不大，似乎沒有調整的必要。當對方覺得改變沒有必要，而且一改又要改很多，那自然沒有人想改變。而這正是在我之前那些人無法推動改變的原因，他們太急了，急著想要一步到位把事情做好。但他們忽略了人性，抗拒改變是人的天性。

而我的方式則是一點一點改變，哪邊有問題就把問題凸顯出來，然後順勢提出一個解決方法，讓大家在潛移默化中逐漸被改變。

關於空降主管安全落地的方法，也可以參考這篇：

空降主管平穩落地四訣竅

當職業發展走到一定階段，去到什麼公司都是要直接帶團隊打仗，「空降」這件事是怎麼樣也避不開的，專業經理人能做的事就是盡可能地做好空降的準備，本文我便以我過去空降的經驗來與大家分享-空降主管如何迅速掌握現況，並平穩落地。 掌握現況，謀定而後動 空降主管初來乍到，對於公司與團隊的現況的把握度通常較低，必須先做足功課，對產業、產品、競爭狀況的掌握是最基本的，但要平穩落地，你還必須要掌握團隊狀況、組織架構、政治關係，以及一些待解問題背後的成因。 猶記得多年前去面試 TutorABC 時，當時的面試官 Arthur 曾問我：「你談了很多你對產品的構想，我覺得內容很好，但我想知道你怎麼展開 onboard 後前幾個月的工作？」 我當時的回答是：「前兩個月我會觀察與了解現況為主，不會急著做太多的調整，因為現況的成因我必須先掌握，配套的調整才會到位。」 當初面試時的資料我都還留著，簡報的最後一頁就是談前半年的計畫，計畫的最前頭就是了解與掌握現況。因為我認為不可能只有我看到問題，肯定很多人都看到問題了，但這個問題卻始終存在，這背後的原因必須被挖掘，脈絡必須要被釐清。 而這些，你光憑查到的資料

游舒帆Gipi 的學習筆記gipi

溫水煮青蛙，漸進式改變

我不談變革，我談的是改善。而這種一點一滴改善，最後做到原先想改變的事，這種做法我習慣稱之為「溫水煮青蛙」。

如果你想要改變一件事，我的建議就是循序漸進，一點一點來，將改變化於無形。往下，我一樣跟大家分享幾個我帶動改變的故事。

建立完整的版控流程

當我想要改變整個研發團隊的版本管理流程時，我不是提一個大提案，然後設法說服所有的研發主管跟上級主管。我採取的做法是從自己部門做起，讓我們部門的流程先穩定下來。

別人看到我們有能力做這件事，紛紛來請益，我們也不吝嗇的協助幾個部門建置了相同的流程。然後我拿著這個成果在週會時跟上級主管們說明，正式獲得了上級主管的認可，讓我們組織了一個小團隊將這個管理流程推行到全部門。

從一個團隊，到多個團隊，到整個研發部門，前後也不過就三個月的時間。重要的是，過程沒有那麼多的阻礙，也沒有花很多時間說服其他人，畢竟我們是拿著成果來證明這件事的。

建立產品管理制度

當年我剛進公司，我發現公司的產品基本上是屬於沒人管理的狀態，沒有產品部門，沒有專責的開發團隊，甚至也沒有產品經理。我覺得這是不對的，所以我有個念頭就是要把產品團隊建立起來，並成為產品部門的主管。而這也是我加入公司的主要目標。

我當時給自己設定的關鍵要素有幾個：

1. 讓大家感受到有專責開發團隊的重要性。
2. 讓大家感受到需要有個產品經理處理產品的大小事。
3. 讓大家覺得這件事由我來負責最恰當不過了。

要先滿足上述三個要素，我想看見的改變才有機會成真。有了方向，我就開始溫水煮青蛙了。

由於當時我身處業務部門，有一定的權力影響產品的走向，我順著業務部門提出的一個產品需求，找上了其他幾個部門的主管，跟他們提到這個案子需要各部門投入資源協助。但過程中為了協調資源不僅花了不少時間，還出了一些成員掉隊讓我不得不緊急調度資源的狀況。

而我也將這些問題如實的紀錄下來，但我並沒有特別提這是誰的問題，我反而很包容這些跨部門同仁的狀況。但我其實埋了一個引子，讓大家開始感覺產品的維護似乎有專責的人還是比較妥當的。

而就我知道，產品過去一年發新版本時經常會出差錯，這些錯誤不僅僅是程式的 bug，還包含了業務部門搞錯產品，賣錯東西，行銷部門誤解產品訴求，傳達了錯誤的資訊，客服部門沒搞懂產品改了什麼，被客戶問倒的狀況。

那時因為產品開發過程有個 PM，我就跟其他部門說，這個案子我們的 PM 會從頭跟到後，不會只關注開發。他會協助其他部門做好事前的溝通跟教育訓練，也會整理文件給大家，並在上線後持續追蹤幾個禮拜，如果大家有問題都可以跟這位 PM 反應。這個動作的背後，我要讓大家感受到有個專責的 PM 好像很不錯。

那個案子上線後的狀況比原先預期的好，而且上線後的問題收斂的速度也很快，各部門主管大多抱持好評態度。此時，我加入公司也將近半年的時間了，我不只協助業務部門解決了多個問題，也承擔起公司內維運任務，並且做出不錯的改進，而近期又策動了產品專案管理的改進。

所以我順勢建議是時候做組織重組了，但我只建議應該要有個專責的產品開發團隊，然後未來每個負責產品開發專案的 PM 都要像這次一樣，不只看著開發工作。這個提案獲得了高層的同意，我也成為這次組織重組過程最關鍵的協調者。

往下的幾個月，這個產品開發團隊陸續繳出了不錯的成果，而幾位 PM 也陸續站穩了腳步，年底時我才進一步跟主管建議成立產品團隊，而這個團隊可以交由我來負責。過去 9 個月，我交出的成績，以及我對產品的專業判斷，都讓老闆相信我能搞得定，最終他同意了。

這是一段比較漫長的故事，但大家也可以看到，我處理的步調是掌握關鍵要素，然後一步步推進，在關鍵時刻發力，讓事情順利發生。

讓業務主管們願意寫文件

上面兩件事的複雜度都比較高一些，接著也來分享一個提到溫水煮青蛙時我一定會分享的案例。

這件事發生在我進公司的第二個月，那時我們推動單一窗口有一小段時間，而窗口一職希望來提需求的業務主管們可以自己填完一份文件再來找他，要不然他總是要問東問西才能釐清需求。但他跟業務主管們溝通了很多次，嘗試說服他們，但最終都無效。

我看到這狀況後跟他說，以後某幾位主管提出的需求，你可以跟對方說這需求要找我討論，由我來處理，我會教會他們寫文件的。窗口將信將疑，覺得我怎麼可能辦到，不過無論如何，他還是按我的話去做了。

隔天一位主管很焦急地來找我，希望我立刻幫他處理某個問題，我告訴他：「我現在手邊正在忙，要不你下午再來找我。」

對方說：「不行啊，現在就需要了。」

我想了想跟他說：「因為我得花些時間釐清你的需求才能交辦給工程師，要不這樣好了，可以麻煩你幫我填一下這份表單，填完後我確認沒問題我就請工程師動手了。」

對方聽到我這麼說，雖然覺得這應該是研發要做的事，但若要加快速度，現在好像也只能如此了，所以他雖然不甘願，但還是自己花了點時間把文件填完了。我很快的看一下沒問題，就馬上請工程師幫他處理了。

沒兩天，他又因為類似的問題找上我，我一樣假裝忙碌，一樣請他幫忙填表單，這一次他說：「好啦，不就自己填表單嘛。」加上這次，他已經自己填了兩次。

第三次他來找我時，他已經自己填好表單了，因為他知道這樣子最省時間。

我笑著感謝他，然後，我還進一步請他幫忙開個講座，教其他業務主管填這個表單。

從不願意填表單，到整個部門主管都自己填，前後也不過 2-3 週的時間。我們的窗口好說歹說，對方都不願意配合，而我這種做法，不僅讓對方願意填，還願意幫我教其他人填這份表單。

從上面三個故事我們可以看到，改變一個人或一個組織不見得是非常困難的一件事，但大刀闊斧的改革是非常容易失敗的，有時你求快，改變來的太激烈，會受到強烈的抗拒，而且一次需要的資源太多，老闆也不容易點頭。反之，如果我們透過漸進式，溫水煮青蛙的模式一點一滴帶動改變，改變反而更快發生。

溫水煮青蛙的觀念，你可以運用在別人身上，也可以用在自己身上，當你有想要改變的事情時，切記，不用在一開始就給自己訂下高遠的目標，而是試著先讓自己從小改變開始，讓自己慢慢適應，讓自己在沒有太多抗拒的狀況下漸漸習慣這件事，一段時間後，你會發現自己已經變成原先期望的那個樣子了。

不要急，設定方向，先來一點小改變，再來一點小改變，持續下去，改變就能成真。

如果你覺得我內容寫得還不錯，歡迎訂閱我的電子報，我每雙週會發送一封電子報到你的信箱。訂閱連結在這，過往的電子報也在這：Gipi電子報

也鼓勵你可以將我的電子報分享給你認為有需要的朋友們，也許你的舉手之勞，將會改變另一個人的思維與習慣。