零經驗如何主導 Active Directory 全公司遷移？技術主管實戰經驗分享

今天要來聊一個… 嗯… 算是一個蠻特別的經驗吧。就是當你被丟到一個你完全不懂的領域，還得帶一個專案的時候，該怎麼辦。

我想很多人可能都有類似的經驗，不論是換工作、部門調動，還是公司突然有個新方向。昨天你還在做你最熟的事，今天突然就要你去管一個你連術語都聽不太懂的團隊。壓力真的很大。

我記得最誇張的一個案子，是關於 Active Directory 的整併。嗯… 如果你對 IT 不熟，可以把 Active Directory 想像成一間超大公司的總管理處。它負責所有員工的身份認證、權限管理，決定誰可以進哪個辦公室、用哪台電腦、開哪個檔案櫃… 基本上就是整個公司的神經中樞。

然後，我就被指派去主導一個兩家公司 AD 合併的專案。我的背景？老實說，我之前是管應用程式的，跟這種底層架構的東西… 真的不熟。我只知道 AD 是用來登入的，但它怎麼蓋的、裡面有哪些坑，我完全是零經驗。

TL;DR

簡單講，這整個故事的核心就是：當你不是技術專家時，你的價值就不在於技術本身，而在於「人」。靠著提問、建立共識，還有最重要的… 情緒價值… 啊不是，是情緒智慧，你反而能把一個快要爆炸的技術團隊，變成一支能解決根本問題的超強隊伍。

一切的開端：一場突如其來的併購

那時候，我們公司併購了另一間軟體公司。這在業界很常見嘛，大公司買小公司。但對內部員工來說，就是一場風暴的開始。我本來負責的系統，剛好要被新公司那邊的取代，所以我… 嗯，算是被「轉型」了吧，就被調去管基礎架構這邊的專案。

第一個來的，就是這個燙手山芋：Active Directory 整合。這件事超級關鍵，因為新公司的員工需要透過我們的 AD 才能存取所有系統。所以這個專案的成敗，直接關係到整個併購案能不能順利走下去。你知道嗎，壓力真的超大。

但真正的問題還不是我的經驗不足，而是那個團隊… 真的，那才叫一個頭兩個大。

團隊分崩離析，簡直是災難現場

我的新團隊，成員來自兩家公司。原本我們公司的工程師，因為熟悉現有系統，被指派去做維運（Operations）；而被併購那家公司的工程師，反而變成要主導整個新 AD 的架構設計。這下好了，問題就來了。

一般來說，工程師（Engineer）的角色是設計和導入新東西，然後交給維運（Ops）去維持系統穩定。這兩個角色天生就有點衝突。工程師想改東西，但任何改變都可能造成系統不穩，然後維運就要去救火。所以… 你懂的。

現在這個安排，更是火上加油。我們這邊的工程師覺得自己被「降級」去做維運，心裡不爽。新來的那群工程師，雖然名義上是主導者，但他們根本不熟我們公司亂七八糟的 AD 結構，一邊看一邊罵，覺得這什麼鬼設計。

我還記得開會的時候，氣氛超僵。為了公平起見，我規定不管你在哪個辦公室，所有人都要用自己的電腦單獨上線開會。因為我很討厭那種「一間會議室 vs 另一間會議室」的開法，那樣很容易讓兩邊的人各自講悄悄話，形成小圈圈，感覺更分裂。但即使這樣… 衝突還是在一個會議上徹底爆發了。有兩個人，一個是我們這邊的資深維運（以前也是工程師），另一個是新公司來的設計工程師，兩個人因為一個遷移策略直接在線上對罵起來。說真的，如果他們在同一個房間，我毫不懷疑會打起來。

當外行，你該怎麼「領導」內行？

面對這種情況，我一個 AD 門外漢，到底能做什麼？我不能跟他們吵技術細節，因為我根本吵不贏。所以，我只能從「人」下手。

首先，我選擇完全透明。我一開始就告訴所有人：「這是我第一次做 AD 專案，很多東西我都不懂，需要各位專家的幫忙。」然後，我不斷地問各種「蠢問題」。

一開始，他們的回答都帶著一點… 嗯… 輕蔑吧。像是「好吧 Jeff，我試著跟你解釋一下…」，然後用對三歲小孩說話的語氣解釋技術概念。我都忍了下來，就聽、就學。我把自己的自尊心收到最小。慢慢地，我從他們的回答中拼湊出整個系統的全貌，也開始能問出一些他們沒想過的邊界問題（edge case）。

有一次，我問了一個關於某種特殊帳號遷移後權限繼承的問題，那個之前最愛教訓我的工程師愣了一下，然後說：「哦… 這點問得好，我還真沒想過。我們可以這樣做…」那一刻，我知道我開始贏得他們的信任了。不是因為我比他懂技術，而是因為我幫他們看到了他們自己沒注意到的盲點。

再來，就是處理那個快炸掉的衝突。既然讓他們一起「說」會吵架，那我就換個方式。我把會議結構改了。

1. 書面化溝通：我請主導設計的工程師團隊，把他們的遷移策略寫成一份詳細的文件。
2. 非同步回饋：然後，我把文件交給維運團隊，讓他們書面審查，並把所有問題、疑慮和建議都寫下來。
3. 分開開會：我分別跟兩邊的團隊開會，針對這些書面回饋一條一條地討論。因為沒有了當面的唇槍舌劍，討論變得非常聚焦且理性。

這個過程很慢，但很有效。它把人跟事分開了。大家不再是攻擊「某個人」的想法，而是在評論一份「文件」。當那份文件在來回修正中越來越完善時，一個共享的願景… 慢慢地，就形成了。

一個更大膽的決定：不遷就，就重建

當團隊終於不再內耗，開始真正合作時，他們得出一個驚人的結論：原本的計畫是錯的。

原本只是想把新公司的東西搬進我們現有的 AD 裡。但他們現在認為，我們現有的 AD 結構本身就問題一堆，是多年來東補一塊、西補一塊的結果。硬把新東西塞進來，只是讓這個爛攤子變得更大。這點跟我們在台灣看到的情況很不一樣，台灣的企業文化可能更傾向於「以和為貴」，就算系統很爛，可能也是先求穩定，不太會像這樣由下而上地提出要「全部重來」。

他們的新提案是：乾脆趁這個機會，把「兩家公司所有的人」，全部遷移到一個全新的、按照最佳實踐設計的 AD 架構裡。

這…這可是一個天翻地覆的改變。專案範疇從「遷移一部分人」，變成「影響公司所有人」。時程也從三個月拉長到六個月。

我拿著這個由團隊共同擬定的新計畫，去找 CIO 和所有高層報告。因為這是一個有清楚邏輯、解決了根本問題、並且由所有技術專家共同背書的方案，我成功拿到了批准。

這個經驗也讓我想起，之前看過像是 Gartner 這種研究機構的報告，他們在談併購後的 IT 整合時，常常強調「快速整合以實現綜效」。但我們的案例反而說明，有時候「慢下來，做正確的事」比「求快，但留下技術債」更重要。

底下我做個簡單的比較，你就知道差在哪了。

執行，以及那個把垃圾桶當文件夾的男人

計畫定了，接下來就是執行。這又是一連串的協調地獄。我們要跟幾十個應用程式的負責人敲定系統變更的時間，還要訓練客服（Help Desk）如何應對用戶可能遇到的問題，發布全公司公告… 等等。

最終，我們爭取到一個長達三週的窗口，分批次地遷移了上萬個用戶帳號和兩萬多台電腦。我們還成立了一個「老虎隊」（tiger team），隨時待命，準備處理各種突發狀況。

然後，我們就遇到了那個最經典的突發狀況。

一位用戶崩潰地回報，說他電腦遷移後，一些「非常重要」的檔案不見了。追問之下才發現… 他老兄竟然把那些重要檔案存在 Windows 的「資源回收桶」裡。

對，你沒聽錯，資源回收桶。他把它當成一個暫存資料夾在用。

我們的遷移腳本當然不會去備份資源回收桶裡的內容。負責的工程師也知道這點，但他打死也沒想到，真的有人會這麼做。這就是最可怕的 edge case，你永遠無法窮盡使用者的所有神奇操作。

幸好，老虎隊的工程師真的超給力。他手動把那位用戶的帳號還原到舊的 AD，幫他從垃圾桶裡把檔案撈出來，存到一個正常的資料夾，然後再重新幫他遷移一次。問題解決。

這件事也讓我學到，再完美的計畫，都比不上一個有能力、也願意解決問題的團隊。

常見錯誤與修正

總結一下這個案子給我的一些啟發吧，或者說，一些新手專案經理很容易犯的錯。

錯誤一：假裝自己是專家。
很多人剛接一個新領域，會很怕被看扁，所以會裝懂。但這超危險，內行人兩三句話就知道你是裝的，馬上就會失去對你的信任。修正：大方承認自己不懂，然後用提問來學習。你的工作不是給答案，而是問出對的問題，引導團隊自己找到答案。

錯誤二：只專注在解決「技術問題」。
看到團隊在吵技術細節，就一頭栽進去想幫忙找技術解法。但很多時候，技術問題的背後其實是「人的問題」——自尊心、本位主義、溝通不良。修正：先解決人的問題。把溝通管道理順，建立團隊的心理安全感。人順了，技術問題往往就能迎刃而解。

錯誤三：死守一開始的計畫。
覺得專案範疇變更（scope creep）是萬惡之源，抵死不從。修正：保持彈性。有時候，在執行過程中發現原本的計畫有根本性的錯誤時，「堅持」反而是最糟的選擇。要懂得判斷，這個範疇變更是為了逃避問題，還是為了解決一個更大的問題。就像我們這個案子，那個「失控」的範疇變更，最後反而成了專案最大的價值所在。

說到底，我覺得帶領一個你不在行的技術專案，最核心的能力真的不是 PMP 證照或什麼專案管理工具，而是那種… 嗯… 讓人願意跟你說實話、願意跟你一起解決問題的「軟實力」吧。