架構師的思維 - 專案管理系統

當您開始思考如何設計一個軟體系統，讓專案管理者 (Project Manager) 能有效管理專案計劃時，合宜的系統架構該長成什麼樣子? 您是否會立即在腦中浮現一個多層級的樹狀結構？這樣的圖像可能讓人聯想到 Microsoft Project 工具軟體的操作介面，最上層是整個專案計畫，下一層解析出數個主要任務，再往下延伸至細部工作，最底層的單項工作則包含工時、內容、負責人、進度百分比等資訊。

如果以此概念進行 UML 模型設計，或許會發現，這樣的架構模型與資料庫設計中的 ERD (Entity-Relationship Diagram) 相當類似。它以樹狀結構為骨幹，連結著各種常見的介面物件。在此基礎上，封裝相關的資料物件的介面，例如新增、修改、刪除、查詢等操作，似乎成為了順理成章的選擇。然而，這種思維框架可能讓我們只專注於「看得到」的部分，而忽略許多更關鍵的「隱性」要素，究竟這裡有什麼不對勁的地方呢？

問題的根源在於，我們思維過於習慣以視覺呈現的資訊為主，從而將標示「可視資料物件」選為主要的系統視角。這並非錯誤，但它僅僅提供了一個「靜態面向」。在物件導向分析方法還未普及前，這樣的資料結構視角或許是主流，然而，純粹以資料結構為重點，卻容易導致「管理」的語意被弱化，特別是在「動態面相」上。專案管理不僅涉及計畫的制定，還包括要在執行過程中不斷查核進度，並因應外部事件（例如規格變更、進度落後、超出預算等），做出適應性調整。若僅以靜態資料的視角呈現，動態的語意將散落到架構的各個角落，顯得支離破碎。

我們常說，好的架構應該具備簡約的美感，做到「所見即所得」，看似直觀易行。但是忽略那些「看不到」的維度，如時間軸、歷史記錄、瞬時事件、快速調整等，有時反而丟失了「管理」的語意。選擇合適的視角，絕對是設計架構的關鍵起手式。ERD 類型的設計比較適合描述靜態的物件，但切記「管理」本質上是圍繞動態行為的，我們可以考慮以 PDCA (Plan-Do-Check-Action) 的程序循環來作為主要視角，也許更能貼合管理的需求，構建出更合適的模型。

在 PDCA 這四步驟中，"Plan" 用於生成想定的工作物件（可參考《設計模式》一書中的創建型模式）；"Do" 則是更新進度，這可以藉由過人工輸入實際工作進展、或設計自動感測器 (Sensors) 收集資料，像是分析任務的產出文件來獲得資訊；"Check" 是關鍵核心動作，負責比對原先預設目標與當前實際狀況的差距；而 "Action" 則代表決策後調整結果並反饋回到 Plan 中。以管理動作發生的時間來看，Plan 位於計畫初始階段或一個PDCA循環的開始，而 Do 則像是 IoT 資料，隨時源源不斷輸入；Check 多半是定期進行的進度審核，當發現差距時，便觸發 Action，讓管理者做出決策以調整計畫。

專案計劃的管理不僅是時程而以，還涉及品質與成本。管理的核心操作都在於 Check，它應作為獨立的語意核心物件，被單獨提出來，周邊連結 Plan 工作物件、以及 Do 衡量進度的物件。抽象定義，Check 的目的是查核現況與目標的吻合度。在時程面上，每項工作任務都有預期工時，隨著執行進度的推進，產出記錄也不斷更新。衡量工作進展類似一種策略，可以藉由計算文件產出的數量，或是累計個案通過的數量得出。品質和成本的管理亦是如此，透過定義衡量方式、設立清晰的目標、收集實際數據，便能有效地追蹤和管理進展。

當 PDCA 的流程被完整建模為架構時，系統主體是一個個疊代的小循環，這些小循環又串成了更大的循環，這樣的設計更符合管理的本質。小規模的循環快速運轉，彈性大，接近 Agile 流程；而大規模的循環則需謹慎規劃與執行，接近 Waterfall 流程。也就是說，PDCA流程循環，才是建築領域架構時的主要核心交易物件。

此外，有人認為架構設計僅僅是 IT 系統設計的範疇，關注點側重於硬體、軟體環境與作業系統，這應該算是一種迷思。雖然執行環境的考量確實重要，但若僅限於此面相，可能有失偏頗。架構需選擇最合宜的面相，找出關鍵核心物件，並選擇妥當的拓樸方式予以連結。那麼，設計應用軟體的系統架構是否需要先深入掌握領域知識？我的回答是肯定的。深度理解領域知識絕對必要，並運用邏輯與歸納推理進行簡化，以實現簡約之美。

專案管理的範疇廣泛，本文僅能觸及一二。本文的目的在於藉由一個熟悉的題材，探討架構師思考時的潛在盲點，並提出適合的模式與常見的反模式 (Patterns and Anti-Patterns)，希望能對資深軟體設計者有所啟發。