文章目錄
先說結論：IT 部門會當你的隊友還是地主，八成在開案第一週就決定了——決定因素不是他們的個性，是你有沒有把權責講清楚：PM 管專案，IT 管系統。
先講一個很多 PM 想不通的現象：導入案照理說是「資訊的事」，資訊部門應該最挺才對，怎麼實際上處處被卡——infra 的需求排不進去、帳號權限開得慢吞吞、動不動一句「資安考量」就把需求打回來？
想通這件事只需要換位思考一次。在 IT 部門眼中，你的專案是什麼？是三件事同時發生：他的地盤被闖進來了（系統環境是他管的，你帶著外部顧問直接進場動土）；他的過去被否定了（要換掉的舊系統，很可能是他當年建的、這些年拚命維護的）；他的未來多了一個要養的小孩——這是最關鍵的一件：專案上線那天，你慶功、顧問請款、然後你們都走了，系統留下來，是 IT 要維運一輩子的。你辦的是婚禮，小孩是他養。
看懂這三層，你就不會再把 IT 的防衛當成刁難。地主的防衛是理性的——問題只在於，你要繼續當闖進來的人，還是變成先敲門的人。
先劃楚河漢界：權責切分的白紙黑字
反直覺的一件事：跟 IT 處得好，第一步是把界線劃清楚，搏感情排後面。感情是潤滑劑，界線是骨架——沒有界線的合作，每一次互動都在重新談判領土，再多咖啡都不夠賠。
開案第一週，跟資訊主管坐下來，把這張表填完、寫進專案章程：
| 事項 | PM 拍板 | IT 拍板 | 需要共識 |
|---|---|---|---|
| 需求優先序、流程設計、時程排定 | ✓ | ||
| 系統架構、主機與網路配置 | ✓ | ||
| 資安規範、帳號權限原則 | ✓ | ||
| 對外系統介接方式 | ✓ | 介接「要不要做」PM 提，「怎麼做」IT 定 | |
| 上線與切換時點 | ✓（營運視角＋系統視角都要點頭） | ||
| 維運交接標準（文件、教育訓練、SLA） | ✓ | 交接「完成的定義」開案就定，不要上線前才吵 |
這張表的精神就一句：專案的事你決定，系統的事他決定，重疊區事先講好誰提案誰核准。 劃清楚之後你會發現 IT 反而變得好合作——地主不怕你來作客，怕的是你搞不清楚誰是主人。
順帶一提，這張表同時保護你：上線後系統出包，維運責任在誰、標準是什麼，白紙黑字都在。權責切分表是雙向的防禦工事，這個邏輯跟文件武器庫那篇講的一模一樣。
把地主變隊友的三個動作
界線劃好了，才輪到搏感情——而且 IT 的感情很難用飯局搏，要用「被當一回事」搏。
動作一：開案就給核心席位。 多數 PM 對 IT 的用法是「需要時才找」——要開權限了、要主機了、要資料了，才想到資訊部門。這種用法等於明著告訴人家：在我眼裡你就是個資源(要用的時候才存在的那種)。正確做法是第一次專案啟動會就讓資訊主管坐核心位置、需求訪談就邀 IT 列席。他未必每場都來，但「被邀請」跟「被通知」是兩種完全不同的待遇，地主分得出來。
動作二：把維運視角提前搬進規格。 這是三個動作裡最值錢的一個。「上線之後誰接手？半夜當機誰值班？顧問撤場後問題找誰？」——這些是 IT 最在乎、卻通常拖到上線前一個月才有人談的問題。你在規格階段就主動問，等於替他把最大的焦慮提前處理掉。而且這對專案本身也是實打實的好處：維運需求（log 怎麼留、備份怎麼做、權限怎麼分層）在規格期進場叫設計，上線前才進場叫追加，價差顧問會很樂意跟你算(相信我，那個報價單你不會想看)。
動作三：功勞給足，給在對的地方。 基礎建設的工作有個悲哀的特性：做得好沒人發現，出事才有存在感。你在指委會的簡報裡固定留一句具體的：「本期環境建置與資料介接由資訊部完成，測試環境提前一週到位」——在老闆面前的具名感謝，對長期被當成「水電工」的部門來說，比什麼都補。這套功勞帳的打法跟帶資深 key user 那篇是同一個邏輯，只是存的帳戶不同。
再多說一層。我一直認為，資訊部門才是最應該了解公司【今天】遇到什麼困境、【未來】想去哪裡的單位——他們手上有全公司的資料流，卻常常被組織放在「修電腦的」位置上。你的專案其實是 IT 從機房走到會議桌的一次機會：讓他們在案子裡當「懂業務的技術把關者」，把「開帳號的」那頂帽子拿掉。做得到這件事的 PM，收穫的除了一個配合的部門，還多一個之後每個案子都罩你的長期盟友。
三種經典衝突，三種接法
情境一：「資安考量，不行。」 菜鳥聽到的是被擋，老手聽到的是開價。「不行」的背後通常是「你沒問過我就想動我的地盤」，所以接法是把否定句轉成條件句：「了解，那怎麼樣的做法可以行？需要補什麼條件，我去生。」我的經驗，十次有八次對面會給出一個具體清單——加密方式、權限分層、簽個資料使用同意——照單辦理就通了。真的遇到無條件的「不行」，才走升級：把「需求的商業價值」與「資安的具體風險」並排送上指委會，讓老闆做取捨（這是裁決題的標準格式，有責無權那篇拆過）。
情境二：IT 要求全部照他們的規範走，時程直接爆掉。 別硬碰，用分級談：核心系統、正式環境、對外介接，完全照規範走，一步不省；測試環境、暫時性工具、專案內部的協作面，談一個簡化流程。多數資訊主管吃這套——因為你先承認了規範的正當性，他才有空間跟你談彈性。全面要求豁免的 PM，等於要地主把整套家規廢掉，誰理你。
情境三：IT 的人力被日常維運抽走，專案端一直開天窗。 這題不要私下拜託工程師加班——人家的考績在資訊主管手上，你的感謝換不了他的年終。正確路徑是把它變成資源裁決題送上去：「專案需要資訊部每週 X 人天，目前實際到位 Y，缺口影響 Z 里程碑，選項一：調整維運優先序；選項二：時程順延；請裁示。」讓老闆去跟資訊主管談資源，那是他們層級的事。
三個情境的共同心法：把 IT 的立場當成合理的，然後用制度解，不用交情凹。
本篇工具帶走：開案權責切分表
拿上面那張表當底，開案第一週跟資訊主管一起填，三個要點：
- 逐項問「這件事最後誰說了算」，填不出來的就是未爆彈，現在吵便宜、上線前吵貴。
- 重疊區寫成「誰提案、誰核准」，不要寫「共同負責」——共同負責＝出事時共同卸責。
- 填完的表進專案章程、指委會過一次，讓切分變成老闆背書的制度——私下約定，換個主管就歸零。
最後說一句：這篇通篇在講 IT，其實方法對任何「地主型部門」都通用——財會的科目、人資的個資、廠務的產線，每個地盤都有它的主人。先敲門、劃界線、給面子，走到哪都是這三件事。敲門愉快！
