有一段時間，我很認真地在思考「什麼系統」。
去書店買了一本《系統分析與設計》，
打開之後，前面幾章還勉強看得下去，
看到後面開始出現各種圖：
什麼資料流程圖、狀態圖、循序圖、類別圖，
我就開始習慣性地跳過。
不是因為我不想學，
而是那整個世界看起來就很陌生。
我後來改用另一種方式「理解系統」：
看人家怎麼畫流程、怎麼拆功能，
跟著做一樣的事，
但是很可惜，
一直都找不到可以幫我建構「系統」的書本或文章。
市面上的書籍，講得和實際工作要用的情境差太多，
非常不容易理解。
期望著，量變創造質變，
如果學會一堆工具，然後加在自己的工作裡，
是不是可以改變甚麼？
於是流程圖有了、框線圖有了、循序圖有了、實體關係圖也有了
系統畫面規劃得很完整，
會議上也說得出一些「看起來很懂系統」的話。
但有一件事一直沒有變。
只要工程師一開始討論
「這裡的狀態會衝到哪裡」
「這一步如果失敗要不要防呆」
「這樣實作以後要怎麼擴充和維護」
腦袋就自動變成放空模式：
「讓我再回去想想…」
那時候我心裡常常浮現一個念頭：
「系統真是一個難搞的大魔王…」
直到很後來，我才慢慢接受一件事。
問題不是「我不會畫圖」，
也不是「我不懂那些名詞」。
而是：
我一直用原本那套 PM 的思考方式，
硬要去理解一個完全不一樣的世界。
這個落差，如果沒有被看見，
你就會一直覺得自己很笨，
卻不知道自己到底卡在哪裡。
◆ PM 習慣的，是「User Story」式的思考
因為我們就是被這樣訓練思考的。
先釐清使用情境，
把使用者的旅程寫出來，
從入口到完成，
一步一步規劃出來。
在這個框架裡，問題會變成：
「使用者從哪裡進來？」
「接下來要看到什麼？」
「按了之後要去哪一頁？」
「最後要完成哪個任務？」
這種思考方式很接近「寫腳本」：
從開場、發展，到結尾。
你會很自然地用時間順序整理事情，
用操作步驟拆需求，
用流程線，把一切串起來。
這對 PM 來說非常直覺，
也很重要，
因為沒有人比你更接近真實使用情境。
只是，當你拿著這一套走進系統的世界時，
就會開始覺得哪裡怪怪的。
因為系統在乎的，不只有「腳本走得順不順」，
它還在乎「這個世界會不會因為你自由發揮，導致崩毀」。
◆ 系統在意的，是「狀態、關係和後果」
有一次我跟技術主管討論一個流程。
我拿著自己畫好的圖，從頭講到尾：
哪一步要填什麼欄位、
按完會跳去哪裡、
成功時顯示什麼畫面。
我講到一半，他突然打斷我。
「等一下，那這筆資料在系統裡，到底會有幾種狀態？」
我愣了一下，只能很心虛地說：「大概就是已送出、已完成、失敗吧…」
他接著問：
「那使用者儲存草稿算什麼？
超過期限會變什麼？
審核中算哪一種？
被退回要回到哪個狀態？
報表要抓哪幾種算進統計裡？」
那一刻我才意識到，
我腦中一直在想的是「步驟」，
而他在想的是「狀態」。
我在意的是「接下來要去哪裡」，
他在意的是「這件事處在什麼位置」。
對我來說，流程像是一條路，
只要走得順就好。
對他來說，系統比較像是一整座城市：
每一條路連到哪裡、
水管怎麼走、
電怎麼供、
哪裡不能堵住、
哪裡出問題會整片停擺。
你加了一根水管，
不只是多一條線，
而是整個壓力分配要重新計算。
這就是差別。
PM 看的是「路線」，
工程師看的是「結構」。
◆ 你一直在結果那一端，系統卻卡在條件那一端
在需求討論裡，
PM 最常說的句子通常長這樣：
「使用者按下去，要看到什麼。」
「這一步完成之後，要出現哪一個頁面。」
「成功的時候，給他什麼提示。」
換句話說，你在講的是
「事情順利的時候，要怎麼收尾」。
但系統的世界有一大半的力氣，
都花在「不順利的時候，不能讓它爆掉」。
所以工程師問的東西，
常常會讓 PM 覺得他們是不是太愛鑽牛角尖：
「這裡沒資料的時候，你要怎麼辦？」
「同一個人同時送兩次，算一次還是兩次？」
「網路斷掉之後重新整理，要不要重送？」
「權限不夠的人如果硬是進來，要不要記錄？」
你覺得那是工程師在雞蛋裡挑骨頭，
但對系統來說，那才是它活不活得下去的關鍵。
如果你一直停在「結果」，
系統就一直得幫你補「條件」。
久了之後，你會養成一個很熟悉的反射動作：
工程師問：「那這個狀況要怎麼處理？」
你回答：「嗯…這個我回去想一下。」
表面上看起來是你很負責，
實際上在對方耳裡，
常常被解讀成：
「你還沒想完就丟過來了。」
這就是落差，
不是你不用功，
而是你從頭到尾都待在結果那一端，
從來沒有真正站到條件那一端看過一次。
◆ 最折磨人的，是那種「一直在門外打轉」的感覺
很多 PM 在這裡會出現一種很強烈的挫折感。
你不是完全聽不懂工程師在講什麼，
但也說不上來自己到底懂了多少。
你知道要畫流程，
也知道要寫例外情境，
甚至會提醒自己「要想清楚欄位」。
可是每一次技術評估會議開完，
你還是會有一種熟悉的悶：
怎麼大家看起來都比我更清楚，
這個系統在做什麼？
久了之後，你可能會開始懷疑自己：
是不是我真的很笨？
是不是我邏輯真的很差？
是不是我根本不適合這個工作？
這種自我懷疑，比被罵還累。
然後想買書來提升自己，結果書還看不懂…
但如果回頭看，其實很多時候問題不在能力，
而是在一開始就沒有人告訴你：
你不能只用原本那一套 PM 腦袋，
去理解這些東西。
你需要的不是再多畫幾張圖，
而是有人帶著你，
從另外一個角度看同一件事情。
◆ 系統分析的起點，不是圖，而是換一種思維方式
後來我開始刻意練習一件很小的事。
每次在寫需求、畫流程之前，
先讓自己停個幾分鐘，
把原本那種「先講步驟」的習慣暫時放旁邊，
改問一些自己以前不太會問的問題。
例如：
「這件事，在系統裡到底是哪一筆『東西』？」
是訂單？一個申請？一個任務？一個紀錄？
「這個『東西』，從頭到尾會經過哪些狀態？」
只要一句話就會卡死的那種地方在哪裡？
「誰有權限動它？」
前台可以改嗎？
只有後台可以改嗎？
還是其實誰都不能改，只能新增下一筆？
「如果這一步失敗，系統要留下什麼痕跡？」
要不要記 log？
要不要提醒客服？
要不要之後可以重試？
你會發現，
當你把這些問題問出來時，
後面要畫的那些圖、
要寫的那些規格，
就會長得不太一樣。
你不再只是畫一條「使用者走過的路」，
而是在設計一個「系統撐得住的世界」。
◆ 拆掉原本那套想事情的方式，才真的踏進系統的門口
嗨，我是廣三。
在軟體開發的環境裡，當 PM 已經二十年了。
現在回頭看，
我會把「學系統」這件事，
总结成一句話：
系統分析，從來就不是會幾種圖的問題，
而是你願不願意，
把自己原本習慣的那套思考方式拆開來重練。
從只看「接下來要去哪裡」，
變成先問「現在是什麼狀態」。
從只在乎「使用者操作順不順」，
變成也在乎「系統會不會被拖垮」。
從只想「這個功能要長什麼樣子」，
變成開始想「這個功能會連動到哪裡」。
當你真的開始這樣練，
你會發現一件蠻安慰人的事：
你並不是不適合碰系統，
你只是以前沒有人告訴你，
要先換一顆腦袋，用另一種方式看它。
當你拆掉了那道「我不懂技術」的高牆，
你會發現，牆後面的風景其實沒有那麼可怕。
工程師不再只是「修正你畫錯的流程」，
而是會抬頭問你： 「你覺得這樣設計，有沒有邏輯上的問題？」
那個瞬間，
你就不再只是一個畫圖的人，
而是一個真正開始「思考系統」的人。
若你在PM這條路上感到迷茫，
或想更清楚了解自己的能力與定位，
歡迎試試這份《PM產品／專案雙軌分析報告》。
它不為了定義你，而是幫助你更看清自己。
歡迎關注：
官網：https://unityprosper.com/
部落格：https://hero-mi.com/
FB：https://www.facebook.com/DigiPRDCoachHeroMi
LINE OA：@hero-mi
《歡迎加我LINE，一起破局未來》
留言