這幾年，只要去到有工程師的社群聊天區，
總是可以看到類似的抱怨：
「營運是不是以為，簡單講一個活動需求，
明天系統就會自己長出來？」
每次看到這種留言，我都會笑一下。
不是覺得工程師誇張，而是那種畫面太熟悉了。
因為在這個故事裡，
真正被當成「理所當然」的那個人，
通常不是營運，也不是研發，
而是夾在正中間的 PM。
現在又是個大AI時代，
總是會有很多人有個錯覺，
只要跟AI或是工程師許願，
明天就可以看到願望實現。
◆ 你以為只是「改個活動頁」
我第一次被營運和研發夾到快喘不過氣，
是在一個看起來非常無害的活動需求。
那天營運丟訊息來：
「下週想推一個促銷活動，
想簡單做一個活動頁就好，
流程跟以前差不多，幫忙排一下時程。」
如果你當過 PM，
應該對這種話不陌生。
當時我也天真地以為，
既然「跟以前差不多」，
那就改一下文案、換個規則，
怎麼算都不會是大事。
真正開始問細節之後，
故事開始加了胡椒、大蒜，還有很多其他配料。
這次活動想順便調整會員等級，
點數機制也要一起改，
在活動條件上希望加上幾個身分條件，
營收報表要針對這次活動加上一些統計數據，
最後再加上一點點新的優惠券的的想法。
一句「簡單活動頁」，
最後牽扯到會員系統、金流、訂單、報表，
甚至還牽到和外部廠商的優惠券的介接。
我整理完，開評估會交給研發。
技術主管看了一圈，只淡淡說了一句：
「這不是活動頁，是整個系統重做。」
那一刻我才真正意識到，
在營運的語言裡，
很多東西都只是「順便」，
但在系統的世界裡，
每一個「順便」都可能是傷筋動骨。
◆ 營運要的是「現在就上」，研發要的是「不要亂來」
後來慢慢發現，
營運和研發看的是同一個產品，
心裡想的卻完全不是同一回事。
在營運眼裡，系統是業績的工具。
他們在意的是：
活動能不能快點上，
KPI能不能達標，
競品今天出了什麼，我們不做客戶是不是會跑掉。
在研發眼裡，系統是一個會壞掉的東西。
他們在意的是：
這樣改會不會把穩定的地方弄爆，
資料接不接得起來，
技術債會不會再多一筆，
半年後維護的人看得懂嗎。
同一個需求，
放在營運那邊，是「業績達標的活動」。
放在研發那邊，是「風險很高的改版」。
你站在中間，看得見兩邊的壓力來源。
營運被市場追著跑，
研發被風險追著跑。
你試著把兩邊拉近一點，
但很快就發現，有時候那根本不是距離問題，
而是方向就不一樣。
◆ 真正卡住的，常常不是技術，而是「沒想完的需求」
很多工程師會說，
營運不懂技術，亂開需求工單。
老實講，這話有一部分是真的。
但更多時候，
問題不是「亂開」，
而是「沒有人陪他們想完」。
營運最常說的一句話是：
「先做起來，我再補細節。」
這句話在會議裡講出來，
通常大家還笑得出來。
但在專案時程裡，
它就是一顆定時炸彈。
後來只要聽到這句話，
我就會強迫自己多問幾句，
雖然問的當下會有點尷尬。
像是：
這個活動的目標是什麼？
是拉新？回流？還是提高客單？
要影響的是哪個指標？
註冊數、下單數、留存率，還是別的？
誰可以參加？
從哪裡進來？
什麼情況下不能參加？
有沒有風險場景？
會不會被洗點、被套利？
活動結束後，
你要怎麼知道有沒有效果？
你想看的數據是什麼？
問到這裡，
營運常常會停下來，皺一下眉說：
「欸，好像真的還沒想那麼細。」
這不是在刁難對方，
而是把原本只是一句「我要做活動」，
煮成一鍋可以吃的東西。
如果這一段沒有經過，
需求直接丟進開發流程，
後面每一個人都會在補那塊「沒想完的空白」。
◆ 你不是傳聲筒，你是翻譯器
剛當 PM 的時候，我也以為，
自己的工作就是把 A 的話轉給 B。
營運說：「做活動頁。」
我寫在文件上：「新增活動頁。」
交給工程師，心裡覺得：「我有幫忙傳話。」
久了才發現，
這種做法只會讓衝突延後發生，
不會讓問題比較小。
PM 如果只是傳聲筒，
最後會被兩邊都討厭。
營運覺得你只會拿技術當擋箭牌，
研發覺得你只會拿需求往他們身上砸。
真正有用的，是「翻譯」。
把營運模糊的期待，翻成具體的規則和流程。
把研發的技術顧慮，翻成營運聽得懂的風險說明。
把所有人說不出口的擔心，整理成可以被討論的選項。
舉個簡單的例子。
研發說：「照這樣做，之後每次改活動都要重寫。」
你如果原封不動丟給營運，
聽起來就會像在說「不要改」。
但你可以換個方式說：
如果現在用快速做法，這檔活動趕得上，
但以後每次活動都要重調一次。
如果現在多花兩週，把機制改成設定化，
這檔活動可能會晚一點，
但之後開新活動只要調參數設定。
你現在比較在意的是這一檔衝出去，
還是之後每一檔都可以安全又快速？
這時候，
你不是替哪一邊講話，
而是在幫大家做選擇。
◆ 跨部門 PM，要練的不只是「更能扛」，而是「更會設計合作方式」
很多 PM 習慣把自己當成那個「負責扛的人」。
有事我來頂，有衝突我來擋，
久了只會把自己耗乾。
後來我慢慢調整，
不再只想著「我要怎麼撐住」，
而是改成「我要怎麼設計，讓這件事比較好一起做」。
例如：
會議不要從「這個需求一定要做」開始，
而是從「有哪幾種做法，各自代價是什麼」開始。
會前先跟營運對一次草稿，
幫忙把需求的輪廓描清楚，
避免在有工程師在場的會議上，
大家才一起「邊想邊改」。
會議結束後，
很快整理一份大家都看得懂的紀錄，
寫清楚「決定要做什麼」、「暫時不做什麼」、
「誰要補什麼資料、什麼時候前要補」，
讓每個人知道自己接下來要做的事。
對營運老實，
不要替他們私下答應一些根本做不到的時程。
對研發也老實，
讓他們知道營運真的有壓力，
但你不是來叫他們加班的，
而是想一起找出成本最合理的方案。
◆ 如果你正好就站在這個位置
如果你現在也常常覺得，
自己每天都被兩邊拉來拉去，
下面的人覺得你不挺他們，
上面的人覺得你不夠積極，
那我想跟你說一件事。
會這麼累，
不代表你不適合當 PM。
很多時候，只是因為你站的位置本來就很尷尬。
營運希望你幫忙推快一點，
研發希望你幫忙擋住一些。
老闆希望你在有限的資源裡，多做一點。
你看得見每個人的壓力，
也真的能理解他們的為難。
但你也知道，
不可能每件事都照他們要求的那樣去做。
這不是讀幾本「溝通技巧」可以解決的事。
這是關於角色的現實。
身為 PM，
你很少有機會站在一個「安全又討喜」的位置。
但是，你會比任何人都更早看到，
產品哪裡出了問題，
流程哪裡卡住，
組織哪裡說一套做一套。
如果說工程師寫的是系統的程式碼，
營運下注的是市場的賭注，
那 PM 做的，
就是在這兩者之間，默默寫下一份「合作的規則」。
這份規則不一定會出現在文件裡，
但會留在每一場會議、每一次折衝、
以及你每天做出的那些小決定裡。
嗨，我是廣三。
如果你現在正站在跨部門的戰場， 覺得自己每天都快被磨到失去感覺。
我想告訴你： 你不需要把所有子彈都擋在身上。
真正的「肩膀」， 不是用來當沙包的， 而是用來扛住「規則」的。
當你能建立起那一套合作的規則， 你就不再是夾心餅乾， 而是這場戰局的「謀略家」。
別只顧著受傷， 試著抬起頭，看清這盤棋。
因為只有你知道， 該怎麼讓這群人，一起走到終點。
若你在PM這條路上感到迷茫，
或想更清楚了解自己的能力與定位，
歡迎試試這份《PM產品／專案雙軌分析報告》。
它不為了定義你，而是幫助你更看清自己。
歡迎關注：
官網：https://unityprosper.com/
部落格：https://hero-mi.com/
FB：https://www.facebook.com/DigiPRDCoachHeroMi
LINE OA：@hero-mi
《歡迎加我LINE，一起破局未來》
留言