從『專案熵』與『經驗曲線』回顧專案開案心得
By Po-Ming Chen in Career
October 1, 2025
剛好職涯近期做了轉換，先前除了寫了 PCAF 碳盤查系統化專案經驗分享，讓我也想再回頭看一下哪些經驗或工作成果值得被書寫記錄，並作為自主反思。
特別是事業處的『資料庫移轉專案』從籌備到開案的心路歷程。
在做 PCAF 碳盤查系統化專案的時候，本質上是參加別人訂好範疇的案子，執行面居多，加上也有專案監管單位（Project Management Office, PMO）的幫忙，縱使時程緊湊，但終究有人告訴你現在身處何處，專案要往哪邊走，預計何時可以到達哪裡。剩下的就是專注把被指派的事情做對，做好。
但是開始做資料庫移轉專案後，眼前的『迷霧感』成長了好幾倍。
作為專案成員，跟著老闆做，開始分擔專案管理的工作後，我發現沒有人會告訴你專案想要走到哪？專案的範疇哪些要留，哪些能捨？甚至工作包（Work Breakdown Structure, WBS）的相依性，也是要透過縝密的需求訪談會議，才能夠梳理得比較清楚。
另外若遇到資深利害關係人配合度不高，可以怎麼辦？
跟長官報告專案規劃和重大議題，可以怎麼報？才會讓他覺得問題正在恰當被關注，持續被解決，又可以趁勢爭取資源，而不會變成冒出隔靴搔癢的指示。
用『經營』的角度來看，一個專案要能順利，就像是經營一個事業。原來『持家』，是比想像地更不容易…
那我可以為自己多做點什麼呢？
如果退好幾步，重新由 101專案管理一日特訓班 課程心得 來看專案管理工作，最大的價值是寫出一套專案『人事時地物錢』的劇本，掌握專案的全貌，以利未來可以運籌帷幄，有效因應變動，也讓團隊成員知道彼此，此時此刻正在忙什麼，有沒有人工作負擔過重等等。
以我個人來說，把一件事『從混亂變秩序』，經驗上都是滿樂在其中的，或者說是『痛苦而快樂著』。不過當眼前的『迷霧感』，或者說『混亂感』，大到無法負荷的時候，也會令人有點手足無措。
首先，當然是擔心掛一漏萬，時間沒有花在刀口上；再者，也會擔心搞錯重點，原本事緩則圓，或讓子彈飛一下，急著想推進，反而因為思慮不周，處理錯方向，反倒治絲益棼，搞得人仰馬翻。
有時坐在座位上，看著專案議題表，想著現在要先找人討論 A 好，還是先處理 B 好，然後又想到先搞定 C，對 D 會有幫助…又意識到， ABCD 都要搞定，不然專案規劃書是很難落筆的，想著想著，腦袋都打結了哈哈哈
這種眼前專案『很多混亂、很多不確定』的感受、概念，後來發現其實不是我一個人特有的困擾，在 專案熵與經驗曲線 這篇文章的內容，完全可以充分表達我的心聲 XD
什麼是『熵』呢？可以單純理解為『事情、系統的混亂程度』。
拆解專案『子熵』的好處
慢慢地，我有一個體會（或許未來的我還會有新的轉變），專案管理工作，重點是把眼前『很多混亂、很多不確定』，適度拆解成不同『子熵』（這詞是我自己創的，若有誤，或者有專案管理領域的標準詞彙，還請指正）。
這時就可以搭配專案管理的一些基本概念。像是專案金三角，資源的三大類別，把事情拆解的比較小，就會比較好想。
像是專案金三角，就可以分為：
- 範疇的熵
- 時程的熵
- 成本的熵
像是依照專案資源的三大類別，就可以分爲:
- 人力的熵
- 機具的熵
- 物料的熵
我不否認不同『子熵』之間可能有交互關係，但拆解後，比較容易個別管理、降低，甚至是擊破。
拆成不同的『子熵』，還有一個很重要不得不的考量，就是『時間有限』。
專案管理工作，或者說專案經理，要有能力在對的時間點，判斷做對的事，然後再引領大家把事情做對。
另外一個體會是專案管理『很可能』無法追求『專案熵』為零的狀況。
個別『子熵』為零，是有可能的，也就是該部分全部抵定，但有趣的是，當你一不管他，不維持一定水平，甚至是相同高水平的管理力道，個別『子熵』又會長大（變得 ≥0）。
也就是它的失序程度又會隨著時間而變大，這時可能就得視情況，把管理力道挪回來。
換言之，專案動態發展下的任意一個時點，不是每一個議題，每一個子混亂都同等重要。
『專案熵』裡面總有特定的『子熵』是比較大的，有些則比較小，或者說還處在目前監控下，可包容的地步。而專注在降低『特定』『子熵』的作為，也就是 PM 該時點的工作重心、管理重心。
若其他專案核心成員也對專案管理有涉略，兩人可以用相同的頻率溝通，也可以嘗試將特定專案『子熵』的管理、控制請他協助，一方面有機會多管齊下，另一方面自己也才不會壓力太大，更延續『時間有限』的必然，有餘裕專注在最需要被管理的專案議題。
讓整體『專案熵』落在一個可包容的地步，讓事情可以有序地發生著，是 PM 工作的最大價值。
學習善用視覺化溝通的『經驗曲線』
另外一個針對 專案熵與經驗曲線這篇文章，很有共鳴的是所謂的『經驗曲線』。某種程度來說是一種『學習曲線』，就是隨著做某一件事情的經驗越多，執行的效率通常會提高，成本也可能會因此降低。
也就是說，循序漸進做某一件事情，對組織、個人來說，其實都是具備程度以上的價值或意義的。
從執行碳盤查系統化專案的工作任務，到支援資料庫移轉專案的專案管理工作，本質上兩個專案都是系統化、系統/資料庫建置類型的專案，從執行面的 1~100，進階到規劃面的 0~1，何嘗不是一種循序漸進呢？
也許該說自己是幸運的。
不然眼前專案籌備開案的工作『混亂感』可能不單只是有點手足無措可以形容的，可能就變得像是剛熟悉了如何組裝汽車，瞬間就要開始研發火箭的感覺…
陣亡機率應該不是成長了好幾倍而已，根本是指數型上升 XD
如果這兩個專案經驗，像是職涯旅途中，做專案執行、專案規劃工作的小節點，那也想趁這個機會記錄一下從籌備到開案過程中，『若有些地方能重來，從籌備第一天起，我可以怎麼做？』
算是用文字把經驗曲線描繪地更深刻一點，以利未來可以繼續從既有的曲線節點無縫接軌！
多善用視覺化的資料流做溝通
開始做資料庫移轉專案後，盤點下來，不重複的資料表有超過 1000 張。重點是上下游關係複雜，有從別的業務系統來的原始資料，然後經過許多層的資料滾算、ETL，然後得到相關的彙整結果表（像是依客戶不同產品別的定期交易筆數、金額）。
這種彙總計算的結果表，可能還會被收錄到全組織共用的平台給大家取用，或者也會給其他業務系統再介接回去，並顯示在前端畫面給使用者做業務經營上的參考。
除了資料表上下游關係很複雜，資料滾算的邏輯複雜度也不遑多讓…
一開始我多是用 Excel 紀錄整個資料流，一欄一欄，從第 0 層的來源表是什麼，從哪一個業務系統來的，再到第 1 層的中繼表，再到第 2 層的中繼表，依此類推記錄下去，然後再記錄到給了哪些下游系統。
若發現可能需要開會討論，或者需要請教資深同仁，就又會挪為一份投影片。
製作 Excel 和 PPT，起初是想說方便跟別人討論，但是卻也讓我的工作內容暴增為四倍：研究資料流 SQL，維護 Excel，維護 PPT，撰寫新資料表的開發規格書。
重點是還要確保這四邊的進度是一致的，變得容易忘記自己維護到哪，也排擠到專心研究資料流 SQL 的時間。
而且自己也不是只有一張表的資料流要看，如果要看 10+ 張表，假設中間都還有 2~3 層的資料流，眼前資料流的『熵』，因著工作流程的繁瑣又大幅提高了至少四倍…
而且還有一個麻煩點是，找到替代的資料源之外，還要找到適合的替代欄位，這都讓『非絕對必要』的 Excel，PPT 維護起來越來越吃力。因為這些細部資訊和替代欄位的取用邏輯、業務邏輯，應該可以直接寫在新規格書內即可，而無需在 Excel，PPT 內又多寫一次。
那可以怎麼做？
除了簡化工作流程，也需要在新規格書內容都抵定前，找一個地方可以記錄迭代研究出來的資料流、替代資料表、替代欄位對應。
後來我開始慢慢嘗試把所有資料流的梳理紀錄，都記錄到像是 Visio 的流程圖工具，流程圖工具並不完美，但至少有幾個好處：
-
一個 Visio 檔案就管理一張資料表
-
不同 Visio 內工作頁，可以記錄著每週迭代梳理的結果，每隔一週，或者有重大會議討論後的 Before/After，就複製出一個新工作頁繼續做，往前溯源也方便
-
一個 Visio 連結就可以完成資訊同步，大家看了視覺化後的資料流，需要口頭解釋來龍去脈的時候，所見即所得，比較不會雞同鴨講。若資料流梳理結果跟過往經驗有落差，也更容易提出討論。
-
一個 Visio 連結就完成會議資料準備，可以截圖放到議程、可以開會直接投影，省下額外維護簡報的時間。
另外有幾個習慣做法，也可以依照資料流的複雜程度，動態調整：
-
每一個流程圖物件就是一個資料表，藉此在整個畫布上展出整個資料表上下游關係（縱使繪製流程圖的規則，每一個物件是一個『動作/行為』，而不是名詞。但是在這個情境，稍微折衷一下）
-
考慮用『顏色』來區辨資料表（物件），哪些已找到替代資料源，哪些還沒，哪部分的資料流已經抵定並寫入新規格書。
-
考慮用『註解』來補充替代資料表內的替代欄位或欄位加工邏輯。
自從改用 Visio 類型的視覺化工具來梳理、紀錄資料流後，不論資料流多複雜，議題大小，透過建立一個視覺化的資料流，跟利害關係人口頭討論、準備會議，慢慢地有感覺比較輕鬆。
一通電話配上一個連結，彼此快速掌握癥結點，都比先前提供 Excel，PPT 或相關截圖來得方便許多。
如果時間能重來…我覺得第一天就應該開始善用視覺化的流程圖工具來梳理、紀錄資料流。
多善用視覺化的時程網圖做『動態』溝通
開始做資料庫移轉專案後，同時跟兩個 IT 團隊配合的配置，不確定是否很特別，但是至少應該不是每一個專案都如此。
起初的規劃，兩個 IT 團隊，工作內容是不會有交集的，僅是基於 IT 團隊的定位差異，有的偏向業務系統開發，有的偏向分析場景開發，而把 WBS 分配給不同的 IT 團隊。也各自拉出了不同 WBS 的時程。
隨著專案進展有一個工作任務的相依性問題，因著對工作任務排程『相依性辨識不足』，導致滿晚才發現…
具體是『IT 團隊甲』 ，說他的 WBS_1，預計規劃成相依的五大任務，姑且就叫做開發程式任務第 1~5，時程預計 3 個月。但是開始進行這 1~5 層程式開發任務前，要先完成兩張資料表 A, B。
兩張資料表也如期展開了規格書撰寫的工作…
偏偏在某一次會議中，決定要把資料表 A, B 框在『IT 團隊乙』的 WBS_2，然後因為專案時程只有維護 WBS 的時程，並沒有細緻到工作任務的時程，結果表面上看起來無關的『甲_WBS_1』和『乙_WBS_2』，其實底下的工作任務是有相依性的，卻沒有人能看出來，真的等到『IT 團隊甲』，要準備寫 SA 文件時，才發現動不了 XDDD
這是一個對範疇『熵』理解不夠深刻、意識不足，導致對時程『熵』始終自我感覺良好，然後在一瞬間幻滅，得面對真實的窘境。好險 PM 之間協調後逢兇化吉 XD
如果時間能重來…
考量 WBS 本來就偏向條列出專案要做哪些事情，專案完成時要交付哪些項目，著重在拆解專案結構和確定專案範疇，比較沒有去管相依性；進到工作排程後，哪些任務誰先誰後，才會是重點。
那麼，從專案籌備期，做專案計劃書時候，至少就要把時程網圖（甘特圖）細緻到工作任務的水平。就算一開始有點粗糙，也可以慢慢補上，開案後有做調整也沒問題。
而且最好是每一次重要決議前後，都把排程再看一次，有沒有工作任務（甚至是 WBS）要拆成獨立一個，以利追蹤、檢視？好比說這個要拆出來的工作任務，預計是要放在哪一個任務的後面或後面？要指派誰來負責？會不會影響到要徑？
確定要調整的話，就複製出一個新工作頁或檔案，往前溯源也方便。
若有卡住的地方，恰好就反應了現在時程『熵』（甚至是範疇『熵』）偏高，最好審慎因應，及早跟利害關係人討論。
調整後也可以趁著專案例行會議進行佈達，確保大家從『人事時地物錢』的角度，知道自己、團隊成員在接下來專案的各時點，將要做什麼，將在做什麼，有沒有窒礙難行的地方。
結論
好的，差不多到一個段落了。剛開始接觸專案管理工作時，我覺得『文件化』是一切，什麼都覺得需要寫下來，不然會忘記，或者怕有人要來翻案會沒有依據。
這對也不對，畢竟如果只是做記錄，像是會議記錄、寫文件，而不能『把頭浮出水平面』預先觀察專案眼前可能有哪些阻礙，並且通知團隊（甚至是老闆）有這樣的風險，然後嘗試排解…那其實這個工作，請助理來做就滿可以了。
慢慢地，我覺得如何在『有限的時間內』恰當地面對眼前的混亂（畢竟眼前的障礙、混亂可能很多），並且把時間花在刀口上，『專案熵』的概念與拆解，可以幫上許多忙。
讓事情可以有秩序地如期發生，讓團隊成員可以專注在崗位上發揮所長（研發、行銷、分析等），是專案管理工作最大的價值。
另外專案的環境終究是一個團隊，如何可以換位思考：
-
他人在想什麼？
-
他可能要什麼？
-
我要什麼？
-
預測他會做出什麼行為？
-
目前他最可能的行為，跟我要的有多契合？
-
如果不是，我能做什麼來影響他？
在影響他人的階段，學習更善用『視覺化、圖像化』的工具或概念，我覺得也是專案管理工作中，『文件化』的更上一階。
輕巧地讓他人看到你看到的，就能讓專案內外的溝通，更加順暢，趨吉避凶。
好的，真的告一個段落了。我想我還有許多可以累積的！