如果說跨部門協調，像是在前線擋子彈，
那「需求轉譯」就是你每天回到營區後，還得一個人加班拆炸彈。
表面上看起來，你只是在寫文件、畫流程圖、補規格。
實際上，你是在替整個團隊，把那些還沒長出形狀的東西，
硬是拆解成一個可以被實作的系統。
而這個過程，很少有人看見。
◆ 營運講的是「抽象」，研發要的是「規格」
你應該很熟悉這些開場白：
「就做成像某某產品那樣就好。」
「幫我做一個活動頁，簡單版就行。」
「把流程調整一下，邏輯差不多，應該不難。」
在營運的世界裡，這些話背後是畫面和情境，
是一個想像中的結果：
使用者順順地完成操作、活動數字往上衝、報表看起來很漂亮。
可是在研發的世界裡，同一句話翻譯過去，
就是一個尷尬的空白。
他們需要的是：
有幾種使用情境？
每一種流程的步驟是什麼？
權限怎麼控管？
有沒有例外狀況，然後怎麼處理？
需要哪些欄位、資料從哪裡來？
成功與失敗要怎麼回報給使用者？
活動怎麼開始、怎麼結束、怎麼驗證成效？
營運給你的是一個「抽象的概念」，
研發要的是「具體可以直接寫進程式裡的邏輯和流程」。
而你，就剛好站在正中間。
你得把那一句「做個活動頁」拆成：
這個活動有幾種玩法？
不同會員等級有沒有不同規則？
什麼條件下可以參加，什麼情況下要被擋下來？
點數從哪裡扣、扣完之後要不要回補？
活動結束後，還能不能查歷史紀錄？
營運沒講的、沒想的、以為「到時候再說」的，
最後都會變成你文件裡的一行行文字。
◆ 你面對的不是「需求不清楚」，而是「根本還沒被想過」
很多 PM 喜歡在文件上寫一句：
「需求待確認。」
但你心裡知道，如果真的放著不管，
等到上線前被翻出來，就是一場災難。
你遇過這種對話嗎？
營運說：「就做得像雙11那樣。」
你問：「那雙11哪樣？」
營運說：「就是很多優惠、很多活動，大家會很想買。」
你再問：「那邏輯是什麼？限制是什麼？要看什麼數字？」
營運沉默三秒：「這個我還在想。」
表面上看起來，是需求不夠清楚。
其實更接近真相的，是有認真思考過，只是不是技術要的。
但也不能怪營運，因為營運也不知道要怎麼去思考怎麼做出來。
但專案沒辦法等到大家都想清楚才開始，
時程往前推、簡報已經送上去、活動時間也公告了，
唯一還能動的，就是你。
於是你開始幫需求「具象化」：
如果沒有講例外，就先假設一個最保守的狀況。
如果沒有講權限，就先幫他想一個合理的作法。
如果沒有講風險，就先替系統多加幾道檢查。
你以為自己只是在把需求補齊，
其實你已經在替整個團隊，代打那一段「本來應該要有人先想好的東西」。
而這一段，很多人都覺得是PM本來就該做好的事。
◆ 每一次補上去的，不只是邏輯，還有你的精神力
回頭看你寫過的需求文件，
會發現一個很殘酷的事實。
那些一行行看似平靜的文字，
其實都是你某一天被追問、被否決、被重來、
然後咬牙撐住之後留下的痕跡。
你知道，只要少寫了一個例外，
最後出包時會是這樣的劇本：
營運會說：「當初就說要考慮到這種情況。」
研發會說：「文件裡沒有寫，我們照文件做。」
老闆會說：「當初 QA 怎麼沒測出來？為什麼沒辦法先提前跟客戶預告？」
於是，你開始寫得越來越細。
流程圖從一張變成三張，
規格書從十頁變成五十頁，
備註從幾行變成幾大段。
你以為是在保護專案，
某種程度上也是在保護自己。
久而久之，你會產生一種很微妙的疲憊：
不是對專案厭倦，
而是對「永遠補不完的空白」感到無力。
明明表面上大家都說要「共創需求」，
實際上卻很少有人願意真正在細節上跟你一起下潛。
多數人，只是把那一大塊思考的工作，默默交給了你。
◆ 你以為問題在「不會寫程式」，其實卡住的是「不了解系統」
很多 PM 在這個階段會開始懷疑自己：
是不是我也要學寫程式？
如果我看得懂 code，是不是就比較不會被擋？
是不是我也要成為半個工程師，
才有資格談規格、談架構？
於是你開始上課、買書、看教學影片，
勉強寫出幾支小小的程式。
這些學習不是壞事，
只是有一天你會發現：
就算你看得懂一點語法、
知道什麼是 API、
可以自己打個簡單的請求，
你還是很難：
把一個模糊的想法拆成完整的系統邏輯，
看得出來這個流程哪裡會卡住，
預先想到資料流會不會打結，
判斷這個需求適不適合現在這個架構。
你缺的不是「寫程式」的能力，
你缺的是「看系統」的能力。
那是一種比較接近這樣的東西：
-系統裡有哪些角色，每個角色在做什麼？
-一個動作背後會經過哪幾個服務？
-資料從哪裡來、會被存到哪裡去？
-哪些地方出錯會波及到其他模組？
-哪些邏輯應該寫死，哪些地方要留彈性？也就是很多 PM 一路做著，
卻從來沒意識到已經在接觸的那塊：「系統分析與設計」。
◆ 真正決定你會不會被需求吃掉的，不是年資，而是你有沒有「系統地圖」
嗨，我是廣三。
一名軟體開發二十年的 PM。
一路走到現在，回頭看才發現，
自己最痛的那些時期，
幾乎都跟「不懂系統」有關。
不懂系統的時候，
你會一直被需求推著跑，
永遠在後面補文件、補流程、補例外。
懂一點系統之後，
你會開始有能力，
在需求還只有一句話的階段，
就看得出來哪裡會出事。
到最後你會發現，
PM 和 RD 之間真正的界線，
從來都不是「會不會寫程式」，
而是「能不能把一個想法變成一個能活在系統裡的東西」。
當你沒有系統思考能力時，
你只是需求的搬運工，
今天這個說一句、明天那個改一句，
你就跟著文件左改右改。
當你慢慢養出系統分析與設計的能力，
你才有辦法：
在需求還是空氣的時候，
就幫它長出一個合理的骨架；
在別人只想著功能的時候，
順便替未來的維護留一點活路。
這不是要你變成工程師，
而是讓你在這條「把空氣變成規格」的路上，
不再只是用燃燒自己的方式往前撐。
如果你現在正被各種半成品的需求追著跑，
或許可以先停下來問自己一個問題：
我每天在補的那些空白，
能不能變成我看系統的起點？
當你沒有系統思考能力時，
你只是需求的搬運工…
用燃燒自己的方式往前撐。
但當你有了那份「系統地圖」，
你不再是被動地「翻譯」，
而是主動地「導航」。
你可以不用再等到 RD 打槍你，
才知道路不通；
你可以不用再等到上線出包，才發現邏輯有洞。
你依然會累，
但那種累，不再是無底洞般的燃燒，
而是像建築師看著藍圖變現的篤定。
這才是「需求轉譯」的終局，
不是為了寫出更厚的文件，
而是為了讓你在混亂的空氣中，
一眼就能看見需求的地圖。
若你在PM這條路上感到迷茫，
或想更清楚了解自己的能力與定位，
歡迎試試這份《PM產品／專案雙軌分析報告》。
它不為了定義你，而是幫助你更看清自己。
歡迎關注：
官網：https://unityprosper.com/
部落格：https://hero-mi.com/
FB：https://www.facebook.com/DigiPRDCoachHeroMi
LINE OA：@hero-mi
《歡迎加我LINE，一起破局未來》
留言