有一段時間，我很認真在補「技術能力」。
看書、買線上課程，連假日都在跟程式語法奮戰。
那時候心裡有一個很單純的想法：
「如果我更懂一點 coding，研發是不是就比較不會那麼火大？」
直到後來，我才慢慢發現，
真正讓研發生氣的，
從來不是你會不會寫程式，
而是你在畫流程、寫規格、丟需求的那一刻，
到底看不看得懂「系統是怎麼運作的」。
◆ 你以為自己畫的是流程圖，研發眼裡看到的是一團打結的箭頭
很多 PM 第一次畫流程圖，都會有一點小小的成就感。
方塊有了、箭頭有了、按鈕有了，
看起來就像是課本上的範例。
我以前也是這樣。
後來有一次我拿著自己畫的流程圖，興致勃勃地去跟技術主管討論。
我一邊指著圖，一邊解釋：
「使用者先點這個按鈕，跳到這個畫面，
選完東西之後按確認，再到下一步…」
我講得眉飛色舞，
技術主管看了一陣子，只淡淡地問：
「那資料從哪裡來？
這一步要存什麼？
哪裡是暫存，哪裡是寫進資料庫？
如果中間失敗了，狀態是回到哪一格？」
那一瞬間我就愣住了。
因為我畫的，根本不是「系統流程」，
我畫的是「使用者故事」。
在我眼裡，流程圖是頁面怎麼切換、按鈕怎麼點。
在研發眼裡，流程圖是資料怎麼流動、狀態怎麼改變。
這兩件事差很多，但我之前一直沒有意識到。
於是後面就變成這樣的日常：
我沒寫清楚條件，研發就問「那不符合條件呢？」
我沒定義好例外，研發就問「那錯了以後要怎麼辦？」
我沒想資料結構，研發就問「這個欄位後台抓得到嗎？」
而我最常講的一句話就是：
「好，我回去想一下。」
你以為自己在負責確認需求，
但在研發耳裡，這句話常常會被翻譯成：
「我還沒想清楚就先丟給你們了。」
◆ 你不懂系統的代價，永遠會反映在「改需求」這三個字上
很多 PM 都覺得，
需求改一改很正常，
市場會變、營運會調整，專案本來就不可能一次到位。
改需求本身沒有錯。
問題是，有些修改不是因為「市場變了」，
而是因為「一開始就沒想清楚」。
你不懂資料流，
所以少了一個欄位，要事後補。
你不懂狀態轉換，
所以流程卡在一個「不上不下」的地方。
你不懂例外處理，
所以工程師只好在程式裡一路塞 if else。
你不懂架構範圍，
所以很輕鬆地說了一句「這裡改一下就好」，
結果研發發現，要動的是好幾個模組。
從你的角度看，
好像就是：「不好意思，又要麻煩你們調整一下。」
從研發的角度看，
則是：「你這個洞，為什麼一開始沒看到？」
你不知道的每一個小細節，
最後都得用他們的工時來補。
補一次，抱怨一次。
補十次，怒氣就會慢慢累積起來。
◆ PM 的一句話，往往是研發好幾天的夜晚
有一種場景，應該很多人都很熟：
你開完會，回到座位上，
突然又收到一封營運的訊息：
「不好意思，剛剛漏講一點，
那個規則我們想再調整一下。」
你心裡一緊，
但還是硬著頭皮走去研發座位旁邊。
「欸，那個…我剛剛跟營運再確認，
這邊的條件要再多一個…」
你說完之後，
眼前這位工程師的臉沒有什麼表情，
只是深呼吸一下，點點頭說：「好。」
你可能會鬆一口氣，覺得「還好，他好像沒有很生氣」。
但你沒有看到的是，
他心裡正在默默把剛剛寫好的那幾百行程式碼直接 delete
對 PM 來說，只是多補一行規則文字。
對研發來說，可能是：
重寫一段邏輯。
重跑一輪測試。
重新檢查條件。
重新確認會不會影響其他功能。
你漏想的，是一個條件。
他多做的，可能是三天。
久而久之，
你會感受到一種很奇怪的氣氛：
表面上大家客客氣氣，
但只要你一走進開發區，
就會不時的感受到工程師的「嘆氣」。
那不是你多敏感，
只是每個人都在想著：
「這次又要改什麼？」
◆ 最讓人受傷的，不是被罵，而是被當成「笨蛋」
說實話，多數工程師沒那麼愛吵架。
很多話他們其實懶得說出口。
真正讓 PM 痛的，
往往不是情緒爆炸當下的那幾句重話，
而是那種無聲的評價：
「這個 PM 好像沒在想系統怎麼運作。」
「丟過來的東西洞太多了。」
「每次都要我們幫忙補需求。」
有時候，你甚至會聽到類似這樣的句子：
「你這樣畫不行啦，邏輯是錯的。」
「你這流程會死在這一步。」
「你這樣設計資料，報表一定拉不出來。」
表面上是在談設計問題，
實際上在傷的，是你對自己專業的認同。
因為那背後隱含的訊息叫做：
「你沒有把這件事想完。」
久了之後，你可能會開始懷疑自己：
我是不是不適合當 PM？
是不是我反應不夠快、邏輯不夠好？
是不是我本來就不該碰這種系統類的東西？
◆ 真正拉開差距的，不是coding，而是「系統架構」
嗨，我是廣三。
一名在軟體開發打滾二十年的 PM。
回頭看這些年，
我發現一個很殘酷、但也很關鍵的現實。
PM 和 RD 之間真正的差距，
不在於會不會寫程式，
而在於，當你在看一個需求的時候，
腦袋裡到底有沒有一個「系統的架構」。
你可以不會寫 code，
但你至少要慢慢知道：
系統是怎麼接到一個請求的
資料是怎麼被存進去、怎麼被拿出來
一個狀態怎麼從「建立」變成「完成」或「失敗」
API 之間是怎麼互相依賴的
一個例外情況有可能會拖累哪些地方
甚至當工程師在說API時
起碼要知道API是甚麼，而不是站著發呆
這些東西，不是叫你變成工程師。
而是讓你在畫流程、寫規格、拆需求時，
不再只是用「畫面」在想事情，
而是慢慢用「系統」在看整個產品。
你理解越少，
研發就越需要用debug來幫你補課。
你理解越多，
不一定代表你會變成多厲害的技術專家，
但bug會少一點，
專案的反覆會少一點，
大家一起踩雷的次數也會少一點。
◆ 從「被動挨罵」到「一起建構系統」
如果你現在正在經歷這種：
畫出來的流程圖總是被挑毛病、
寫出來的規格總是補不完、
每天都在跟「改需求」搏鬥、
還常常覺得自己像一個不被信任的 PM，
我想先說，
這不代表你不適合這份工作。
很多時候，只是因為沒有人好好教你，
「怎麼用系統的角度看同一個產品」。
當你開始願意多問一句「那資料要從哪裡來？」
多想一下「這一步失敗時，狀態要回到哪裡？」
多畫一條「錯誤路徑」而不是只畫「順利路徑」，
你會發現，研發問你的問題會慢慢變少，
開規格會時的火氣也會慢慢下降。
因為在那個當下，
你已經不是單純的需求搬運工，
而是跟他們站在同一邊，一起設計系統的人。
系統分析與設計，
聽起來很像課本裡的名詞，
但對 PM 來說，它其實是很實際的一件事：
它決定了，你畫出的每一個框、每一個箭頭、每一句規則，
是讓別人多做三天，
還是幫大家省掉三次的重工。
而當你開始看得懂這些背後的關係時，
研發對你的那一份怒氣，
就有機會，慢慢轉成一點點信任。
甚至有一天，你會發現：
當 RD 遇到難解的邏輯時，
他會轉過頭找你確認：
「我們去白板那邊，討論一下系統流程。」
那一刻，你就不再是一個「提需求的人」，
你是一個被工程師認可「懂系統的人」。
若你在PM這條路上感到迷茫，
或想更清楚了解自己的能力與定位，
歡迎試試這份《PM產品／專案雙軌分析報告》。
它不為了定義你，而是幫助你更看清自己。
歡迎關注：
官網：https://unityprosper.com/
部落格：https://hero-mi.com/
FB：https://www.facebook.com/DigiPRDCoachHeroMi
LINE OA：@hero-mi
《歡迎加我LINE，一起破局未來》
留言