案例 · 軟體專案管理

讓一群人,
把一件事做完

資訊系統整合與集團 IT 的專案管理。帶開發團隊替客戶建置客製化系統,從需求訪談、規格、時程控管,一路到上線與使用者教育訓練;後期轉任駐點部門主管,同時管理分派在十幾間客戶公司的團隊。

資訊業 2001 – 2020 · 其中軟體專案管理十年以上

2009 – 2013 因生育與育兒暫離職場,2013 年回到專案管理,一路做到帶部門。

9,381
全國到考人數(單次)
0
事故
30
帶領人數上限
10+
同時駐點的客戶公司
起點

先是做的人,才是管的人

入行的前五年我不是在管專案,是在做東西。這件事後來決定了我當 PM 的方式—— 規格寫不清楚會變成多少返工、一個需求改下去工程師要動幾個地方,我知道,因為我自己動過。

2001 – 2002
三光行
系統整合工程師 企業入口網站的整合導入,以及網站功能的專案管理。第一次接觸「把系統導進一間公司」這件事。
2002 – 2004
宏通數碼
專案及應用工程師 UI 設計、網頁應用程式開發、資料庫維護、客戶技術服務。同時碰介面、後端與客戶,四件事在同一個人身上。
2004 – 2006
SOHO 接案
網頁設計師 平面、網頁與多媒體動畫設計。自己找案子、自己交付——二十年後的接案專案,規矩就是從這裡學的。
角色

兩種責任,兩種難處

一種是把一個專案做完,一種是讓十幾個專案同時不出事。後者要管的不是進度,是人。

專案經理
帶開發團隊為客戶建置客製化系統 需求訪談 → 規格 → 時程控管 → 上線 → 使用者教育訓練,整條流程走完,不是只顧到交付。
駐點部門主管
最高帶領近 30 人,分派於十幾間不同客戶公司 同一時間橫跨多個客戶專案。負責目標設定、績效考核與人才培育——人不在自己眼前,管理方式就得換。
兩個接手的案子

都是接手,不是從零開始

兩個都是別人做到一半、狀況已經發生的案子。接手比新建難的地方在於:你沒有重來的權利。

案子一 · 不能出錯的那種

國家級客語認證考試系統

分兩天舉行、全國 9,381 人到考的認證考試系統,中途接手。

這種系統的特性是沒有第二次機會:考試當天出錯,不是延後上線就能解決,是全國考生的權益。所以準備工作的重點不在功能多完整,在於每一種會壞的情況都事先想過、而且演練過。

結果是零事故。

案子二 · 結不掉的那種

台大語言中心(LTTC)考試系統

接手時已經瀕臨無法結案。功能一直在做,但永遠有下一項;雙方對「這個案子什麼時候算做完」的認知從來沒有對齊過。

我做的第一件事不是排時程,是重新跟客戶談定「完成」的定義——把它從一種感覺,變成一組寫得出來、雙方都認的條件。定義一旦談定,剩下的就只是把它做完。

案子順利結案。

後面這一句,是我後來每一個專案都在用的: 案子結不掉,通常不是做得不夠多,是沒人講清楚做到哪裡算完。

集團 IT

在製造業做系統導入

佳世達資訊技術服務部,負責集團多系統的規劃、導入與維運。使用者是自己的同事,這讓「導入」變成一件跟人有關的事。

系統導入
集團多系統的規劃、導入與維運 需求分析 → 跨部門協作 → 驗收上架。跨部門最花時間的不是技術,是讓各部門對同一件事的定義一致。
資料交付
以 MS SQL 產製使用者實際需要的報表 不是把資料丟出來就算交付——使用者要的是能拿去做決定的那一份。
遠端協作
與中國的工程師團隊遠端協作開發與測試 負責規格、進度與品質控管到上線部署。人不在同一個辦公室,規格寫得夠不夠清楚會直接變成返工成本。
這條線

換了場景,招式沒換

離開這個產業之後,我開過一間店、做過一個品牌的數位營運、接過一個案子、替自己蓋了一套 AI 系統。看起來跳得很遠,但每一次解的其實是同一題。

LTTC 那次是「重新談定完成的定義」;後來接案時把驗收變成一個有日期的事件、訂位系統把「誰還沒確認點餐」變成資料庫上的一個檢視、AI Agent 把「今天該做什麼」變成畫面上看得到的一行——都是同一件事:

把「做到哪裡算完成」
從腦袋裡的感覺,
變成看得見、對得起來的東西。

差別只在於,以前這件事靠會議和文件達成,現在我可以直接把它做進系統裡。 而我做得出來,是因為入行的前五年本來就在做——不是學了 AI 才會。

回到
作品集