在製造部的時候，我其實不會直接對到 PMO。
比較常遇到的，是 planning 帶著需求來對製造部。
老實說，那時候我常常覺得很煩。
事情明明已經在跑了，卻還要被要求重新畫進程、對時間、補表格。
有些作業明明每週都在做，只是因為資料取得時間不同，會議時間就要跟著改，但不變的是：每週都要為這件事重新整理一次。
站在製造部的視角裡，這些事情看起來不像在解決問題，比較像是在反覆確認一個大家早就知道的困難。
那些 planning 最常問、製造部最不想回答的問題
planning 最常問的，通常是這兩個問題：
- 為什麼比上週退步？
- 落後可不可以追回來？
以我在製造部的經驗，很多時候答案其實很直接：很難，甚至不可能。
現場不是不知道落後，而是事情已經在救、人在處理，很難再停下來，用一個「可以被拿去討論」的方式，親口說出：「這一段真的追不起來。」
所以那時候的我，只覺得這些問題很不切實際。
但風險其實不是單向的
回頭看才發現，事情其實並不只是 planning 單向丟需求。
在製造部的時候，除了 planning 帶著規劃來對製造，我們也很常在現場感覺到機況有風險，主動回頭去跟 planning 確認影響是什麼。
有時候是設備狀態不穩，有時候是實驗條件卡關，當下不一定已經造成明顯影響，但會讓人直覺覺得：「這樣下去不太對。」
這種時候，我們需要的不是立即的答案，而是把這個模糊的風險感覺，轉換成 planning 能理解的影響範圍：
可能會掉多少、會卡多久、有沒有需要提前調整規劃。
只是那個時候的我，並沒有意識到，我們其實已經在做一件後來在 PMO 才被正式定義出來的事情。
剛進 PMO，我其實也一樣覺得很煩
轉到 PMO 之後，我的第一個不適應是：
很多在製造部看起來「已經在動」的事情，到了 PMO 這邊，卻必須被重新整理成數字、進程與風險。
需求不能只用感覺描述，而是要說清楚影響多少、落後多久、風險在哪。
這些資訊不是為了追究誰，而是為了讓後面的討論有共同基準。
一開始我也覺得這些事情拖很久。
一件事情要對齊 N 個單位，要整理資料、發正式信、等回覆、留紀錄。
對比製造部那種「講一講，事情馬上要做」的節奏，PMO 的世界看起來真的很慢。
後來我才發現，慢不是重點，能不能被談才是
真正的轉念，是我慢慢看懂一件事。
PMO 在做的，不是替 planning 為難製造部，也不是幫任何一方下決定。
我們做的，是把需求與風險轉換成「可以被看到的數字」，讓 planning 和製造部，能在同一個基準上溝通與判斷。
當風險被說清楚，planning 才能決定要不要調整規劃？
製造部也才能回應：這件事是做得到、做不到，還是需要調整條件才有可能。
很多時候，其實不是不知道追不回來，而是需要有人把這件事說清楚、記下來。
只有這樣，後面的出貨調整、對外溝通、風險承認，才能真的開始。
為什麼製造部和 planning 常常互相不理解
站在中間看，我才發現，這其實不是態度問題，而是系統設計的差異。
製造部是一個即時反應型系統：事情來了先救，沒做到再找原因、提需求。
重點是現在不能出事。
planning 則是在對抗另一種不確定：如果這樣下去
之後怎麼交代？
哪裡要調整？
哪些風險必須被承認？
而 PMO 站在中間，不是決定方向，而是確保這些模糊的訊號，
不管來自現場還是規劃端，都能被翻譯成三邊都聽得懂的資訊。
不是誰比較有效率，而是每一邊在承擔的風險不同。
我現在才懂，為什麼需求一定要被「整理過」
回頭看過去，我不覺得製造部做錯了什麼。
在現場，事情不等人，也沒有太多餘裕為未來停下來整理。
但現在站在 PMO 的位置，我才明白，如果需求與風險沒有被整理成數字與影響，它其實無法被真正拿去規劃。
那些看起來很煩、很慢、很重複的動作，不是為了干擾現場，而是為了讓事情能在不同單位之間流動。
結語
製造部在處理事情，planning 在做規劃，而 PMO 的工作，是把來自各方的需求與風險，轉換成可以被看到、被討論、被決策的資訊。
當我站在中間看清楚這件事之後，我才真正理解，事情不只是被「解決」，還必須被「說清楚」。
也正是在那個時候，我開始意識到，原來工作，是可以有終點的。
